At first sight, one may think that we should care about pods, but Kubernetes recommends using another abstraction called replication controllers.

You will never run one pod instance in production. Instead, you will run many of them to offer high availability and to support all the traffic. Replication controllers are intended to ensure that a specified number of pods are up and running. It's common to have issues with services running in the wild, and sometimes a host crashes, making one or more pods unavailable. Replication controllers are constantly monitoring the system for such problems, and when a pod crashes, it automatically creates a new replica for this pod, as shown in the following diagram:

Let's review the following file, which shows an example of a replication controller:

apiVersion: v1
kind: ReplicationController
metadata:
    name: application-xyz-rc
spec:
    replicas: 3
    selector:
        tier:front-end
    template:
        metadata: 
            label:
                env:production
        spec:
            containers:             
               ...

The content of this file is pretty similar for pods; the main difference is the kind of Docker Service that is specified. In this case, it uses the ReplicaController value. Later, we will define the desired number of replicas and the selector section can be used to specify labels.

Using this file, the replica can be created by running the kubectl create command, as follows:

kubectl create -f application-xyz-rc.yaml 

You can verify how pods are being created when required. You can delete a pod with the following command:

kubectl delete pod <pod-name>

You can then query the available pods with the following command:

kubectl get pod