Support MinReadySeconds on StatefulSet · Issue #65098 · kubernetes/kubernetes

Is this a BUG REPORT or FEATURE REQUEST?:

/kind feature

What happened:

Using a StatefulSet for memcached clusters would be a good choice, as stable hostnames will avoid unnecessary data reassignment during a deploy. In order to let cache hit rate stabilize before updating the next pod, I was looking for the MinReadySeconds option as available in Deployment, DaemonSet, and ReplicaSet. Unfortunatley it doesn't look like that option exists in StatefulSets.

What you expected to happen:

Have a MinReadySeconds option in Statefulset.

How to reproduce it (as minimally and precisely as possible):

kubernetes/staging/src/k8s.io/api/apps/v1/types.go

Lines 114 to 173 in 1a7a609

    
           // A StatefulSetSpec is the specification of a StatefulSet. 
        
           type StatefulSetSpec struct { 
        
           	// 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. 
        
           	// TODO: Consider a rename of this field. 
        
           	// +optional 
        
           	Replicas *int32 `json:"replicas,omitempty" protobuf:"varint,1,opt,name=replicas"` 
        
           	// selector is a label query over pods that should match the replica count. 
        
           	// It must match the pod template's labels. 
        
           	// More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors 
        
           	Selector *metav1.LabelSelector `json:"selector" protobuf:"bytes,2,opt,name=selector"` 
        
           	// template is the object that describes the pod that will be created if 
        
           	// insufficient replicas are detected. Each pod stamped out by the StatefulSet 
        
           	// will fulfill this Template, but have a unique identity from the rest 
        
           	// of the StatefulSet. 
        
           	Template v1.PodTemplateSpec `json:"template" protobuf:"bytes,3,opt,name=template"` 
        
           	// 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. 
        
           	// TODO: Define the behavior if a claim already exists with the same name. 
        
           	// +optional 
        
           	VolumeClaimTemplates []v1.PersistentVolumeClaim `json:"volumeClaimTemplates,omitempty" protobuf:"bytes,4,rep,name=volumeClaimTemplates"` 
        
           	// 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. 
        
           	ServiceName string `json:"serviceName" protobuf:"bytes,5,opt,name=serviceName"` 
        
           	// 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 
        
           	PodManagementPolicy PodManagementPolicyType `json:"podManagementPolicy,omitempty" protobuf:"bytes,6,opt,name=podManagementPolicy,casttype=PodManagementPolicyType"` 
        
           	// updateStrategy indicates the StatefulSetUpdateStrategy that will be 
        
           	// employed to update Pods in the StatefulSet when a revision is made to 
        
           	// Template. 
        
           	UpdateStrategy StatefulSetUpdateStrategy `json:"updateStrategy,omitempty" protobuf:"bytes,7,opt,name=updateStrategy"` 
        
           	// 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. 
        
           	RevisionHistoryLimit *int32 `json:"revisionHistoryLimit,omitempty" protobuf:"varint,8,opt,name=revisionHistoryLimit"` 
        
           }

Anything else we need to know?:

I'd be happy to contribute a patch, if you confirm the lack of MinReadySeconds on StatefulSets is not desired.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support MinReadySeconds on StatefulSet #65098

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	// A StatefulSetSpec is the specification of a StatefulSet.
	type StatefulSetSpec struct {
	// 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.
	// TODO: Consider a rename of this field.
	// +optional
	Replicas *int32 `json:"replicas,omitempty" protobuf:"varint,1,opt,name=replicas"`

	// selector is a label query over pods that should match the replica count.
	// It must match the pod template's labels.
	// More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors
	Selector *metav1.LabelSelector `json:"selector" protobuf:"bytes,2,opt,name=selector"`

	// template is the object that describes the pod that will be created if
	// insufficient replicas are detected. Each pod stamped out by the StatefulSet
	// will fulfill this Template, but have a unique identity from the rest
	// of the StatefulSet.
	Template v1.PodTemplateSpec `json:"template" protobuf:"bytes,3,opt,name=template"`

	// 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.
	// TODO: Define the behavior if a claim already exists with the same name.
	// +optional
	VolumeClaimTemplates []v1.PersistentVolumeClaim `json:"volumeClaimTemplates,omitempty" protobuf:"bytes,4,rep,name=volumeClaimTemplates"`

	// 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.
	ServiceName string `json:"serviceName" protobuf:"bytes,5,opt,name=serviceName"`

	// 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
	PodManagementPolicy PodManagementPolicyType `json:"podManagementPolicy,omitempty" protobuf:"bytes,6,opt,name=podManagementPolicy,casttype=PodManagementPolicyType"`

	// updateStrategy indicates the StatefulSetUpdateStrategy that will be
	// employed to update Pods in the StatefulSet when a revision is made to
	// Template.
	UpdateStrategy StatefulSetUpdateStrategy `json:"updateStrategy,omitempty" protobuf:"bytes,7,opt,name=updateStrategy"`

	// 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.
	RevisionHistoryLimit *int32 `json:"revisionHistoryLimit,omitempty" protobuf:"varint,8,opt,name=revisionHistoryLimit"`
	}