Introduction to Kubernetes

Kubernetes Workloads

Kubernetes workloads are divided into two major components: pods (the basic building block) and controllers (e.g. ReplicaSet, Deployment, StatefulSet, CronJob, etc.).

Pods

A Pod for Kubernetes is what a container is for Docker: the smallest and simplest unit in its object model. It's helpful to conceptualize Pods as a single instance of an application—or a container. In reality, a Pod encapsulates one or more containers as well as storage resources, an IP address, and rules on how the container(s) should run.

As Pods are meant to be an atomic unit in Kubernetes, each Pod should really run a single instance of a given application. So, if you need to run multiple copies of a container, each container should run within its own unique Pod instead of having all of those containers be in a single Pod. However, sometimes a multi-container Pod makes sense if they are closely-related (a common example is some logging component). One key thing to note is that all the containers in a Pod will share the same environment: memory, volumes, network stack, and most importantly, the IP address.

In a typical deployment, Pods are not directly created by the programmer. Instead, the Controller will schedule a Pod to run on a Node. Some important things to know about Pods:

• A Pod can only exist on a single Node
• A Pod can never be in a partially-deployed state. If a part of the Pod never comes up, it is considered unhealthy and fails.
• A Pod is not "healed" but rather treated as a disposable component. In other words, if a Pod becomes unhealthy, Controller elements will kill the Pod and start up another Pod, replacing rather than healing it.

Controllers

As mentioned earlier, Pods are usually deployed indirectly via Controllers. The one used most frequently is Deployments, but we will quickly cover some other types of Controllers.

ReplicaSet

ReplicaSet, as the name suggests, deploys the specified replicas of the Pod. Unless you require custom updates to the Pods, it’s recommended that you use Deployments, which are higher level objects that wrap around ReplicaSets.

Deployments

Deployments allow for rolling updates and easy rollbacks on top of ReplicaSets. You can define the desired state in the Deployment model, including scaling, rolling updates in canary or blue/green fashion, and Deployments will take care of it for you.

StatefulSets

StatefulSets are similar to Deployments, but maintain a "sticky identity" for each of the Pods. It’s useful for applications in which a stable network identifier or persistent storage is required. A common example would be ElasticSearch.

CronJobs

As the name suggests, CronJob manages time-based jobs. Going with our ElasticSearch example, one common task would be sending out daily reports or cleaning up old data.