Kubernetes :-

This document offers a comprehensive overview of Kubernetes, an open-source container

orchestration platform that automates the deployment, scaling, and management of
containerized applications. It outlines core concepts, architecture, and components essential
for effective cloud-native application operations.

Key Concepts :-
Pods
A Pod is the smallest deployable unit in Kubernetes, which can contain one or more
containers. Pods share the same network namespace and can communicate with each other
using localhost.

Services
A Service is an abstraction that defines a logical set of Pods and a policy by which to access
them. Services enable communication between different parts of an application.

Deployments
A Deployment is a controller that provides declarative updates to Pods and ReplicaSets. It
allows you to define the desired state of your application and Kubernetes will manage the
deployment process.

Namespaces
Namespaces are a way to divide cluster resources between multiple users or applications.
They provide a mechanism for isolating resources and managing access.

ReplicaSet
A ReplicaSet is a Kubernetes controller that ensures a specified number of identical Pods are
running at all times. It monitors the current state of the cluster and automatically creates or
deletes Pods to match the desired number of replicas.
EX :- replicas: 3 in deployment.yaml
Kubernetes Architecture :-
Kubernetes architecture consists of a master node and worker nodes. The master node is
responsible for managing the cluster, while worker nodes run the applications.

Master Node Components

• API Server: The front-end for the Kubernetes control plane.
• Scheduler: Assigns Pods to nodes based on resource availability.
• Controller Manager: Regulates the state of the cluster.
• etcd: A distributed key-value store used for storing cluster data.

Worker Node Components

• Kubelet: An agent that runs on each worker node and ensures that containers are
running in Pods.
• Kube Proxy: Manages network routing for services.
• Container Runtime: The software responsible for running containers (e.g., Docker,
containerd).

Kubernetes Architecture and Components

Master Node
Worker Nodes
API Server
Kubelet
Scheduler
Kubernetes Kube Proxy
Controller Manager Architecture
Container Runtime
etcd

Getting Started with Kubernetes :-

Storage Overview :
Kubernetes provides a flexible and extensible model for managing storage, enabling
workloads to persist and share data across nodes and application lifecycles. Storage in
Kubernetes is abstracted through a set of APIs and primitives designed for portability,
scalability, and dynamic provisioning.

1. Volumes:-
Kubernetes Volumes provide a mechanism to attach storage to pods, ensuring data can be
retained across container restarts within the same pod. They support various types, including
emptyDir, hostPath, and cloud provider volumes.

2. Persistent Volumes (PV):-

A Persistent Volume is a cluster-scoped storage resource, decoupled from pod lifecycles. It
represents a piece of storage provisioned manually or dynamically and made available to
workloads via Persistent Volume Claims (PVCs).

3. Projected Volumes:-
Projected Volumes allow the aggregation of multiple volume sources (such as Secrets,
ConfigMaps, and Downward API) into a single volume mount, simplifying configuration
management for applications.
4. Ephemeral Volumes:-
Ephemeral volumes are temporary storage volumes tied to the lifecycle of an individual pod.
These are suitable for non-persistent workloads and include in-memory or inline-defined CSI
volumes.

5. Storage Classes:-
A StorageClass defines the "class" of storage offered by a storage provider, typically
differentiated by performance, cost, or availability. It enables dynamic provisioning of
volumes with predefined parameters.

Understanding Pod :-
Pod lifecycle:-
A Pod starts in Pending, moves to Running, and ends in Succeeded or
Failed based on container outcomes.If the Pod’s state can’t be determined due to issues, it is
marked as Unknown.

Init Containers:-
Init containers run before the main application containers in a Pod.
Used for setup tasks like initializing data or checking service dependencies.
Run sequentially and must complete successfully for the main containers to start.

Sidecar Containers:-
Sidecars run alongside the main application container in the same Pod.
Common uses: logging, monitoring, proxying (e.g., Istio envoy proxies).
They enhance or support the primary container but are not dependent on each other’s
lifecycle.

Ephemeral Containers:-
Special containers added to a running Pod for debugging purposes.
Don’t modify the Pod’s spec and can’t have ports or volumes.
Useful for troubleshooting live Pods without restarting them.

Disruptions:-
Events that cause Pods to shut down or restart (e.g., node maintenance, voluntary evictions).
Pod Disruption Budgets (PDBs) can be defined to limit how many Pods can be disrupted at
once during voluntary disruptions.
CONFIGURATIONS :-
1. Labels:-
Key-value pairs attached to Kubernetes objects (like Pods) for identification and organization.
Use cases:
Selecting a group of objects (e.g., via kubectl or selectors in Services/Deployments).
Logical grouping (e.g., app=nginx, tier=frontend).

