Kubernetes Architecture

What is Kubernetes?

Kubernetes (often abbreviated as K8s) is an open-source container orchestration platform that automates containerized applications' deployment, scaling, and management. It helps organizations efficiently run applications across multiple machines while ensuring high availability, scalability, and reliability.

---

Why Use Kubernetes?

Managing containers manually can be complex, especially in large-scale applications. Kubernetes simplifies this by providing:

• Automated Deployment & Scaling – Easily deploy and scale applications as needed.

• Self-Healing – Automatically restarts failed containers and replaces unhealthy nodes.

• Load Balancing & Service Discovery – Distributes traffic efficiently across containers.

• Storage Orchestration – Manages persistent storage for stateful applications.

• Rolling Updates & Rollbacks – Ensures smooth application updates without downtime.

---

How Kubernetes Works

Kubernetes follows a master-worker architecture:

• Control Plane (Master Node) – Manages the cluster and schedules workloads.

• Worker Nodes – Run application workloads inside containers.

• Pods – The smallest deployable unit, containing one or more containers.

Kubernetes uses a declarative configuration (YAML/JSON), in which users define the desired state of their applications. Kubernetes then ensures that it is maintained.

Why do we call it k8s?

The term K8s is a shorthand for Kubernetes, where the "8" represents the eight letters between "K" and "s" (Kubernetes). This type of abbreviation is known as a numeronym, commonly used in the tech industry to simplify long words (e.g., i18n for "internationalization" and a11y for "accessibility").

K8s became widely adopted as a more convenient way to refer to Kubernetes, especially in technical discussions, documentation, and command-line tools.

What are the benefits of using k8s?

Kubernetes provides several advantages for managing containerized applications efficiently.

1. Automated Deployment & Scaling

• Deploy applications seamlessly without manual intervention.

• Automatically scale applications up or down based on demand.

• Horizontal Pod Autoscaler (HPA) adjusts resources dynamically.

2. Self-Healing & High Availability

• Automatically restarts failed containers.

• Reschedules workloads if a node fails.

• Performs rolling updates and rollbacks without downtime.

3. Load Balancing & Traffic Management

• Distributes network traffic efficiently across containers.

• Ensures high availability and prevents overload on a single instance.

4. Service Discovery & Networking

• Manages internal and external networking between application components.

• Built-in DNS for automatic service discovery.

5. Efficient Resource Utilization

• Optimally distributes workloads across nodes.

• Supports multi-cloud and hybrid cloud environments.

6. Security & Configuration Management

• Manages secrets and configurations securely using Secrets & ConfigMaps.

• Enforces policies for access control and isolation.

7. Storage Orchestration

• Supports dynamic provisioning of persistent storage (e.g., AWS EBS, Google Persistent Disk).

• Easily attaches storage to stateful applications.

8. Portability & Flexibility

• Runs applications across on-premises, cloud, and hybrid environments.

• Works with different container runtimes like Docker, containerd, and CRI-O.

9. CI/CD & DevOps Integration

• Automates deployments and integrates with CI/CD tools like Jenkins, GitHub Actions, and ArgoCD.

• Enables canary deployments, blue-green deployments, and GitOps workflows.

Explain the architecture of Kubernetes

Kubernetes follows a master-worker (control plane-worker node) architecture. It consists of a control plane that manages the cluster and multiple worker nodes that run applications.

---

1. Control Plane (Master Node)

The control plane is responsible for managing the overall cluster, scheduling workloads, and maintaining the desired state of applications. It includes:

a. API Server

• Acts as the entry point for all Kubernetes operations.

• Exposes the Kubernetes API, allowing communication between internal components and external clients (e.g., kubectl, dashboards).

• Handles authentication, authorization, and validation of requests.

b. Controller Manager

• Ensures the cluster is always in the desired state.

• Includes different controllers like:

  • Node Controller – Monitors and responds when nodes go down.

  • Replication Controller – Ensures the correct number of pod replicas are running.

  • Service Controller – Manages service endpoints.

c. Scheduler

• Assigns newly created Pods to available worker nodes based on resources, constraints, and policies.

d. etcd (Cluster Store)

• A highly available distributed key-value store that stores cluster configuration, state, and metadata.

• Ensures consistency across the cluster.

---

2. Worker Nodes

Worker nodes are responsible for running the actual application workloads. Each node consists of:

a. Kubelet

• A critical agent that runs on every worker node.

• Ensures the assigned Pods are running and communicating with the API server.

• Monitors node health and reports status back to the control plane.

