DAY 7 : ReplicaSet

DAY 7 : ReplicaSet

A Replica Set's purpose is to maintain a stable set of replica Pods running at any given time.

It is responsible for monitoring the health of the modules it manages and ensuring that the required number of replicas are always running, thus providing self-healing capabilities. ReplicaSet automatically detect and recover from module failures by creating new replicas to replace the failed ones, ensuring that the desired state of the application is maintained. With their self-healing feature, ReplicaSet contribute to the overall resilience and high availability of applications in Kubernetes clusters.

A Kubernetes RS helps with load-balancing, reliability, and scaling, as follows:

Load balancing: Replication allows Kubernetes to have multiple instances of a pod. This means that traffic is sent to different instances, which prevents a single instance from being overloaded.

Reliability: Replication ensures that we have multiple instances of an application, which means that it won’t fail just because one of the containers fails.

Scaling: With Kubernetes, you can quickly scale your application up or down by adding or removing instances.

Working with ReplicaSets

Step 1: Create a YAML file that defines the ReplicaSet. This file should include the number of replicas you want, the container image to use, and any other desired properties such as environment variables or resource limits.

To create the ReplicaSet, you can use the kubectl create command and pass it to the YAML file as an argument:

$ kubectl create -f replicaset.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: <RSName>
spec:
  replicas: <noOfPODReplicas>
  selector:  # To Match POD Labels.
    matchLabels:  # Equality Based Selector
      <key>: <value>
    matchExpressions:  # Set Based Selector 
    - key: <key>
      operator: <in/not in>
      values:
      - <value1>
      - <value2>
  template:
    metadata:
      name: <PODName>
      labels:
    <key>: <value>
    spec:
    - containers:
      - name: <nameOfTheContainer>
    image: <imageName>
        ports:
    - containerPort: <containerPort>$ kubectl create -f replicaset.yaml apiVersion: apps/v1 kind: ReplicaSet metadata: name: spec: replicas: selector: # To Match POD Labels. matchLabels: # Equality Based Selector : matchExpressions: # Set Based Selector - key: operator: <in/not in> values: - - template: metadata: name: labels: : spec: - containers: - name: image: ports: - containerPort: Writing a ReplicaSet manifest The apiVersion field specifies the version of the Kubernetes API that the object is using. The kind field specifies the type of object that this file represents. In this case, it is a ReplicaSet. The metadata field contains metadata about the ReplicaSet, such as its name. The spec field contains the specification for the ReplicaSet. It includes the following fields: replicas: the number of replicas of the pod that should be running at any given time selector: a label query that determines which pods should be managed by the ReplicaSet template: the pod template that will be used to create new pods when the ReplicaSet needs to scale up or down. The template field contains the following fields: metadata: metadata for the pod spec: the specification for the pod. The spec field for the pod includes a containers field, which specifies the containers that should be run in the pod. In this case, there is a single container named my-app that is based on the my-app: latest image and exposes port 80. Step 2: Create a ReplicaSet using the configuration in replicaset.yaml

Writing a ReplicaSet manifest

  • The apiVersion filed specifies the version of the Kubernetes API that the object is using.

  • The kind field specifies the type of object that this file represents. In this case, it is a ReplicaSet.

  • The metadata field contains metadata about the ReplicaSet , such as its name.

  • The spec field contains the specification for the ReplicaSet. It includes the following fields:

    • replicas: The number of replicas of the pod that should be running at any given time

    • selector: A label query that determines which pods should be managed by the ReplicaSet

  • template: The pod template that will be used to create new pods when the ReplicaSet needs to scale up or down. The template field contains the following fields:

    • metadata: metadata for the pod

    • spec: the specification for the pod. The spec filed for the pod includes a containers field, which specifies the containers that should be run in the pod. In this case, there is a single container named my-app that is based on the my-app: latest image and exposes port 80.

Step 2: Create a ReplicaSet using the configuration in replicaset.yaml

$ kubectl create -f 
gmemegen_deployment.yaml

Step 3: Verify that the ReplicaSet was created

$ kubectl get replicasets

Deleting pods in ReplicaSet

$ kubectl delete pods <pod-name>

Deleting ReplicaSet

$ kubectl delete rs <rs name?>

Scaling a ReplicaSet

  1. Manually by using the command.

  2. ReplicaSet as a Horizontal Pod Autoscaler Target.

We can scale the replicaset manually by changing the no. of replicas needed by using the following command.

kubectl scale rs <name of replicaset> --replicas=5

ReplicaSet as a Horizontal Pod Autoscaler Target

Scaling of replicaset can also be done by using a resource called horizontal pod autoscaler. The pods will scale automatically when the threshold value of the pod CPU will reach the maximum value as mentioned in the manifest file it depends on our requirement based on the incoming traffic.

Difference Between ReplicaSets and Deployments

ReplicaSetDeployments
ReplicaSet will ensure that the desired no. of pods are matching the specified no. of pods as mentioned in the yaml file.Deployment is an advanced replication set that will manage the lifecycle of pods.
ReplicaSet is not suitable for applications that are going to have rolling updates and rollbacks.Deployment supports the rolling update and rollbacks.
Internally replicaset will take care of pods and pods will take care of containers.Internally deployment is going to take care of the replicaset and replicaset will take care of the pod.