Pods and Deployments

Pods

At the end of the day, we don’t care about containers or Kubernetes. We care about the application(s) the clusters are serving to our users. Many applications require more than one container, different storage, networking configurations, and so on. To manage applications more efficiently, Kubernetes has Pods.

Each Pod typically only runs a single instance of an application but isn’t required.

Although allowed, running multiple applications in a single Pod is frowned upon. A Pod containing one container is like an everyday server cluster containing a single node. There’s no point because you are defeating the purpose of the cluster, which is to provide redundancy. Always follow the industry one-application-per-Pod norm.

You can define a Pod via a manifest as you can see below. You can tell this is a Pod manifest by the kind attribute chosen. When you deploy the manifest below, K8S will create a Pod running one Nginx container.

metadata:

spec:
  containers:
    ports:

You’ll find that Pods alone are typically used for development and testing purposes primarily because they have no self-healing capabilities by themselves. To ensure applications maintain redundancy and automatic remediation, you should ensure Pods are replicated.

Pod replication is more than one pod running the same exact application. For example, if you had two replicas of the nginx-pod, that means you would have two Pods running the same exact configuration of Nginx.

For more information on replication, check out a brief overview of replication.

Deployments

Kubernetes is a container orchestration platform but doesn’t necessarily have to orchestrate containers directly. Once you start grouping containers in Pods, those Pods need to be orchestrated too! You need deployments. Deployments orchestrate Pods or, more specifically, allow admins to define the desired state of Pods to ensure they stay that way.

A Deployment provides declarative updates to Pods and Replica sets. In this chapter, we’re only going to focus on how deployments and Pods interact.

You must have a way to define the desired state of Pods within a deployment so each deployment contains a manifest. Just like the Pod defined in the manifest above, deployments can have manifests too by specifying a kind attribute of Deployment.

Kubernetes uses deployments to keep Pods in their desired state to self-heal and to automatically scale up or down Pods and containers if need be.

metadata:

spec:
  selector:
    matchLabels:


  template:
    metadata:
      labels:

    spec:
      containers:

        ports:

Recall that deployments control Pods (that’s more than one). The replicas attribute defines how many Pods that deployment will create and manage; in this case, it’s 2. When this deployment runs, it will create two identical Pods (replicas).

Deployments have many advantages like managing Pod replicas for redundancy, but they also inherently have self-healing capabilities. Kubernetes Deployments provide self-healing for all Pods and the containers inside of the Pods.

For example, perhaps you have an Nginx web server running in a container and the Nginx service stops. A Kubernetes Deployment can auto-detect the application that has stopped and automatically create a new container with the running Nginx web server. Kubernetes has self-healing capabilities like this built-in with no configuration needed.

With the Kubernetes default networking comes Kubernetes DNS. Out-of-the-box Kubernetes that are networking comes baked with CoreDNS, a popular open-source DNS platform. CoreDNS runs as a Pod inside of the Kubernetes cluster and manages all DNS settings so you don’t have to.