b. Container Runtime

• The software is responsible for running containers.

• Supports Docker, containerd, and CRI-O.

c. Kube Proxy

• Manages networking and load balancing within the cluster.

• Routes network traffic between services and pods.

---

3. Kubernetes Objects

In addition to the core architecture, Kubernetes uses several key objects to manage workloads:

• Pods – The smallest deployable unit, containing one or more containers.

• ReplicaSets – Ensures a specified number of identical Pods are running.

• Deployments – Manages rolling updates and rollbacks.

• Services – Exposes and balances network traffic to Pods.

• ConfigMaps & Secrets – Manages configuration data and sensitive information securely.

---

How Kubernetes Works (Flow)

1. Define Application Deployment – Users submit a YAML or JSON file specifying the desired state.

2. API Server Processes the Request – The request is validated and stored in etcd.

3. Scheduler Assigns Pods – Pods are scheduled to worker nodes based on available resources.

4. Kubelet Ensures Execution – The node’s kubelet runs the containers using the container runtime.

5. Networking & Load Balancing – Kube-proxy routes traffic and balances requests.

6. Self-Healing & Auto-Scaling – Kubernetes monitors workloads and adjusts as needed.

What is a control plane?

The Control Plane is the brain of Kubernetes. It manages the entire cluster by making decisions about scheduling, scaling, and maintaining the desired state of applications. It runs on the master node(s) and consists of several key components.

---

Key Components of the Control Plane

1. API Server (kube-apiserver)

• The entry point for all Kubernetes operations.

• Exposes the Kubernetes API, allowing users and system components to interact (e.g., using kubectl).

• Handles authentication, authorization, and validation of requests.

2. Controller Manager (kube-controller-manager)

• Ensures the cluster is always in the desired state.

• Runs different controllers, including:

  • Node Controller – Monitors worker node health.

  • Replication Controller – Maintains the correct number of running Pods.

  • Endpoint Controller – Updates Service and Pod relationships.

3. Scheduler (kube-scheduler)

• Assigns new Pods to available worker nodes based on resource availability, constraints, and policies.

• Ensures balanced workload distribution.

4. etcd (Cluster Store)

• A distributed key-value store that holds all cluster data, including configuration, state, and metadata.

• Ensures consistency across the cluster.

5. Cloud Controller Manager (Optional)

• Integrates Kubernetes with cloud providers (AWS, GCP, Azure).

• Manages cloud-specific services like storage, networking, and load balancers.

---

How the Control Plane Works

1. A user submits a request (e.g., kubectl apply -f deployment.yaml).

2. The API Server processes and validates the request.

3. The Scheduler assigns workloads (Pods) to suitable worker nodes.

4. The Controller Manager ensures the cluster remains desired.

5. etcd stores all cluster information for consistency.

---

Why is the Control Plane Important?

• Centralized Management – Oversees and controls all Kubernetes operations.

• Ensures High Availability – Maintains application uptime by rescheduling failed Pods.

• Automates Scaling – Adjusts resources dynamically based on demand.

Difference between kubectl and kubelets

- Checking cluster status (kubectl get nodes/pods).
- Scaling applications. | - Ensuring that assigned pods are running properly.
- Restarting failed containers.
- Reporting node and pod status to the control plane. | | Example Command | kubectl get pods – Lists all running pods in the cluster. | Does not have user-executed commands; runs in the background on worker nodes. |

Role of the API server:

The API Server (kube-apiserver) is the central communication hub of a Kubernetes cluster. It acts as an interface between users, applications, and other Kubernetes components, processing requests and managing cluster state.

---

Key Responsibilities of the API Server

1. Handles Requests from Clients (kubectl, UI, or APIs)

• Accepts commands from users via kubectl, client libraries, or external systems.

• Processes REST API requests and validates input data.

2. Communication with Control Plane Components

• Acts as the single point of communication between components like Scheduler, Controller Manager, etcd.

• Ensures all components work in sync to maintain cluster state.

3. Authentication & Authorization

• Authenticates users and service accounts before processing requests.

• Implements Role-Based Access Control (RBAC) to restrict access.

4. Stores and Retrieves Data from etcd

• Writes cluster state and configuration data to etcd (the cluster’s key-value store).

• Reads data from etcd to respond to queries about nodes, pods, and other resources.

5. Load Balancing & Scaling

• Directs requests to the appropriate nodes.

• Facilitates scaling operations by adjusting replicas and scheduling new workloads.

6. Watches for Changes and Notifies Components

