Skip to content

Latest commit

 

History

History
17 lines (13 loc) · 2.6 KB

V1beta1StatefulSetSpec.md

File metadata and controls

17 lines (13 loc) · 2.6 KB

V1beta1StatefulSetSpec

Properties

Name Type Description Notes
PodManagementPolicy string podManagementPolicy controls how pods are created during initial scale up, when replacing pods on nodes, or when scaling down. The default policy is `OrderedReady`, where pods are created in increasing order (pod-0, then pod-1, etc) and the controller will wait until each pod is ready before continuing. When scaling down, the pods are removed in the opposite order. The alternative policy is `Parallel` which will create pods in parallel to match the desired scale without waiting, and on scale down will delete all pods at once. [optional]
Replicas int32 replicas is the desired number of replicas of the given Template. These are replicas in the sense that they are instantiations of the same Template, but individual replicas also have a consistent identity. If unspecified, defaults to 1. [optional]
RevisionHistoryLimit int32 revisionHistoryLimit is the maximum number of revisions that will be maintained in the StatefulSet's revision history. The revision history consists of all revisions not represented by a currently applied StatefulSetSpec version. The default value is 10. [optional]
Selector V1LabelSelector [optional]
ServiceName string serviceName is the name of the service that governs this StatefulSet. This service must exist before the StatefulSet, and is responsible for the network identity of the set. Pods get DNS/hostnames that follow the pattern: pod-specific-string.serviceName.default.svc.cluster.local where "pod-specific-string" is managed by the StatefulSet controller.
Template V1PodTemplateSpec
UpdateStrategy V1beta1StatefulSetUpdateStrategy [optional]
VolumeClaimTemplates []V1PersistentVolumeClaim volumeClaimTemplates is a list of claims that pods are allowed to reference. The StatefulSet controller is responsible for mapping network identities to claims in a way that maintains the identity of a pod. Every claim in this list must have at least one matching (by name) volumeMount in one container in the template. A claim in this list takes precedence over any volumes in the template, with the same name. [optional]

[Back to Model list] [Back to API list] [Back to README]