Kubernetes Pods, ReplicationControllers and Deployments

In Kubernetes, containers are running within a pod. A Pod is group of one or more containers running on a worker node. A pod basically represents the application you want to run on your Kubernetes cluster.

Pods can be created directly or through a Replication Manager (either a ReplicationController or a Deployment). Even though pods can be created directly, you don’t want to do so as if the pod goes down, no mecanism will be there to make it up again. Hence, it is always better and recommended to create your pods and manage it through a ReplicationController or a Deployment, and let them manage and handle the availability of the pod and fix it if any issue is found on it. For instance, it will spin up a new pod on another host if the original host goes down.The image below shows the difference between an pod deployed directly (Pod A) and another pod (Pod B) managed by a ReplicationController or Deployment.

Credit: Kubernetes in Action

Creating Unmanaged Pods


Creating pods directly and without using going through a Replication Manager is quite easy. You just need to specify kind: Pod in the yaml descriptor file, and run it using the kubectl create command.

The file below contains the enough information to create a pod called testapp from the latest Alpine image.

To create the actual pod

Use kubectl get pods to check the pods status

The status of your pod might show CrashLoopBackOff, which is normal. The pod is crashing because it starts up then immediately exits, thus Kubernetes restarts and the cycle continues. To avoid such behaviour, you need to have your Dockerfile have a Command to run. I haven’t used any Dockerfile in this example.

Creating Managed Pods using ReplicationControllers


ReplicationControllers used to be the way to create managed pods, but this method is deprecated and will be shown here for testing purpose only. ReplicationControllers can be created straight away using the kubectl run command, and adding the –generator=run/v1 attribute.

Keep in mind that kubectl run will be deprecated, so If you want to use the descriptor file instead, you just need to specify the kind: ReplicationController in the yaml descriptor file.

The file below will above will create a ReplicationController named webapp with three replicas (of pods) of the latest Apache image and label the pods as webapp.

Our pods are now running and managed by the ReplicationController.

Creating Managed Pods using Deployments


Creating pods through deployment is the method to use while in production as these are intended to replace ReplicationControllers. They actually provide the same functions as ReplicationControllers, with the ability to manage changes by rolling out and rolling them back if needed. Previously, this would have to be done with kubectl rolling-update which was not declarative and did not provide the rollback features with ReplicationControllers.

To run the deployment

Our deployment is now running with 4 pods replicas

Now let’s go ahead and describe the Deployment

  • The StrategyType is RollingUpdate. Rolling updates allow Deployments’ update to take place with zero downtime by incrementally updating Pods instances with new ones. The new Pods will be scheduled on Nodes with available resources.
  • The minReadySeconds is used to specify the amount of time needed to load resources — before they’re truly considered “ready”. If you think your pod will take some time to load all processes, let’s say 5 seconds, it is better to change this value to 5.
  • The RollingUpdateStrategy is related to the update strategy used in your deployment and specifies the limit number of missing pods before it’s replaced (1 max unavailable), and the limit number of extra pods as we scale the new pods back up (1 max surge).

If needed, you would be able to edit the deployment configuration and change these settings as desired with the following command

Output

Let’s change the number of replicas to 5, the maxSurge and maxUnavailable values to 3 and 2

Press :wq to save the changes and the vi editor

You can check that your changes are effective now

The thing to note is that Deployments manage pods through ReplicaSets, which behaves the same way as Replication Controllers, except that they provide granular control on the updating strategies of the pods and have more options for the selector.

Find this post interesting. Share it!

Leave a Comment

Your email address will not be published. Required fields are marked *