Table of contents
Replication Controller
A ReplicationController in Kubernetes ensures that a specified number of pod replicas are running at any given time. Essentially, it makes sure that a pod or a homogeneous set of pods is always up and available. Let’s dive into how it works:
Pod Management:
If there are too many pods, the ReplicationController terminates the extra ones.
Conversely, if there are too few pods, the ReplicationController starts additional replicas.
Unlike manually created pods, those maintained by a ReplicationController are automatically replaced if they fail, are deleted, or are terminated. For instance, when disruptive maintenance (such as a kernel upgrade) occurs, your pods are re-created on a node.
Even if your application requires only a single pod, it’s recommended to use a ReplicationController.
Supervision Across Nodes:
Think of a ReplicationController as a process supervisor, but instead of overseeing individual processes on a single node, it supervises multiple pods across multiple nodes.
In discussions and
kubectl
commands, ReplicationController is often abbreviated as “rc.”
Example Configuration:
Let’s create a simple ReplicationController that reliably runs three instances of the nginx web server:
apiVersion: v1 kind: ReplicationController metadata: name: nginx spec: replicas: 3 selector: app: nginx template: metadata: name: nginx labels: app: nginx spec: containers: - name: nginx image: nginx ports: - containerPort: 80
You can run this example by downloading the replication.yaml file and applying it using:
kubectl apply -f replication.yaml
Check the status of the ReplicationController with:
kubectl describe replicationcontrollers/nginx
The output will show the desired replicas and their status.
Replica Sets
A ReplicaSet (RS) in Kubernetes is a crucial resource that ensures a stable set of running pods for a specific workload. Let’s dive into the details:
Purpose of a ReplicaSet:
A ReplicaSet maintains a specified number of identical pods at all times.
If a pod fails or is evicted, the ReplicaSet compensates by creating additional pods to maintain the desired count.
It acts as a safety net, ensuring that your application remains available even if individual pods encounter issues.
How It Works:
A ReplicaSet defines several fields:
Selector: Specifies how to identify pods it can acquire.
Replicas: Indicates the desired number of pods.
Pod Template: Describes the data for new pods created to meet the replica criteria.
The ReplicaSet continuously monitors the state of its pods.
When needed, it creates or deletes pods based on the template.
Pods acquired by a ReplicaSet have their identifying information linked via the
metadata.ownerReferences
field.
When to Use a ReplicaSet:
While you can directly use ReplicaSets, it’s recommended to use Deployments instead.
Deployments manage ReplicaSets and provide declarative updates to pods.
Unless you require custom update orchestration or don’t need updates at all, use Deployments.
Define your application in the Deployment’s
spec
section.
Here’s an example of creating a ReplicaSet for a PHP-Redis guestbook application:
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
spec:
replicas: 3
selector:
matchLabels:
tier: frontend
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3
Apply this manifest using kubectl apply -f frontend.yaml
. You’ll see the ReplicaSet and managed pods:
kubectl get rs
NAME DESIRED CURRENT READY AGE
frontend 3 3 3 6s
That's great if you have make till here you have covered Kubernetes Concept ReplicationController and Replica Sets.
If you liked what you read, do follow and any feedback for further improvement will be highly appreciated!
Thank you and Happy Learning!👏