Kubernetes Architecture Basics

Day 30/90 with Shubham Londhe

Are you tired of juggling multiple servers and manually scaling your applications as they grow? Say hello to Kubernetes, the game-changer in the world of containerization and cloud-native applications.

What is Kubernetes?

Kubernetes is like a super-hero for managing containers. But what are containers? Think of them as small, portal packages that hold all the things your application needs to run the code smoothly.

Now, Imagine you have a bunch of containers that need to run together to make your application work. eg(Front-end, Back-end, database, etc). Kubernetes comes to the rescue!

It helps you manage and control these containers, making sure they run in the right place, at the right time, and on the right machines as well.

Kubernetes acts like a brain that coordinates and distributes these containers across multiple computers called Nodes.

With Kubernetes, you can easily deploy, update, and roll back your application without any downtime. It also handles load balancing, so that traffic is evenly distributed among your containers, keeping your application responsive and reliable.

Hence Kubernetes is like a SuperHero

Kubernetes Architecture

KUBERNETES CLUSTER

A Kubernetes cluster consists of control plane nodes and worker nodes.

Control Plane

The control plane is responsible for container orchestration and maintaining the desired state of the cluster. It has the following components.

• API Server
• ETCD
• Scheduler
• Controller Manager

What is a Kubernetes Cluster?

Kubernetes Cluster contains a bunch of nodes. These nodes can be actual computers (physical) or virtual ones. They might be sitting in your own data center or up in the cloud. Now, these nodes are like the hosts that carry and run your applications, but there’s a twist — they run these applications in special containers.

Let’s understand control plane components in depth:

ETCD:

Everything from configurations to the current state of your cluster is neatly organized and stored in etcd. Hence a primary data store in Kubernetes.

It stores all configurations, states, and metadata of Kubernetes objects (pods, secrets, daemonsets, deployments, configmaps, statefulsets, etc).

• etcd is like a high-tech dictionary, storing data as key-value pairs. Acts as central repository for Kubernetes. A nonrelational database that stores data as keys and values. The datastore is built on top of BboltDB which is a fork of BoltDB.
• It ensures that when you retrieve data, you get a consistent and accurate view of the cluster.
• etcd scales and can handle growing numbers of key-value pairs efficiently. Whether your cluster has a handful or multiple nodes.
• etcd uses the raft consensus algorithm, which ensures that all the copies of data across the cluster are in sync.
• etcd stores all objects under the /registry directory key in key-value format.

Key: /k8s/nodes/node-1
Value: {"status": "active", "resources": {"cpu": "4", "memory": "16GB"}}

API Server:

API Server is like a superhero command hub. It coordinates all the processes between the control plane and worker node components.

• When you want something to happen in your cluster, like deploying an application or checking on its health, etc. the command is sent to the API Server.
• It provides a RESTful API that allows users to interact with the Kubernetes control plane and perform actions such as deploying and scaling applications, monitoring the cluster, and managing resources.
• So when you use kubectl to manage the cluster, at the backend you are actually communicating with the API server through HTTP REST APIs. However, the internal cluster components like the scheduler, controller, etc talk to the API server using gRPC.
• It is the only component that communicates with etcd to store and retrieve critical cluster information.
• It ensures that requests are evenly distributed across multiple instances, preventing overload on a single server.
• It coordinates with kubelet agents on each node, ensuring they receive the right instructions. Kubelet agents are like the performers executing tasks on individual machines.
• It is responsible for validating and processing incoming requests and communicating with other Kubernetes components

Scheduler

Scheduler serves as a decision-maker for Pod Placement. It is responsible for scheduling Kubernetes pods on worker nodes.

When you deploy a pod, you specify the pod requirements such as CPU, memory, affinity, taints or tolerations, priority, persistent volumes (PV), etc. The scheduler’s primary task is to identify the create request and choose the best node for a pod that satisfies the requirements.

• It optimizes resource utilization by considering factors like node capacity, workload balancing, and user-defined policies such as affinity rules.
• Kubernetes supports topology-aware scheduling, allowing users to define constraints based on the hierarchical structure of their infrastructure, such as regions and zones. The Scheduler ensures that Pods are placed in a way that respects these topological constraints
• It strives to distribute Pods evenly across nodes, avoiding situations where some nodes are overloaded while others are underutilized.