2. Secrets:-
Store sensitive data (e.g., passwords, tokens, keys) securely.
Use cases:
Mount into Pods as environment variables or volumes.
Reduce hardcoding of sensitive info in images or manifests.
valueFrom: { secretKeyRef: { name: db-secret, key: password } }

3. ConfigMaps:-
Store non-sensitive configuration data as key-value pairs.
Use cases:
Inject app configs via environment variables or mounted volumes.
Decouple configs from container images.
valueFrom: { configMapKeyRef: { name: app-config, key: APP_MODE } }

4. Probes:-
Monitor the health and readiness of containers.
Types:
* Liveness Probe: Checks if the app is running. Restarts container if it fails.
* Readiness Probe: Checks if the app is ready to receive traffic.
* Startup Probe: Ensures the app starts correctly before other probes kick in.
Use cases: Helps in auto-healing and smarter traffic routing.

5. Annotations:-
Attach non-identifying metadata to objects.
Use cases:
Store information like build/version info, monitoring config, or deployment history.
Not used for selection (unlike labels).
annotations: { backup.velero.io/backup-volumes: "my-volume" }

6. Resources:-
Define compute resources required or limited for containers.
Use cases:
• Request CPU and memory to guarantee minimum resources.
• Set limits to prevent a container from using excessive CPU or memory.
• Help Kubernetes schedule pods effectively and enforce QoS.
• resources: { requests: { cpu: "250m" }, limits: { memory: "500Mi" } }
SECURITY :-
Security in Kubernetes is the set of measures to protect the cluster, workloads, and data
from unauthorized access and threats. It involves controlling access, securing
communication, and managing secrets safely. These practices help ensure the integrity and
confidentiality of applications running in the cluster.

1)ὑ Service Account (SA):-

A Service Account is a special type of Kubernetes account used by pods (applications
running in the cluster) to interact with the Kubernetes API.
✅ Key Points:
• Automatically mounted into pods under
/var/run/secrets/kubernetes.io/serviceaccount/
• Used for authenticating requests to the Kubernetes API.
• You can create custom Service Accounts and assign specific permissions using RBAC.

2)ὐ RBAC (Role-Based Access Control)

RBAC controls who can do what in a Kubernetes cluster.
It defines:
• Roles: What actions are allowed (e.g., read pods, create deployments)
• RoleBindings: Who (users, groups, or service accounts) gets those permissions
✅ Key Components:
1. Role – Grants permissions within a namespace
2. ClusterRole – Grants permissions cluster-wide
3. RoleBinding – Assigns a Role to a user/SA within a namespace
4. ClusterRoleBinding – Assigns a ClusterRole to a user/SA across the cluster.

3) ᾞ Controlling Access to the Kubernetes API

Controlling access to the Kubernetes API ensures that only authenticated and authorized
users or services can interact with the Kubernetes control plane.
✅ Key Components:
ὑ Authentication – Verifies who is making the request
Ὥ Authorization – Determines what the authenticated entity is allowed to do
ἱ API Server Access Restrictions — Limits where requests can come from
Ὄ Audit Logging — Tracks who did what and when
Preemption and Eviction:-

1]Taints and Tolerations:-

Taints and tolerations work together to ensure that pods are not scheduled onto
inappropriate nodes. One or more taints are applied to a node; this marks that the node
should not accept any pods that do not tolerate the taints.

a) NoSchedule -Pods will not be scheduled on the node unless they tolerate the taint.
b) PreferNoSchedule -ubernetes tries to avoid scheduling pods on the node, but may
allow it.
c)NoExecute -Causes pods to be evicted from the node and blocks new pods unless they
tolerate it.

2]Assigning Pods to Nodes:-

a) NODESELECTOR:
nodeSelector is the simplest way to tell Kubernetes to schedule a Pod
only on Nodes with a specific label (like a tag).
Use Case:
You have Nodes with different types of disks (SSD and HDD), and you want your
high-performance database Pod to run only on SSD Nodes.
Example:
Run this database Pod only on Nodes that are tagged as ‘disktype: ssd’.

b) NODEAFFINITY:
nodeAffinity is a more advanced and flexible way to assign Pods to
Nodes based on labels, allowing both mandatory rules and preferences.
Use Case:
You want your AI model training Pod to run on GPU Nodes, preferably in the us-east
region, but still run elsewhere if needed.
Example:
Prefer to run this Pod on Nodes with a GPU in the us-east zone, but it’s okay if those aren't
available.

c) PODAFFINITY:
podAffinity allows you to schedule a Pod close to other Pods — on the
same Node or in the same zone/rack, based on the labels of those other Pods.
Use Case:
You have a web server and a Redis cache. You want the web server Pods to run on the
same Node as the Redis Pods for low-latency communication.
Example:
Put this web server Pod on a Node where a Redis Pod is already running.

