LeaderWorkerSet API

Number of leader-workers groups. A scale subresource is available to enable HPA. The selector for HPA will be that of the leader pod, and so practically HPA will be looking up the leader pod metrics. Note that the leader pod could aggregate metrics from the rest of the group and expose them as a summary custom metric representing the whole group. On scale down, the leader pod as well as the workers statefulset will be deleted. Default to 1.

LeaderWorkerTemplate defines the template for leader/worker pods

RolloutStrategy defines the strategy that will be applied to update replicas when a revision is made to the leaderWorkerTemplate.

StartupPolicy determines the startup policy for the worker statefulset.

NetworkConfig defines the network configuration of the group

Conditions track the condition of the leaderworkerset.

ReadyReplicas track the number of groups that are in ready state (updated or not).

UpdatedReplicas track the number of groups that have been updated (ready or not).

Replicas track the total number of groups that have been created (updated or not, ready or not)

HPAPodSelector for pods that belong to the LeaderWorkerSet object, this is needed for HPA to know what pods belong to the LeaderWorkerSet object. Here we only select the leader pods.

LeaderTemplate defines the pod template for leader pods.

WorkerTemplate defines the pod template for worker pods.

Number of pods to create. It is the total number of pods in each group. The minimum is 1 which represent the leader. When set to 1, the leader pod is created for each group as well as a 0-replica StatefulSet for the workers. Default to 1.

RestartPolicy defines the restart policy when pod failures happen. The former named Default policy is deprecated, will be removed in the future, replace with None policy for the same behavior.

SubGroupPolicy describes the policy that will be applied when creating subgroups in each replica.

SubdomainPolicy determines the policy that will be used when creating the headless service, defaults to shared

The maximum number of replicas that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of total replicas at the start of update (ex: 10%). Absolute number is calculated from percentage by rounding down. This can not be 0 if MaxSurge is 0. By default, a fixed value of 1 is used. Example: when this is set to 30%, the old replicas can be scaled down by 30% immediately when the rolling update starts. Once new replicas are ready, old replicas can be scaled down further, followed by scaling up the new replicas, ensuring that at least 70% of original number of replicas are available at all times during the update.

The maximum number of replicas that can be scheduled above the original number of replicas. Value can be an absolute number (ex: 5) or a percentage of total replicas at the start of the update (ex: 10%). Absolute number is calculated from percentage by rounding up. By default, a value of 0 is used. Example: when this is set to 30%, the new replicas can be scaled up by 30% immediately when the rolling update starts. Once old replicas have been deleted, new replicas can be scaled up further, ensuring that total number of replicas running at any time during the update is at most 130% of original replicas. When rolling update completes, replicas will fall back to the original replicas.

Type defines the rollout strategy, it can only be “RollingUpdate” for now.

RollingUpdateConfiguration defines the parameters to be used when type is RollingUpdateStrategyType.

The number of pods per subgroup. This value is immutable, and must not be greater than LeaderWorkerSet.Spec.Size. Size must be divisible by subGroupSize in which case the subgroups will be of equal size. Or size - 1 is divisible by subGroupSize, in which case the leader is considered as the extra pod, and will be part of the first subgroup.