Our previous article covered Namespaces and Services and we are slowly increasing our knowledge of Kubernetes and how we can start to run our services on a basic environment. In todays article, we will explain to you how ReplicaSets and ReplicationControllers can be used to help you deploy your Pods and make sure they are always running.

Don't worry, if you need to catch up a little, and are just starting out, checkout our previous posts that cover an [introduction to Kubernetes](https://stemgeeks.net/hive-163521/@run.vince.run/getting-started-with-kubernetes-basic-concepts-of-kubernetes), [Pods](https://stemgeeks.net/hive-163521/@run.vince.run/getting-started-with-kubernetes-deploy-pods), [Namespaces and Services](https://stemgeeks.net/hive-163521/@run.vince.run/getting-started-with-kubernetes-namespaces-and-services).

<h2>ReplicaSets and ReplicationController</h2>
If you create a Pod from a simple definition, you will have the issue occasionally where the pod could still go down and it would be lost, and you would need to restart it again from your Pod definition file. Instead of having to watch out for these events to happen, we can create our Pods as part of a ReplicaSet or ReplicationController.

If the Pod then fails the replication controller, will bring up a new instance of the Pod. Replication controllers will also be able to spin up additional pods when the demand is needed. In this tutorial we will cover both ReplicationControllers and ReplicaSets, but note that the controllers are being replaced by ReplicaSets.

A replication controller or replica set is created using a yaml to define how it will be set up, specifying the same details as we needed in our pod definition; apiVersion, kind, metadata and spec. In the definition below, we have set up our definition and in the spec of the ReplicationController, we have simply added the spec of our Pod that the controller will control, including the metadata and spec within the spec.template of the replication controller. We also need to include the replicas we need as part of our definition, in our case we have set “replicas: 3”.

```
1 apiVersion: v1
2 kind: ReplicationController
3 metadata:
4   name: myapp-rc
5   labels:
6     app: myapp
7     type: front-end
8 spec:
9   template:
10  metadata:
11    name: nginx
12    labels:
13      app: myapp
14  spec: 
15    containers:
16      - name: nginx-container
17         image: nginx
18  replicas: 3
19   
```

To then create the replication controller, you use the kubectl create command with the -f option and providing the yaml file we created.

```
kubeclt create -f <replication_controller_yaml>
replicationcontroller/myapp-rc created
```

To see our replication controllers, we can use the get command below with the kubectl command:

```
kubectl get replicationcontroller
NAME       DESIRED   CURRENT   READY   AGE
myapp-rc   3         3         3       24s

kubectl get pods

NAME             READY   STATUS    RESTARTS   AGE
myapp-rc-7l98t   1/1     Running   0          44s
myapp-rc-s985r   1/1     Running   0          44s
myapp-rc-xgxqm   1/1     Running   0          44s
```

A replica set is a little different were you also need to use the selector as we have in line 19 below to match the label of the pod we are going to be managing.

```
1 apiVersion: apps/v1
2 kind: ReplicationSet
3 metadata:
4   name: myapp-replicaset
5   labels:
6     app: myapp
7     type: front-end
8 spec:
9   template:
10   metadata:
11     name: nginx
12     labels:
13       app: myapp
14   spec: 
15     containers:
16       - name: nginx-container
17         image: nginx
18 replicas: 3
19 selector: 
20   matchLabels:
21   type: front-end
22
```

You then create the ReplicaSet the same way you would create any other definition file, but when you need to query a ReplicaSet, you would use the following kubectl command: 

```
kubectl get replicaset
```

Scaling up your replicas can be done by editing the definition yaml file and then running the kubectl replace command:

```
kubectl replace -f <yaml_definition_file>
```

Or using the kubectl scale command as we have below:

```
kubectl scale --replicas=4 replicationcontroller myapp-rc
replicationcontroller/myapp-rc scaled

kubectl get pods                                         
NAME             READY   STATUS              RESTARTS   AGE
myapp-rc-7l98t   1/1     Running             0          8m48s
myapp-rc-s985r   1/1     Running             0          8m48s
myapp-rc-td6mj   0/1     ContainerCreating   0          3s
myapp-rc-xgxqm   1/1     Running             0          8m48s
```

Of course you can delete a ReplicaSet or ReplicationController by simply using the kubectl delete command, but remember, all the pods that the controllers manage, will also be deleted.

```
kubectl delete replicationcontroller myapp-rc
replicationcontroller "myapp-rc" deleted

kubectl get pods                             
No resources found in default namespace.
```

Hopefully another piece to the puzzle, and hopefully you are seeing Kubernetes can actually be pretty clear and straight forward. Probably the reason why it has been adopted so quickly and is so popular. 

**About The Author
I am a DevOps Engineer, Endurance Athlete and Author. As a DevOps Engineer I specialize in Linux and Open Source Applications. Particularly interested in Search Marketing and Analytic’s, and is currently developing my skills in devops, continuous integration, security, and development(Python).**

Posted with [STEMGeeks](https://stemgeeks.net)