A ReplicaSet (RS) is a Kubernetes object that ensures there is always a stable set of running pods for a specific workload. The ReplicaSet configuration defines a number of identical pods required, and if a pod is evicted or fails, creates more pods to compensate for the loss.
In Kubernetes, you do not create ReplicaSets directly. ReplicaSets are set up as part of the Deployment construct. We’ll show how Deployments automatically create ReplicaSets, with a practical code example.
This is part of our series of articles on Kubernetes autoscaling.
In this article, you will learn:
You can define a ReplicaSet with fields, including:
Once you define the fields, the ReplicaSet starts creating and deleting pods to reach the specified amount.
Related content: read our guide to Kubernetes autoscaling.
A ReplicaSet is one of three types of Kubernetes replication. Replication Controllers were the precursor to ReplicaSets, and Deployments are a declarative way to control ReplicaSets and pods. The code examples in this section were shared by Mirantis.
Another mechanism that deploys pods on multiple nodes, primarily used for background services, is the Kubernetes Daemonset - learn more in our guide.
This is an older replication mechanism, which was replaced by ReplicaSets, but still works and is widely used. It creates a certain number of identical pods, and if a pod fails, replaces it. It also lets you update several pods or delete pods with one command.
The ReplicationController has a name, and specifies how many times the pod should be replicated (3 in the example above). The template specifies which pod should be replicated. The selector determines which pods belong to this Replication Controller.
While pods created by ReplicationController are semantically identical, their configuration may change over time. This makes it useful for replicated stateless applications, sharded topologies, worker-pool, and other scenarios.
ReplicaSets are declared in a similar way to ReplicationControllers, but provide more selector options. According to the Kubernetes documentation, ReplicaSets are usually not used directly—they are typically created as part of a deployment.
Here is a simple example using matchLabels as the selector.
Here is a more advanced example that checks two conditions to see if a pod belongs to the ReplicaSet: testing if the app label matches the matchExpressions, and checking if the “tier” label does not equal to “production”.
Deployments are one level up from ReplicaSets. They allow you to use a declarative method to deploy ReplicaSets and pods. You use YAML configuration to define what your group of pods should look like, and the deployment manipulates Kubernetes objects to create pods exactly according to the YAML specification.
Unlike a ReplicaSet, in a deployment, you can modify the YAML Pod template, and the deployment will take care of rolling out the changes. You can roll back to a previous version of your configuration if necessary.
This tutorial is based on code from the Kubernetes documentation. We’ll define a deployment with a ReplicaSet that provisions 3 NGINX pods.
A few things to note about the deployment structure:
To create a deployment using this example, run this command:
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
To check deployment status:
The final output of pods running in the ReplicaSet will look like this:
Spot Ocean from Spot by NetApp frees DevOps teams from the tedious management of their cluster’s worker nodes while helping reduce cost by up to 90%. Spot Ocean’s automated optimization delivers the following benefits:
Learn more about Spot Ocean today!
for up to 20 instances