Exploring the Components of Kubernetes Architecture

𝐠𝐑𝐏𝐂 𝐯𝐬. 𝐑𝐄𝐒𝐓

gRPC:

Created by Google in 2015 for ultra-fast service communication.

Uses HTTP/2 and Protocol Buffers (protobuf) for efficient, compact data transfer.

features:
Speed: Faster data transfer in binary format.
Multiplexing: Multiple tasks over one connection.
Streaming: Real-time, bidirectional communication.

𝐑𝐄𝐒𝐓:

Around since 1971, commonly used for web services.
Relies on HTTP/1.1 and typically uses JSON or XML formats.
Advantages:
Simplicity: Easy to implement and understand.
Widespread: Supported by most web services.

Challenges:

Performance: Slower due to larger, text-based data.
Efficiency: Not as optimal for high-volume tasks.

Kubernetes Architecture:

The main components like etcd, kube-api-server they communicate with each other in grpc and we communicate to them in REST

Kubernetes has two main components

• Control plane / master

• Worker place/node or slave

NOTE: etcd has no full form, which means that etc is a directory in Linux, its file system and d means distributed. And we use it as a database

Quesetion: For example if our master node will down and our application is already deployed, so will our application run or not?

ANS: Yes, but can’t be updated.

Because:

• The application is deployed on Worker node

• The Control plance(Master Node) is for management

Master Node has Five components :

1. kube-api-server

2. etcd

3. kube-scheduler

4. kube-controller manager

5. cloud-controller manager

Kube API Server

What is:

If the kube-api-server goes down then the whole Cluster will be down. And no activity can be done.

• communication between master and worker node.

• primary interface for interacting with cluster

• ex - security guard check id of student - this is a way to check identity

  Bearer token certificate

What the Kube API server does:

1. Authentication:

   1. Check/verify Who you are

2. Authorization:

   1. What access/ authority do you have

   2. RBAC(Rolle Back Access Control) checks what access you have. only team lead make cluster, intern can only see

   3. its work as CR or monitor

3. Admission Control(Important):

   two types of admission control

   

   1. mutating 2. validating

      mutating : which can be change means you give power to change anything it check yaml is write or not then validate

      • It’s very dangerous in the entire cluster

      • If someone has tweaked anything in the mutating admission controller then the entire production or the application can be down.

validating : green check or cross

What is Webhook?

a webhook is a way to send a notification to another system or service when a specific event occurs. It's essentially a callback function that allows different systems to communicate with each other in real-time. When an event happens, the webhook sends a message to a specified URL, which can then trigger an action in another system.

NOTE:

• Some webhooks are Mutating

• Some webhooks are validating

• But Some webhooks are mutating and validating both.

How to check which webhook is enabled.

cd /etc/kubernetes/manifests

pwd

ls
kube-apiserver.yaml etcd.yaml kube-scheduler.yaml
kube-controller-manager.yaml
## All these control plane components are running as a static pod

cat kube-apiserver.yaml | grep enable

Kubernetes is a plugin-based architecture

custom resource defination(CRD)

a Custom Resource Definition (CRD) is a way to extend the Kubernetes API to support custom resources that are not part of the core Kubernetes API. A CRD defines a new resource type that can be created, updated, and deleted, just like built-in resources such as Pods, Services, and Deployments.

• CRDs allow you to create custom resources that are specific to your application or use case.

• CRDs provide a way to extend the Kubernetes API without modifying the core code.

• CRDs can be used to create resources that are not part of the core Kubernetes API, such as databases, message queues, or other custom resources.

• A CRD is defined using a YAML or JSON file that specifies the resource type, its properties, and its validation rules.

Here is an example of a CRD definition for a custom resource called MyResource

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: myresources.stable.example.com
spec:
  group: stable.example.com
  versions:
  - name: v1
    served: true
    storage: true
  scope: Namespaced
  names:
    plural: myresources
    singular: myresource
  validation:
    openAPIV3Schema:
      type: object
      properties:
        spec:
          type: object
          properties:
            foo:
              type: string
            bar:
              type: integer

This CRD definition defines a custom resource called MyResource with two properties: foo and bar. The foo property is a string, and the bar property is an integer.

