Day 30 | Kubernetes Architecture

Understanding Kubernetes Architecture:

Imagine a City with a Grand Coordinator:

1. Mayor's Office (Master Node):

   • The city has a Mayor's office, which is like the master node in Kubernetes.

   • The mayor's office makes high-level decisions for the entire city.

2. City Planners (API Server):

   • The city planners work in the Mayor's office, deciding where buildings should go and how roads should be laid out.

   • In Kubernetes, the API server is like these city planners. It takes high-level requests and decides how the containers (buildings) should be arranged and managed.

3. City Records (etcd):

   • There's a central database, like the city records, that keeps track of all the important information about the city—where each building is, how many people live in each house, etc.

   • In Kubernetes, this is called etcd. It keeps track of the configuration and state of the entire Kubernetes city.

4. City Controllers (Controller Manager):

   • The city has controllers, like traffic controllers and building controllers, ensuring everything runs smoothly.

   • In Kubernetes, the Controller Manager oversees controllers like the Replication Controller, making sure the right number of buildings (replicas) are in place.

5. City Scheduler (Scheduler):

   • There's a city scheduler who decides where new buildings should be constructed based on available space.

   • In Kubernetes, the Scheduler decides which worker node should run a new container, making sure there's enough space and resources.

Now, the City Workers (Worker Nodes):

1. Neighbourhoods (Worker Nodes):

   • The city is divided into neighbourhoods, each managed by a local work team.

   • In Kubernetes, these neighbourhoods are worker nodes. Each worker node is like a neighbourhood where containers (houses) are located.

2. Local Leaders (Kubelet):

   • Each neighbourhood has a local leader who ensures that houses are in good shape and everything runs smoothly.

   • In Kubernetes, the Kubelet runs on each worker node, making sure containers are healthy and doing their job.

3. Building Contractors (Container Runtime):

   • There are various building contractors (construction companies) in the city, each responsible for constructing different types of buildings.

   • In Kubernetes, the container runtime (like Docker) is the building contractor. It constructs and runs containers based on the city's (Kubernetes) plan.

Communication and Coordination:

1. City Hall Announcements (API Communication):

   • The Mayor's office communicates with the neighbourhoods through city hall announcements.

   • In Kubernetes, API communication between the master node and worker nodes ensures everyone is on the same page.

In a Nutshell: Kubernetes is like a well-organized city where the Mayor's office (Master Node) makes decisions, city planners (API Server) arrange things, and local leaders (Kubelet) in neighbourhoods (Worker Nodes) ensure everything operates smoothly. The city's records (etcd) keep track of important details, and the building contractors (Container Runtime) construct and manage the buildings (containers) based on the city's plan. It's a coordinated effort to maintain a well-functioning city of containers!

Kubernetes Master Node Components (Control Plane):

1. API Server:

   • What it does: The API server is the central management point for the entire Kubernetes cluster. It serves as the front-end for the control plane, handling communication and commands from various sources, including the Kubernetes CLI (kubectl), the web-based dashboard, and other parts of the control plane.

   • Simple Example: When a user deploys an application using the kubectl command, the API server receives the request, validates it, and initiates the necessary actions to deploy the specified workload.

2. etcd:

   • What it does: etcd is a distributed key-value store that stores the configuration details and the state of the entire Kubernetes cluster. It provides a consistent and highly available datastore for all cluster data, including configuration details, state information, and metadata.

   • Simple Example: If you deploy a new Pod, etcd stores information about that Pod, such as its configuration, current status, and relationships with other resources in the cluster.

3. Controller Manager:

   • What it does: The controller manager oversees various controllers that regulate the state of the cluster. Controllers continuously work to ensure that the current state matches the desired state defined by the user or system. Examples include the Replication Controller and the Deployment Controller.

   • Simple Example: If you deploy a Pod with three replicas, the Replication Controller, managed by the Controller Manager, ensures that there are always three instances of that Pod running, even if some of them fail or are terminated.

4. Scheduler:

   • What it does: The scheduler is responsible for placing containers on worker nodes based on resource requirements, policies, and optimization strategies. It ensures that containers are distributed efficiently across the cluster.

   • Simple Example: If you submit a request to deploy a new Pod without specifying a particular node, the Scheduler decides which worker node should run that Pod, taking into consideration factors like resource availability and load balancing.

