ITech With Om

08/05/2026

Defining the Role

At the top, the image defines a DevOps Engineer as someone who integrates **development** and **operations**. The primary goal is to:
* **Build** software efficiently.
* **Automate** manual processes.
* **Deliver** reliable updates to users at a fast

The DevOps Pipeline

The center of the image illustrates a typical **Continuous Integration/Continuous Deployment (CI/CD)** journey. It shows how code moves from a computer to a real-world user:
| Stage | Action | Tool Example |
|---|---|---|
| **Developer** | The starting point where code is written. | Local IDE |
| **GitHub** | Code is pushed to a central repository for version control. | Git |
| **CI/CD Pipeline** | The code is automatically built, tested, and verified. | Jenkins, GitLab CI |
| **Docker** | The application is "containerized" to ensure it runs anywhere. | Kubernetes (K8s) |
| **AWS Cloud** | The application is deployed to the cloud to scale for traffic. | Amazon Web Services |
| **Users** | The final stage where the live application reaches the audience. | Web/Mobile App |
> **The Loop:** A dotted line labeled **Monitor • Feedback • Improve** connects the "Users" back to the "Developer," highlighting that DevOps is a circular, iterative process rather than a straight line.
>
# # 3. Key Responsibilities
The bottom section highlights five pillars of what a DevOps Engineer actually does on a daily basis:
* **Automate:** They write scripts to handle repetitive tasks so humans don't have to do them manually.
* **Deploy:** They ensure that moving code from a test environment to a live environment is fast and error-free.
* **Scale:** They set up systems (like the cloud) so that if a million people visit a site at once, the servers don't crash.
* **Monitor:** They use dashboards to track the health of the system and catch bugs before users notice them.
* **Secure:** They integrate security check

08/05/2026

HPA
VPA

08/05/2026

15/03/2026

Taint & Tolerations

30/01/2026

🔍 Ingress vs LoadBalancer – Kubernetes Simplified

This visual highlights a key Kubernetes concept:

➡️ LoadBalancer exposes a single service directly
➡️ Ingress acts as a smart entry point, routing traffic to multiple services using HTTP rules

Choosing the right one helps with:

✔️ Better architecture design
✔️ Cost optimization
✔️ Scalable microservices

22/01/2026

In Kubernetes, Ingress and Ingress Controller work together to expose your applications to users outside the cluster (usually via HTTP/HTTPS).

1️⃣ What is Ingress?

Ingress is a Kubernetes API object that defines rules for routing external traffic to internal services.

👉 Think of Ingress as a traffic rulebook.

What Ingress does

Routes traffic based on:

Host (domain name)

Path (/api, /login, etc.)

Supports:

HTTP / HTTPS

TLS (SSL certificates)

Path-based and host-based routing

Example

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: app-ingress
spec:
rules:
- host: myapp.example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80

Simple flow

User → Ingress → Service → Pod

⚠️ Important:
Ingress does nothing by itself. It only contains rules.

2️⃣ What is an Ingress Controller?

Ingress Controller is the actual engine that:

Reads Ingress rules

Configures a load balancer / proxy

Routes traffic accordingly

👉 Think of it as the traffic police that enforces the rules.

Common Ingress Controllers

NGINX Ingress Controller (most popular)

HAProxy Ingress

Traefik

AWS ALB Ingress Controller

Azure Application Gateway Ingress Controller

What it does

Watches Kubernetes API for Ingress objects

Creates routing configs

Handles:

Load balancing

SSL termination

Path & host routing

Rewrite rules

3️⃣ Why both are needed?

Component Role

Ingress Defines what traffic rules should be
Ingress Controller Implements how traffic is handled

❌ Without Ingress Controller → Ingress rules won’t work
✅ Without Ingress → Controller has nothing to route

4️⃣ Real-world analogy

🏢 Office building

Ingress → Visitor policy (which floor for which department)

Ingress Controller → Security guard directing visitors

5️⃣ Ingress vs Service Type LoadBalancer

Feature Service LoadBalancer Ingress

Public IP One per service One for many services
Routing No path-based routing Yes
Cost Higher Lower
SSL Limited Advanced

6️⃣ When should you use Ingress?

✔ Multiple services behind one

20/01/2026

In Kubernetes, a Service is an abstraction that provides a stable network endpoint (IP + DNS) to access a set of Pods, even though Pods are ephemeral (they can be created, destroyed, or rescheduled).