to create crd,

kubectl apply -f myresource-crd.yaml

etcd

• It is a database

• It is a NoSQL database

• No fixed Schema is defined

• Distributed Key: Value

• Data not Encrypted

WAL(Write Ahead Log):

to ensure the durability of data. The WAL is a log of all changes made to the system, and it's used to recover the system in case of a failure.

• When a change is made to the system, it's first written to the WAL.

• The WAL is then used to update the system's state.

• In case of a failure, the WAL is used to recover the system's state.

Question:

How many nodes should you add to a cluster so that it’ll be highly available in the most optimized way?

Ans: Odd number of nodes.

Always choose an odd number of nodes in the production.

Formula: n\2+1

Pick the one whose fault tolerance is high

Kube-Scheduler

its like event planner

responsible for scheduling pods on nodes in cluster.

its ensure that desired no of replicas of pod are running

Two cycles:

1. Scheduling cycle

Binding Cycle

kube-controller-manager

responsible for running controllers that ensure desired state of cluster

cloud control manger : responsible for managing cloud specific resources such as load balancer and storage.

Worker Node:

It has mainly three components:

• kubelet

• kube-proxy

• CRI

In Kubernetes, a worker node can have up to 110 pods by default.

Pod: Ideally, every Pod has one Container But in some cases, there can be multiple Container in a Pod which can be a helper, Monitoring agents, init containers

Architecture:

kube-proxy

is a n/w proxy that provide n/wing and cloud balancing capabilities for pods in cluster

use ip table for networki ng

• it has some limited work.

• It runs as a DaemonSet

• By default, it is installed on every Worker Node

• Creating IP table and IP mapping

ClusterIp=PrivateIP

RFC1918- cidr range (10 172 192)

classless inter domain range

not available for public

there are private range

used internally only

Kubelet

• Every worker node has one kubelet

• To run the container

• Manage your pod, container

• To communicate with the API server

• Calls CRI to take care of the container

• Configure Cgroups

• Configure Pods network using CNI

• Pull Images

• Start the container

• Run the application

CRI, CNI, CSI

Previously kubernetes was a small project, so at that time every function was In-Tree(code Hardcoded)

Then they plan to make it a Plugin-based system

To define the basic interface these three interfaces were created.

CNI( Container Network Interface)

• Assign IP to Node

• Assign IP to Pod

These are the solutions that CRI provided two years ago, now it also provides Observability

CRI( Container Runtime Interface):

Container runtime means to boot up the container. Like:

• Catainerd

• rocket

• Crio

A CRI can manage multiple Pods on a single node.

CSI( Container Storage Interface)

• persistent volume

CRI, CNI, and CSI are not components of Kubelet itself, but they are interfaces that Kubelet interacts with to manage containers, networking, and storage in a Kubernetes cluster

• Container Runtime Interface (CRI):

  • Kubelet interacts with the container runtime on the node.

  • Handles container creation, management, and execution.

  • Abstracts the underlying container runtime details from the Kubernetes control plane.

• Container Network Interface (CNI):

  • Kubelet configures networking for Pods on the node.

  • Utilizes CNI plugins for various networking configurations, such as overlay and bridge networking.

  • Provides a standardized approach for networking setup across different environments.

• Container Storage Interface (CSI):

  • Kubelet provisions and manages persistent storage volumes for Pods.

  • Interacts with storage providers (cloud or local) through CSI drivers.

  • Standardizes storage management across different storage systems in the cluster.

In matrics, companies track two things:

Time + Queue

This means what time any service is talking

And everything in kubernetes is in the queue

• See the depth of the queue

• what time does it take to empty the queue

Assignment

1. communication between pods in the same namespace - service mesh

2. communication between pods in the same node but different namespace - kubeproxy

3. communication in different nodes - kubeproxy

4. communication between different clusters - VPN or some other networking solution like peering

5. communication between different containers in the same namespace - localhost

I would like to extend my heartfelt thanks to Preet Munjal for providing valuable insights and content on kubernetes.

• Let's stay connected and continue to learn from each other. If you have any more questions or topics you'd like to discuss, feel free to reach out to me anytime.

  LinkedIn: [https://www.linkedin.com/in/anas133/]