Kubernetes Fundamentals for Beginners

Learning Kubernetes Fundamentals

Kubernetes is one of the buzz word of the decade, and possibly for the coming century as well. It’s so simple, yet complex and powerful to reduce the workload of the DevOps guys in the industry for application deployment, scaling and availability. Let’s unfold the pieces of this tool and learn it’s architecture and components.

Topics to be covered

• What is Kubernetes ?
• Birth and Evolution of Kubernetes
• Why Kubernetes ?
• Kubernetes Architecture

What Is Kubernetes?

Kubernetes is an open-source container orchestration tool for automating deployments, scaling and management of containerized applications.

Let’s take an example of a football team to understand this better. A football teams consists of many players, both playing actively on the field as well those outside the field which include the coach as well as substitute players. Now the primary agenda of the team would be score goals and eventually win the game. We would call this as meaningful-work just to correlate later with Kubernetes. Below mentioned are some points of how the football team would work towards winning:

• #A) Players are arranged on the field at different positions depending on their role, like attackers in the forward part, defenders in the defending area, mid-fielders in the center area and goalkeeper near the defending goal post.
• #B) Once the game starts, players work in consensus trying to make a goal or in the other case defend a goal.
• #C) The coach also provides continuous instructions from the stands to the players.
• #D) If a player gets injured/or is not able to play, he/she is replaced by another player to take on the role.

Kubernetes is somewhat similar when it comes to make microservices run and function together to achieve the end goal of servicing your customer/client. Now let’s do a point-by-point comparison of the football analogy with Kubernetes.

• #A) in Kubernetes translates to different objects, each having some specific role to perform while serving end user request. It can consist of monitoring, service-discovery, load-balance, config-management or other types of functionalities.
• #B) in Kubernetes translates to each object trying to do it’s part of the job and giving it’s output to the other, so that it can take up the next part.
• #C) in Kubernetes translates to kube API server which issues instructions to other components
• #D) in Kubernetes translates to kube control manager which continuously monitors health of the services and its resources.

This comparison should give a decent understanding of the high level working of Kubernetes. We will cover the specific Kubernetes components mentioned here in the later sections.

Birth and Evolution of Kubernetes

Kubernetes (also known as k8s) was born in Google, starting with Borg, then Omega for around 15 years and then finally Google was kind enough to open-source the project to the entire developer community as Kubernetes in 2014. A very resourceful article describing the evolution of Kubernetes from Borg and Omega is described here. It has come a long way from there, to being one of the biggest adopted and community backed open-source project. Almost all major vendors providing hosting solutions including cloud services offer managed Kubernetes service in their catalog. By the way, the term Kubernetes originates from Greek, meaning helmsman or pilot : a person who steers a ship or boat. If you look at the logo of Kubernetes, you’ll probably get some idea, but we’ll talk on this later.

Why Kubernetes ?

Kubernetes was born out of few fundamental requirements that the IT industry was struggling with:

• Businesses are changing in an ever evolving speed which has led to the wide-spread adoption of microservice architecture.
• Application teams now need to focus more on their business logic and needs, leaving the responsibility for application deployment and management to service providers and tools.
• Automate tasks in the SDLC as much as possible with proper controls and security measures.

Kubernetes provides solution wrt to all of the above requirements. The reason its so popular is that, its predecessors (Borg and Omega) have been battle tested for years at Google’s production scale and post it being open-sourced, it has been backed by major tech and cloud service providers with new capabilities being continually built. The following are the high level features that describe Kubernetes:

• Assures high availability with zero downtime
• Highly performant and scalable
• Reliable infrastructure to support data recovery with ease

Now that we have a decent idea of what Kubernetes is, let’s dig a bit deeper into how it is organized.

Kubernetes Architecture

Kubernetes Architecture Diagram

The above diagram shows the components of Kubernetes architecture. Below are the specifics of each component.