d) PODANTIAFFINITY:
podAntiAffinity ensures that certain Pods are not scheduled near
each other, often used to spread replicas across Nodes for fault tolerance.
Use Case:
You have 3 replicas of your app. You want to make sure each one runs on a different Node
so they don’t all go down if one Node fails.
Example:
Do not run this Pod on a Node that already has another replica of this app running.
 2]Pod Disruption:-
Handles voluntary and involuntary interruptions; managed with Pod Disruption Budgets
(PDBs).Use Case: During a rolling update of a backend service, a PDB ensures at least 2 of 5
pods are always available to prevent downtime.

3]Assigning Pods to Nodes:-

Scheduler places pods based on rules like selectors, affinity, taints, and resource
availability.Use Case: A machine learning job is scheduled only on GPU-enabled nodes
using a nodeSelector.

4]Pod Topology Spread Constraints:-

Distributes pods evenly across zones/nodes for better availability.Use Case: Spread
replicas of a database pod across different availability zones to stay online during zone
failures.

5]Descheduler:-
Rebalances or evicts poorly placed pods based on current cluster state.Use Case: After a
new node is added, Descheduler moves long-running pods to balance load and free up
older nodes.

Kubernetes Pod Scheduling and Management

Assigning Pods to Nodes

Taints and Tolerations
nodeSelector
NoSchedule
nodeAffinity
PreferNoSchedule
podAffinity
Kubernetes NoExecute
podAntiAffinity Pod
Scheduling
and
Management Pod Disruption
Pod Topology Spread Constraints
Voluntary Interruptions
Zone Distribution
Involuntary Interruptions
Node Distribution

Descheduler

Load Balancing
Resource Optimization
Services, Load Balancing, and Networking:-
Services are used to expose a set of pods as a network service. They abstract away the pod
IPs and provide a stable endpoint. There are several types of Services, each designed for
different use cases:
ὓ 1. ClusterIP (default)
• Description: Exposes the service on an internal IP within the cluster.
• Accessible from: Inside the cluster only.
• Use case: Internal communication between pods and services.
• Example: Microservice A talks to Microservice B inside the same cluster.
ὓ 2. NodePort
• Description: Exposes the service on a static port on each node’s IP.
• Accessible from: Outside the cluster using <NodeIP>:<NodePort>.
• Use case: Quick external access during development or debugging.
• Example: Access a service by browsing to http://<NodeIP>:30007.
ὓ 3. LoadBalancer
• Description: Provisions an external load balancer (usually from a cloud provider) and
assigns a public IP.
• Accessible from: Public internet.
• Use case: Production-grade access to your app, often behind a cloud load balancer.
• Example: Exposing a public-facing web application.
ὓ 4. Headless Service (ClusterIP: None)
• Description: No cluster IP is assigned; returns pod IPs directly.
• Accessible from: Inside the cluster, mainly used with StatefulSets.
• Use case: Direct pod-to-pod communication, service discovery, or custom load
balancing.
• Example: Useful in Cassandra, Kafka, or other stateful applications.

ὓ Ingress
• What it is:An Ingress is a Kubernetes resource that defines rules for routing
external HTTP/HTTPS traffic to services inside the cluster.

• Key Features:
• Path-based routing (e.g., /app1, /app2)
• Host-based routing (e.g., app.example.com)
• TLS/SSL termination

ὓ Ingress Controller
• What it is:A controller that actually implements the Ingress resource. It listens
for changes to Ingress resources and configures a reverse proxy (like NGINX or
Traefik) accordingly.

• Popular Ingress Controllers:

• NGINX Ingress Controller (most common)
• Traefik
• HAProxy
• AWS ALB Ingress Controller
• Istio Gateway (as part of service mesh)
• Note: Ingress won’t work without an Ingress Controller running in your cluster.
ADD ONS:-

DaemonSet –
Definition:A DaemonSet ensures a specific pod runs on every node (or selected nodes) in a
Kubernetes cluster.

ὊUse Case:Used for deploying node-level services like log collectors, monitoring agents,
security tools, or network plugins.

Example:To monitor all nodes, a company deploys Prometheus Node Exporter as a

DaemonSet, ensuring metrics are collected from each node automatically.

Let me know if you need a visual summary or slide format.

COREDNS :-
CoreDNS is a flexible and extensible DNS server that acts as the default service discovery
mechanism in Kubernetes. It resolves service and Pod names to IP addresses inside the
cluster, allowing components to communicate using names instead of hardcoded IPs.
Use case:
1. Service Discovery:Pods use DNS names to find and connect to other services (like
databases, APIs).
2. Pod-to-Pod Communication:CoreDNS resolves internal DNS names so Pods can
communicate without needing IP addresses.

3. External Name Resolution:CoreDNS forwards unknown queries (e.g., google.com) to

upstream DNS servers like 8.8.8.