Kubernetes API described...

What is Kubernetes?

Kubernetes is an Open Source Container Orchestration System for automating Software Deployments, Scaling and Management (thank you Wikipedia).

Basically Kubernetes is used to create a cluster or clusters of machines (virtual or physical) that run containerised workloads. So, if we think about something like Docker, which is a container engine, you might use Docker to run an Oracle database, for example, with Kubernetes, you might spin up multiple instances of that container, perhaps multiple instance of many containers to allow you to scale up rapidly.

Everything is an object

Kubernetes considers each compute and storage resource as an object, this allows it to build clusters in a loosley coupled way. Loosely Coupled in computing terms means that you can change aspects of one component without adverse impact on another, or more importantly, without adverse impact on the cluster as a whole.

The Control Plane

The kubernetes master node handles what is called the control plane, this is like a governor module, it manages workloads and directos communications throughout the nodes in the cluster. The control plane also handles things like Role Based Access Control, Network Segmentation, Encryption and Authentication, it can run on a single node or multple masters supporting high-availability clusters. Components include:

Etcd

A persistent, lightweight, distributed, key-value data store. What is a key-value data store I hear no-one asking?

A Key-Value datastore is like a dictionary in programming terms, or a hash table. This is a collection of Objects, we might simplistically look at it like this:

car1 = { 
  "Brand": "Toyota:,
  "Model": "Prius:,
  "Model Year": 2020
}

car2 = { 
  "Brand": "Citroen:,
  "Model": "C4:,
  "Model Year": 2016
}

Okay, that is a simple example, but what it shows is that an object can contain many details and that each detail holds both a Key (e.g. Brand) and a Value (e.g. Toyota).

In Kubernetes, this key-value data store is holding State Information for the distributed architecture, this is where we hold information about the desired state for all the components within the architecture.

API Server

I started this post because I was fascinated with how much chatter exists between the components of a kubernetes cluster. These conversations take place using APIs, so I was starting to picture each component as having its own API Server. I may have missed the point here.

The API Server uses JSON over HTTP to serve both the internal and external interface for Kubernetes.

The API Server processes and validates REST (REprisentational State Transfer) requests and then updates the state of the API objects in Ectd.

The API Server also uses Etcd’s watch API to monitor the cluster, push critical configuration changes and importantly, restore any divergences of the cluster back to the desired state.

All fascinating stuff, I am sure you will agree.

Scheduler

We’re not talking about your Outlook Calendar here. This is a bit more clever, this monitors resource allocation in each node to ensure that workload is not oversubscribed, basically using any resources it has access to without trying to take too much from the node. This is important because in many of these containerised workloads we often over-subscribe the systems resources, that is to say we might use a system with 192GB of RAM, we may allow several nodes to access up to 80% of the total RAM available based on the assumption that they will unlikely all need it at the same time, else one or more of them will slow down and possibly come to a halt. The scheduler can help manage this to shift workload to a node that is perhaps less busy at that particular time.

A Kubernetes Worker Node

I’ve only heard of them as being Worker Nodes, but apparently they are also known as minions, these are the machine(s) where the workload(s) are deployed. Every node in the cluster must run a runtime container as well as the following components:

Kubelet

The kubelet is reponsible for the running state of each node. This component is responsible for starting, stopping and maintaining application containers. These application containers are organised into Pods under the direction of the control plane.

Kubelet monitors the state of the pod, if the pod is not in the desired state, the pod re-deploys to the same node.

Node status is relayed every few seconds using heartbeat messages to the API Server.

I am still getting to know the Kubernetes world, I’ve never really used it beyond labs, but you never know what is around the corner.