Controller Manager

The Controller Manager keeps a keen eye on the current state of your cluster.

It runs continuously and watches the actual and desired state of objects. If there is a difference in the actual and desired state, it ensures that the Kubernetes resource/object is in the desired state.

Think of the Replication Controller as a director ensuring that there is the right number of actors (Pods) on the stage (cluster). If there are too few or too many, the Replication Controller makes adjustments

• It also acts as a Garbage Collector which removes old and unused resources, keeping everything neat and efficient.

Following is the list of important built-in Kubernetes controllers.

1. Deployment controller
2. Replicaset controller
3. DaemonSet controller
4. Job Controller (Kubernetes Jobs)
5. CronJob Controller
6. endpoints controller
7. namespace controller
8. service accounts controller.
9. Node controller

When you want to create a deployment, you describe the desired state of your application in a YAML file. This includes specifications like the number of replicas, volume mounts, and any associated configurations.

→ The Deployment Controller ensures consistency by making adjustments as needed. Whether you scale up, scale down, or make any other changes, the controller makes sure the deployment aligns with what you’ve declared in the YAML file.

If you have a unique act (application) with special requirements, you can bring in a custom controller to manage it with precision

Worker Node

Worker Node is responsible for running containers. It’s a physical or virtual machine that hosts and executes containers.

Let’s understand worker node components in depth:

Container Runtime

The worker node includes a container runtime such as Docker Shim or containerd. This runtime is the engine that manages the creation, execution, and termination of containers on the node.

Kubelet

Kubelet is an agent available on every node that acts as a bridge between the master (Control Plane) and the containers running on the node.

Kubelet is responsible for the following.

• Creating, modifying, and deleting containers for the pod.
• Responsible for handling liveliness, readiness, and startup probes.
• Responsible for Mounting volumes by reading pod configuration and creating respective directories on the host for the volume mount.
• Collecting and reporting Node and pod status via calls to the API server.

Kubelet is also a controller that watches for pod changes and utilizes the node’s container runtime to pull images, run containers, etc.

Kube-Proxy

Kube-proxy is a network proxy that runs on each node in a Kubernetes cluster.

Imagine you have a Kubernetes cluster running a web application deployed as multiple pods. To make these pods accessible, you create a Service named web-service.

When we create the service object, it gets a virtual IP assigned to it. It is called ClusterIP. It is only accessible within the Kubernetes cluster. You cannot ping the ClusterIP because it is only used for service discovery, unlike pingable pod IPs.

When you expose pods using a Service (ClusterIP), Kube-proxy creates network rules to send traffic to the backend pods (endpoints) grouped under the Service object. Meaning, that all the load balancing and service discovery are handled by the Kube proxy.

Kube proxy talks to the API server to get the details about the Service (ClusterIP) and respective pod IPs & ports (endpoints).

• Load Balancing: Kube Proxy ensures that traffic is load-balanced between the two pods.
• Dynamic Network Rules: Kube Proxy dynamically manages network rules using tools like iptables. It sets up rules so that when a pod sends a request to web-service, Kube Proxy directs it to one of the pods behind the scenes.

What are EKS, AKS, and GKS?

These are all managed Kubernetes services offered by major cloud providers:

• Amazon Elastic Kubernetes Service (EKS): A managed Kubernetes service on AWS, best suited for organizations already heavily invested in AWS resources and services.
• Azure Kubernetes Service (AKS): A managed Kubernetes service on Microsoft Azure, ideal for organizations within the Azure ecosystem and those seeking the fastest access to new Kubernetes versions.
• Google Kubernetes Engine (GKE): A managed Kubernetes service on Google Cloud Platform, known for its ease of use, automatic updates, and focus on Kubernetes expertise.

Managing the control plane can be complex and time-consuming, and requires specialized expertise and resources. Outsourcing or using managed services (EKS, GKS, etc) allows them to focus on their core competencies and leave the overhead of infrastructure management to specialists.

Thank you for reading this article.

Do add some claps, if you liked the article 👏

Follow for more such content ❤

LinkedIn: https://www.linkedin.com/in/tejashree-salvi-003aa2195/