KUBERNETES

Tejas Pokale
1
 INDEX
Sr.no TOPICS COVER

1 Introduction to Kubernetes

2 Kubernetes Installation

3 Pod creation

4 Kubernetes service

5 Replication Controller

6 Replica Set

7 Deployment

8 Health Probe

9 Namespace

10 Volume

11 DaemonSet

12 Job

13 StatefulSet

14 Horizontal PodAutoscaling

15 Ingress

2
Introduction to Kubernetes
Kubernetes (K8s) is an open-source platform for automating the deployment, scaling, and

management of containerized applications. Originally developed by Google and now maintained by the
Cloud Native Computing Foundation (CNCF), Kubernetes has become the industry standard for
container orchestration.

Why Kubernetes?

Managing containers at scale is challenging. Kubernetes simplifies this by providing:

• Automation: Handles deployment and scaling.

• Resilience: Self-healing and failover capabilities.

• Efficiency: Optimizes resources for performance and cost.

Key Features of Kubernetes

1. Automated Scheduling: Places containers on the best-suited nodes.

2. Self-Healing: Restarts failed containers and reschedules them as needed.

3. Load Balancing: Ensures traffic is evenly distributed across containers.

4. Storage Orchestration: Connects containers to different storage solutions.

5. Rolling Updates and Rollbacks: Ensures smooth updates with minimal downtime.

6. Declarative Configurations: Uses YAML/JSON for easy management.

Core Components

• Cluster: A group of nodes, managed by Kubernetes, running your applications.

• Pod: The smallest deployable unit, which can contain one or more containers.

• Node: A worker machine that runs pods.

• Service: Ensures stable communication between pods and external users.

• ConfigMap & Secret: Stores configurations and sensitive data securely.

• Ingress: Manages external access to services.

3
Why Use Kubernetes?

• Portability: Runs on any infrastructure—cloud, on-premises, or hybrid.

• Scalability: Easily handles growing workloads.

• Resilience: Provides high availability and fault tolerance.

Applications of Kubernetes

• Running microservices and distributed systems.

• Managing cloud-native applications.

• Scaling batch processing jobs.

• Automating CI/CD pipelines for faster delivery.

4
Kubernetes Installation on Ubuntu Linux
Step 1: Update and Install Required Dependencies

commands on both master and worker nodes:

sudo apt-get update -y

sudo apt-get install docker.io -y

sudo apt-get install -y apt-transport-https ca-certificates curl gnupg

sudo mkdir -p /etc/apt/keyrings

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o

/etc/apt/keyrings/kubernetes-apt-keyring.gpg

sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg]

https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list

sudo apt-get install -y kubectl kubeadm kubelet

5
Step 2: Setup Master Node

Run the following commands only on the Master Node:

sudo kubeadm init --ignore-preflight-errors=all

mkdir -p $HOME/.kube

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

sudo chown $(id -u):$(id -g) $HOME/.kube/config

kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.0/manifests/calico.yaml

kubeadm token create --print-join-command

• The kubeadm token create --print-join-command command generates the token and join
command for worker nodes.

• Copy the output for use in the next step.

Step 3: Open Required Port

• Open port 6443 on both master and worker nodes to ensure communication between them.

Step 4: Join Worker Nodes

Run the kubeadm join command generated on the master node on each Worker Node:

sudo kubeadm join <master_ip>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

Step 5: Verify Cluster Setup

Run the following on the Master Node to check the status of the nodes:

kubectl get nodes

This command should display all nodes (master and workers) with their status.

6
Check pods

Kubectl get pods

To check master node pods

Kubectl get pods -n kube-system

Create a directory

mkdir nginxpod

Create .yml file

Nano nginxpod.yml

7
Nginxpod.yml file

Kubectl appy -f nginxpod.yml

Sudo crictl ps

8
Kubectl pet pod -o wide

Kubectl describe pod (pod name)

Kubectl logs nginxpod(pod name)

Kubectl exec -it nginxpod /bin/bash

9
Kubernetes Services

A Service in Kubernetes allows stable communication between applications (Pods) and external users
or systems by abstracting the underlying Pods' dynamic nature.

Types of Kubernetes Services

1. ClusterIP (Default):

o Accessible only within the cluster.

o Used for internal communication between Pods and other cluster components.

2. NodePort:

o Exposes the Service on a specific port of each cluster node.

o Allows external access using <NodeIP>:<NodePort>.

