Introduction
In this new article we discuss about ReplicaSets.
What is a ReplicaSet ?
A ReplicaSet’s purpose is basically to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.
For example, if we only have a single POD in our application and this one fails, our users won’t be able to access our application. To prevent this scenario, we would like to have one more instance than one POD. In this case, if one fails, we still our application running on the other one.
ReplicaSets (previously known as ReplicationControllers) provides Hight Availability :
The ReplicaSet ensures that the number of PODs specified in your configuration are running at all time !
Another reason to use ReplicaSet is to share the load of an application on multiple PODs. Indeed, it is easy with ReplicaSet to scale your infrastructure.
How to create a ReplicaSet
Using a configuration YAML file
As usual, we create the following YAML File with the following mandatory parts :
apiVersion: kind: metadata: spec:
In our example, we will create a Replication with 3 replicas, which is called “frontend” and which will use the image “gcr.io/google_samples/gb-frontend:v3”.
So let’s begin with these 4 sections.
- The api version in our case is “apps/v1”. (You can see that’s different from our previous lecture with PODs)
- The kind will be ReplicaSet, for obvious reasons
- Metadata will contain the name and labels.
- Finally, the “spec” is the most important part of our YAML file. It will be composed by the number of replicas AND by a POD template. It will be exactly the same as you would have used to create a single POD.
Here is our final YAML file called myreplicaset.yaml :
apiVersion: apps/v1 kind: ReplicaSet metadata: name: frontend labels: app: guestbook tier: frontend spec: # modify replicas according to your case replicas: 3 selector: matchLabels: tier: frontend template: metadata: labels: tier: frontend spec: containers: - name: php-redis image: gcr.io/google_samples/gb-frontend:v3
We can now deploy our ReplicaSet running the following command :
$ kubectl create -f myreplicaset.yaml replicaset.apps/frontend created
And that’s all !
You can get more information on your Replicaset running the following command :
kubectl describe replicasets frontend
How to scale you ReplicaSet
There are basically two ways to scale your ReplicaSet :
- Using the kubectl scale command :
$ kubectl get pods NAME READY STATUS RESTARTS AGE frontend-22t8d 0/1 ContainerCreating 0 2s frontend-6fq9g 1/1 Running 0 3m36s frontend-fr468 1/1 Running 0 3m36s $ kubectl scale replicaset frontend --replicas=2 replicaset.extensions/frontend scaled $ kubectl get pods NAME READY STATUS RESTARTS AGE frontend-6fq9g 1/1 Running 0 3m3s frontend-fr468 1/1 Running 0 3m3s
- Modify your configuration file and apply the changes with “kubectl apply -f myreplication.yaml” command :
$ vi myreplicaset.yaml $ kubectl apply -f myreplicaset.yaml replicaset.apps/frontend configured $ kubectl get pods NAME READY STATUS RESTARTS AGE frontend-22t8d 1/1 Running 0 109s frontend-6fq9g 1/1 Running 0 5m23s frontend-fcpm7 1/1 Running 0 24s frontend-fr468 1/1 Running 0 5m23s
Conclusion
In the next lecture, we will see together Deployments. A ReplicaSet ensures that a specified number of pod replicas are running at any given time. However, a Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to Pods along with a lot of other useful features. Therefore, Kubernetes recommends using Deployments instead of directly using ReplicaSets, unless you require custom update orchestration or don’t require updates at all.
Sources
kubernetes.io
