In an earlier blog post, we covered the basics of Kubernetes and the features around Container Orchestration that it provides. To summarize, as the number of containers increases, you need an orchestration layer that will help in auto-scaling, rolling updates, health checks, service endpoints, load balancing and more. And Kubernetes provides us with those functionalities. In this post, we are going to look at the basic buildings blocks in Kubernetes. The diagram is taken from the reference architecture documentation from the official Kubernetes documentation.

Reference Architecture Diagram

 

Let us break it down into key building blocks that we need to understand.

Cluster and Nodes

In the diagram above, a cluster is a group of nodes, where a node can be a physical machine or virtual machines. Each of the nodes will having the container runtime (Docker or rkt) and will also be running a kubelet service, which is an agent that takes in the commands from the Master controller (more on that later) and a Proxy, that is used to proxy connections to the Pods from another component (Services, that we will see later).

Pod

A Pod is a group of containers that form a logical application. For e.g. If you have a web application that is running a NodeJS container and also a MySQL container, then both these containers will be located in a single Pod. A Pod can also share common data volumes and they also share the same networking namespace. Remember that Pods are ephemeral and they could be brought up and down by the Master Controller. Kubernetes uses a simple but effective means to identify the Pods via the concepts of Labels (name – values).

Master Controller

This is the main controller for your cluster and it takes care of multiple things for you. Think of this as a heart of your operations that enables all the features for which you want Kubernetes in the first place. Usually there is one Master Controller as you can see in the diagram and it has multiple components in it like Discovery Service for the Pods, Replication Controller, Scheduling  and an API Manager to take in commands from the command line utility (kubectl) and communicate to the Nodes.

Replication Controller

One of the features that we talked about using Kubernetes for is the auto scaling (up or down) of Pods. This is done by the Replication Controller component. All you need to do is specify the number of Pods, the container images that need to be started on them and rules for launching or bringing down the Pods. The controller will take care of scheduling the Pods on the Nodes.

Services

If we have multiple Pods that are running, how do we ensure that there is a single endpoint to access them. A service takes care of that. It provides a unified way to route traffic to a cluster and eventually to a list of Pods. Keep in mind that the same Labels will be used to identify the Service and the Pods. By using a Service, Pods can be brought up and down without affecting anything. It is seamless to the client who is using it. As you can see, Kubernetes may look complex but it has a set of components that have well-defined functionality. You have the choice of running the Kubernetes installation either locally or even via fully-managed services available in the cloud. For e.g. Google provides the Google Container Engine (GKE), where they provide you with a Master Controller that is fully managed by them. All you need to do is define your Cluster , Nodes and definitions around Pods, Services and Replication Controllers. Fully Managed Container Orchestration services do make it easier to jumpstart your move to Kubernetes.