Master Nodes: This is the brain of the Kubernetes architecture. It has the components with core logic of storing deployment configuration, checking and scheduling applications on proper worker nodes, and maintaining high-availability. Let’s check each component individually.

• api-server: This is the sole interaction unit to the user inside a Kubernetes cluster. All actions by user that come from a Graphical User interface or kubectl command line (ideally the GUI would create the kubectl equivalent command based on action on UI) are sent to the API server via a HTTP interface. The API server receives the request, and delegates the appropriate action to the responsible component in the Control Plane. Any client level authentications if present are also done here.
• etcd: This is the persistent and highly available key-value data store inside the Kubernetes cluster to store all cluster data. Application as well as cluster level information is stored here. Any other control plane component when in need of any data, calls etcd.
• scheduler: It is responsible to assign a proper worker node to deploy the application. The scheduler checks for application resource and specifications, and assigns a worker node which matches the criteria to create pods.
• control-manager: This component collectively represents all the controllers (node, job, endpoint, service account) that are responsible to provide high availability. All the controllers run reconciliation loops for applications and other kubernetes services to detect failures and take a corrective action.
• ccm: Cloud control manager is a pluggable component that runs some controllers specific to a Cloud service provider. A cloud service provider can have some specifications of its own, and those are provided via APIs to the cloud control manager. In case of running a cluster on a PC or on premises, the cluster does not have a ccm component.

One additional information about high availability within the master nodes. There is a convention to keep the number of master nodes an odd number. This is to avoid a condition called split-brain, where master nodes will be unable to select a leader amongst themselves in case or a network disruption or master nodes failing. Okay, now you might think why a leader amongst the master is needed. You will be able to relate this better if you know the concept of Leader-Follower used in a Kafka cluster for the brokers. The mechanism is quiet similar to that, but we’ll not go deeper on this topic in this article.

Worker Nodes: These nodes are where your applications actually run on. They have some basic binaries running to deploy applications and provide networking capabilities. When a application deployment is requested via kubectl cli, the api-server receives it and stores the details in etcd. The scheduler component then looks for an appropriate worker node and assigns the deployment to it. The worker node then pulls the image and configuration and spins up the application. Let’s check each component individually:

• kubelet: This is a kubernetes agent running on each worker node, responsible to deploy pods and make sure they are running with the needed configurations. It looks for PodSpec (a YAML representation of a Pod) provided by the api-server to manage the pods.
• kube-proxy: This is the networking utility inside a node that maintains network rules on a node and enables pods to communicate inside an outside the cluster. It can use the packet filtering mechanism of the underlying OS if present.
• container-runtime: It’s a binary of the actual container system that is being used. The most widely used container runtime is Docker but Kubernetes does support others like containerd and CRI-O

What’s Next

Before going on, it’s now time to answer the question we left back in Section 2 (Birth and Evolution of Kubernetes) about the logo of Kubernetes. Now it should make more sense comparing it with the term helmsman. Just like a helmsman steers the ship into a correct direction to reach the destination, Kubernetes also directs your application deployment and management requirements via the various components it has so that you are served with an end state you have envisioned.
Next it’s time to dig deep into some of the core Kubernetes objects, that let you deploy an application with all the needed network connectivity, scaling, confidential data management, high availability and data storage requirements. We’ll list them down over here:

• Deployments: To create a deployment via replica sets for the specified image.
• Pods: Abstraction of a container application.
• Network Policy: The networking rules to be applied to a pod for internal and external communication.
• Secrets: Managing confidential information inside the kubernetes world.
• ConfigMaps: Managing configuration across environments and decoupling it from application development.
• Services & Ingress: Abstraction to hide individual pods behind a layer, to maintain high availability and connectivity.
• Volumes: Configure persistent data storage.
• StatefulSets: Develop stateful applications and data persistence for databases.

We’ll take a bit deeper insight into these Kubernetes objects in the next article here.