🔹 Why Kubernetes Services are needed

Pods get dynamic IPs → they change when Pods restart

Applications need a fixed way to talk to Pods

Services solve this by:

Providing a stable IP/DNS

Load balancing traffic across Pods

Enabling internal and external access

🔹 How a Service works (internally)

1. Pods are created with labels

2. Service uses label selectors to find matching Pods

3. kube-proxy programs iptables/IPVS rules

4. Traffic sent to the Service is distributed across Pods

Client → Service (IP/DNS) → Pod1 / Pod2 / Pod3

🔹 Types of Kubernetes Services

1️⃣ ClusterIP (Default)

Accessible only inside the cluster

Used for internal communication

📌 Example:

Frontend → Backend

Backend → Database

apiVersion: v1
kind: Service
metadata:
name: backend-svc
spec:
type: ClusterIP
selector:
app: backend
ports:
- port: 80
targetPort: 8080

🧠 Use case: Microservices communication

---

2️⃣ NodePort

Exposes service on each node’s IP

Port range: 30000–32767

Accessible from outside the cluster

Client → NodeIP:NodePort → Service → Pods

📌 Example:

type: NodePort
ports:
- port: 80
targetPort: 8080
nodePort: 30007

🧠 Use case: Testing / non-production environments

⚠️ Not recommended for production

---

3️⃣ LoadBalancer

Creates an external cloud load balancer

Automatically assigns public IP

Supported in cloud providers (AWS, Azure, GCP)

Internet → Cloud LB → Service → Pods

📌 Example:

type: LoadBalancer

🧠 Use case: Exposing applications publicly

---

4️⃣ ExternalName

Maps Service to an external DNS name

No selector, no Pods

📌 Example:

apiVersion: v1
kind: Service
metadata:
name: external-db
spec:
type: ExternalName
externalName: db.example.com

🧠 Use case: Access external services like SaaS DB, APIs

---

5️⃣ Headless Service

clusterIP: None

No load balancing

Returns Pod IPs directly

📌 Example:

clusterIP: None

🧠 Use case:

StatefulSets

Databases (MySQL, Kafka)

16/01/2026

16/01/2026

A Pod is the smallest deployable unit in Kubernetes.
It represents one or more containers that run together on the same node.

15/01/2026

This is how a Kubernetes Pod is created and managed, and the two ways (Imperative vs Declarative) to create it in a Kubernetes cluster.

1️⃣ Cluster → Node → Pod → Container (Hierarchy)

Flow shown on the left side:

Cluster
The whole Kubernetes environment.

Node (Worker Node)
A VM or physical machine inside the cluster.
👉 Node has its own IP address

Pod

Smallest deployable unit in Kubernetes

Runs inside a Node

Gets a unique Pod IP

Acts as a wrapper around one or more containers

Container

Actual application (example: nginx)

Always runs inside a Pod

Shares Pod’s:

Network (same IP)

Storage (volumes)

📌 Key takeaway:
👉 Node IP ≠ Pod IP
👉 Containers do not get their own IP; they use the Pod IP.

2️⃣ Imperative vs Declarative Approach

🔹 Imperative (Command-based)

Shown at the bottom-left:

kubectl run nginx-pod --image=nginx:latest

You tell Kubernetes WHAT to do right now

Fast & simple

Mostly used for:

Testing

Learning

Temporary
---

🔹 Declarative (YAML / JSON)

Shown on the right side (Pod YAML):

apiVersion: v1
kind: Pod
metadata:
name: pod-nginx
namespace: default
labels:
app: nginx
type: front-end
spec:
containers:
- name: nginx-container
image: nginx:1.18

Applied using:

kubectl create -f pod.yaml
# or
kubectl apply -f pod.yaml

You describe DESIRED STATE

Kubernetes ensures reality matches the YAML

Best for:

Production

CI/CD

GitOps

✅ Version controlled
✅ Reproducible
✅ Scalable & reliable

3️⃣ What the YAML Parts Mean

Section Purpose

apiVersion: v1 Kubernetes API version
kind: Pod Type of object
metadata Name, namespace, labels
labels Used by Services, selectors
spec Desired state
containers Application definition
image Docker image to run

What this image teaches

✔ Pod is a logical wrapper around containers
✔ Pod lives inside a node
✔ Pod gets its own IP
✔ Containers share Pod networking
✔ Two creation styles:

Imperative → quick commands

Declarative → YAML (recommended)