o Suitable for basic external connectivity.

3. LoadBalancer:

o Integrates with cloud providers to create an external load balancer.

o Automatically allocates an external IP for access.

o Ideal for scaling and production-grade applications.

4. ExternalName:

o Maps the Service to an external DNS name.

o No traffic routing; directly resolves to the external resource.

Key Use Cases

• ClusterIP: Internal microservices communication.

• NodePort: Testing and exposing services during development.

• LoadBalancer: Production-level external traffic handling.

• ExternalName: Accessing external databases or APIs.

NodePort: for debugging and testing

create .yml file

10
 nano myservice.yml

myservice.yml

Kubectl appy -f myservice.yml

Kubectl get services

11
Kubectl get pod

Kubectl get services -o wide

Create html page

Check on browse

12
LOAD BALANCER

Copy existing myservice.yml file to loadwalaservice.yml

nano loadwalaservice.yml

Kubectl apply -f loadwalaservice.yml

Kubectl get services

13
Launch the load balancer manually

Create the target group

14
Edit security group

Create new index.htm page and show loadbalancing. pod name is different but labale is same

15
Copy ip and paste it to browser

Replication Controller, ReplicaSet, and Scaling in Kubernetes

• Replication Controller:

o Ensures a specified number of pod replicas are running.

o Deprecated in favor of ReplicaSet.

• ReplicaSet:

16
 o Manages pod replicas with more flexible selectors.

o Works with Deployments for rolling updates.

• Scaling:

o Manual Scaling: Adjust the number of replicas manually.

o Autoscaling: Pods are scaled automatically based on metrics like CPU usage (via
Horizontal Pod Autoscaler)

Replication Controller

Mkdir replicationcontrollerwala

Cd replicationcontrollerwala

Create .yml file

nano myreplica.yml

Kubectl apply -f myreplica.yml

Kubectl get rc

Kubectl get pod

17
To check self healing

Kubectl get pods -l env=prod

Kubectl get pods -l env

kubectl get pods -l app

18
Change lable

Cp myreplica.yml youreplica.yml

Cp myreplica.yml ourreplica.yml

19
Nano yourreplica.yml

Nano ourreplica.yml

Kubectl apply -f youreplica.yml

Kubectl apply -f oureplica.yml

Kubectl get rc-o wide

20
Kubectl get rc -o wide

Kubectl get rs -o wide

Scaling:

Kubectl scale rc myrc –replicase

Kubectl get pod

21
nano myreplica.yml

nano ourreplica.yml

22
Kubectl apply -f myreplica.yml

Kubectl apply -f youreplica.yml

Kubectl apply -f ourreplica.yml

Kubectl get rc -o wide

Kubectl get rs -o wide

23
To show selectors

Kubectl get replicationcontroller -o wide

Kubectl get pods -l env=dev

Change lables

cp myreplica.yml yourreplica.yml

cp myreplica.yml ourreplical.yml

24
nano yourreplica.yml

nano ourreplica.yml

kubectl get pods -l env=prod

kubectl get pods -l env

kubectl get pod -l env

25
ReplicaSet

Cd replicasetwala

Nano replica.yml

26
Nanoourreplica.yml

Nano yourreplica.yml

kubectl apply -f myreplica.yml

kubectl apply -f youreplica.yml

kubectl apply -f ourreplica.yml

kubectl rc grt -o wide

kubectl rs grt -o wide

27
Kubectl get pods -l env

Kubectl get pod -l env=dev

Kubectl get pod --selector ’env in {dev,testing}’

28
DEPLOYMENT

Mkdir deploymentwala

Cd mydeploymentwala

nano mynginx.yml

29
Mynginx.yml

kubectl apply -f mynginx.yml

kubectl get all

Version change(by command)

Kubctl set image deployment/meridep ngintconaner

Kubectl rollout status deployment meridep

30
Version (change by .yml file)

Nano mynginx.yml

kubectl rollout history deployment meridep

kubectl rollout undo deploy meridep -- to—revision=2

klubectl annotate deployments.apps meridep kubernetes.io/change-cause”nayahai”

31
Statergy

Nano sat.yml

Kubectl apply -f stat.yml

kubectl rollout undo deploy meridep -- to—revision=2

kubectl rollout history deployment meridep

32
HEALTHPROBE