5. Cloud Controller Manager:

   The Cloud Controller Manager (CCM) in Kubernetes is a component responsible for interacting with the underlying cloud provider's APIs to manage resources specific to that cloud environment. It abstracts and provides a consistent interface for Kubernetes to interact with cloud-specific services. Let's explore the role of the Cloud Controller Manager with a simple example:

   Example: Load Balancer Service in a Cloud Environment

   1. User Request:

      • A user deploys a web application on a Kubernetes cluster and creates a Service of type LoadBalancer to expose the application to external traffic.

   2. Cloud Controller Manager Takes Action:

      • The Cloud Controller Manager identifies the creation of a LoadBalancer Service type.

   3. Load Balancer Provisioning:

      • The Cloud Controller Manager interacts with the cloud provider's API to provision a load balancer. The specifics of how load balancing is achieved vary based on the cloud provider (AWS, GCP, Azure, etc.).

   4. External IP Assignment:

      • Once the load balancer is provisioned, the Cloud Controller Manager obtains an external IP address from the cloud provider.

   5. Configuration Update:

      • The Cloud Controller Manager updates the Kubernetes Service configuration with the external IP address.

   6. Service Access:

      • External users can now access the web application using the assigned external IP, and the load balancer distributes traffic among the application's Pods.

Simple Example Scenario: Imagine you want to deploy a web application on your Kubernetes cluster:

1. You use kubectl to submit a deployment request for the web application.

2. The API server receives your request and validates it.

3. The API server instructs etcd to store the configuration details of the deployment.

4. The Controller Manager ensures that the desired number of replicas of the application is running by interacting with etcd.

5. The Scheduler decides which worker nodes should run the application's Pods based on resource availability.

6. The API server communicates with the Kubelet on the selected worker nodes to initiate the deployment.

In this scenario, the components on the master node collaborate to process your deployment request, maintain the desired state of the cluster, and coordinate the deployment of the web application across the worker nodes.

Kubernetes Worker Node Components (Data Plane):

1. Kubelet:

   • What it does: Kubelet is an agent that runs on each worker node and ensures that containers are running in a Pod, a basic unit of deployment in Kubernetes. It communicates with the master node to receive instructions about which containers to run and their desired state.

   • Simple Example: If the master node instructs the worker node to run a Pod with a web server container, the Kubelet makes sure that the web server container is running and healthy on that worker node.

2. Container Runtime:

   • What it does: The container runtime is responsible for pulling container images and running containers based on the instructions from the master node. Docker is a common container runtime used in Kubernetes, but others like containerd or CRI-O can also be employed.

   • Simple Example: If the master node instructs the worker node to run a Pod with a specific Docker container, the container runtime (Docker, in this case) pulls the container image and starts the container on the worker node.

3. Kube Proxy:

   • What it does: Kube Proxy maintains network rules on nodes, enabling communication between Pods and handling external traffic. It helps in load balancing and routing traffic to the appropriate containers within Pods.

   • Simple Example: If multiple Pods are running a web application on a worker node, Kube Proxy ensures that external requests are appropriately distributed among these Pods. If a user accesses the application, Kube Proxy directs the request to one of the available Pods.

Simple Example Scenario: Imagine you have a Kubernetes cluster with a master node and a worker node. You want to deploy a web application that consists of multiple instances (Pods) of a web server.

1. The master node instructs the worker node to run three Pods of a web server.

2. Kubelet on the worker node ensures that three instances of the web server container are running in separate Pods.

3. The container runtime (e.g., Docker) pulls the web server image and starts the containers.

4. Kube Proxy configures network rules to handle incoming requests to the web application, ensuring they are distributed among the available Pods.

In this scenario, Kubelet, Container Runtime, and Kube Proxy work together on the worker node to fulfil the instructions from the master node and manage the deployment of the web application.

CLEAR PICTURE OF KUBERNETES ARCHITECTURE AND ITS COMPONENTS:

  +-------------------------+
  |                         |
  |       Master Node       |
  |                         |
  | +---------------------+ |
  | |      API Server     | |
  | +---------------------+ |
  | |         etcd        | |
  | +---------------------+ |
  | | Controller Manager | |
  | +---------------------+ |
  | |      Scheduler      | |
  | +---------------------+ |
  +-------------------------+
           |  |  |
           |  |  |
           v  v  v
  +-------------------------+
  |                         |
  |      Worker Nodes       |
  |                         |
  | +---------------------+ |
  | |       Kubelet       | |
  | +---------------------+ |
  | | Container Runtime  | |
  | +---------------------+ |
  | |      Kube Proxy     | |
  | +---------------------+ |
  +-------------------------+

• Communication:

  • Arrows represent communication pathways between components.

This is a high-level and simplified representation. In a real-world scenario, there would be multiple worker nodes, and the interactions between components would be more complex.