0% found this document useful (0 votes)
13 views

Kubernetes is an application

Kubernetes is an application orchestrator primarily for containerized cloud-native microservices, consisting of a control plane and worker nodes. The control plane includes essential components such as the API server, scheduler, and controller manager, while worker nodes execute tasks and report back to the control plane. Applications are packaged in containers, wrapped in Pods, and deployed using manifest files, allowing Kubernetes to manage desired states and ensure self-healing capabilities.

Uploaded by

Atmajyoti
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views

Kubernetes is an application

Kubernetes is an application orchestrator primarily for containerized cloud-native microservices, consisting of a control plane and worker nodes. The control plane includes essential components such as the API server, scheduler, and controller manager, while worker nodes execute tasks and report back to the control plane. Applications are packaged in containers, wrapped in Pods, and deployed using manifest files, allowing Kubernetes to manage desired states and ensure self-healing capabilities.

Uploaded by

Atmajyoti
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as TXT, PDF, TXT or read online on Scribd
You are on page 1/ 5

Kubernetes is an application orchestrator.

For the most part, it orchestrates


containerized cloud-native microser-
vices apps.

A Kubernetes cluster is made of a control plane/ Master node and nodes/ worker
node. The control plane exposes the API, has a scheduler
for assigning work, and records the state of the cluster and apps in a persistent
store. Nodes are where user
applications run.

The control plane/ Master Node

Kubernetes control plane nodes are servers that run the cluster’s control plane
services.

different services making up the control plane.

(1) The API server--The API server is the Grand Central of Kubernetes. All
communication, between all components, must go
through the API server

(2) The cluster store(etcd service)--The cluster store is the only stateful part of
the control plane and persistently stores the entire configuration and
state of the cluster.The cluster store is the only stateful part of the control
plane and persistently stores the entire configuration and
state of the cluster.

(3)The controller manager and controllers--The Controller Manager is like a


supervisor that manages multiple controllers in a Kubernetes cluster.A controller
is a background process that constantly watches the API Server for changes and
ensures the current state of the cluster matches the desired state.
Each controller follows a simple loop:
Obtain desired state → Checks what the user wants (e.g., 3 replicas of a pod).
Observe current state → Looks at the cluster to see what's actually running.
Determine differences → Finds differences (e.g., only 2 pods running instead of
3).
Reconcile differences → Fixes the problem (e.g., creates 1 more pod to match
the desired state).

(4)The scheduler- The scheduler is responsible for deciding which node will run a
new Pod in Kubernetes. It does not run the Pod—it just picks the best node for it.
How Does the Scheduler Work
Watches for new tasks (Pods) in the API Server.
Filters out unsuitable nodes (e.g., not enough CPU/RAM, network port conflicts,
taints, affinity/anti-affinity rules).
Ranks the remaining nodes based on factors like:
Does it already have the required container image?
How much free CPU and memory does it have?
How many tasks is it already running?
Selects the best node (highest ranking score) and assigns the task (Pod) to it.

(5)The cloud controller manager---If you’re running your cluster on a supported


public cloud platform, such as AWS, Azure, GCP, or Linode, your
control plane will be running a cloud controller manager. Its job is to facilitate
integrations with cloud services,
such as instances, load-balancers, and storage.

Worker nodes
worker Nodes are servers that are the workers of a Kubernetes cluster.
At a high-level they do three things:
1. Watch the API server for new work assignments
2. Execute work assignments
3. Report back to the control plane (via the API server)

There are three major components of a node


(1) Kubelet--The kubelet is the main Kubernetes agent that runs on every node (both
master and worker nodes).
What Does Kubelet Do?
Registers the Node with the Cluster
When a node joins the cluster, kubelet reports the node’s CPU, memory, and
storage to the API Server.
Watches for New Work (Pods)
Kubelet continuously monitors the API Server for new Pods assigned to its
node.
Manages Containers on the Node
It instructs the container runtime (Docker, containerd, or CRI-O) to start
or stop containers.
It ensures that the required Pods are running as expected.
Reports Node & Pod Status to the Control Plane
If a Pod fails, kubelet reports back, but does not reschedule it—that’s the
scheduler’s job.

(2) Container runtime--The container runtime is the software responsible for


pulling container images and starting and stopping containers.Kubernetes itself
does not run containers directly—it relies on a container runtime to do this.
containerd and CRI-O became the preferred runtimes for k8s.

