• Home
  • Docker
  • Kubernetes
  • Java
  • Ubuntu
  • Maven
  • Big Data
  • CI
  • Install
  • Samples
  • Archived
Kubernetes | StatefulSets (statefulsets|sts)
  1. Notes
  2. StatefulSets (statefulsets|sts)
  3. Pods' Names
  4. Pods' Hostnames
  5. Headless Services
  6. Pods' Volumes
  7. Pods Creation/Deletion
  8. Rolling Updates
  9. Example of a StatefulSet
  10. DNS Resolution
  11. Delete StatefulSets

  1. Notes
    Please visit these pages for more details about StatefulSets:
    https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/
    https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/
    https://kubernetes.io/docs/concepts/security/controlling-access/
    https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/
  2. StatefulSets (statefulsets|sts)
    StatefulSets allow deploying Pods that require unique names, hostnames, and volumes.

    Once a Pod of a StatefulSet is deployed, its name, hostname, and volumes will last for the lifetime of the StatefulSet.

    Unlike a Deployment, a StatefulSet maintains a sticky identity for each of its Pods.

    If a Pod get restarted (including failures) or rescheduled (including when it's deployed on a new node), it will still keep the same information (name, hostname, volumes).

    If the StatefulSet get scaled down (Pods terminated) and then scaled up (new Pods), the new Pods will get back the same state as the old Pods.

    To create/deploy a StatefulSet, you need first to create a manifest YAML file. The manifest file describe the StatefulSet and its components (name, Pods, ...). You can use "kubectl" (or any rest client tool) to post the manifest file to the API server If applicable, the API server verifies that the request is authenticated, validates it's authorized, and runs the admission controllers on it. The API server verifies the manifest file and, if no issues, it writes a record for that manifest in the cluster store (etcd). The scheduler will then read the record and deploy the Pod of the StatefulSet to a healthy worker node with enough available resources.

    The same behaviour, described above, applies if you use the imperative command ("kubectl create") to create the StatefulSet.

    A StatefulSet run as a control loop that watches the state of the cluster through the API Server and if it notices that the current state is different from the desired state defined for the StatefulSet, it will tries to get the current state aligned with the desired state. For example, if a Pod get terminated, a new one will be created (with same name and hostname and attached to the same volume).
  3. Pods' Names
    Each Pod of the StatefulSet will get a unique name.

    The name is constructed from the StatefulSet's name and the Pod's ordinal: <StatefulSet-Name>-<Pod-Ordinal>

    The Pod's ordinal is an integer number that starts from 0.

    The first Pod to be created for the StatefulSet will get the ordinal 0, the second Pod 1, the third Pod 2, ...

    For example, if a StatefulSet has the name "nginx" and defines 3 replicas, then the Pods will have the following names: "nginx-0", "nginx-1", "nginx-1".
  4. Pods' Hostnames
    Each Pod of the StatefulSet will get a unique hostname.

    The name is constructed from the StatefulSet's name and the Pod's ordinal: <StatefulSet-Name>-<Pod-Ordinal>

    The Pod's ordinal is an integer number that starts from 0.

    The first Pod to be created for the StatefulSet will get the ordinal 0, the second Pod 1, the third Pod 2, ...

    For example, if a StatefulSet has the name "nginx" and defines 3 replicas, then the Pods will have the following hostnames: "nginx-0", "nginx-1", "nginx-1".
  5. Headless Services
    A Kubernetes Service has a stable IP address/DNS name that are exposed on the network. It maintains the list of Pods associated with it and to which it will route requests.

    A headless Service is a regular Service without a ClusterIP (the "spec.clusterIP" set to "none).
    The headless Service must be listed in the "spec.serviceName" field of the StaefulSet.
    The Pods, that match the StatefulSet's label selector, will have unique DNS hostnames that allow applications to request directly a Pod.
    A DNS SRV record will be created for each Pod that matches the label selectors of the headless Service.
    A DNS query, using the name of the headless Service, allows retrieving the list of the Pods associated to the headless Service.
  6. Pods' Volumes
    Each Pod of the StatefulSet will get its own volume created at the same time when the Pod is created.

    StatefulSets use Volume Claim Templates to provision dynamically volumes. A Persistent Volume Claim is created for each Pod.

    The name is constructed from the Volume Template Claim name, the StatefulSet's name and the Pod's ordinal:
    <VolumeClaimTemplate-Name>-<StatefulSet-Name>-<Pod-Ordinal>
    or: <VolumeClaimTemplate-Name>-<Pod-Name>

    The Pod's ordinal is an integer number that starts from 0.

    The first Pod to be created for the StatefulSet will get the ordinal 0, the second Pod 1, the third Pod 2, ...

    For example, if a StatefulSet has the name "nginx" and defines Volume Template Claim with the name "pv-data", and defines 3 replicas, then the Pods will have the following hostnames:
    "pv-data-nginx-0", "pv-data-nginx-1", "pv-data-nginx-1".

    The volumes won't be deleted if you delete the Pods or the StatefulSet.
    If you scale down and scale up again the StatefulSet, any existing volumes will be associated to the new Pods based on their names.

    Once you are done with a StatefulSet, you can delete the volume manually.
  7. Pods Creation/Deletion
    StatefulSets provides two means to control how their Pods are created and deleted.

    The "spec.podManagementPolicy" field accept two values: OrderedReady (default), Parallel.
    The OrderedReady setting allows an ordered creation and deletion of the Pods of a StatefulSet.
    The Parallel setting allows a parallel creation and deletion of the Pods of a StatefulSet (still the Pods preserve their uniqueness and identity guarantees).

    Unlike Deployments that delegate the scaling and self healing of Pods to the ReplicaSets controllers (which allow creating Pods in parallel), StatefulSets manage directly the Pods' creation and deletion.

    • OrderedReady:
      When deploying a StatefulSet, the Pods will be created in order and each Pod must be running and ready before the next one can be created. If a Pod fails to start, it will be retried again and the next Pods won't be created if the failure is not fixed.

      The same apply when scaling up the StatefulSet, new Pods will be created in order and each new Pod must be running and ready before the next one can be created.

      When deleting a StatefulSet, the Pods will be terminated in a reverse order. The Pod with the highest ordinal will be terminated first and each Pod must be completely terminated before the next one can be terminated. If a Pod fails to terminate, it will be retried again and the next Pods won't be terminated if the failure is not fixed.

      The same apply when scaling down the StatefulSet, Pods with the highest ordinal will be terminated first and each Pod must be completely terminated before the next one can be terminated.

      The "spec.template.spec.terminationGracePeriodSeconds" field allows configuring a grace period to ensure that Pods are terminated gracefully, before forcing the termination in case the Pods was not terminated by then.

    • Parallel:
      This allow StatefulSets to create and terminate pods in parallel.
      This settings does not apply when rolling updates.
  8. Rolling Updates
    When performing rolling updates, the Pods will be updated in a reverse order. The Pod with the highest ordinal will be updated first and each Pod must be running and ready before the next one can be updated. If a Pod fails to get updated, it will be retried again and the next Pods won't be updated if the failure is not fixed.
  9. Example of a StatefulSet
    Let's define a simple StatefulSet to deploy nginx "hello-nginx-statefulset":

    If you are using Kubernetes on Docker Desktop, you will need to adjust the volumeClaimTemplates section as following:

    If you are using Kubernetes on Docker Desktop, you also need to define a Persistent Volume (hostPath) for each Pod replica.
    For more details, see Volumes.

    Let's define the headless Service:

    Let's create the Persistent Volumes (again this is needed only for Kubernetes on Docker Desktop):

    View the Persistent Volumes (the STATUS is Available):

    Let's create the StatefulSet:

    Check the Pods creation:

    Check the Persistent Volume Claims:

    Check again the Persistent Volumes (the STATUS should be Bound now):

    Let's create the headless Service:

    Check the headless Service:
  10. DNS Resolution
    Please see more details about Kubernetes DNS Service (and dnsutils utility) in this page: Kubernetes Cluster

    Please see more details about Kubernetes Services in this page: Services (services|svc)

    Let's check the headless Service:

    The previous provided the IP addresses of the Pods of the StatefullSet.

    Let's resolve the fully qualified DNS names of the Pods:


    Kubernetes constructs DNS sub-domains as follow: <POD-NAME>.<HEADLESS-SERVICE-NAME>.<NAMESPACE>.svc.cluster.local

    The pods of the StatefulSet, as shown above, have the following fully qualified DNS names:
    nginx-0.nginx.default.svc.cluster.local
    nginx-1.nginx.default.svc.cluster.local
  11. Delete StatefulSets
    To delete a StatefulSet using its manifest file:

    To delete a StatefulSet using its name:

    When deleting the StatefulSet, all Pods will be terminated in parallel.

    If you need that the Pods get deleted in order, then you need first to scale down the StatefulSet to 0 replicas and then delete it.

    Scale down the StatefulSet to 0 replicas:

    Check that the StatefulSet has no replicas before deleting the StatefulSet:
© 2025  mtitek