Kubectl Rollout Restart for Statefulset - Kubernetes

Stateful applications are managed via Kubernetes StatefulSets, a particular workload API object. They offer guarantees concerning the ordering and uniqueness of pods, in contrast to deployments. Applications like databases and distributed systems, which need trustworthy, unique network IDs and long-term storage, rely upon stateful sets.

They guarantee that every pod receives a distinct, accurate identification and storage, maintaining consistency even in the event of restarts. Due to this, StatefulSets are essential for applications that need consistent state and data integrity. All in all, they make it easier to manage stateful applications in a dynamic container environment like Kubernetes.

What are Kubernetes StatefulSets?

Kubernetes Statefulsets are the resource types in Kubernetes that manages the deployments and scaling of stateful applications. It ensures each pod maintains a unique stable identity and persistent storage. It is ideal for applications like databases or distributed systems that requires network identites and stable storage.

Step By Step to Restart Stateful set in Kubernetes

Create stateful set

Step 1: Here is my statefulset in my Kubernetes cluster list the statefulset in the kubernetes cluster using the below command.

kubectl get statefulset

Step 2: List the all resources in the kubernetes cluster by using the below command.

kubectl get all

Step 3: Here is my statefulset manifest file in the kubernetes cluster.

cat statefulset.yaml

• The statefulset yaml code that we used here, has been provided as follows:

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx  # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 1  # by default is 1
  minReadySeconds: 10  # by default is 0
  template:
    metadata:
      labels:
        app: nginx  # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: "my-storage-class"
      resources:
        requests:
          storage: 1Gi

Service Definition

The following discuss on the definition lines of Kubernetes resource type Service:

• apiVersion: v1: Specifies the API version of the Kubernetes resource.
• kind: Service: Declares that this resource is a Service.
• metadata: Provides metadata about the Service.
• name: nginx: Names the Service "nginx".
• labels: Associates labels with the Service.
• app: nginx: Labels the Service with app:nginx.
• spec: Defines the desired state of the Service.
• ports: Lists the ports exposed by the Service.
• port: 80: Exposes port 80.
• name: web: Names this port "web".
• clusterIP: None: Specifies that this Service is a headless service, meaning it doesn't have a cluster IP.
• selector: Defines how to select the pods targeted by this Service.
• app: nginx: Selects pods with the label app: nginx.

StatefulSet Definition

• apiVersion: apps/v1: Specifies the API version of the Kubernetes resource.
• kind: StatefulSet: Declares that this resource is a StatefulSet.
• metadata: Provides metadata about the StatefulSet.
• name: web: Names the StatefulSet "web".
• spec: Defines the desired state of the StatefulSet.
• selector: Specifies how to select the pods managed by this StatefulSet.
• matchLabels: The labels used to match pods.
• app: nginx: Matches pods with the label app: nginx.
• serviceName: "nginx": The name of the headless Service used by the StatefulSet.
• replicas: 1: Specifies the number of pod replicas (default is 1).
• minReadySeconds: 10: Specifies the minimum number of seconds for which a newly created pod should be ready without any of its containers crashing, for it to be considered available (default is 0).
• template: Defines the pod template for the StatefulSet.
• metadata: Provides metadata about the pod template.
• labels: Labels for the pod template.
• app: nginx: Labels the pods with app: nginx (must match .spec.selector.matchLabels).
• spec: Defines the pod specification.
• terminationGracePeriodSeconds: 10: The amount of time given to the pod to terminate gracefully before it is killed.
• containers: Lists the containers in the pod.
• name: nginx: Names the container "nginx".
• image: registry.k8s.io/nginx-slim:0.8: Specifies the container image.
• ports: Defines the ports exposed by the container.
• containerPort: 80: Exposes container port 80.
• name: web: Names this port "web".
• volumeMounts: Lists the volumes to be mounted into the container.
• name: www: Refers to the volume named "www".
• mountPath: /usr/share/nginx/html: Mounts the volume at /usr/share/nginx/html.
• volumeClaimTemplates: Defines a template for PersistentVolumeClaims.
• metadata: Provides metadata about the PVC template.
• name: www: Names the PVC "www".
• spec: Defines the specification of the PVC.
• accessModes: ["ReadWriteOnce"]: Specifies that the volume can be mounted as read-write by a single node.
• storageClassName: "my-storage-class": Specifies the storage class to use.
• resources: Requests storage resources.
• requests: It used for specifying the requests.
• storage: 1Gi: Requests 1Gi of storage.