(3) Kube-Proxy-- kube-proxy runs on every node and is responsible for networking
inside the Kubernetes cluster.
What Does Kube-Proxy Do?
Assigns a Unique IP to Each Node
Ensures every node in the cluster gets a unique internal IP.
Manages Service Networking (Routing Traffic to Pods)
It sets up iptables or IPVS rules to forward traffic to the correct Pod.
Without kube-proxy, Services in Kubernetes wouldn’t work.
Handles Load Balancing Inside the Cluster
Distributes traffic between Pods for a Service.
Uses Round-Robin, Least Connections, or other algorithms depending on
IPVS/iptables mode.

Kubernetes DNS---Kubernetes has an internal DNS service that allows Pods and
Services to discover and communicate with each other using domain names instead of
IPs.Kubernetes uses CoreDNS to provide internal DNS resolution.CoreDNS typically
runs only on control plane nodes because it is part of the cluster's control plane
services.

Packaging Applications for Kubernetes

To run an application in Kubernetes, you need to follow three key steps:


Package as a Container
Write your application (e.g., Python, Java, Node.js).
Build it into a container image using Docker or Podman.
Store the image in a container registry (Docker Hub, Quay, or a private
registry).

docker build -t myapp:v1 .


docker push myregistry.com/myapp:v1
Wrap in a Pod
A Pod is the smallest unit in Kubernetes.
It runs one or more containers together.
Example Pod YAML:

apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name: myapp
image: myregistry.com/myapp:v1
Deploy Using a Manifest File:

You define your application setup in a YAML file (called a manifest).


This includes details like how many copies (replicas) of your app should run

Deploy Using a Controller (Deployment)


Deployments ensure scalability, self-healing, and rolling updates.
Example Deployment YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
spec:
replicas: 3
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: myapp
image: myregistry.com/myapp:v1

Apply the Deployment:


kubectl apply -f myapp-deployment.yaml

Understanding the Declarative Model and Desired State in Kubernetes

Kubernetes follows a declarative model, meaning you describe how your application
should look, and Kubernetes makes it happen.
How It Works:
Declare the Desired State:
You write a YAML manifest file that describes your application’s state.
Example: How many replicas to run, which image to use, and what ports to
expose.
Submit to the API Server:
You use kubectl apply -f deployment.yaml to send the manifest to
Kubernetes.
Store in the Cluster:
Kubernetes saves this as the desired state in its database (etcd).
Implement the Desired State:
Kubernetes schedules Pods on available nodes and ensures the application
runs.
Continuous Monitoring & Self-Healing:
If the observed state (what’s actually running) differs from the desired
state, Kubernetes fixes it.
Example: If a Pod crashes, Kubernetes creates a new one to replace it.

Example Scenario
You deploy a web app with 10 replicas (desired state). If a node crashes, reducing
the running replicas to 8, Kubernetes automatically creates 2 new replicas to
restore the desired count to 10.

Here's a simple Deployment YAML file for a web application running 10 replicas in
Kubernetes:
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
spec:
replicas: 10 # Desired number of replicas
selector:
matchLabels:
app: web-app
template:
metadata:
labels:
app: web-app
spec:
containers:
- name: web-app
image: nginx:latest # Replace with your application image
ports:
- containerPort: 80

Explanation:
replicas: 10 → Ensures 10 instances of the app are always running.
image: nginx:latest → Uses an Nginx container (replace with your own app
image).
Kubernetes monitors the state → If a Pod crashes, Kubernetes replaces it
automatically.

Pod in Kubernetes

In VMware, the smallest unit is a Virtual Machine (VM).


In Docker, the smallest unit is a Container.
In Kubernetes, the smallest unit is a Pod.

A Pod is a wrapper around one or more containers.


Kubernetes does not run containers directly—it runs them inside Pods.
A Pod provides networking, storage, and management for the containers inside it.

What Does a Pod Provide


Creates a network stack (each Pod gets its own IP address).
Sets up kernel namespaces (for isolation).
Provides shared storage and memory (if multiple containers exist inside the Pod).

General thinks to know about pod


A Pod is only "ready" when all its containers are running.
If a Pod fails to start completely, it is considered a failure.
A Pod always runs on a single node (even if it has multiple containers).
Pods are temporary—they can be created, run, and then deleted.
If a Pod dies unexpectedly, Kubernetes creates a new one (not the same, but
identical).
New Pods get a new ID and IP address each time they are recreated.
You can't modify a running Pod.
If you need a change, Kubernetes deletes the old Pod and creates a new one with the
new configuration.

You might also like