Shashikant shah

Wednesday, 17 January 2024

Kubernetes cluster Components .

 1.Kubernetes cluster Components.




Control Plane Components (Master Node) :-
i)                    kube-apiserver
ii)                  etcd
iii)                kube-scheduler
iv)                kube-controller-manager
v)                  cloud-controller-manager  (optional):
            vi)         Kubelet (Manage static pods like kube-apiserver, kube-controller, kube-scheduler, etcd )

Components Worker Node :-
i)                    kubelet
ii)                  kube-proxy
iii)                Container Runtime
iv)                Optional: CNI Plugins (Container Network Interface):




Kubernetes (K8s) core components,

Servers

Component

Description

kube-apiserver

Entry point for all REST operations; manages all communication with the cluster

etcd

Distributed key-value store for cluster configuration and state

kube-scheduler

Assigns pods to available nodes based on resource availability and rules

kube-controller-manager

Runs controllers to handle cluster state changes (e.g., ReplicaSet, Node)

cloud-controller-manager

Manages cloud provider-specific control logic (e.g., AWS, GCP)

nodes

kubelet

Agent that runs on each node and ensures containers are running as expected

kube-proxy

Manages networking, forwards traffic to the correct pod inside the cluster

Container Runtime

Runs and manages containers (e.g., containerd, Docker, CRI-O)

Add-ons

CoreDNS

Provides DNS resolution within the cluster

metrics-server

Collects resource metrics (CPU, memory) used by HPA, dashboards, etc.

Dashboard

Web-based UI to manage and monitor Kubernetes resources

Network Plugin (CNI)

Enables pod-to-pod networking (e.g., Calico, Flannel, Cilium)

Ingress Controller

Manages external access to services (e.g., NGINX, Traefik, HAProxy)

 

Workload Resources

Resource

Description

Pod

Smallest deployable unit that runs one or more containers

Deployment

Manages stateless pods with rolling updates and rollbacks

ReplicaSet

Ensures a specified number of identical pods are running

StatefulSet

Manages stateful pods with persistent identity and storage

DaemonSet

Runs one pod per node (e.g., for logging or monitoring agents)

Job

Runs a pod to completion (batch tasks)

CronJob

Schedules jobs to run at specific times like a cron task

Service Discovery & Load Balancing

Resource

Description

Service

Stable network endpoint to access pods

Ingress

Manages external HTTP/S access to services

IngressClass

Defines controller for managing ingress rules

Endpoint

Internal object listing the pod IPs backing a service

EndpointSlice

Scalable version of Endpoints for large clusters

 

Configuration Resources

Resource

Description

ConfigMap

Stores configuration data as key-value pairs

Secret

Stores sensitive data (passwords, tokens, etc.)

PersistentVolume (PV)

Abstraction for storage provided by the admin

PersistentVolumeClaim (PVC)

Request for storage used by pods

StorageClass

Defines storage types and provisioners

Volume

Abstract storage mounted in a pod

Access & Security

Resource

Description

ServiceAccount

Provides identity for pods to interact with the API

Role

Defines access rules within a namespace

ClusterRole

Like Role, but for cluster-wide access

RoleBinding

Assigns Role to a user/service account in a namespace

ClusterRoleBinding

Assigns ClusterRole to subjects across namespaces

NetworkPolicy

Controls traffic flow between pods

Metadata & Policy

Resource

Description

Namespace

Virtual cluster for resource isolation

Label / Selector

Metadata key-value used for grouping resources

Annotation

Non-identifying metadata (not used for selection)

LimitRange

Sets min/max/default resource usage per pod/container

ResourceQuota

Limits resource consumption per namespace

Autoscaling & Scheduling

Resource

Description

HorizontalPodAutoscaler (HPA)

Scales pods based on CPU/memory usage

VerticalPodAutoscaler (VPA)

Recommends or applies resource requests per pod

PodDisruptionBudget (PDB)

Ensures minimum availability during disruptions

Affinity/Anti-Affinity

Control pod placement based on labels

Taints & Tolerations

Control which nodes a pod can be scheduled on

Observability

Resource

Description

Event

Records state changes or failures

Probe (liveness, readiness, startup)

Check pod health

Metrics (via metrics-server)

Resource usage for HPA and monitoring

Custom Resources

Resource

Description

CustomResourceDefinition (CRD)

Define your own K8s resource type

Operator

Extends Kubernetes to manage custom apps like native resources



ON Master Node :-

How many pods are running on k8s cluster.













How many pods are running on worker side.










1.Kube API Server :-


















i) Kube-API-Server interacts with API, Its a frontend of the kubernetes control plane. API for almost every operation User interact with these API using a tool call Kubectl or UI through a dashboard.

ii) The Kubernetes API (Application Programming Interface) is a set of HTTP endpoints that allow you to interact with a Kubernetes cluster.

iii) The kube API serves as the communication interface between different components of Kubernetes and enables users to control and manage various aspects of the cluster.

iv) All operations (create, update, delete) are submitted to the API server, and it validates and processes them.


