By Jeff Spaleta, Principal Developer Advocate

It's no secret that the popularity of running containerized applications has exploded over the past several years. Being able to iterate and release an application by provisioning its dependencies through code is a big win. In fact, according to Gartner, "more than 75% of global organizations will be running containerized applications in production" by 2022.

For organizations that operate at a massive scale, a single Linux container instance isn't enough to satisfy all of their applications' needs. It's not uncommon for sufficiently complex applications, such as ones that communicate through microservices, to require multiple Linux containers that communicate with each other. That architecture introduces a new scaling problem: managing all those individual containers. Developers will still need to take care of scheduling the deployment of containers to specific machines, managing the networking between them, growing the resources allocated under heavy load, and much more.

Enter Kubernetes!

Kubernetes is a container orchestration system - a way to manage the lifecycle of containerized applications across an entire fleet. It's a sort of meta-process that grants the ability to automate the deployment and scaling of several containers at once. Several containers running the same application are grouped together. These containers act as replicas, and serve to load balance incoming requests. A container orchestrator, then, supervises these groups, ensuring that they are operating correctly.

A container orchestrator is essentially an administrator in charge of operating a fleet of containerized applications. If a container needs to be restarted or acquire more resources, the orchestrator takes care of itself.

Kubernetes terminology and architecture

Kubernetes introduces a lot of vocabulary to describe how an application is organized. It's best to understand by looking at the smallest layer and then working up:

Pods

●        A Kubernetes pod is a group of containers, and is the smallest unit that Kubernetes administers. Pods have a single IP address that is applied to every container within the pod. Containers in a pod share the same resources such as memory and storage. This allows the individual Linux containers inside a pod to be treated collectively as a single application, as if all the containerized processes were running together on the same host in more traditional workloads.

Deployments

●        Kubernetes deployments define the scale at which users want to run their applications by letting them set the details of how they would like pods replicated on Kubernetes nodes. Deployments describe the number of desired identical pod replicas to run and the preferred update strategy used when updating the deployment. Kubernetes will track pod health and will remove or add pods as needed to bring users' application deployment to the desired state.

Services

●        A service is an abstraction over the pods, and essentially, the only interface the various application consumers interact with. As pods are replaced, their internal names and IPs might change. A service exposes a single machine name or IP address mapped to pods whose underlying names and numbers are unreliable. A service ensures that, to the outside network, everything appears to be unchanged.

Nodes

●        A Kubernetes node manages and runs pods; it's the machine (whether virtualized or physical) that performs the given work. Just as pods collect individual containers that operate together, a node collects entire pods that function together. When operating at scale, users want to be able to hand work over to a node whose pods are free to take it.

Master server

●        This is the main entry point for administrators and users to manage the various nodes. Operations are issued to it either through HTTP calls or connecting to the machine and running command-line scripts.

Cluster

●        A cluster is all of the above components put together as a single unit.

Kubernetes components

With a general idea of how Kubernetes is assembled, it's important to examine the various software components that make sure everything runs smoothly. Both the master server and individual worker nodes have three main components each.

Master server components

1.       API Server

a.        The API server exposes a REST interface to the Kubernetes cluster. All operations against pods, services, and so forth, are executed programmatically by communicating with the endpoints provided by it.

2.       Scheduler

a.        The scheduler is responsible for assigning work to the various nodes. It keeps watch over the resource capacity and ensures that a worker node's performance is within an appropriate threshold.

3.       Controller manager

a.        The controller-manager is responsible for making sure that the shared state of the cluster is operating as expected. More accurately, the controller manager oversees various controllers which respond to events (e.g., if a node goes down).

Worker node components

1.       Kubelet

a.        A Kubelet tracks the state of a pod to ensure that all the containers are running. It provides a heartbeat message every few seconds to the master server. If a replication controller does not receive that message, the node is marked as unhealthy.

2.       Kube proxy

a.        The Kube proxy routes traffic coming into a node from the service. It forwards requests for work to the correct containers.

3.       Etcd

a.        etcd is a distributed key-value store that Kubernetes uses to share information about the overall state of a cluster. Additionally, nodes can refer to the global configuration data stored there to set themselves up whenever they are regenerated.

Overall, there's a lot more to uncover when it comes to Kubernetes. For more information on the applications of Kubernetes and for additional insight, check out Sensu's Co-Founder and Chief Technology Officer, Sean Porter's "Monitoring Kubernetes" series, where he uncovers the challenges and the main data sources for monitoring Kubernetes.

##

About the Author

Jeff Spaleta is the Principal Developer Advocate at Sensu, where he works with the Sensu Community to create compelling solutions and stories. His work with Sensu as a user and developer enables him to gain valuable insight that helps inform Sensu product messaging and engineering priorities. Residing in Fairbanks, Alaska, Jeff's interests range from technology to coffee, curling, and singing.