• Continuously monitors resources for updates.

• Sends notifications to controllers and schedulers to take necessary actions.

---

How the API Server Works (Flow)

1. A user runs kubectl apply -f deployment.yaml.

2. The API Server validates and authenticates the request.

3. The request is stored in etcd as the desired state.

4. The Scheduler assigns the workload to a worker node.

5. The Kubelet on the node ensures the application runs correctly.

6. The API Server updates and monitors the resource state.

---

Why is the API Server Important?

• Single Source of Truth – Controls all interactions in the cluster.

• Ensures Security – Manages authentication, authorization, and encryption.

• Facilitates Automation – Enables CI/CD pipelines and external integrations.

What is Minikube?

Minikube is a lightweight tool that allows users to run a single-node Kubernetes cluster on their local machine. It is primarily used for development, testing, and learning Kubernetes without requiring a full multi-node cluster.

---

Key Features of Minikube

• Supports running Kubernetes locally with a single node.

• Works with multiple hypervisors such as VirtualBox, Docker, HyperKit, and KVM.

• Quick setup for testing Kubernetes applications.

• Provides built-in add-ons like Ingress, Metrics Server, and Dashboard.

• Offers experimental support for multi-node clusters.

---

Minikube Architecture

Minikube runs a virtualized environment that simulates a Kubernetes cluster. It includes:

• Minikube CLI – A command-line tool (minikube) to manage the cluster.

• Kubernetes API Server – Manages cluster resources and interactions.

• Single Node (VM or Container) – Acts as both the control plane and worker node.

• Container Runtime – Uses Docker, containerd, or CRI-O to run containers.

---

How to Install & Start Minikube

1. Install Minikube

   • On Linux:

       curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
       sudo install minikube-linux-amd64 /usr/local/bin/minikube
     

   • On Windows and Mac: Install using Chocolatey, Homebrew, or direct download.

2. Start Minikube

    minikube start
   

3. Verify Cluster Status

    kubectl get nodes
   

---

When to Use Minikube?

• Ideal for learning Kubernetes concepts.

• Useful for local development and testing Kubernetes applications.

• Helps validate Kubernetes deployments in CI/CD pipelines before moving to production.

---

Limitations of Minikube

• Not suitable for production environments.

• Limited to single-node clusters, with experimental multi-node support.

• Performance depends on system resources.

Features of Minikube:

Minikube provides a lightweight Kubernetes environment for local development and testing. Some of its key features include:

1. Single-Node Kubernetes Cluster

• Runs a full Kubernetes cluster on a single machine.

• Useful for learning and testing Kubernetes locally.

2. Multi-Node Support (Experimental)

• Allows users to create multi-node clusters for advanced testing.

3. Supports Multiple Container Runtimes

• Works with Docker, containers, and CRI-O.

4. Built-in Add-ons

• Provides optional add-ons such as:

  • Ingress for managing external access to applications.

  • Metrics Server for monitoring resource usage.

  • Dashboard for a web-based UI.

5. Compatibility with Kubernetes Tools

• Works with kubectl and other Kubernetes tools.

• Supports Helm for package management.

6. Cross-Platform Support

• Runs on Linux, macOS, and Windows.

• Can be used with virtual machines or container-based environments.

7. Supports Multiple Hypervisors

• Works with VirtualBox, KVM, HyperKit, VMware, and Docker drivers.

8. Port Forwarding

• Allows exposing services running inside Minikube to the host machine.

9. Load Balancer Emulation

• Simulates Kubernetes LoadBalancer services locally.

10. Easy Cluster Management

• Provides simple commands to start, stop, delete, and inspect the cluster.

Install Minikube on your local

For installation, you can Visit this page.

I cannot install Minikube on my local system, but I can guide you through the installation process on your machine.

How to Install Minikube

Step 1: Check System Requirements

Before installing Minikube, ensure you have:

• A system with at least 2 CPUs, 2GB RAM, and 20GB free disk space

• A hypervisor like VirtualBox, Docker, HyperKit, or KVM installed

• kubectl installed (optional but recommended)

Step 2: Download and Install Minikube

On Windows (Using PowerShell or CMD)