In Kubernetes, a health probe is a mechanism used by the Kubernetes system to monitor the health of
applications running in a container. Kubernetes uses these probes to determine if a container is
healthy or unhealthy. There are two main types of health probes:

1. Liveness Probe

o Checks whether the application inside a container is still running.

o If the liveness probe fails, Kubernetes kills the container and restarts it (based on the
pod's restart policy).

o Use Case: To detect and remedy situations where the application is in a deadlock or not
responding.

2. Readiness Probe

o Checks whether the application inside a container is ready to serve requests.

o If the readiness probe fails, Kubernetes removes the pod from the Service's endpoints,
so it doesn’t receive traffic.

o Use Case: To ensure that the application has completed its startup process and is ready
to handle requests.

3. Startup Probe

• It ensures that the application is fully initialized before Kubernetes considers it "live."

• During the startup phase, Liveness Probes are disabled to avoid restarting the container
prematurely.

• Once the Startup Probe succeeds, Kubernetes switches to using the Liveness Probe (if
configured) for ongoing health checks.

33
Liveness Probe

Kubectl apply -f health.yml

Kubectl get pod

Kubectl delete pod (pod name)

new pod is created

Liveness Probe

34
Livenessprobe.yml

35
Readiness Probe

36
Startup Probe:

37
Namespaces in Kubernetes

A namespace in Kubernetes is a virtual cluster that provides logical isolation for resources within the
same physical cluster. It is primarily used for organizing and managing workloads, enabling multi-
tenancy, and implementing access controls in Kubernetes environments

Purpose of Namespaces

1. Resource Isolation: Separate workloads and resources to avoid conflicts.

2. Access Management: Control user and team access to specific resources.

3. Resource Organization: Structure resources based on projects, teams, or environments.

4. Multi-Tenancy: Enable multiple users or teams to share the same Kubernetes cluster securely.

Default Namespaces

1. default: The namespace used when no specific namespace is assigned.

2. kube-system: Contains Kubernetes system components (e.g., API server, scheduler).

3. kube-public: Accessible by all users and used for public resources.

4. kube-node-lease: Stores node heartbeat leases to enhance performance of node health

monitoring.

User-Defined Namespaces

Users can create custom namespaces to organize resources for specific purposes, such as:

• Projects or teams (e.g., team-a, team-b).

• Environments (e.g., dev, staging, prod).

Key Features

1. Logical Isolation: Workloads in one namespace are independent of those in another.

2. Scoped Resources: Namespaces group resources such as pods, services, and deployments.

3. Role-Based Access Control (RBAC): Assign granular access permissions per namespace.

4. Resource Quotas: Limit CPU, memory, and other resource usage within a namespace.

38
How Namespaces Work

• Resources are scoped to a namespace unless they are cluster-wide (e.g., nodes, storage
classes).

• Users can specify the namespace in commands or set a default namespace for ease of use.

Managing Namespaces

39
Namespace by using.ymlfile

40
Volumes in Kubernetes

A volume in Kubernetes is a directory that can be accessed by containers in a pod. It enables data to
persist across container restarts and allows containers within the same pod to share data. Volumes
address the ephemeral nature of container storage, making it suitable for applications requiring
stateful data or configuration.

Purpose of Volumes

1. Persistent Storage: Retain data even if a container restarts.

2. Data Sharing: Enable data sharing between containers in the same pod.

3. Flexible Configuration: Pass configuration or secrets securely to containers.

Types of Volumes in Kubernetes

1. EmptyDir

o Definition: A temporary volume that is created when a pod starts and deleted when the
pod stops.

o Use Case: Suitable for temporary data such as caches, scratch space, or intermediate
files.

o Key Characteristics:

▪ Data is lost when the pod is deleted.

▪ All containers in the pod can access the data.

2. HostPath

o Definition: A volume that maps a file or directory from the node’s filesystem into the pod.

o Use Case: Useful for accessing specific files or directories on the host machine, such as
logs or system-level resources.

o Key Characteristics:

▪ Tightly coupled with the host node, making pods less portable.

▪ Requires careful configuration to avoid security risks.

3. PersistentVolumeClaim (PVC)

41
 o Definition: A mechanism to request and claim persistent storage resources. PVCs bind
to PersistentVolumes, which represent actual storage, such as network storage or cloud-
based volumes.

o Use Case: Suitable for applications requiring persistent storage that survives pod
restarts or re-creation.

o Key Characteristics:

▪ Decouples storage from pods, making it reusable and portable.

▪ Supports dynamic provisioning with storage classes.

4. ConfigMap

o Definition: A volume that injects configuration data into containers as files or

environment variables.

o Use Case: Ideal for storing non-sensitive configuration data such as environment
settings, configuration files, or command-line arguments.

o Key Characteristics:

▪ Centralizes configuration management.

▪ Enables updates to configuration without restarting containers.

5. Secret

o Definition: A volume specifically designed to securely pass sensitive information like

passwords, tokens, or API keys to containers.

o Use Case: Essential for securely managing sensitive data in applications.

o Key Characteristics:

▪ Encrypted at rest within the Kubernetes cluster.

▪ Accessible as environment variables or mounted files in containers.

▪ Ensures sensitive data is not hard-coded into container images or application

code.

42
EmptyDir

HostPath

43
Nfs

44
Config map

45
By using another imge nginx

Config.file

46
47
Secret

48
PersistentVolumeClaim (PVC)

49
50
DaemonSet in Kubernetes

A DaemonSet in Kubernetes is a controller that ensures a copy of a specific pod runs on all (or
selected) nodes in the cluster. It is typically used to deploy background system-level services or
applications that need to run on every node.

Purpose of DaemonSet

1. System Monitoring: Deploying monitoring agents (e.g., Prometheus Node Exporter, Fluentd).

2. Log Aggregation: Running log collection agents on every node.

3. Networking: Setting up network components such as DNS services or proxies (e.g., CoreDNS,
kube-proxy).

4. Custom Node Tasks: Running tasks specific to each node, such as node health checks or
backups.

Key Features of DaemonSet

1. One Pod per Node: Ensures exactly one pod is running per eligible node.

2. Node Selection: Can restrict pods to specific nodes using labels and node selectors.

3. Automatic Updates: New nodes automatically get the DaemonSet pods upon joining the cluster.

4. Controlled Deletion: When deleted, the associated pods are removed from the nodes.

How DaemonSet Works

1. Deployment:

o DaemonSets deploy pods based on a defined configuration, and Kubernetes ensures that
one pod is scheduled per node.

2. Targeting Nodes:

o Node Selector: Specifies which nodes the DaemonSet should target.

o Taints and Tolerations: Configures pods to tolerate specific taints on nodes.

o Affinity Rules: Fine-tunes node selection using affinity and anti-affinity rules.

3. Updates:

o Rolling updates can be performed to update the pods managed by a DaemonSet.

51
Creating a DaemonSet

52
Jobs in Kubernetes

A Job in Kubernetes is a controller that ensures a specified number of pods successfully complete a
task. Unlike Deployments, which maintain a set number of running pods, Jobs are used for batch
processing and tasks that have a definite completion point. Once the task is completed, the pods are
terminated.

Purpose of Jobs

1. Batch Processing: Running tasks that need to be completed once (e.g., data processing,
backups).

2. One-Time Operations: Executing one-off tasks that don't need to be continuously running.

3. Data Migration: Performing tasks like database migration or initialization.

4. ETL Tasks: Running Extract, Transform, Load (ETL) jobs that are periodic or triggered.

Key Features of Jobs

1. Task Completion: Jobs ensure that a task is successfully completed, retrying pods in case of
failure.

2. Pod Management: Creates one or more pods and tracks their completion.

3. Parallel Execution: Supports running multiple pods in parallel to complete the task faster.

4. Pod Retry Mechanism: Automatically retries failed pods until the desired number of
completions is achieved.

5. Graceful Termination: When the task completes, the associated pods are terminated.

How Jobs Work

1. Specifying Desired Completions:

o A Job will continue running pods until the specified number of completions is reached.

o This number can be defined using the completions field in the Job's specification.

2. Pod Management:

o The Job controller creates pods to run the specified task and monitors their completion.

Once the task is completed successfully, the pod terminates.

3. Retry Mechanism:

o If a pod fails to complete the task, the Job controller will retry the pod. The number of
retries can be controlled via the backoffLimit field.

53
4. Parallelism:

o Jobs can be configured to run multiple pods simultaneously using the parallelism field.
This can speed up completion when the task is divisible

54
55
CronJob in Kubernetes

A CronJob in Kubernetes is a resource used to run jobs on a scheduled basis, much like cron jobs in
Linux. It allows you to run batch jobs or tasks at specific times or intervals, providing powerful
scheduling capabilities in Kubernetes.

Purpose of CronJob

1. Scheduled Tasks: Run tasks at regular intervals, such as backups, database cleanup, and
periodic reporting.

2. Periodic Jobs: Automate recurring tasks that need to be executed on a schedule.

3. Task Automation: Eliminate the need for manual intervention for repetitive tasks.

How CronJob Works

1. Cron-like Scheduling:

o CronJobs are based on a cron expression (a string that defines time intervals), which
specifies when the job should run.

o The cron format is: * * * * * (minute, hour, day of month, month, day of week).

2. Job Creation:

o CronJobs automatically create Jobs according to the schedule defined by the cron
expression.

o The job runs at the specified time and completes its task.

3. Job Execution:

o The CronJob creates a new Job and ensures that the associated task (specified in the
Job template) is executed as a pod.

o After the pod completes successfully, the job is considered finished.

4. Concurrency Policy:

o CronJobs allow you to control how multiple jobs should be handled when the scheduled
time occurs:

▪ Allow: Allows multiple jobs to run concurrently.

▪ Forbid: Prevents a new job from starting if the previous one hasn't completed.

▪ Replace: Terminates any currently running job and starts a new one.

56
 5. Time Zone:

o Kubernetes CronJobs use UTC time by default for scheduling.

o To handle time zone-specific schedules, you need to manage it outside of Kubernetes or

use external tools.

Creating a CronJob

*****

|||||

| | | | +---- Day of week (0 - 7) (Sunday = 0 or 7)

| | | +------ Month (1 - 12)

| | +-------- Day of month (1 - 31)

| +---------- Hour (0 - 23)

+------------ Minute (0 - 59)

57
StatefulSet in Kubernetes

A StatefulSet in Kubernetes is used to manage stateful applications that need stable identities and
persistent storage. This is different from a regular deployment where pods are stateless. StatefulSets
are ideal for applications like databases that require data to be saved and remain consistent even if
the pod is restarted or moved.

Why Use StatefulSet?

1. Stable Identity: Each pod in a StatefulSet gets a unique name (like mysql-0, mysql-1, etc.) that
doesn't change, even if the pod restarts.

2. Persistent Storage: Each pod gets its own dedicated storage that is preserved even if the pod
is rescheduled to another node.

3. Order of Deployment: Pods are created, updated, and deleted in a specific order. This is helpful
for apps that need to start in a particular sequence (e.g., databases).

4. Scaling: Pods in a StatefulSet are scaled in order (first pod-0, then pod-1, etc.), and scaling down
happens in reverse order.

How Does StatefulSet Work?

1. Stable Pod Names: Pods in a StatefulSet get stable, unique names that help other services
identify them easily.
58
2. Storage Persistence: Each pod has a PersistentVolume associated with it, which ensures the
data is retained even when pods are deleted or moved.

3. Ordered Deployment and Shutdown: Pods are created and deleted in a specific order, which is
important for some applications (like databases) where certain pods need to start before others.

4. Rolling Updates: When updating a StatefulSet, Kubernetes updates the pods one at a time,
ensuring minimal disruption.

59
 Horizontal Pod Autoscaler

Horizontal Pod Autoscaler (HPA) in Kubernetes automatically adjusts the number of pods in a
deployment based on resource usage (like CPU, memory) or custom metrics. It ensures efficient
resource utilization and handles varying workloads effectively.

Key Points:

• Scales pods up or down based on demand.

• Uses Metrics Server or custom metrics for scaling decisions.

• Configurable via YAML or CL

• Scales Pods: Automatically increases or decreases the number of pods based on application demand.
• Metrics-Based: Relies on Metrics Server or custom metrics (e.g., CPU, memory, or external metrics).
• Easy Configuration: Managed using YAML files or Kubernetes CLI commands for flexibility.

60
61
An Ingress in Kubernetes is an API object that manages external access to services within a cluster,
typically HTTP and HTTPS traffic. It acts as a smart router, allowing you to define rules for directing
traffic to the appropriate backend services.

Key Features of Ingress:

• HTTP/HTTPS Routing: Routes requests to services based on hostnames, paths, or both.

• Load Balancing: Distributes traffic across multiple pods.

• TLS Termination: Supports SSL/TLS for secure communication.

• Custom Rules: Define rules for complex traffic management.

This example routes traffic based on the hostname and path:

62
THE END

63