OpenKruise

website·Indexed 34 days ago

https://openkruise.io/

An extended component suite for Kubernetes focused on automating application management. It includes OpenKruiseGame (OKG) for cloud-native game server management on Kubernetes, Kruise Rollouts for progressive delivery (canary, blue-green, and A/B testing), and specialized controllers like CloneSet, AdvancedStatefulSet, and GameServerSet.

Tokens
332.6K
Snippets
1.3K
Records
1.9K
Agent score
68%

What's inside OpenKruise

  1. Overview of OpenKruise BroadcastJob

    A BroadcastJob distributes a Pod on every node in the cluster. It combines the behavior of a DaemonSet (ensuring a Pod runs on all selected nodes) and a Job (expecting the Pods to run to completion). It is typically used for software upgrades (e.g., Kubelet) or cluster-wide validation checks. By default, it consumes no resources after all Pods succeed, but it can be configured to stay alive to handle new nodes added to the cluster.
  2. Overview of on-demand volume mounting in KruiseAgents

    On-demand volume mounting allows developers to declare one or more existing Persistent Volumes (PVs) to be mounted into a sandbox at the time of claiming. This is an alternative to provisioning a new PVC per sandbox via volumeClaimTemplates.

    Key characteristics:

    • The PV must already exist in the cluster before the claim is made.
    • A single PV can be mounted into multiple sandboxes (e.g., for shared datasets or model caches).
    • Mounts are orchestrated by agent-runtime and CSI sidecars injected into the sandbox Pod.
    • Supported for sandboxes claimed from warm pools, created on no stock, and in-place image upgrades.
    • Limitation: Mounts are not restored when a sandbox is recovered from a checkpoint.
  3. Overview of UnitedDeployment for multi-domain pod management

    UnitedDeployment is a controller designed to manage pods across multiple domains in a Kubernetes cluster. It represents different domains as groups of nodes identified by labels and provisions a specific workload (a 'subset') for each group using a matching NodeSelector. This ensures pods are scheduled to the target domain. Currently, it supports StatefulSet, Advanced StatefulSet, CloneSet, and Deployment as workload types.
    apiVersion: apps.kruise.io/v1alpha1
    kind: UnitedDeployment
    metadata:
      name: sample-ud
    spec:
      replicas: 6
      selector:
        matchLabels:
          app: sample
      template:
        statefulSetTemplate:
          metadata:
            labels:
              app: sample
          spec:
            selector:
              matchLabels:
                app: sample
            template:
              metadata:
                labels:
                  app: sample
              spec:
                containers:
                - image: nginx:alpine
                  name: nginx
      topology:
        subsets:
        - name: subset-a
          nodeSelectorTerm:
            matchExpressions:
            - key: node
              operator: In
              values:
              - zone-a
          replicas: 1
        - name: subset-b
          nodeSelectorTerm:
            matchExpressions:
            - key: node
              operator: In
              values:
              - zone-b
          replicas: 50%
        - name: subset-c
          nodeSelectorTerm:
            matchExpressions:
            - key: node
              operator: In
              values:
              - zone-c
  4. Overview of PersistentPodState (PPS)

    v1.8
    PersistentPodState (PPS) is a Kruise feature designed to persist Pod states that standard Kubernetes StatefulSets do not cover, such as Pod IP retention and priority scheduling to previously deployed nodes. This is critical for services sensitive to IP changes (e.g., discovery middleware) or services using host-local disks where moving to a different node would result in data loss.
  5. Overview of WorkloadSpread for multi-domain elastic scheduling

    WorkloadSpread is a multi-domain CRD introduced in OpenKruise v0.10.0 that allows a Workload to distribute Pods across different nodes, zones, clusters, and providers. It enables differential configurations across these domains, providing capabilities for multi-domain scattering, elastic scheduling, and fine-grained management in a non-intrusive manner.
  6. Overview of OpenKruise BroadcastJob

    v1.8
    A BroadcastJob distributes a Pod on every node in the cluster. It combines the behavior of a DaemonSet (ensuring a Pod runs on all selected nodes) and a Job (expecting the Pods to run to completion). It is ideal for one-time tasks across a cluster, such as software upgrades (e.g., Kubelet) or ad-hoc cluster inspection scripts. By default, it consumes no resources after all Pods succeed, though it can be configured to stay alive to handle newly added nodes.
  7. Overview of AdvancedCronJob

    AdvancedCronJob is an enhanced version of the standard Kubernetes CronJob. While a standard CronJob only creates Jobs, AdvancedCronJob supports multiple job resource templates, allowing users to periodically trigger BroadcastJobs (for node-wide execution) or ImageListPullJobs (for periodic image pre-pulling). It is available in v1beta1 and v1alpha1 versions starting from Kruise v1.9.0.
    apiVersion: apps.kruise.io/v1beta1
    kind: AdvancedCronJob
    spec:
      template:
        # Choose one of the following:
        jobTemplate: { ... }
        broadcastJobTemplate: { ... }
        imageListPullJobTemplate: { ... }
  8. Overview of OpenKruise Advanced Workloads

    OpenKruise provides a suite of advanced workloads including CloneSet, Advanced StatefulSet, Advanced DaemonSet, BroadcastJob, SidecarSet, and UnitedDeployment. These workloads enable advanced capabilities such as configurable scale/upgrade strategies, parallel operations, and in-place updates. In-place updates allow updating container images or environments by restarting only the specific container without recreating the Pod, reducing the impact on the scheduler, CNI, and CSI.
  9. Overview of OpenClaw on OpenKruise Agents

    OpenClaw is an open-source AI programming assistant gateway providing unified LLM access, tool invocation, and code execution. When deployed via OpenKruise Agents, it provides each user with an independent, data-persistent sandbox environment. Data persistence is achieved using volumeClaimTemplates to ensure user configuration files and working data are preserved across sandbox recreations.
  10. Overview of OpenKruise BroadcastJob

    v1.7
    A BroadcastJob distributes a Pod on every node in the cluster. It combines the behavior of a DaemonSet (ensuring a Pod runs on all selected nodes) and a Job (expected to run to completion). It is ideal for tasks like software upgrades (e.g., Kubelet), cluster-wide validation checks, or ad-hoc inspection scripts. Once all Pods succeed, the BroadcastJob typically stops consuming resources, unless configured to stay alive to handle new nodes added to the cluster.
  11. Overview of OpenKruise WorkloadSpread

    WorkloadSpread (introduced in v0.10.0) is a non-invasive, "plug and play" feature that distributes pods of a workload to different types of nodes according to defined rules. It supports multiple workload types, including Deployment, ReplicaSet, Job, and CloneSet. Unlike Pod Topology Spread Constraints, it supports exact customized partition numbers and proportions and maintains these distributions during scale-down events. Unlike UnitedDeployment, it is a lightweight configuration that associates with existing workloads rather than requiring a new workload type.
  12. Overview of PodProbeMarker

    v1.8
    PodProbeMarker allows for customized probe semantics beyond standard Kubernetes Liveness, Readiness, and Startup probes. It is useful for scenarios such as determining if a GameServer is idle for cost optimization or identifying the role (main vs. secondary) of a Pod in a K8S Operator setup. The feature executes probes and can automatically update Pod labels, annotations, and status conditions based on the result.