1. Download and install Minikube:

    choco install minikube
   

   (If you don’t have Chocolatey, you can manually download the installer from Minikube's official page)

2. Start Minikube:

    minikube start
   

On macOS (Using Homebrew)

1. Install Minikube:

    brew install minikube
   

2. Start Minikube:

    minikube start
   

On Linux

1. Download the Minikube binary:

    curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
   

2. Install Minikube:

    sudo install minikube-linux-amd64 /usr/local/bin/minikube
   

3. Start Minikube:

    minikube start
   

Step 3: Verify Installation

Check if Minikube is running:

kubectl get nodes

If everything is set up correctly, you should see a single node in the output.

Pod:

A Pod is the smallest and simplest deployable unit in Kubernetes. It represents one or more containers that share the same network, storage, and configuration. Pods ensure that tightly coupled containers run together on the same node.

---

Key Features of a Pod

• Encapsulates one or more containers that share resources.

• Has a unique IP address within the cluster.

• Supports shared storage (Volumes) for data persistence.

• Manages container lifecycle by handling restarts and failures.

• Works as a single deployment unit that Kubernetes schedules on nodes.

---

Types of Pods

1. Single-Container Pod

   • Runs a single application inside a container.

   • The most common type of pod.

   • Example: A simple web server like Nginx.

2. Multi-Container Pod

   • Runs multiple containers that work together.

   • Containers share networking and storage.

   • Example:

     • One container serves as a web server.

     • Another container collects logs from the web server.

---

Pod Lifecycle

A pod goes through multiple phases during its lifecycle:

1. Pending – The pod has been accepted but is waiting for scheduling.

2. Running – The pod is running, and at least one container is active.

3. Succeeded – All containers have terminated successfully.

4. Failed – A container has exited with an error.

5. Unknown – The pod state cannot be determined.

---

Creating a Pod

A Pod can be created using a YAML file.

Example: A Simple Nginx Pod

apiVersion: v1
kind: Pod
metadata:
  name: my-nginx-pod
spec:
  containers:
    - name: nginx
      image: nginx
      ports:
        - containerPort: 80

Apply this pod using:

kubectl apply -f pod.yaml

---

How Pods Communicate

• Each Pod has a unique IP address within the cluster.

• Pods communicate using ClusterIP services or Pod IPs directly.

• Multi-container pods use localhost to communicate internally.

Creating the first pod on Kubernetes through Minikube

Once Minikube is installed and running, follow these steps to create and deploy your first Pod.

---

Step 1: Start Minikube

Ensure Minikube is running on your local machine. If it is not running, start it using:

minikube start

Verify that the Minikube node is ready:

kubectl get nodes

You should see a node in the Ready state.

---

Step 2: Create a Pod Manifest File

Create a YAML file (pod.yaml) to define a Pod running an Nginx container.

apiVersion: v1
kind: Pod
metadata:
  name: my-first-pod
spec:
  containers:
    - name: nginx-container
      image: nginx
      ports:
        - containerPort: 80

---

Step 3: Deploy the Pod

Apply the YAML file to create the Pod in the Minikube cluster.

kubectl apply -f pod.yaml

---

Step 4: Verify the Pod is Running

Check the status of the pod:

kubectl get pods

You should see an output like this:

NAME            READY   STATUS    RESTARTS   AGE
my-first-pod    1/1     Running   0          10s

To get detailed information about the pod:

kubectl describe pod my-first-pod

---

Step 5: Access the Pod

To access the running Nginx container, use:

kubectl exec -it my-first-pod -- /bin/sh

Inside the container, you can run:

ls

To exit the container, type:

exit

---

Step 7: Clean Up the Pod

To delete the pod and free up resources, run:

kubectl delete pod my-first-pod

What is Deployment in k8s?

A Deployment in Kubernetes is a higher-level abstraction used to manage the deployment and scaling of applications. It ensures that the specified number of identical Pods (containers) are running and provides features like rolling updates, versioning, and self-healing.

---

Key Features of a Kubernetes Deployment

1. Declarative Updates
   A Deployment allows you to declare the desired state of your application, and Kubernetes will work to ensure that the actual state matches it. This makes updates and rollbacks easy to manage.

2. Scaling Pods
   You can scale the number of replicas (Pods) running in a Deployment to meet the required load, either manually or automatically using Horizontal Pod Autoscalers (HPA).

3. Rolling Updates and Rollbacks

   • Rolling Updates allow you to update an application without downtime. Kubernetes will gradually replace old Pods with new ones.

   • If a problem arises, Kubernetes can roll back to the previous version of the Deployment.

4. Self-Healing
   If a Pod in a Deployment fails or is deleted, Kubernetes automatically creates a new Pod to maintain the desired number of replicas.

5. Versioning
   Kubernetes maintains different versions of the Deployment, so you can track changes to the application.

---

Deployment Example

Here’s a basic example of how to create a Deployment running an Nginx web server.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80

• replicas: 3: Ensures that 3 Pods are running at all times.

• selector: Matches the Pods managed by this Deployment.

• template: Describes the Pod template that is used to create new Pods.

---

Deploying the Example

1. Save the above YAML file as nginx-deployment.yaml.

2. Apply the Deployment using the following command:

    kubectl apply -f nginx-deployment.yaml
   

3. Verify the Deployment:

    kubectl get deployments
   

4. Check Pods created by the Deployment:

    kubectl get pods
   

---

Scaling the Deployment

To scale the Deployment up or down:

kubectl scale deployment nginx-deployment --replicas=5

This command will scale the Deployment to 5 replicas.

---

Updating the Deployment

To update the image of the containers:

kubectl set image deployment/nginx-deployment nginx=nginx:latest

Kubernetes will gradually update the Pods with the new image, ensuring zero downtime (rolling update).

---

Rolling Back a Deployment

To roll back to a previous version:

kubectl rollout undo deployment/nginx-deployment

---

When to Use Deployments in Kubernetes?

• When you need to manage applications with a set number of Pods.

• When you require zero-downtime updates and rollbacks.

• When scaling Pods dynamically based on load is needed.

• When you want Kubernetes to automatically handle application failures and restarts.

Task-1:

Create one Deployment file to deploy a sample todo-app on K8s using the "Auto-healing" and "Auto-Scaling" features

• add a deployment.yml file (the sample is kept in the folder for your reference)

• apply the deployment to your k8s (minikube) cluster by command kubectl apply -f deployment.yml

To complete this task, you need to create a deployment.yml file for the Todo-App, using both auto-healing and auto-scaling features.

---

Step 1: Create the deployment.yml File

Here is a sample deployment.yml that deploys a simple Todo application, utilizing auto-healing and auto-scaling.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: todo-app-deployment
spec:
  replicas: 3  # Initial replicas for auto-healing
  selector:
    matchLabels:
      app: todo-app
  template:
    metadata:
      labels:
        app: todo-app
    spec:
      containers:
        - name: todo-app
          image: yourusername/todo-app:latest   # Use your own image or a public one
          ports:
            - containerPort: 8080
          resources:
            requests:
              memory: "64Mi"
              cpu: "250m"
            limits:
              memory: "128Mi"
              cpu: "500m"
  strategy:
    type: RollingUpdate   # Ensures no downtime during updates
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: todo-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: todo-app-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

---

Explanation of Key Components:

1. Auto-Healing (Replica Management):

   • The replicas field in the Deployment spec is set to 3, which ensures there are always 3 Pods running.

   • If any Pod fails or is deleted, Kubernetes will automatically create a new Pod to replace it, maintaining the desired number of Pods.

2. Auto-Scaling (HorizontalPodAutoscaler):

   • The HorizontalPodAutoscaler (HPA) is configured to adjust the number of Pods based on CPU utilization.

   • The minReplicas is set to 2 and maxReplicas is set to 10, meaning that the application will scale between 2 to 10 Pods based on CPU usage.

   • The HPA will adjust the number of Pods if the average CPU utilization exceeds 50%.

3. Rolling Update:

   • The RollingUpdate strategy ensures zero downtime during updates by gradually replacing old Pods with new ones.

---

Step 2: Apply the Deployment to Minikube

Once you've created the deployment.yml file, follow these steps:

1. Ensure Minikube is Running: Start your Minikube cluster (if it's not already running):

    minikube start
   

2. Apply the Deployment: Apply the deployment.yml file to the Kubernetes cluster:

    kubectl apply -f deployment.yml
   

3. Verify the Deployment: After applying, you can check if the Deployment was successfully created:

    kubectl get deployments
    kubectl get pods
   

4. Check Auto-Scaling: You can verify the auto-scaling behavior by observing the Horizontal Pod Autoscaler:

    kubectl get hpa
   

5. Test Auto-Healing: To test auto-healing, delete one of the Pods manually, and Kubernetes will create a new one:

    kubectl delete pod <pod-name>
   

---

Step 3: Expose the Deployment (Optional)

To access the Todo app, you can expose the Deployment using a service:

kubectl expose deployment todo-app-deployment --type=NodePort --port=8080

Then, get the URL to access the app:

minikube service todo-app-deployment --url

---

Step 4: Clean Up the Resources

Once you are done testing, you can delete the resources:

kubectl delete -f deployment.yml