Learning: Kubernetes

Kubernetes (or popularly known as K8), is a portable, extensible, open-source platform for managing containerized workloads and services. In other words, how to load balance requests/tasks of your services and, how to manage those very services — whether it be deploying them with zero downtime or perhaps start the service back up if it went down (self-heal). It is important to understand how it all happens on a high level and what are the basic components involved in these actions. In this blog we will look at what Kubernetes is comprised of and their roles in it.

What Kubernetes is not?

Unlike traditional PaaS (Platform as a Service) system offering, Kubernetes operates at the container level rather than at the hardware level. My top three favorite things Kubernetes does not do are as follows:

1. Does not limit the types of applications supported. Kubernetes aims to support an extremely diverse variety of workloads, including stateless, stateful, and data-processing workloads. If an application can run in a container, it should run great on Kubernetes.
2. Does not deploy source code and does not build your application. Continuous Integration, Delivery, and Deployment (CI/CD) workflows are determined by organization cultures and preferences as well as technical requirements.
3. Does not provide application-level services, such as middleware (for example, message buses), data-processing frameworks (for example, Spark), databases (for example, MySQL), caches, nor cluster storage systems (for example, Ceph) as built-in services. Such components can run on Kubernetes, and/or can be accessed by applications running on Kubernetes
4. (I know, I lied. It’s 4 things…) Additionally, Kubernetes is not a mere orchestration system. In fact, it eliminates the need for orchestration. The technical definition of orchestration is execution of a defined workflow: first do A, then B, then C. In contrast, Kubernetes comprises a set of independent, composable control processes that continuously drive the current state towards the provided desired state. It shouldn’t matter how you get from A to C. Centralized control is also not required. This results in a system that is easier to use and more powerful, robust, resilient, and extensible.

So long story short, it’s just all around containers.

Architecture Terminology

A Kubernetes cluster is made of nodes depicted above. These nodes are divided into two categories — master (blue) and worker (gray). In a production environment, you will have more than 1 nodes for each category. In the above picture our environment contains 3 master nodes and 4 worker nodes. Each node runs a container runtime — in this case its Docker.

Master

Control Plane: a set of containers that manage the cluster. These containers exist inside 1 or more master nodes. In here each master node (in the control plane) run 5 following containers:

• etcd: distributed storage system for key& value.
• API Server: a container that allows us to talk to the cluster. API could use etcd to store data on storage system.
• Scheduler: a container that controls how/where your containers are places on nodes on objects called pods.
• Control Manager: this container looks at the state of the whole system and everything that is running in it using the API server. And it takes the orders that is giving it (or the “specs”) and determines the difference between what you are asking it to do and what is actually going on. It is basically a loop that is differencing the whole system and figuring out how to make everything that is currently happening the same what you have asked it do.
• Core DNS: a container to control DNS which isn’t built in. By default, its core dns.

Worker

A worker is typical of receiving requests in the form of tasks sent by the master. Each worker comes with few running “stuff” besides the pods that run inside them.

Kubelet: a container that will run a small agent on each worker node to allow that node to talk to Kubernetes master.

Remember, since docker has swarm built-in, swarm doesn’t need a separate agent to facilitate this communication. That was all built into the Docker Engine.

Now with Kubernetes, running on top of docker (or whatever other container runtime you pick), it needs its own engine API that talks to the local Docker, or the local runtime, whichever that may be. Then it talks back up to the control plane, or master, which is in charge of running the Kubernetes cluster. In order to ensure proper running of your application containers kubelet needs to make sure that it is doing so by checking the pod’s health status and informing the control plane. It needs to talk to Control Plane using it’s API Server. Kind of things it communicates to control plane are as follows:

Hey boo (Control Plane)! Could I please get a list of containers you want me to keep an eye on?

Yo Control Plane bro! This pod right up here messed up and it’s in bad state!

Kube Proxy: kube-proxy is a network proxy that runs on each worker in your cluster, implementing part of the Kubernetes Service concept — A way to expose an application running on a set of Pods as a network service. kube-proxy maintains network rules on workers. These network rules allow network communication to your Pods from network sessions inside or outside of your cluster.

Next we look into PODS — the main unit of all work in Kubernetes!