Kubernetes Components Overview

I borrowed the above image from Kubernetes site.

Let us begin with a high level overview of what Kubernetes is which will make explaining it’s components easier.

Per kuberenetes.io, “Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available. The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes combines over 15 years of Google’s experience running production workloads at scale with best-of-breed ideas and practices from the community.”

A Kubernetes cluster is made of a a Master node and a set of worker nodes (formerly minions), that run containerized applications. Master is a collection of three processes that run on a single node or multiple nodes in your cluster.  Minions/worker nodes in your cluster hosts Pods that are used for application workloads.  For my VMWare people out there think of the Master as a vCenter server, the minions/worker nodes as a ESXi host, and Pods as a virtual machine.

Below you will find some of the key components of Kubernetes and their definitions:

Etcd
Consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data. etcd stores the configuration data of the Kubernetes cluster, representing the state of the cluster (what nodes exist in the cluster, what pods should be running, which nodes they are running on, and a whole lot more) at any given point of time.

API Server
The API server is the front end for the Kubernetes control plane.  It exposes the API (REST) and consumes JSON files via manifest files. This is the component we interact with the most as users. For my VMWare people think of this as your vCenter interaction point; if you wanted to deploy a new VM, you wouldn’t go to the individual host in a cluster and deploy the VM locally, you would log into the vCenter.

kubelet proxy
kube-proxy is a network proxy that runs on each node in your cluster.  It’s job is to maintain network rules on the nodes in the cluster.  Also, it allows network sessions outside and inside of the cluster.  Finally, it is responsible for a portion of the services.

Kubelet
Each node in the cluster runs the kubelet agent.  This agent ensures that containers are running successfully in a Pod.  Another function of the kubelet is to register the node with the apiserver.  This agent also reports back to the master to ensure that the Pods as described in the YAML file are running as intended and healthy.

Scheduler
In short, the scheduler observes the apriserver for new pod builds and assigns work to the minions/worker nodes to build the new Pods.  The criteria for choosing Pod placement depends on resource requirements and availability.  For my VMWare people think of this like DRS workload placement.

Controller Manager
In short, this is the controller of controllers.  Some of the underlying controllers are the endpoint, replication, and node controllers.  The controller manager key responsibilities is to watch for changes and to maintain desired state.  IE, if you set the replication replica to 3 and you lose a node in the cluster, it is the responsibility of the Controller Manager to ensure desired state and re-deploy a 3rd node in the cluster.

Container runtime
In short, it is the component that is responsible for running containers and supports several container runtimes, most popular being Docker.

Summary:
This is a lot of information provided above but I hope it gives everyone a solid overview.  Now that we have covered the basics and their definition we can move onto other concepts and designs.  As always, I hope y’all find this helpful.