2.ETCD (etcd distributed key-value store):-

























etcd is a simple distribute key value store. Kubernetes uses etcd as its database to store all cluster data's. Some of the data stored in etcd is job scheduling information, pods, state information and etc.

etcd is consistent and high-available store.

Fully replicated :- The entire state is available on every node in the cluster.

Secure :- Implements automatic TLS with optional client certificate authentication.

Fast :-  Benchmarked at 10,000 writes per sec.


3. kube-scheduler :-





















Scheduler watches the pods and assigns the pods to run on specific hosts.

4.kube-controller-manager :-























1) Node controller - Its responsible for noticing and responding when nodes go down.

2) Replication controllers - It maintains the number of pods. It controls how many identical copies of a pod should be running somewhere on the cluster.

3) Endpoint controllers joins services and pods together.

4) Token controllers - Services account and Token controllers handles access managements.

5) ReplicaSet controllers ensure number of replication of pods running at all time.

6) Deployment controller provides declarative updates for pods and replicasets.

7) Daemonsets controller ensure all nodes run a copy of specific pods.

8) Jobs controller is the supervisor process for pods carrying out batch jobs Services allow the communication.

Namespace

CronJob

StatefulSet

9) PV controller is responsible for managing Persistent Volumes within a cluster.


5.cloud-controller-manager  (optional):

























The cloud-controller-manager is a component in Kubernetes that allows cloud providers to integrate their services with a Kubernetes cluster. It provides a separation of concerns between cloud-specific operations and core Kubernetes functionality, making it easier to maintain and extend Kubernetes for different cloud environments.

6.Kubelet :-
























Kubelet is the primary node agent runs on each nodes and reads the container manifests which ensures that containers are running and healthy.

7.Kube-proxy :-

























Kube-proxy is a process helps us to have network proxy and loadbalancer for the services in a single worker node. It performs network routing for tcp and udp packets, and performs connection folding. Worker nodes can be exposed to internet via kubeproxy.



Pods workflow :-























1.       User request to Kube-Api-Server.

2.       kube-API-Server first creates a pod according to the memory and CPU requirements, only the container remains to be created.

3.       Kube-Scheduler checks the pod's resources, then the kube-scheduler decides the correct node.

4.       The kube-schedule sends requests to the kubelet to schedule pods.

5.       Kubelet makes a request to Docker then the container is created in Pods.

6.       kubelet sends pods status request to kube-api-server.

7.       kube-api-server communicates to ETCD DB and stores pod information in ETCD DB.


Kubectl :-

  •  Kubectl is a command line configuration tool (CLI) for Kubernetes used to interact with master node of kubernetes. Kubectl has a config file called kubeconfig, this file has the information about server and authentication information to access the API Server.

Objects can be managed in three ways with Kubectl tools.        

i) Imperative Commands.
ii) Imperative Object Configuration.
iii) Declarative Object Configuration.


i) Imperative Commands :- Kubernetes objects can quickly be created, updated, and deleted directly using imperative commands built into the kubectl command-line tool.

ii) Imperative Object Configuration :- In this approach, we operate directly on live objects in a cluster using kubectl CLI as arguments or flags.

For example :
If the command creates objects via CLI or yaml files.
If you then make changes to the firstpod.yaml file and run the kubectl create -f firstpod.yaml command again, there will be no changes. If you want to change anything, you have to do it using the edit command.

 # kubectl edit  <podname>

Generate POD Manifest YAML file (-o yaml). Don't create it(--dry-run)

# kubectl run nginx --image=nginx --dry-run=client -o yaml

Advantages:

·    Commands are simple, easy to learn and remember.

·    Commands require only a single step to make changes to the cluster.

Disadvantages:

·   Commands cannot be committed to source control system and difficult to review.

·   Commands do not provide an audit trail associated with changes.

·  Commands do not provide a template for creating new objects.


iii) Declarative Object Configuration :- In this approach, we create YAML or JSON files for creating, updating, or deleting Kubernetes objects in a cluster using kubectl apply command. There is no need to change each object individually through commands. Change will happen without disturbance. If you create a yaml manifest file and use the apply command, the object will be created. If you make changes in the firstpod.yaml file and run it again command

 For example :-

# kubectl  apply  -f  firstpod.yaml

# kubectl create -f <filename|url>: # used for creating an object from a specified file

# kubectl replace -f <filename|url>: # used for updating a live object from a specified file

# kubectl delete -f <filename|url>: # used for deleting an object from a specified file

# kubectl get -f <filename|url> -o yaml: # used for viewing info about an object from a specified file

# kubectl apply -f <filename|url> : # used for creating/Updating an object from a specified file

# kubectl apply -f <directory> : # used for creating/Updating all objects specified in the directory

Advantages:

·                Object configurations can be stored in a source control system for reviewing changes before push.

·                Object configuration provides a template for creating new objects.

Disadvantages

·                Object configuration requires basic understanding of the object schema.

·                Object configuration requires the additional step of writing a YAML file.









































































No comments:

Post a Comment