Step 4: List the persistent volume and persistent volume clam using the below command.

kubectl get pv
kubectl get pvc

Step 5: List the storage class in the kuberentes cluster by using the below command.

kubectl get sc

Step 6: Here is the our persistent volume manifest file in the kuberenetes.

• The pv.yaml (Persistant Volume) manefist file that we used here, has been provided as follows:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-1
spec:
  capacity:
    storage: 1Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: my-storage-class
  hostPath:
    path: /opt

The above code is detailed here as follows:

• apiVersion specifies the version of the Kubernetes API that you’re using to create this resource. v1 is the stable version for core resources like PersistentVolumes.
• kind indicates the type of Kubernetes resource. Here, it’s a PersistentVolume, which is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using a StorageClass.
• metadata is used to provide identifying information about the resource.
• name: pv-1 is the unique name of this PersistentVolume. This name is used to reference the PV within the cluster.
• spec contains the specification of the desired behavior of the PV.
• capacity: Specifies the storage capacity of the PV.
• storage: 1Gi indicates that the volume has a capacity of 1 Gibibyte.
• volumeMode specifies the mode of the volume.
• Filesystem: The volume is formatted as a filesystem. Another possible value is Block, which would indicate a raw block device.
• accessModes specifies the ways in which the volume can be accessed by pods.
• ReadWriteOnce: The volume can be mounted as read-write by a single node. Other possible values are ReadOnlyMany (can be mounted as read-only by many nodes) and ReadWriteMany (can be mounted as read-write by many nodes).
• persistentVolumeReclaimPolicy defines what happens to the PV when the PVC that bound it is deleted.
• Retain: The volume is retained and needs to be manually cleaned up by the administrator. Other possible values are Delete (the volume is deleted) and Recycle (the volume is scrubbed and made available again).
• storageClassName indicates the StorageClass to which this PV belongs. This is used for dynamic provisioning and helps Kubernetes understand how to provision the storage. my-storage-class should match a StorageClass defined in your cluster.
• hostPath specifies the path on the host node's filesystem to expose to the pod.
• path: /opt indicates the directory on the host that is mounted into the pod. hostPath volumes are useful for development and testing on a single-node cluster but are not recommended for production due to lack of portability and data durability.

Step 7: Here is my storage class manifestfile in the kubernetes cluster.

• The above discussing storageclass.yaml manefist file has been provided as follows:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-storage-class
provisioner: my-storage-provider
parameters:
  type: fast

The above storageclass.yaml file is discussed in details as follows:

• The type type Kubernetes object that is produced is given in the kind assets. It's a StorageClass in this particular instance of storage.
• The API version which was used to build this object can be seen in the apiVersion characteristic. The StorageClass resource's API version is storage.k8s.io/v1.
• This section contains metadata about the StorageClass object, such as its name.
• This specifies the name of the StorageClass. It is a unique identifier within the cluster for this particular storage class. In this case, the storage class is named my-storage-class.
• The provisioner field specifies the type of provisioner to use for dynamically provisioning volumes. The provisioner is responsible for creating and managing the actual storage resource in the underlying infrastructure.
• This is a placeholder for the actual provisioner name. In a real scenario, this would be something like kubernetes.io/aws-ebs for AWS Elastic Block Store, kubernetes.io/gce-pd for Google Compute Engine Persistent Disk, or another specific provisioner name depending on the cloud provider or storage solution.
• This section contains parameters that are specific to the provisioner. These parameters define the characteristics of the storage that will be provisioned.
• This is an example of a parameter that the provisioner can employ to indicate the type of storage. Type's meaning differs based on the provider. It might refer to a specific type of disk that has low latency or a high IOPS (Input/Output Operations Per Second).

Method 1: Delete StatefulSet Pods Individually

• Delete each pod one by one.

kubectl delete pod web-0
kubectl delete pod web-1 ...etc

Method 2: Delete the Entire StatefulSet

• Delete the StatefulSet

kubectl delete statefulset <statefulset-name>

• Optionally, if you want the StatefulSet to be recreated immediately, you can recreate it using the same YAML definition:

kubectl apply -f <statefulset-manifestfile-name>

• For instance, you can restart a StatefulSet termed nginx by removing each of its pods one at a time. The StatefulSet nginx will list every pod which has been handled by this command.
• Following that, you may remove every pod by themselves: