Kubernetes as a container orchestration platform

Building and running a single container seems easy enough. However, things can get complicated when you need to run multiple containers across multiple servers. This is where a container orchestrator can help. A container orchestrator takes care of scheduling containers to be run on servers, restarting containers when they fail, moving containers to a new host when that host becomes unhealthy, and much more.

The current leading orchestration platform is Kubernetes (https://kubernetes.io/). Kubernetes was inspired by the Borg project in Google, which, by itself, was running millions of containers in production.

Kubernetes takes a declarative approach to orchestration; that is, you specify what you need and Kubernetes takes care of deploying the workload you specified. You don't need to start these containers manually yourself anymore, as Kubernetes will launch the Docker containers you specified.

Note

Although Kubernetes supports multiple container runtimes, Docker is the most popular runtime.

Throughout the book, we will build multiple examples that run containers in Kubernetes, and you will learn more about the different objects in Kubernetes. In this introductory chapter, we'll introduce three elementary objects in Kubernetes that you will likely see in every application: a Pod, a Deployment, and a Service.

Pods in Kubernetes

A Pod in Kubernetes is the essential scheduling block. A Pod is a group of one or more containers. This means a Pod contains either a single container or multiple containers. When creating a Pod with a single container, you can use the terms container and Pod interchangeably. However, the term Pod is still preferred.

When a Pod contains multiple containers, these containers share the same filesystem and the same network namespace. This means that when a container that is part of a Pod writes a file, other containers in that same Pod can read that file. This also means that all containers in a Pod can communicate with each other using localhost networking.

In terms of design, you should only put containers that need to be tightly integrated in the same pod. Imagine the following situation: you have an old web application that does not support HTTPS. You want to upgrade that application to support HTTPS. You could create a Pod that contains your old web application and includes another container that would do SSL offloading for that application as described in Figure 1.3. Your users would connect to your application using HTTPS, while the container in the middle converts HTTPS traffic to HTTP:

Figure 1.3: Example of a multi-container Pod that does HTTPS offloading

Note

This design principle is known as a sidecar. Microsoft has a free e-book available that describes multiple multi-container Pod designs and designing distributed systems (https://azure.microsoft.com/resources/designing-distributed-systems/).

A Pod, whether it be a single or a multi-container Pod, is an ephemeral resource. This means that a Pod can be terminated at any point and restarted on another node. When this happens, the state that was stored in that Pod will be lost. If you need to store state in your application, you either need to store that in a StatefulSet, which we'll touch on in Chapter 3, Application deployment on AKS, or store the state outside of Kubernetes in an external database.

Deployments in Kubernetes

A Deployment in Kubernetes provides a layer of functionality around Pods. It allows you to create multiple Pods from the same definition and to easily perform updates to your deployed Pods. A Deployment also helps with scaling your application, and potentially even autoscaling your application.

Under the covers, a Deployment creates a ReplicaSet, which in turn will create the Pod you requested. A ReplicaSet is another object in Kubernetes. The purpose of a ReplicaSet is to maintain a stable set of Pods running at any given time. If you perform updates to your Deployment, Kubernetes will create a new ReplicaSet that will contain the updated Pods. By default, Kubernetes will do a rolling upgrade to the new version. This means that it will start a few new Pods. If those are running correctly, then it will terminate a few old Pods and continue this loop until only new Pods are running.

Figure1.4: Relationship between Deployment, ReplicaSet, and Pods

Services in Kubernetes

A Service in Kubernetes is a network-level abstraction. This allows you to expose the multiple Pods you have in your Deployment under a single IP address and a single DNS name.

Each Pod in Kubernetes has its own private IP address. You could theoretically connect your applications using this private IP address. However, as mentioned before, Kubernetes Pods are ephemeral, meaning they can be terminated and moved, which would impact their IP address. By using a Service, you can connect your applications together using a single IP address. When a Pod moves from one node to another, the Service will ensure traffic is routed to the correct endpoint.

In this section, we have introduced Kubernetes and three essential objects with Kubernetes. In the next section, we'll introduce AKS.