Docker → Builds and runs containers.
Kubernetes → Orchestrates containers across multiple nodes.

Key points:

• Docker = container runtime.

• Kubernetes = container orchestration tool.

• Kubernetes provides auto-healing, auto-scaling, load balancing.

• Kubernetes runs on a cluster → if one node fails, workloads shift automatically.

2. Main Components of Kubernetes Architecture

Control Plane

• API Server → Entry point for all commands.

• Scheduler → Decides which node runs a pod.

• etcd → Key-value store for cluster state.

• Controller Manager → Runs controllers like ReplicaSet, Node Controller, Job Controller.

• Cloud Controller Manager → Integrates with cloud providers (e.g., creates LoadBalancer IPs).

Worker Node

• kubelet → Ensures pods run and are healthy.

• kube-proxy → Manages networking rules and service routing.

• Container Runtime → Docker, containerd, CRI-O, etc.

3. Docker Swarm vs Kubernetes

Docker Swarm

• Simple and easy.

• Limited networking and scaling.

• Good for small workloads.

Kubernetes

• Highly scalable, flexible.

• Advanced networking (CNI).

• Large ecosystem & community.

• Industry standard for production.

4. Docker Container vs Kubernetes Pod

• Container → Single isolated runtime.

• Pod → Kubernetes unit that can contain one or more containers.

• Containers in a pod share:

  • Network namespace

  • Storage volumes

  • Lifecycle

Pod = wrapper around one or more containers.

5. What is a Namespace?

Namespace provides logical isolation within a Kubernetes cluster.

Use cases:

• Multi-project isolation

• Resource separation

• Independent RBAC policies

• Isolated services, configs, secrets

6. Role of kube-proxy

kube-proxy:

• Manages network rules on nodes

• Updates iptables/ipvs

• Routes service traffic to appropriate pods

• Enables ClusterIP, NodePort, LoadBalancer traffic flow

7. Types of Kubernetes Services

ClusterIP

• Default type

• Internal access only

• Used for service-to-service communication

NodePort

• Opens a port on each node

• External access via NodeIP:Port

LoadBalancer

• Creates cloud load balancer

• Exposes app to the internet

8. Difference Between NodePort and LoadBalancer

NodePort

• Access via NodeIP:NodePort

• Limited to your cluster/node network

• No external load balancing

LoadBalancer

• Cloud provider allocates a public IP

• Global reach over the internet

• Adds external LB + NodePort behind the scenes

9. Role of kubelet

kubelet:

• Ensures pods are running

• Reports pod/node status to API server

• Restarts containers if required

• Handles pod lifecycle management

10. Day-to-Day Kubernetes Activities (DevOps Engineer)

A strong interview-ready answer:

• Deploy and manage applications on Kubernetes

• Monitor cluster health and workloads

• Troubleshoot pod failures, service issues, networking problems

• Handle upgrades and maintenance of master/worker nodes

• Manage RBAC, namespaces, resource quotas

• Support developers with deployment issues

• Manage CI/CD pipeline deployments to Kubernetes

• Handle cluster security, patching, vulnerabilities

• Operate logging and monitoring (Prometheus, Grafana, Loki, EFK)

✅ WHY MONITORING?

If you have only one Kubernetes cluster, monitoring is easy.
But in a real company:

• Multiple teams use the same cluster.

• Teams complain: “My deployment is not receiving requests”, or “Service was down for some time.”

• You may have multiple clusters: dev, staging, prod.

As clusters increase, you need a monitoring solution to understand:

• What is happening inside your clusters?

• Which deployment is down?

• Is API server healthy?

• Are replica counts matching?

• Are nodes running or not?

✅ WHY PROMETHEUS?

Prometheus was created by SoundCloud and is now completely open-source.

Prometheus:

• Scrapes metrics from Kubernetes.

• Stores metrics in a Time Series Database.

• Can trigger alerts using Alertmanager.

• Provides a UI for running PromQL queries.

✅ WHY GRAFANA?

Prometheus gives output but not visually appealing.

Grafana:

• Connects to Prometheus as a data source.

• Visualizes data using dashboards.

• Makes metrics easy to understand.

✅ PROMETHEUS ARCHITECTURE (Simple Explanation)

Prometheus includes:

1️⃣ Prometheus Server

• Scrapes metrics from Kubernetes API Server.

• Stores metrics in time-series format on disk.

2️⃣ Kubernetes API Server

• Exposes built-in metrics at:
  /metrics

• Shows default cluster metrics.

3️⃣ Alertmanager

• Prometheus pushes alerts to it.

• Alertmanager sends notifications (Slack, Email, etc.).

4️⃣ PromQL Interface

• Used in Prometheus UI or Grafana to run queries.

5️⃣ External Access

• Grafana pulls data from Prometheus.

• Tools like curl or Postman can also query Prometheus APIs.

✅ GRAFANA USE

Grafana helps visualize Prometheus data through graphs and dashboards.

✅ DEMO: INSTALL PROMETHEUS + GRAFANA ON MINIKUBE

We create a Kubernetes cluster using Minikube:

minikube start --memory=4096 --driver=hyperkit

(Use hyperkit on Mac, VirtualBox or Docker on other systems.)

🔥 INSTALL PROMETHEUS USING HELM

1. Add the Prometheus Helm repo:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

2. Install Prometheus:

helm install prometheus prometheus-community/prometheus

3. Check pods:

kubectl get pods -A

You will see:

• Prometheus server

• Prometheus alertmanager

• kube-state-metrics

• node-exporter

❗ kube-state-metrics

This component provides extra Kubernetes metrics NOT available in the Kubernetes API server.
It exposes metrics for:

• Deployments

• Daemonsets

• Pods

• ReplicaSets

• Services

• Replica count

• Desired vs Actual state

Without kube-state-metrics you only get basic Kubernetes metrics.

🔥 EXPOSE PROMETHEUS SERVER USING NODEPORT

Default service is ClusterIP, so expose it:

kubectl expose service prometheus-server --type=NodePort --name=prometheus-server-ext

Get service:

kubectl get svc

Use Minikube IP:

minikube ip

Open Prometheus:

http://<minikube-ip>:<node-port>

You can now run PromQL queries.

🔥 INSTALL GRAFANA USING HELM

1. Add Grafana repo:

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

2. Install Grafana:

helm install grafana grafana/grafana

3. Get admin password:

kubectl get secret -n default grafana -o jsonpath="{.data.admin-password}" | base64 --decode

4. Expose Grafana:

kubectl expose service grafana --type=NodePort --name=grafana-ext

5. Access Grafana:

http://<minikube-ip>:<node-port>

Login using:

• User: admin

• Password: (from command above)

🔥 ADD PROMETHEUS AS A DATASOURCE IN GRAFANA

Grafana → Data Sources → Add → Select Prometheus

Enter URL:

http://<minikube-ip>:<prometheus-nodeport>

Save & Test → should show Data source is working.

🔥 IMPORT KUBERNETES DASHBOARD (ID: 3662)

Grafana → Dashboards → Import → Enter ID:

3662

Select data source = Prometheus → Import.

A beautiful Kubernetes dashboard appears showing:

• API server health

• Nodes

• CPU & Memory usage

• Cluster info

• Pod counts

• Node uptime

🔥 ENABLE kube-state-metrics FOR DEPLOYMENT-LEVEL METRICS

Expose kube-state-metrics:

kubectl expose service prometheus-kube-state-metrics --type=NodePort --name=kube-state-metrics-ext --target-port=8080

Get NodePort:

kubectl get svc

Open:

http://<minikube-ip>:<nodeport>/metrics

Now you will see deployment-level, pod-level, and service-level metrics.

These metrics appear inside your Grafana dashboards.

🎉 END RESULT

You successfully installed:

✔️ Kubernetes Cluster (Minikube)
✔️ Prometheus
✔️ Grafana
✔️ kube-state-metrics
✔️ Kubernetes monitoring dashboard (ID: 3662)

Now your Grafana shows:

• Nodes

• API Server

• Pods

• Deployments

• Resource usage

• Replica counts

• Cluster uptime

• Realtime metrics

A ConfigMap is used to store non-sensitive configuration data that your application needs — such as:

• Database port

• Connection type

• Any general configuration values

In normal applications (non-Kubernetes), developers normally store such info using:

• Environment variables

• Configuration files

• OS environment values

Why? Because you should never hardcode values inside an application, especially because they might change in future.

⭐ In Kubernetes, a ConfigMap helps you store such non-sensitive values and inject them into Pods:

You can inject ConfigMap data into a Pod as:

1. Environment Variables, or

2. Files using Volume Mounts

2. Why do Secrets exist if ConfigMaps already store data?

Because ConfigMaps store data in plain text.

In Kubernetes:

• All resources (Pods, Deployments, ConfigMaps, etc.) are stored in etcd.

• ConfigMap values are NOT encrypted in etcd.

If a hacker gains access to etcd, they can read ConfigMap data easily.

But for sensitive data like:

• DB Password

• API Keys

• Token

• Certificates

Kubernetes provides Secrets.

3. What is a Secret? Why is it different?

A Secret is used to store sensitive information.

Kubernetes Secrets provide security in two major ways:

1. Secrets are encrypted at rest (in etcd)

Before storing Secrets in etcd, Kubernetes encrypts the values.
Even if someone gets etcd access, they cannot read the contents without the decryption key.

2. You can enforce strong RBAC on Secrets

You can configure RBAC so that:

• Developers can access Pods, Deployments, ConfigMaps

• But cannot access Secrets

This protects sensitive data even more.

4. ConfigMap vs Secret — Interview Style Answer

Both are used to pass data into Pods, but:

• ConfigMap = non-sensitive

• Secret = sensitive

5. How Kubernetes handles ConfigMap & Secret creation

When you create:

• ConfigMap or

• Secret

using kubectl apply -f file.yaml:

✔ The API server takes the YAML
✔ Stores it inside etcd
✔ Makes it available for Pods

6. Problem with environment variable updates

If you use ConfigMap as environment variables, there is a limitation:

❗ If ConfigMap value changes → existing Pods will NOT update automatically.

Why?

Because container environment variables cannot be changed without restarting the container.

This is a well-known container limitation.

Solution

Use volume mounts instead of environment variables.

7. Using ConfigMap as a Volume Mount

When you mount a ConfigMap as a volume:

• Kubernetes maps each key-value pair as a separate file.

• When the ConfigMap updates:

  • Kubernetes updates the file contents inside the container automatically

  • Without restarting the Pod

This is extremely useful for dynamic configuration.

Example:

/opt/DBPort

contains:

3306

If ConfigMap changes to 3307, the file updates automatically in 2–10 seconds.

8. Why volume mount method is more dynamic

✔ Pod does NOT restart
✔ Container does NOT restart
✔ File content updates automatically
✔ Application can read updated values

If your app watches the file, it can adjust configuration dynamically.

9. Secrets work the exact same way

Just like ConfigMaps:

✔ Secrets can be injected

• As environment variables, or

• As volume mounts

✔ Updating the Secret updates the mounted file automatically.

✔ But environment variables still require Pod restart.

10. Bonus: Types of Secrets

Kubernetes supports:

• generic (normal key-value)

• docker-registry

• tls (for certificates)

• opaque (default)

• service account token secrets

Conclusion

Your full explanation boils down to this:

⭐ ConfigMap

Used to store non-sensitive configuration.
Can be used as environment variables or mounted as files.

⭐ Secret

Used to store sensitive configuration.
Encrypted in etcd and protected by RBAC.

⭐ Environment variable method

Dynamic updates do not reflect without Pod restart.

⭐ Volume mount method

Dynamic updates reflect automatically inside the container.

• Deployment

• Service

• Pod

• ConfigMap

• Secret

• Ingress

These are called native resources.

Sometimes companies (Istio, ArgoCD, Prometheus Operator, Kyverno, etc.) want to add new features that Kubernetes does not support by default.

To do this, Kubernetes allows you to:

👉 Extend the Kubernetes API
This extension is done using:

1. CRD — Custom Resource Definition

2. CR — Custom Resource

3. Custom Controller

🟦 1. CRD — Custom Resource Definition

CRD = Definition / Schema of a new Kubernetes API.

It tells Kubernetes:

• What is the name of the new resource?

• What are the fields allowed?

• What is the API version and kind?

• What does the YAML structure look like?

Example: Istio defines a new resource called VirtualService.

Istio provides a CRD so Kubernetes understands:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService

CRD is installed once by DevOps engineers (usually via Helm or operator).

Purpose of CRD:

✔ Introduces a new type of resource into Kubernetes
✔ Validates all CR created by users
✔ Extends Kubernetes API

🟦 2. CR — Custom Resource

CR = User-created object based on the CRD.

Example: After installing the Istio VirtualService CRD, a user can create:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app
spec:
  ...

This YAML is the Custom Resource.

Summary:

• CRD = Template / Model / Schema

• CR = Actual object created by the user

Same logic as:

• Deployment resource definition (built-in)

• Deployment YAML (your object)

🟦 3. Custom Controller

CRD + CR alone do nothing.
Like Ingress without an Ingress controller → useless.

A Custom Controller is required to watch the CR and take action.

For example:

In Istio:

• VirtualService CRDs define the API

• VirtualService CRs define the config

• Istio Controller watches those CRs

• Then configures Envoy proxy accordingly

Controller Responsibilities:

✔ Watches for create / update / delete of CR
✔ Performs actions on cluster
✔ Maintains desired state

⭐ Flow Diagram (Short & Clear)

DevOps Engineer:
    1. Install CRD → Adds new API to Kubernetes
    2. Install Controller → Logic to handle CRs

User / Developer:
    3. Creates Custom Resource (CR)

Controller:
    4. Watches CR
    5. Performs required actions

⭐ Simple Example Using Istio

Step 1: DevOps installs CRDs

Istio CRDs include:

• VirtualService

• DestinationRule

• Gateway

• PeerAuthentication
  …

Step 2: DevOps installs Istio Controller

This controller will watch all Istio CRs.

Step 3: User creates CR

kind: VirtualService
...

Step 4: Istio Controller sees it and configures Envoy proxies.

⭐ How Custom Controllers Are Written

Usually written in Go because:

• Kubernetes itself is written in Go

• Official client library client-go

• Best support + ecosystem

Process (high-level):

1. Set watchers for CR events (Add/Update/Delete)

2. Add events to a workqueue

3. Process each event

4. Take action → create/update Kubernetes resources or external systems

Frameworks used:

• controller-runtime

• operator-sdk (for building operators)

⭐ Key Points to Remember (Interview-Friendly)

• CRD adds a new resource type to Kubernetes.

• CR is an instance of that resource.

• Controller makes the CR actually do something.

• CRD = schema, CR = object, Controller = brain/logic.

• Without the controller, CR does nothing.

When a Pod is created in Kubernetes, it receives a dynamic IP address.
If the Pod dies and restarts, its IP changes.
So other Pods (like checkout → payments) cannot rely on Pod IP because it changes, creating issues like 404 Not Found when trying to call the old IP.

Solution → Kubernetes Service

A Service gives a stable virtual IP (ClusterIP) that stays constant even if Pods change.

2. Types of Kubernetes Services

(1) ClusterIP (default)

• Only accessible inside the cluster

• Used for internal communication (e.g., checkout → payments)

(2) NodePort

• Exposes service on each node via a port between 30000–32767

• Access: NodeIP:NodePort

• Problems:

  • Random high port → cannot open all ports in firewall

  • Nodes might not be accessible from outside

  • Not secure for production

(3) LoadBalancer

• Cloud provider provisions an external IP

• Works well on AWS, Azure, GCP

• Drawbacks:

  • One LoadBalancer = one external IP

  • Expensive when you have many services (100+ services = 100+ LoadBalancers)

LoadBalancer on bare metal?

Yes. Use MetalLB (CNCF project) to simulate LoadBalancer in on-prem or home labs.

3. Why We Need Ingress

LoadBalancer works but becomes expensive and hard to manage if you have many services.

Ingress solves 2 big problems:

1. Reduce cost

One public IP → route traffic to many services
example.com/login
example.com/checkout
example.com/payments

2. Advanced routing

Ingress supports:

• Host-based routing (foo.example.com)

• Path-based routing (/checkout, /pay)

• Wildcards (*.example.com)

• Authentication (BasicAuth)

• Web Application Firewall (in some controllers)

• TLS/SSL termination

4. What Is an Ingress?

An Ingress is a Kubernetes object containing traffic-routing rules:

• Which host goes to which service

• Which path goes where

• TLS settings

But Ingress alone does nothing.

5. What Is an Ingress Controller?

It is a software component that:

1. Watches Ingress resources

2. Reads routing rules

3. Updates its internal load balancer (e.g., nginx.conf)

Examples:

• NGINX Ingress Controller

• HAProxy Ingress

• Traefik

• Istio Gateway

• F5

• ALB Ingress (AWS)

• Contour

• ~30+ others

How it works:

• You install the ingress controller

• It runs inside the cluster (except big enterprise LBs)

• It watches all Ingress objects

• It writes config (e.g., /etc/nginx/nginx.conf)

• It handles client traffic and routes correctly

6. Path-Based & Host-Based Routing (Concept)

Host-based routing

foo.example.com → service A
bar.example.com → service B

Path-based routing

example.com/checkout → checkout-service
example.com/payments → payments-service

Wildcard host (*)

*.bar.com → same service

Wildcards are commonly used with TLS (wildcard certificates).

7. TLS / SSL in Ingress

There are 3 ways to handle HTTPS in Ingress:

7.1 SSL Passthrough

How it works:

• Load balancer does not decrypt

• Traffic passes encrypted directly to the backend

• Backend Pod decrypts the request

Pros:

• End-to-end encryption

• Maximum privacy (LB can’t see traffic)

Cons:

• Load balancer cannot:

  • inspect packets

  • block attacks

  • do routing based on URL path

• Backend service handles expensive SSL decryption → higher CPU usage

• LB acts only as TCP forwarder → fewer features

7.2 SSL Offloading (SSL Termination)

How it works:

• Load balancer decrypts traffic

• Sends HTTP (unencrypted) traffic to backend services

Pros:

• Fastest (backend does not decrypt)

• LB can inspect, filter, apply WAF rules, routing, etc.

• Good for high traffic loads

Cons:

• Traffic between LB → Pod is not encrypted

• Vulnerable to man-in-the-middle inside the cluster

• Not ideal for high-security environments

7.3 SSL Bridging (Re-Encryption)

Also called Re-Encrypt in OpenShift.

How it works:

1. Load balancer decrypts request

2. Inspects / applies routing

3. Load balancer re-encrypts

4. Sends encrypted traffic to backend Pod

Pros:

• LB can inspect traffic

• Keeps encryption between LB ↔ Pod

• Most secure option with advanced LB features

Cons:

• Backend still decrypts → same CPU cost as passthrough

• Load balancer also decrypts → more LB CPU usage

8. Comparison Summary

9. Which One Should You Use?

If you want maximum performance → SSL Offloading

Backend stays free from decryption load.

If you want maximum security → SSL Bridging

Everything encrypted end-to-end + LB security features.

If you want zero LB involvement → SSL Passthrough

Not recommended unless required.

Two reasons:

1. They don’t understand why Ingress is required.

2. Practical setup fails on Minikube or local clusters because Ingress controller is missing.

2. Before Ingress (Before Kubernetes v1.1)

People used Kubernetes with:

• Deployment → creates Pods

• Service → exposes Pods, provides internal/external LB using kube-proxy

Everything worked fine until real production needs appeared.

3. Problems People Faced With ONLY Services

Problem 1 — Missing Enterprise Load Balancing Features

Traditional VM-based environments had powerful load balancers like:

• Nginx (as LB)

• F5

• HAProxy

• Traefik

These offered advanced features:

• Path-based routing /a → service1, /b → service2

• Host-based routing app.example.com → service1

• Sticky sessions

• Weighted/rationed load balancing (70/30)

• Whitelisting / blacklisting

• TLS/HTTPS termination

• WAF
  ...and many more

Kubernetes Services DID NOT support these.
Service only does simple round-robin load balancing using kube-proxy.

This made enterprises unhappy.

Problem 2 — Huge Cost with LoadBalancer Services

When using:

type: LoadBalancer

Every Service gets a public static IP.

In large companies:

• 1000 services = 1000 load balancers = huge cloud cost
  Cloud providers charge for every static LB IP.

In VMs earlier:

• They used one load balancer for all apps.

• Routing done by path/host rules.

So Kubernetes LoadBalancer type became too expensive.

4. Kubernetes Adds a New Concept → INGRESS

To solve above two problems.

Kubernetes said:

• “We will let users create a Ingress resource”

• But Kubernetes will not implement LB logic for all vendors.

• Instead, LB companies must create Ingress Controllers.

5. What is an Ingress Controller?

A load balancer implementation inside Kubernetes.

Examples:

• NGINX Ingress Controller

• HAProxy Ingress Controller

• Traefik

• F5 BIG-IP Ingress

• Ambassador

• Apache APISIX

Workflow:

1. User creates Ingress resource (rules like path/host/TLS).

2. Ingress controller reads those rules.

3. Ingress controller configures the load balancer inside the cluster.

Without an Ingress controller:

• Ingress does nothing.

6. Practical Understanding (Extremely Important)

Just like:

• Pods → handled by Kubelet

• Services → handled by kube-proxy

• Deployments → handled by deployment-controller

Ingress → MUST be handled by Ingress Controller.

So:
✔ You can create 100 Ingress YAML files
✖ Nothing will work
❗ Unless the Ingress controller is installed.

7. Common Ingress Controller Installation (Minikube Example)

On Minikube, installation is simple:

minikube addons enable ingress

This deploys:

• nginx-ingress-controller Pod

• In namespace ingress-nginx

After this:

• Ingress controller starts watching your Ingress rules

• Updates routing internally

8. Example of the Ingress Resource in Your Content

You created:

• Deployment → Pod

• Service → NodePort

• Ingress → Host-based routing (foo.bar.com)

Ingress YAML points to:

serviceName: my-service
servicePort: 80
path: /bar
host: foo.bar.com

9. After Ingress Controller Installs

• Ingress now gets an Address (IP).

• Ingress controller logs show:

    Successfully synced ingress: Ingress example
  

This means:

• Controller picked up your Ingress rule

• Updated its internal Nginx config

10. Accessing Ingress on Local Machine

Because DNS is not real on local environment:

• You MUST update /etc/hosts file

• Map your domain (foo.bar.com) to Ingress IP

Example:

192.168.64.11 foo.bar.com

Then you can access:

http://foo.bar.com/bar

11. Summary — What You Should Remember

Ingress solves two major problems

1. Missing enterprise-grade LB features

2. High cost of cloud LB for each service

Ingress requires Ingress Controller

Without it → Ingress does nothing.

Ingress Controller = Load Balancer + API Gateway inside Kubernetes

One Ingress can route traffic to MANY services

Using host/path rules.

You gave a long demo where you:

• Create a Kubernetes deployment

• Create different types of services

• Test traffic flow

• Use Kubeshark to see how traffic flows inside the cluster

The goal:
Understand Service Discovery, Load Balancing & Exposing Apps inside/outside Kubernetes.

✅ 2. Kubernetes Cluster Setup (Minikube)

You use:

minikube status

to confirm the cluster is running.

Then you clean the namespace:

kubectl get all
kubectl delete deploy <name>
kubectl delete svc <name>

Only the default Kubernetes service remains.

✅ 3. Build the Application Image

You go to a GitHub repo (docker-zero-to-hero), use a Django app and build your image:

docker build -t python-sample-app-demo:v1 .

✅ 4. Create Deployment (deployment.yaml)

You take a template from Kubernetes docs and modify:

• replicas: 2

• Add labels:

    app: sample-python-app
  

• Add container image:

    image: python-sample-app-demo:v1
  

• Add containerPort:

    containerPort: 8000
  

Apply it:

kubectl apply -f deployment.yaml

Check:

kubectl get deploy
kubectl get pods -o wide

⚠️ You highlight that Pod IPs keep changing, so you cannot rely on Pod IPs directly.

✅ 5. Why Services Are Needed

Because:

• Pod IPs change

• Pods scale up/down

• Pods restart

So you need stable networking via:

1. Labels

2. Selectors

3. Services

Services always look for pods by label, not by IP.

✅ 6. Create the Service (service.yaml)

You create a NodePort service:

type: NodePort
selector:
  app: sample-python-app
ports:
  - port: 80
    targetPort: 8000
    nodePort: 30007

Apply:

kubectl apply -f service.yaml

Check:

kubectl get svc

✅ 7. How NodePort Works

NodePort exposes the app on:

<NodeIP>:<NodePort>

You get Minikube IP:

minikube ip

Then access:

curl http://<minikube-ip>:30007/demo

Or via browser:

http://<minikube-ip>:30007/demo

This works only inside the same network (internal users).

✅ 8. LoadBalancer Mode

You edit the service:

kubectl edit svc <name>

Change:

type: LoadBalancer

In cloud providers (AWS/GCP/Azure) you get:

EXTERNAL-IP = Public IP

But in Minikube this stays:

pending

(You mention MetalLB as an alternative.)

✅ 9. Service Discovery Test

You break the selector on purpose:

selector:
  app: sample-python

This no longer matches:

app: sample-python-app

Result:

• Service can’t find pods

• No traffic

• Proves services depend 100% on correct labels/selectors

✅ 10. Load Balancing Concept

Since you created 2 pods, NodePort or ClusterIP service will:

• Split traffic between pods

• Do round-robin

• Always discover new pods automatically (because labels match)

✅ 11. Kubeshark

Used at the end (not included in detail in your text) to:

• Capture real traffic

• Show how service selects pods

• Show internal communication inside the cluster

🎉 Summary of Your Entire Content in 10 Sentences

1. You start a Minikube cluster and clean the namespace.

2. You build a Python/Django Docker image.

3. You create a Kubernetes deployment with 2 replicas.

4. You explain Pod IPs change, so they cannot be used directly.

5. You create a NodePort service with proper labels/selectors.

6. You show how NodePort exposes the app on <NodeIP>:<NodePort>.

7. You demonstrate using the app from browser and using curl.

8. You convert service type to LoadBalancer for external traffic (cloud only).

9. You intentionally break selectors to show service discovery failure.

10. You use Kubeshark to visualize pod-to-service traffic inside Kubernetes.

In real production environments:

• We don’t deploy pods directly.

• We deploy deployments, which internally create a ReplicaSet, which finally creates pods.

Assume we have a deployment with 3 pods (replicas).

These replicas are required because:

• One pod cannot handle many concurrent users.

• For example: if 1 pod handles 10 users and you have 100 users → you need ~10 pods.

⚠️ Problem: What if There Is No Service in Kubernetes?

Pods get dynamic IP addresses.

Example:

• Pod 1 → 172.16.3.4

• Pod 2 → 172.16.3.5

• Pod 3 → 172.16.3.6

If a pod crashes, Kubernetes auto-heals and creates a new pod → new IP address.

Example:

• Pod 1 dies

• New Pod 1 → 172.16.3.8 (IP changed)

Now the users/testers/other internal teams who were using 172.16.3.4 cannot access the application anymore.

So even though Kubernetes healed the pod correctly → application becomes unreachable due to changed IP.

This is the core reason Kubernetes Services are required.

🟦 How a Service Solves This Problem

Instead of giving direct pod IPs to users, DevOps creates a Service on top of the Deployment.

Users will now access the application using:

payment.default.svc

The service:

1. Acts as a load balancer

2. Performs service discovery

3. Can expose applications externally

1️⃣ Load Balancing

The service receives traffic and distributes it across all pods.

Example:

• 10 requests → Pod1

• 10 requests → Pod2

• 10 requests → Pod3

So all pods handle load evenly.

2️⃣ Service Discovery (VERY IMPORTANT)

A service does NOT track pod IPs.

Instead, it uses:

✔️ Labels

✔️ Selectors

Example label on pods:

app: payment

If pods die and new ones are created:

• IP address changes

• Label remains the same

• Service always finds the correct pods because it filters by labels.

This solves the problem of constantly changing IPs.

3️⃣ Exposing Applications Externally

Services can expose your app inside or outside the cluster depending on the service type.

There are 3 main service types:

🔹 Type 1 — ClusterIP (default)

• Application accessible only inside the Kubernetes cluster

• Provides load balancing + service discovery

• Not accessible from outside

🔹 Type 2 — NodePort

• Application accessible inside your organization / VPC

• Anyone who can reach Worker Node IP can access the app

• Useful for internal company apps

🔹 Type 3 — LoadBalancer

• Application accessible from the internet (publicly)

• Creates a Cloud Load Balancer (ELB on AWS)

• Best for apps like:

  • amazon.com

  • Any public website

Note:

• LoadBalancer works only on cloud providers (AWS, GCP, Azure)

• Does NOT work by default on Minikube (needs addons/metallb)

🌐 Example Summary (From Your Content)

🧠 Final Summary of Your Content

Kubernetes Services provide:

✔️ Load Balancing

✔️ Service Discovery (through labels & selectors)

✔️ External Exposure (depending on type)

Without a Service:

• Pods get new IPs when recreated

• Users cannot access the application

• Auto-healing breaks connectivity

With a Service:

• Users access via a single stable address

• Traffic is distributed

• IP changes of pods don’t matter

You can create containers using any platform — for example, Docker.

In Docker:

You usually run a container using commands like:

docker run -it image_name
docker run -d -p 8080:80 -v /data:/app --network mynet nginx

Here you specify options such as:

• -p → port mapping

• -v → volumes

• --network → network type

This is the command-line specification for running a container.

⚙️ 2. Kubernetes Simplifies This – YAML Manifest

Kubernetes introduced an enterprise-level approach to manage containers.

Instead of writing long commands, Kubernetes allows you to define everything in a YAML manifest file (for example, pod.yaml).

In the YAML file, you define:

• Container image name

• Ports to expose

• Volumes

• Network details

This YAML file acts as a running specification for your container.

So:

🟩 Pod YAML = Declarative specification to run your container in Kubernetes

📦 3. What is a Pod?

A Pod is the smallest deployable unit in Kubernetes.
It’s a wrapper around one or more containers.

A Pod defines how the container should run — image, ports, volumes, and other configurations.

🧩 Single vs Multiple Containers in a Pod

• A Pod can contain a single container (most common).

• It can also contain multiple containers if they are tightly coupled — for example:

  • One main application container

  • One sidecar container (for logging, proxy, API gateway, etc.)

🕸️ Why multiple containers in a Pod?

Because:

• They share the same network (can communicate using localhost)

• They share the same storage volumes

📘 Example use case:
Service Mesh — one main app container and one sidecar container for service routing.

⚡ 4. Why Do We Need Deployments?

Now that you can deploy an app using a Pod, the next question is:

Why move from Pod to Deployment?

Because Pods cannot auto-heal or auto-scale.

Kubernetes provides features like:

• Auto-healing → restart failed Pods automatically

• Auto-scaling → increase/decrease Pods based on load

Pods alone cannot do this.
To achieve these behaviors, Kubernetes uses a Deployment.

🚀 5. What is a Deployment?

A Deployment is a higher-level resource that manages Pods.

When you create a Deployment, it:

1. Creates an internal resource called a ReplicaSet

2. The ReplicaSet then creates and manages Pods

🧠 Flow:
Deployment → ReplicaSet → Pod

📄 Deployment YAML (simplified example)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Here:

• replicas: 2 → desired number of Pods

• template: → defines the Pod specification

🧩 6. What is a ReplicaSet?

A ReplicaSet is a Kubernetes controller that ensures the desired number of Pods are always running.

If you delete or lose a Pod:

• The ReplicaSet will immediately recreate it.

Example:

If Deployment says replicas: 2:

• ReplicaSet ensures 2 Pods are always running.

• If one is deleted, a new one is automatically created.

→ This is called auto-healing.

🔁 7. How Deployments Enable Zero Downtime

If you update the replicas value from 2 → 3 in your YAML and apply it again:

kubectl apply -f deployment.yaml

Kubernetes:

• Notices the change

• Automatically creates one new Pod (via ReplicaSet)

• Keeps existing Pods running

✅ This ensures zero downtime and smooth scaling.

🧠 8. Controller Concept in Kubernetes

A Controller in Kubernetes maintains the desired state of the cluster.

For example:

• If Deployment YAML says 3 replicas → the controller ensures 3 Pods are always running.

Controllers constantly watch and reconcile:

Desired State (YAML) = Actual State (cluster)

Examples of controllers:

• ReplicaSet Controller

• Deployment Controller

• DaemonSet Controller

• Custom Controllers (like ArgoCD, Admission Controllers)

🧩 9. Pod vs Container vs Deployment (Interview Key Question)

Summary:

Container → Pod → Deployment
Each layer adds management capability on top of the previous one.

🧩 10. Deployment vs ReplicaSet

📘 Think of it like this:
Deployment = Manager
ReplicaSet = Worker ensuring Pods match Deployment instructions

🧩 11. Real-Time Demo Behavior (as explained)

• kubectl apply -f pod.yaml → creates one Pod

• If you kubectl delete pod <name> → Pod is gone; app stops

❌ No auto-healing in a Pod.

✅ With Deployment:

• kubectl apply -f deployment.yaml → creates Deployment → ReplicaSet → Pod

• If you delete one Pod:

    kubectl delete pod <name>
  

  Immediately, ReplicaSet recreates a new Pod (auto-healing)

• If you increase replicas from 1 → 3:

    kubectl apply -f deployment.yaml
  

  ReplicaSet creates two new Pods (scaling)

→ All without downtime.

⚙️ 12. Common kubectl Commands

📈 13. Zero Downtime Example Summary

• Deleted Pod → instantly recreated (auto-healing)

• Increased replicas → new Pods created automatically (scaling)

• All without affecting users → zero downtime

🧩 14. Practical Assignment

• Create a Deployment YAML with your own image

• Apply it to cluster

• Delete a Pod → observe auto-healing

• Increase replicas → observe scaling

• Use kubectl get rs to verify ReplicaSet creation

🧠 15. Key Interview Questions

1. Difference between Container, Pod, and Deployment

2. Difference between Deployment and ReplicaSet

3. What is a Controller in Kubernetes?

4. How does auto-healing work in Kubernetes?

5. What ensures desired vs actual state?

✅ 16. Summary of Key Concepts

🟢 Final Flow:
Deployment → ReplicaSet → Pod → Container

We are moving from Docker (container) to Kubernetes (container orchestration).
In Docker, you directly deploy containers using commands like:

docker run -d -p 8080:80 nginx

But in Kubernetes, you cannot directly deploy a container.
Instead, you deploy your application as a Pod — which is the smallest deployable unit in Kubernetes.

📦 2. What is a Pod?

A Pod is the basic unit of deployment in Kubernetes.

📘 Definition:
A Pod is a wrapper around one or more containers that defines how a container should run in Kubernetes.

🧩 Why not deploy containers directly?

Because Kubernetes is a declarative system — it doesn’t want you to manually type commands for every run like Docker.
Instead, Kubernetes expects you to declare the desired state in a file (usually YAML).

Example:

• In Docker → you write:
  docker run -d -p 80:80 nginx

• In Kubernetes → you define a pod.yaml with all specifications.

This allows:

• Standardization across environments

• Easier automation

• Consistency in deployment

🧾 3. Pod YAML File (Specification)

A Pod is defined using a YAML file.

Example:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.14.2
      ports:
        - containerPort: 80

🟢 This YAML replaces all the Docker CLI flags like:
-p, -v, --network, etc.

🔄 Equivalent Docker Command

The above YAML is equivalent to:

docker run -d --name nginx -p 80:80 nginx:1.14.2

So, a Pod = Docker container + YAML configuration wrapper.

👥 4. Single vs Multiple Containers in a Pod

A Pod can have:

• One container (most common)

• Multiple containers (special use-cases)

Why multiple containers?

Some applications need helper containers (sidecars) for:

• Logging

• Config loading

• Proxying traffic

If you place containers inside one Pod:

• They share the same network (localhost)

• They share the same storage volume

Example:

• containerA can talk to containerB using localhost:port

• Both can read/write shared files

🌐 5. Networking & IPs in Pods

• Each Pod gets a unique Cluster IP (assigned by kube-proxy)

• Containers inside the same Pod share the same IP address

• Other Pods in the cluster can communicate using this Pod IP

⚙️ 6. Understanding kubectl (Kubernetes CLI)

Like Docker uses docker commands, Kubernetes uses kubectl (pronounced cube control).

Common Commands

👉 All Kubernetes interaction happens through kubectl.

💻 7. Setting up Kubernetes Locally

For local practice, we use Minikube (lightweight Kubernetes cluster).
Other options include kind, k3s, microk8s.

Steps:

🧩 Step 1: Install kubectl

Search → “install kubectl”
Follow instructions for your OS (Linux/Mac/Windows).

Example for macOS:

brew install kubectl
kubectl version

🧩 Step 2: Install Minikube

Search → “install Minikube”
Then follow commands based on your OS and CPU architecture (Intel/ARM).

Example:

brew install minikube
minikube version

🧩 Step 3: Start the Cluster

minikube start

🖥️ This creates a single-node Kubernetes cluster (1 virtual machine).

In production, you’d have multiple master and worker nodes.
But for learning, 1 node (control plane + worker) is enough.

🚀 8. Deploying Your First Pod

Create a pod YAML file:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Deploy it:

kubectl create -f pod.yaml

Verify it:

kubectl get pods
kubectl get pods -o wide

Access it inside cluster:

minikube ssh
curl <pod-cluster-ip>

It should return → “Thank you for using nginx”.

🔍 9. Debugging Pods

If your pod has issues, use:

kubectl describe pod <pod-name>

→ Shows Pod events, errors, status, etc.

To view logs of the application:

kubectl logs <pod-name>

💡 10. Cleanup

To delete your Pod:

kubectl delete pod <pod-name>

📘 11. Reference – kubectl Cheat Sheet

For all kubectl commands:
🔗 Kubernetes Official kubectl Cheat Sheet

Keep this handy — even experienced DevOps engineers refer to it.

⚙️ 12. From Pod → Deployment

You learned:

• Pod = single or multi-container unit

• Defined using YAML

Next step:

• To enable Auto-healing & Auto-scaling,
  you use Deployments — which are wrappers around Pods.

✅ Summary

In real-world production environments, DevOps engineers must:

• Create

• Upgrade

• Configure

• Delete
  Kubernetes clusters — across multiple environments (dev, staging, prod).

Managing these life cycles manually (especially at scale) is complex.
Hence, automation tools like KOPS are used.

🧩 2. Why Not Minikube, Kind, K3s, or MicroK8s?

• These are lightweight, single-node setups meant for learning and development only.

• They lack:

  • High availability

  • Multi-node support

  • Production-grade fault tolerance

  • Scalability and security controls

📌 In short:

Minikube / K3s / Kind = Local dev use only
KOPS / EKS / OpenShift / Rancher = Production-ready systems

🏗️ 3. Kubernetes in Production (Distributions)

Just like Linux has distributions (Ubuntu, Red Hat, Amazon Linux),
Kubernetes also has multiple distributions.

💡 Why use distributions?

• Provide enterprise support

• Manage security patches

• Simplify setup and upgrades

• Offer ready-to-use integrations

🧠 4. Common Production Scenarios

• Organizations may have:

  • Hundreds of Kubernetes clusters

  • Or one large cluster with thousands of nodes

• Managed solutions (EKS, GKE, AKS) cost a lot when scaled.

• Hence, many companies use open-source Kubernetes with tools like KOPS to manage lifecycle operations.

⚖️ 5. Kubernetes vs EKS

🟩 Key Point:
EKS = Kubernetes + AWS management + Paid support
KOPS = Kubernetes + Full control + Open source management

⚙️ 6. What Is KOPS?

KOPS = Kubernetes Operations Tool

A CLI tool that automates the creation, management, and lifecycle of Kubernetes clusters on AWS and other clouds.

✳️ KOPS manages:

• Cluster creation

• Configuration changes

• Upgrades

• Node scaling

• Cluster deletion

KOPS stores all cluster configuration in an S3 bucket, which acts as the cluster state store.

🧰 7. Why KOPS Is Popular

🪜 8. Pre-requisites Before Using KOPS

Before creating a cluster with KOPS, ensure you have:

🔧 Software Requirements:

1. Python 3

2. AWS CLI

3. kubectl

4. KOPS

☁️ AWS Requirements:

• AWS account access

• IAM user (Admin or with following policies):

  • AmazonEC2FullAccess

  • AmazonS3FullAccess

  • IAMFullAccess

  • AmazonVPCFullAccess

• AWS CLI configured via:

    aws configure
  

📦 9. Step-by-Step Setup with KOPS

Step 1️⃣: Create an S3 Bucket for Cluster State

KOPS stores cluster metadata in S3.

aws s3 mb s3://kops-state-store-1

Step 2️⃣: Export the S3 Bucket Path

export KOPS_STATE_STORE=s3://kops-state-store-1

Step 3️⃣: Create the Kubernetes Cluster Definition

kops create cluster \
--name=k8s.local \
--zones=us-east-1a \
--node-count=2 \
--node-size=t2.micro \
--master-size=t2.micro \
--state=s3://kops-state-store-1

Step 4️⃣: Build (Launch) the Cluster

kops update cluster k8s.local --yes

⏱️ This process takes several minutes — KOPS provisions EC2 instances, networking, security groups, IAM roles, etc.

🧩 10. Domain Considerations

KOPS requires a domain name (for the cluster API endpoint).
You can use:

If using a real domain:

• Purchase it (e.g., GoDaddy)

• Configure DNS in AWS Route 53

• Create a hosted zone:

    aws route53 create-hosted-zone --name dev.example.com
  

💰 11. Cost Caution

⚠️ KOPS uses AWS resources:

• EC2 instances

• EBS volumes

• S3 buckets

• Route 53 entries

🧾 These all incur AWS billing, even in free-tier accounts.

Tip:
If you only want to learn, stop after the “create cluster” step — do not run the final “update cluster” command.

🧱 12. KOPS in the Real World

• Used by DevOps teams for multi-environment orchestration.

• Commonly manages:

  • Dev, QA, Staging, and Production clusters

  • Clusters across multiple AWS accounts or regions

• Supports upgrades via:

    kops upgrade cluster
    kops rolling-update cluster
  

• Supports deletion via:

    kops delete cluster --name=<cluster-name> --yes
  

🧭 13. Comparison: Other Installation Tools

🧩 14. Interview Tip

When asked about Kubernetes setup in production, say:

“In our organization, we manage multiple Kubernetes clusters using KOPS on AWS.
KOPS handles the full lifecycle — creation, configuration, upgrades, and deletion.
For staging and testing, we use .k8s.local domains, and for production we use Route 53 hosted domains like prod.company.com.”

🧠 15. In Summary

✅ Final One-Liner Summary:

KOPS is a powerful open-source tool used by DevOps engineers to create, manage, and scale hundreds of production-grade Kubernetes clusters — providing automation, versioning, and reliability without managed-service costs.

• The word “Kubernetes” has 10 letters.

• To shorten it, the middle 8 letters (“ubernete”) are replaced with the number 8, forming K8s.

Kubernetes → K + 8 letters + s → K8s

🐳 2. Docker vs Kubernetes (Before Architecture)

Before understanding Kubernetes architecture, you must know how it differs from Docker.

👉 Hence, Kubernetes = Enterprise-level orchestration of containers across clusters.

🏗️ 3. Basic Idea

Kubernetes architecture has two main layers:

+----------------------------------------+
|        Kubernetes Architecture         |
|----------------------------------------|
| Control Plane (Master Components)      |
| Data Plane (Worker Node Components)    |
+----------------------------------------+

⚙️ 4. Core Concepts: Container vs Pod

• In Docker: smallest unit = Container

• In Kubernetes: smallest unit = Pod

A Pod is like a wrapper around one or more containers — with added features like networking, restart policies, and scaling.

🧱 5. Kubernetes Node Structure

Kubernetes Cluster =

• 1 or more Master Nodes (Control Plane)

• 1 or more Worker Nodes (Data Plane)

For simplicity:

1 Master Node + 1 Worker Node

🧮 6. Data Plane (Worker Node) Components

Each Worker Node contains components responsible for running the actual application Pods.

🧩 Components:

1. Kubelet

   • Ensures Pods are running as expected.

   • Talks to the Control Plane.

   • Reports pod status.

   • Performs “auto-healing”: restarts pods if they crash.

2. Kube-proxy

   • Manages networking and communication between Pods and nodes.

   • Allocates IP addresses to Pods.

   • Handles service load balancing.

   • Uses Linux iptables for routing.

3. Container Runtime

   • Actually runs containers inside Pods.

   • Examples:

     • Docker Shim

     • containerd

     • CRI-O

   • Kubernetes supports any runtime that implements the Container Runtime Interface (CRI).

Summary:
Worker node = { Kubelet + Kube-proxy + Container Runtime }
→ These three together form the Data Plane.

🧠 7. Control Plane (Master Node) Components

These components control, schedule, and manage the cluster.

🧩 Components:

1. API Server

   • The heart of Kubernetes.

   • All external or internal requests go through it.

   • Provides the Kubernetes REST API.

   • Validates and processes commands (e.g., from kubectl).

2. Scheduler

   • Decides which node should run a new Pod.

   • Uses resource data and rules to make the placement decision.

3. etcd

   • The database of Kubernetes.

   • A key-value store that saves cluster state and configuration.

   • Used for backup and recovery.

4. Controller Manager

   • Runs background “controller” processes that manage the cluster state.

   • Examples:

     • ReplicaSet Controller → ensures correct number of pods.

     • Node Controller, Endpoint Controller, etc.

   • Ensures the cluster stays in the desired state.

5. Cloud Controller Manager (CCM)

   • Bridges Kubernetes with cloud providers (AWS, Azure, GCP, etc.).

   • Handles:

     • Cloud load balancers

     • Cloud storage

     • Node management

   • Not required for on-premises clusters.

   • Open source – cloud vendors can extend it for their own integrations.

🔁 8. Flow Example — Pod Creation

1. User runs command:
   kubectl apply -f pod.yaml

2. API Server: receives the request.

3. Scheduler: decides on which node to place the pod.

4. etcd: stores pod info and cluster state.

5. Kubelet (on worker): runs the pod using container runtime.

6. Kube-proxy: assigns IP, configures networking, enables load balancing.

7. Controller Manager: ensures the desired number of pods are running.

🧩 9. Summary Table

🧭 10. Final Concept

• Control Plane → “Brain” (decides, schedules, manages)

• Data Plane → “Body” (executes, runs workloads)

• Together they make Kubernetes a self-healing, auto-scaling, cluster-based orchestration system.

📝 11. Assignment Idea (Optional)

• Draw your own Kubernetes architecture diagram.

• Label control plane and worker components.

• Write a short explanation and post it on LinkedIn or GitHub as a study note.

✅ In short:

Kubernetes = Control Plane (manages) + Data Plane (executes)
Each component has a clear, defined responsibility that together make K8s scalable, reliable, and automated.

Kubernetes is considered the future of DevOps.
If you plan a long-term career (“marathon”) in DevOps — not just short CI/CD tasks — learning Kubernetes is essential.

• You can get jobs doing basic DevOps tasks (CI/CD, build and release),
  but true DevOps engineers are expected to understand container orchestration, which means Kubernetes.

• Kubernetes dominates the modern microservices and container world.

⚙️ 2. Prerequisite — Docker and Containers

Before learning Kubernetes, you must understand containers and Docker.
Because Kubernetes works on top of containers.

You should already know:

• What containers are, and how they differ from virtual machines

• Container networking and namespace isolation

• Why containers are lightweight

• How to secure containers

• Multi-stage Docker builds and distroless images

📘 In short — get strong with container fundamentals, not just Docker commands.

🐋 3. Docker vs Kubernetes — The Core Difference

So, Kubernetes doesn’t replace Docker — it extends and manages it.

⚠️ 4. Problems with Docker Alone

When you use only Docker, several issues arise in real-world production.

🧩 Problem 1: Single Host Limitation

• Docker runs all containers on one host.

• If one container consumes too many resources (CPU/RAM), others may crash.

• There’s no way for containers to move between hosts.

🧠 Result: If one node fails, all containers on it fail too.

⚕️ Problem 2: No Auto-Healing

• If a container stops, it stays stopped until manually restarted.

• In large systems (10,000+ containers), manual monitoring is impossible.

🧠 Need: A system that automatically detects and restarts failed containers.

📈 Problem 3: No Auto-Scaling

• When user load increases (e.g., from 10,000 to 1 million users),
  containers must scale up.

• In Docker, this must be done manually.

• Docker also lacks built-in load balancing.

🧠 Need: A platform that can automatically add/remove containers as demand changes.

🏢 Problem 4: Lacks Enterprise Features

Docker by itself doesn’t provide:

• Load balancers

• Firewalls

• API gateways

• Whitelisting / Blacklisting

• Advanced networking / Security policies

• Auto-healing / Auto-scaling mechanisms

🧠 Need: A production-ready system that can integrate and automate all this.

🧠 5. Kubernetes — The Solution

Kubernetes was created by Google, inspired by their internal system Borg, and is now maintained by the CNCF (Cloud Native Computing Foundation).

Kubernetes is designed to solve all four Docker limitations.

🧩 Problem 1 Solved: Cluster Architecture

• Kubernetes runs as a cluster of multiple nodes.

• If one node fails or is overloaded, pods (containers) are automatically rescheduled to another node.

• Supports both Master (Control Plane) and Worker Nodes.

🧠 Result: High availability and fault tolerance.

⚕️ Problem 2 Solved: Auto-Healing

• Kubernetes monitors the health of containers (pods).

• If a pod fails, it automatically creates a new pod (even before the old one is completely dead).

• Managed through ReplicaSets / Deployments.

🧠 Result: Application stays up even when individual pods fail.

📈 Problem 3 Solved: Auto-Scaling

• Kubernetes supports Horizontal Pod Autoscaler (HPA).

• Based on CPU or memory thresholds (e.g., 80%), Kubernetes automatically creates or removes pods.

• You can also manually scale by editing YAML files.

🧠 Result: Application adjusts to user load dynamically.

🏢 Problem 4 Solved: Enterprise-Level Features

Kubernetes supports or integrates with:

• Load balancers (via Services, Ingress Controllers)

• Firewalls and Network Policies

• API Gateways

• Service Meshes (Istio, Linkerd)

• Security Controls (RBAC, Admission Controllers)

• Monitoring tools (Prometheus, Grafana)

• Logging tools (ELK / EFK)

🧠 Result: Kubernetes is production-ready and enterprise-grade.

🧱 6. Kubernetes Is Evolving

• Kubernetes is not 100% perfect — it’s still evolving rapidly.

• The CNCF community continuously adds new capabilities.

• Many open-source tools integrate with Kubernetes:

  • Prometheus – Monitoring

  • Grafana – Visualization

  • Ingress-NGINX / Traefik – Load balancing

  • Helm – Package management

  • Podman / Buildpacks – Image building

Each of these tools enhances Kubernetes capabilities.

⚙️ 7. Extensibility (CRDs and Controllers)

Kubernetes allows Custom Resources (CRDs) and Controllers,
so organizations can extend its features — e.g.:

• Create custom load balancers

• Add new resource types

• Integrate with 3rd-party tools

Example:
Kubernetes doesn’t provide advanced load balancing by default,
but Ingress Controllers (like NGINX Ingress) were built using CRDs to provide this.

🌍 8. Why Organizations Adopt Kubernetes

Companies like Netflix, Amazon, Flipkart, PayPal use Kubernetes because:

• It automates deployment, scaling, and management.

• It provides resiliency and flexibility.

• It standardizes infrastructure across environments (cloud, hybrid, on-prem).

💬 9. Important Points to Remember

• Kubernetes ≠ Docker replacement — it uses Docker or container runtimes under the hood.

• Kubernetes manages containers at scale.

• Kubernetes is cluster-based, not single-host.

• It provides Auto-healing, Auto-scaling, Load balancing, and Enterprise-grade control.

• It is open-source and backed by the CNCF community.

🧩 10. What’s Next

In the upcoming topics:

1. Kubernetes Architecture

2. Pods

3. Deployments

4. Services

5. Ingress Controllers

6. Admission Controllers

Each topic will build upon today’s foundation.

✅ Summary

In short:
Kubernetes is the brain that manages your containers.
It makes container-based infrastructure scalable, resilient, and production-ready.

Answer:
Docker is an open-source containerization platform used to build, package, and run applications inside lightweight, portable containers. It helps manage the entire lifecycle of containers — building images, running containers, pushing/pulling images from registries, etc.

You can add:
“In my projects, I use Docker to write Dockerfiles, build images, run containers, optimize image size, and push artifacts to registries like Docker Hub/ECR.”

2. How are Containers different from Virtual Machines?

Answer:

Never say containers “don’t have an OS” — correct answer is:
They include only minimal system libraries, not a full OS.

3. Explain the Docker Lifecycle.

Answer:
The Docker lifecycle includes:

1. Write Dockerfile

2. Build image → docker build

3. Run container → docker run

4. Tag & Push image to registry (Docker Hub, ECR, GCR)

5. Pull image on any environment

6. Manage containers (start/stop/remove/prune)

4. What are the main Docker components?

Answer:

1. Docker Client (CLI) – sends commands

2. Docker Daemon – core engine that executes actions

3. Docker Images – read-only templates

4. Docker Containers – running instances of images

5. Docker Registry – stores images (Docker Hub, ECR, private registry)

Daemon is the “heart” of Docker — if it stops, Docker actions cannot be executed.

5. Difference between COPY and ADD in Dockerfile?

Answer:

• COPY – Copies files/folders from local machine → image (preferred)

• ADD – Same as COPY + supports downloading from URL or auto-extracting archives.

Use COPY unless you specifically need ADD’s special features.

6. Difference between CMD and ENTRYPOINT?

Answer:

Best practice: Use ENTRYPOINT for the main command and CMD for default arguments.

Example:

ENTRYPOINT ["python", "app.py"]
CMD ["--port", "8000"]

7. What are Docker networking types? What is the default?

Answer:

1. bridge – default network for containers

2. host – container shares host network

3. overlay – used in multi-host (Swarm/Kubernetes)

4. macvlan – container appears as a physical device on network

5. none – no network

8. How do you isolate networking between containers?

Answer:
Create a custom bridge network:

docker network create secure_net
docker run --network secure_net ...

Containers on different networks cannot talk to each other unless explicitly connected.

9. What is a Multi-Stage Docker Build?

Answer:
It allows you to use multiple FROM statements and copy only the required build artifacts into the final image.

Why?

• Reduces image size

• Removes build tools from production image

• Improves security

Example: Reduce image from ~800MB → 1MB using scratch/alpine.

10. What are Distroless Images?

Answer:
Distroless images (e.g., gcr.io/distroless/...) are minimal images that contain only:

• your application

• required runtime dependencies

They do not contain:
❌ shell (sh, bash)
❌ package managers (apt, yum)
❌ OS utilities (ping, curl)

Benefit:
Extremely secure, tiny, no attack surface.

🔥 Real-Time Docker Challenges (Must-Know for Interviews)

1. Docker Daemon – Single Point of Failure

• Docker daemon is one single process

• If daemon crashes → containers may stop or fail

Modern solution: Podman (daemonless, rootless).

2. Docker Daemon Runs as Root

• By default, daemon runs with root privileges

• If a container is compromised, host becomes vulnerable

Solution:

• Use rootless Docker

• Use Podman (runs fully rootless)

• Always set USER in Dockerfile

3. Image Size Issues

• Developers often install unnecessary tools

• Leads to huge (GB-sized) images

• Slow deploys, security risks

Solutions:

• Multi-stage builds

• Distroless images

• Base images like alpine

4. Networking Misconfigurations

• Wrong port mappings

• Misuse of host network

• Containers unintentionally communicating

Solution:
Custom networks & proper isolation.

5. Security Vulnerabilities

• Using outdated base images

• Running containers as root

• Storing secrets inside images

Solution:

• Scan images (Trivy, Anchore)

• Use secrets manager

• Use non-root user in Dockerfile

Secure Containers Using Custom Bridge Network

1️⃣ Introduction — Why Docker Networking?

• Docker Networking (or container networking) enables communication:

  • Between containers.

  • Between containers and the host system.

• Every Docker container requires networking to send and receive data.

• Networking in containers is similar in concept to traditional networking in virtual machines but lighter and more flexible.

2️⃣ Why Do We Need Docker Networking?

🧩 Scenario 1 — Containers Need to Communicate

• Example:

  • Frontend container ↔ Backend container.

• These containers must exchange data (e.g., API calls, responses).

• Networking allows this communication using IPs or service names.

🔒 Scenario 2 — Containers Need Isolation

• Example:

  • A login container and a payment container.

• Payment container stores sensitive information (credit cards, user data).

• We need logical isolation — login users must not access the payment container.

So, Docker networking helps achieve both:

• Connectivity, and

• Isolation.

3️⃣ Networking Basics — Containers vs Virtual Machines

4️⃣ How Containers Communicate with the Host

🔧 Default Host Interface

• Every host (server or laptop) has a network interface like:

    eth0 → 192.168.1.10
  

• Each container also gets its own interface:

    eth0 → 172.17.0.2
  

• These two belong to different subnets — so, direct ping fails.

🌉 The Solution — Virtual Ethernet Bridge

• Docker automatically creates a virtual bridge called docker0.

• This bridge acts like a router between the host and containers.

• When you create a container, Docker links its virtual ethernet (veth) to this bridge.

✅ Result: Containers can now communicate with the host and each other.

5️⃣ Default Docker Network — The Bridge Network

⚙️ What Is Bridge Networking?

• A bridge connects containers to the host through a virtual switch (docker0).

• It provides:

  • Communication between containers.

  • Communication between container and host.

  • Internet access (via NAT).

🧩 Example:

docker network ls

Shows:

NETWORK ID     NAME      DRIVER    SCOPE
abcd1234       bridge    bridge    local

📦 Behavior:

• Containers connected to the same bridge can ping each other.

• All containers share the same subnet.

• This network is created automatically by Docker.

6️⃣ Other Docker Network Types

1. 🧱 Bridge Network (Default)

• Virtual bridge (docker0) created automatically.

• Containers communicate using internal IPs.

• Suitable for single-host setups.

2. 🌐 Host Network

• The container shares the host’s network stack.

• No separate IP; it uses the host’s IP.

• Example:

    docker run -d --network=host nginx
  

• Pros: Faster, direct access.

• Cons: No isolation; insecure (container = host access).

3. 🕸️ Overlay Network

• Used for multi-host communication (in Docker Swarm or Kubernetes).

• Creates a network that spans across multiple Docker hosts.

• Allows containers on different machines to communicate securely.

• Common in container orchestration platforms.

7️⃣ Networking Deep Dive — How Communication Works

Example setup:

Host eth0: 192.168.1.5
docker0 (bridge): 172.17.0.1
Container 1 eth0: 172.17.0.2
Container 2 eth0: 172.17.0.3

• Both containers use the same bridge (docker0).

• Hence:

  • They can ping each other.

  • They share the same communication channel.

⚠️ Problem:

• All containers use the same bridge.

• A security risk — if one container is compromised, others are accessible.

8️⃣ Custom Bridge Networks — Securing Containers

To isolate sensitive containers, you can create custom bridge networks.

🧱 Why Create Custom Bridges?

• The default bridge (docker0) allows all containers to communicate.

• A custom bridge provides:

  • Network segmentation.

  • Security boundaries.

  • Controlled communication.

🧰 Create a Custom Bridge

docker network create secure_network

🧪 Verify

docker network ls

Output:

bridge
host
none
secure_network

9️⃣ Attach Containers to Custom Bridge Networks

Example:

Step 1 — Run Normal Containers

docker run -d --name login nginx
docker run -d --name logout nginx

• Both use default bridge network.

• Can ping each other.

Step 2 — Create a Secure Network

docker network create secure_network

Step 3 — Run Secure Container

docker run -d --name finance --network=secure_network nginx

Step 4 — Verify

docker inspect finance

You’ll see:

"Networks": {
  "secure_network": {
    "IPAddress": "172.19.0.2"
  }
}

✅ Result:

• login → bridge → 172.17.x.x

• finance → secure_network → 172.19.x.x

• They cannot ping each other.

• Finance container isolated successfully.

🔒 Summary of Isolation

This achieves network-level security while staying within Docker itself.

🔍 Host Network Example

docker run -d --name host_demo --network=host nginx

• Container uses host’s IP (192.168.1.5).

• docker inspect host_demo shows:

  • "NetworkMode": "host"

  • No separate IP address.

• ⚠️ No isolation — directly exposed on host’s interface.

🔚 Recap — Docker Networking Summary

🧠 Key Takeaways

• Docker networking lets containers communicate or isolate as needed.

• Bridge Network → Default communication method.

• Host Network → Shares host network; faster but insecure.

• Overlay Network → For multi-host clusters (Docker Swarm/Kubernetes).

• Custom Bridge Network → Best way to isolate secure containers on a single host.

Containers are ephemeral (temporary).
When a container stops or crashes, all data inside it is lost.

🧩 Example 1: NGINX Logs Lost After Container Stops

• Suppose you run an NGINX container that stores user login info and IP addresses in a log file.

• These logs are critical for security audits and user tracking.

• If the container goes down → the log file is deleted because the container filesystem is temporary.

• Result: Company loses important user and audit data.

🧩 Example 2: Frontend–Backend Data Sharing Problem

• A backend container continuously writes data (e.g., JSON, YAML, or HTML files).

• A frontend container reads these files to display content to users.

• If the backend container goes down:

  • All previously written files are lost.

  • The frontend can’t access old records (e.g., yesterday’s data).

• Result: Broken application — only today’s data is available.

🧩 Example 3: Container Needs to Read Host Files

• A cron job on the host creates files periodically.

• The container needs to read those files.

• By default, a container cannot access the host filesystem.

• Result: Container fails to read required host files.

2️⃣ The Solution — Persistent Storage Options

Docker introduced two methods to solve these problems:

1. Bind Mounts

2. Volumes

Both allow data to persist even if containers are deleted or recreated.

3️⃣ 🔗 Bind Mounts

🧠 Concept

Bind mounts connect (bind) a folder inside the container to a folder on the host machine.

• Example:

    Host folder: /app
    Container folder: /app
  

• Any changes made inside the container’s /app folder reflect on the host, and vice versa.

⚙️ How It Works

• Data is stored on the host.

• If the container stops or is removed → the host folder still contains all files.

• When a new container is started and the same folder is bound again, the data is retained.

✅ Advantages

• Very simple setup.

• Great for development environments where you want to see changes instantly.

⚠️ Limitations

• Must specify exact host directory path.

• Works only on that specific host.

• No built-in management via Docker CLI.

4️⃣ 📦 Docker Volumes

🧠 Concept

Volumes provide Docker-managed storage that is independent of the container lifecycle.

• You create a volume using Docker commands.

• Docker internally manages where and how it’s stored on the host.

🧩 Example

docker volume create mydata
docker run -d --mount source=mydata,target=/app nginx

Now /app inside the container is linked to the Docker volume mydata.

🧰 Lifecycle Management

• Create, inspect, delete volumes easily:

    docker volume create <name>
    docker volume ls
    docker volume inspect <name>
    docker volume rm <name>
  

• Volumes can be attached to one or multiple containers.

⚙️ Features and Benefits

• Managed via Docker CLI (no manual path setup).

• Logical partitions created on the host.

• Can be moved, backed up, and shared across containers.

• Can use external storage like:

  • AWS S3

  • NFS

  • External EC2 instance disks

• Supports high-performance storage (e.g., SSD/NVMe) for data-intensive apps.

• Excellent for production environments.

🧱 Difference from Bind Mounts

5️⃣ 🧩 Volume Command Examples

# Create a new volume
docker volume create myvol

# List all volumes
docker volume ls

# Inspect details
docker volume inspect myvol

# Delete a volume
docker volume rm myvol

6️⃣ 🧠 Practical Example

Step 1 — Create a Volume

docker volume create myvol

Step 2 — Run Container Using Volume

docker run -d --mount source=myvol,target=/app nginx

• The container nginx now uses /app linked to myvol.

• Any file written in /app is persisted.

Step 3 — Inspect Container Mount

docker inspect <container_id>

You’ll see:

"Mounts": [
  {
    "Type": "volume",
    "Name": "myvol",
    "Source": "/var/lib/docker/volumes/myvol/_data",
    "Destination": "/app",
    "Mode": "rw"
  }
]

Step 4 — Delete the Volume

You cannot delete a volume that’s in use:

docker volume rm myvol
# Error: volume is in use

So first stop and remove the container:

docker stop <container_id>
docker rm <container_id>
docker volume rm myvol

7️⃣ 🔍 -v vs --mount Option

Example:

# Short form
docker run -d -v myvol:/app nginx

# Verbose form
docker run -d --mount source=myvol,target=/app nginx

✅ Recommended: Use --mount for clarity in production or team projects.

🏁 Summary

🎯 1. Objective

In this session, we’ll learn:

1. The concept of Multi-Stage Docker Builds

2. The concept of Distroless (Destroyless) Images

Both concepts are closely related — using distroless images enhances the efficiency and security of multi-stage builds.

🧱 2. The Problem with Traditional Docker Builds

Let’s take a simple example:
You want to containerize a Python calculator application.

Typical Steps

1. Start from a base image (e.g., ubuntu:latest)

2. Set a working directory (optional)

3. Install dependencies:

   • Python

   • pip

   • Required Python modules/packages

4. Copy source code into the image

5. Build and run the application (via CMD or ENTRYPOINT)

⚠️ Problem

Although this Dockerfile works, it’s inefficient:

• The image includes the entire Ubuntu OS plus unnecessary packages (apt, curl, etc.)

• These packages are only needed during build, not runtime

• The final image becomes huge and slow to pull/run

⚙️ 3. Build vs. Run Phases

For instance:

• A Java app needs JDK to build, but only JRE to run.

• A Python app needs pip and libraries to build, but only Python runtime to run.

So, it’s wasteful to keep all build-time tools in the final image.

🧩 4. Docker’s Solution — Multi-Stage Builds

To solve this problem, Docker introduced multi-stage builds.

💡 Concept

You can split your Dockerfile into multiple stages, using multiple FROM statements in one file.

Each stage:

• Builds a specific part of your application

• Can copy artifacts (like binaries) to the next stage

• Keeps the final image minimal

🏗️ 5. Example: Two-Stage Dockerfile

Stage 1 – Build Stage

FROM ubuntu AS build
RUN apt-get update && apt-get install -y python3 pip
COPY . /app
WORKDIR /app
RUN python3 setup.py build

Stage 2 – Final Stage

FROM python:3.10-slim
COPY --from=build /app/dist /app
CMD ["python3", "/app/main.py"]

✅ Result:

• The build tools (like apt, compilers, pip caches) are excluded

• Only the necessary runtime (Python + your app) remains

• Image size drastically reduces

🧮 6. Example: Multi-Stage Build for Complex App

Imagine a 3-tier application:

• Frontend (React)

• Backend (Java Spring Boot)

• Database (MySQL)

Traditional Method:

• All dependencies (Node.js, JDK, MySQL client) installed in one image → ~1 GB+.

With Multi-Stage Build:

• Each part built in separate stages:

  • Stage 1 → Frontend build (React)

  • Stage 2 → Backend build (Java)

  • Stage 3 → Final stage (only Java runtime + built artifacts)

• Final image = ~150 MB

Result:
Image size reduced by ~85–90% with cleaner, modular build process.

📉 7. Image Size Comparison Example

⚙️ 8. Multi-Stage Docker Syntax Example

# Stage 1: Build
FROM ubuntu AS build
RUN apt-get install -y golang
COPY . /src
WORKDIR /src
RUN go build -o calculator calculator.go

# Stage 2: Final (Distroless)
FROM scratch
COPY --from=build /src/calculator /
ENTRYPOINT ["/calculator"]

Explanation:

• AS build → Creates a named stage

• COPY --from=build → Copies artifact from build stage

• FROM scratch → Uses an empty minimal image (distroless base)

🪶 9. What Are Distroless Images?

Definition

A Distroless Image is a very minimalistic base image that includes:

• Only runtime binaries (e.g., Python runtime, Java runtime)

• No package manager, no shell, no OS utilities

🔍 Examples

🧰 10. Why Distroless?

✅ Advantages

🔒 11. Security Benefits

• Traditional base images (like Ubuntu, CentOS) come with many system packages → higher attack surface.

• Distroless images have no shell, no apt, no curl, etc.

• Hackers can’t exploit missing tools.

• Greatly reduces CVE (Common Vulnerability Exposure) count.

Example:

In interviews, you can say:
“We moved from Ubuntu-based containers to Python Distroless images, eliminating unnecessary system binaries and greatly reducing vulnerability exposure.”

🦴 12. Special Case: Go (Golang) Applications

• Go produces statically compiled binaries.

• Doesn’t even need a runtime to execute.

• Works perfectly with the scratch base image.

• Final image size can be as small as 1–2 MB.

Hence, Go + Multi-Stage + Distroless = 💯 perfect combination.

🔍 13. Finding Distroless Images

Visit the official Google Distroless GitHub repository:
👉 https://github.com/GoogleContainerTools/distroless

There you’ll find folders for:

• base, cc, java, python3, nodejs, etc.
  Each folder’s README.md lists the image name (e.g., gcr.io/distroless/java17).

🧾 14. Key Interview Points

🧠 15. Summary

✅ Final Takeaway:

Using Multi-Stage Docker Builds + Distroless Images gives you:

• Massive reduction in image size

• Improved container startup speed

• Drastically fewer security vulnerabilities

• Best practice for all modern production-grade container builds

Before working on real DevOps projects or advanced Docker concepts, it’s essential to first understand:

• What containers are

• How they differ from virtual machines (VMs)

• What Docker and Buildah do in the container world

This session focuses purely on concepts, not hands-on commands.

💡 2. Background: From Physical Servers → Virtual Machines → Containers

🖥️ Physical Servers

• Earlier, organizations ran one application per physical server.

• Hardware resources (CPU, RAM, storage) were often underutilized.

• Maintaining thousands of physical servers was expensive and inefficient.

🧰 Virtualization

To improve resource utilization, the concept of virtualization was introduced using a Hypervisor.

Hypervisor:
A software layer that lets you create multiple virtual machines (VMs) on a single physical server.

Each VM has:

• Its own Operating System (OS)

• Its own applications and dependencies

• Logical isolation from other VMs

Benefits:

• Better hardware utilization

• Isolation between applications

• Easier deployment than physical servers

Drawback:

• Each VM still requires a full OS, consuming large amounts of CPU, RAM, and disk.

• Even with virtualization, many VMs remain underutilized most of the time.

⚙️ 3. The Problem with Virtual Machines

Let’s say:

• Physical server = 100 GB RAM, 100 CPUs

• You create 4 VMs (25 GB RAM each)

Even if one VM’s application only needs 10 GB RAM, the rest (15 GB RAM) stays idle.

At scale — say, 1 million VMs — that wasted capacity means huge financial loss.

Hence, a more lightweight and resource-efficient approach was needed.

🧩 4. Solution: Containers

Containers were introduced to solve these inefficiencies.

Definition:

A container is a lightweight, standalone package that includes everything needed to run a piece of software — code, libraries, dependencies, and minimal OS components.

🏗️ How Containers Run

Containers can be created:

1. Directly on a physical server, or

2. On top of a virtual machine

In both cases, you install a containerization platform (like Docker, Podman, or Buildah) over the host OS.

⚖️ 5. Containers vs Virtual Machines

📌 In short:

Virtual machines isolate hardware.
Containers isolate processes.

🧠 6. Why Containers Are Lightweight

• Containers don’t include a full OS — only minimal system libraries and dependencies.

• They share the host system’s kernel.

• Only necessary components are bundled → drastically smaller image sizes.

Example:

• VM image: ~2–3 GB

• Container image: ~100–500 MB

This makes containers:

• Faster to build

• Easier to transfer (“ship”)

• Quicker to deploy

📦 7. What’s Inside a Container

A container image includes:

1. Application code

2. Application dependencies (libraries, frameworks)

3. System dependencies (minimal OS libraries)

If additional libraries are needed (e.g., Python, Node.js, Java), they’re added via base images (e.g., python:3.10, node:18, openjdk:17).

⚙️ 8. How Docker Works

Docker is a containerization platform that simplifies container creation and management.

🔄 Docker Lifecycle

Behind the scenes, Docker Engine executes these commands and handles:

• Layered image building

• Container lifecycle management

• Resource sharing with host OS

⚠️ 9. Drawbacks of Docker

While Docker made containers popular, it has a few limitations:

🧱 Single Point of Failure (SPOF)

• All containers depend on the Docker Engine daemon.

• If the Docker daemon stops, all containers stop.

🧩 Layer Complexity

• Docker builds images in layers.

• Too many layers can slow builds and consume disk space.

🔧 10. Alternative: Buildah

To overcome Docker’s limitations, Buildah was introduced.

🏗️ What Is Buildah?

A container image–building tool that doesn’t depend on a daemon like Docker Engine.

🔍 Benefits of Buildah

• No single point of failure

• No background daemon

• Works well with Podman and Skopeo

• Compatible with Docker images (OCI compliant)

• Simpler scripting via shell commands

Unlike Docker (which uses Dockerfile), Buildah can create images directly from shell scripts.

🧭 11. Real-World Architecture

Model 1: Containers on Physical Server

Physical Server
 └── OS
     └── Docker Engine / Container Platform
         ├── Container 1
         ├── Container 2
         └── Container 3

Model 2: Containers on Virtual Machine (Most Common)

Physical Server (Cloud / Data Center)
 └── Virtual Machine
     └── OS
         └── Docker Engine / Podman / Buildah
             ├── Container 1
             ├── Container 2
             └── Container 3

📌 Most organizations today use Model 2 because:

• They rely on cloud providers (AWS, Azure, GCP)

• They avoid maintaining physical data centers

🚀 12. Why Docker Became So Popular

• Simple to learn and use (docker build, docker run)

• Strong community support

• Easy image sharing through Docker Hub

• Integrated with orchestration tools like Kubernetes

• Lightweight and portable — “Build once, run anywhere”

🧾 13. Summary Table

✅ 14. Final Summary

• Containers evolved to improve resource efficiency over VMs.

• Docker popularized containers through ease of use and portability.

• Containers are lightweight, fast, and ideal for microservices.

• Docker’s limitations (single point of failure, layer bloat) led to tools like Buildah and Podman.

• Today, containerization is the foundation of modern DevOps and cloud-native computing.

This is a common interview question to understand your real experience.
You should answer by describing the tools your organization uses.

Example structure explained in your content:

• Assume your company uses Java.

• Jenkins is the main orchestrator.

• Different tools are connected with Jenkins: Maven, Sonar, AppScan, Argo CD, Kubernetes, Helm, etc.

• Explain how a developer commits code to GitHub.

• Jenkins pipeline automatically triggers and pulls the code.

• Jenkins builds the code (e.g., with Maven).

• It performs code quality checks or security checks (e.g., Sonar, AppScan).

• Then the application is promoted to Dev using Argo CD and Kubernetes.

• Argo CD watches the Git repository and deploys new versions using updated image tags and Helm charts.

• If Kubernetes is difficult, you can say you deploy to EC2 instead.

The content also refers to a Jenkins pipeline example in the GitHub repository that updates Kubernetes manifests and lets Argo CD deploy based on GitOps.

2. What are the different ways to trigger Jenkins pipelines?

Since Jenkins and GitHub are separate tools, Jenkins must know when new code is pushed.

There are three methods:

• Poll SCM

• Build triggers (Cron)

• Webhooks

Explanation from your content:

• Polling and Cron jobs are inefficient because Jenkins repeatedly checks GitHub, which consumes resources and can have time delays.

• Webhooks are the best method:

  • When a developer commits code, GitHub sends a JSON payload to Jenkins.

  • GitHub notifies Jenkins through an API.

  • Jenkins receives the payload and triggers the pipeline.

3. How to back up Jenkins?

For Jenkins administration roles, backup is important.

Summary from your content:

• The main folder to back up is .jenkins from the Jenkins home directory.

• This folder contains jobs, logs, and configuration.

• Use tools like rsync to sync backups to storage (EBS or other).

• Some large organizations store Jenkins data in external databases, so those databases must be backed up as well.

• Plugins or user content may need separate backup steps.

4. How do you store or handle secrets in Jenkins?

Secrets must never appear in logs or UI.

Jenkins provides credential plugins, but the recommended explanation:

• Use external secret managers such as HashiCorp Vault.

• Jenkins integrates with Vault.

• Pipelines fetch secrets from Vault during runtime.

5. What is the latest version of Jenkins?

Interviewers ask this to check whether you actually use Jenkins regularly.
Not knowing the current version can give a bad impression.

If you claim to be a CI/CD engineer using Jenkins, you must stay updated.

6. What are shared modules in Jenkins?

Shared modules/shared libraries mean:

• A DevOps engineer writes a pipeline once.

• Many development teams reuse that pipeline.

• This avoids each team rewriting the same logic.

It’s a reusable pipeline approach.

7. Can Jenkins build applications using multiple programming languages with different agents?

Yes.

Explanation in your content:

• Example: frontend (Node.js), backend (Java), microservice (Python).

• Jenkins can run multiple stages using different Docker agents.

• Each stage uses a separate Docker container with required dependencies.

• Containers are removed after pipeline execution, saving resources.

8. How to set up Auto Scaling Groups with Jenkins?

Some companies need multiple worker nodes.

Explanation:

• Jenkins master runs on one EC2 instance.

• Many teams may need many worker nodes.

• Load can increase during certain periods.

• Auto Scaling Groups in AWS automatically add/remove Jenkins worker nodes.

• This prevents unused nodes from wasting costs.

9. How to add a new worker node in Jenkins?

Summary:

• Go to Manage Jenkins → Manage Nodes and Clouds.

• Add a new node.

• Provide IP address, SSH keys, authentication.

• Launch the node to make it active.

10. How to install plugins in Jenkins?

Two ways:

UI Method

• Manage Jenkins → Manage Plugins

• Search and install plugins

CLI Method

• Use a Java command to install plugins directly

• Useful for automation or when installing many plugins at once

• Some plugins must be manually uploaded if not available in the plugin catalog.

11. What is JNLP and why is it used?

Explanation:

• JNLP is a way for Jenkins agents (workers) to communicate with Jenkins master.

• You download a JNLP JAR and run it on the agent.

• It allows remote launch and communication.

• The agent receives build tasks from the master.

12. What are some common Jenkins plugins?

Interviewers check your practical experience.

The content suggests:

• Be familiar with common plugins.

• Look at which plugins Jenkins installs by default.

• Prepare a list to avoid blanking during interviews.

Wrap-up

The speaker ends by saying:

• These are the main interview questions.

• The repository contains detailed answers.

• You can submit pull requests if something is missing.

• Feedback is welcome, and viewers should subscribe and share.

GitHub Actions is another CI/CD solution.
It works similarly to Jenkins — it performs Continuous Integration and Continuous Delivery tasks.
The main difference:

• GitHub Actions works only with GitHub

• GitLab CI works only with GitLab

So before choosing GitHub Actions or GitLab CI, an organization must consider whether they will stay on that platform in the future.
If a company may move to a different platform later (like GitHub → GitLab → AWS → Azure DevOps → self-hosted Git), GitHub Actions or GitLab CI is not ideal because they are tied to their respective platforms.

Like you choose Terraform over CloudFormation because Terraform works across multiple clouds, choosing GitHub Actions makes sense only if you plan to stay on GitHub.

Even though GitHub Actions is powerful and often better than Jenkins, platform-lock-in is its main limitation.

Starting With GitHub Actions

You don't install plugins manually.
To use GitHub Actions, create a folder in your repository:

.github/workflows

Inside this folder, you create YAML files (your pipelines).

Example:
If you write on: push in the first line, it means:

• Whenever someone pushes a commit, run this pipeline.

It doesn’t matter what kind of commit it is—any push will trigger the workflow.

You can have multiple workflow files (10, 20, or more).
Each can handle different jobs, such as:

• Checking pull-request description

• Linting or formatting checks

• Running CI

• Running CD
  Companies often split workflows this way.

The ArgoCD project is shown as an example.
Their .github/workflows folder has multiple workflows such as CI build, code checks, PR title check, release, and security scanning.

GitHub will run any workflow whose trigger condition matches.

Writing a GitHub Actions Workflow

A simple Python example is used.

Inside an src folder, an addition.py program contains:

• A simple addition function

• A unit test for that function

The workflow should:

1. Run on every commit

2. Check out the code

3. Create a Python environment

4. Install dependencies

5. Run the tests

When a commit is made (adding a comment in the example), GitHub Actions automatically starts running the workflow.

The logs show steps like:

• Set up job

• Check out the repository

• Set up Python

• Install dependencies

• Run tests

• Complete job

How is this defined?

Everything is written in the workflow YAML file.

YAML formatting makes it easy (similar to Kubernetes YAML).

You define:

• Workflow name

• Trigger event

• Jobs

• Container image (Ubuntu latest)

• Multiple Python versions (e.g., 3.8 and 3.9)
  → which is why two jobs were executed

Then steps are defined:

• Checkout plugin

• Setup Python plugin

• Install dependencies

• Run tests

Understanding Plugins in GitHub Actions

GitHub Actions has a marketplace of plugins.
You don’t install plugins manually (unlike Jenkins).
They are available by default.

Example:
actions/checkout@v3
→ checks out the repo

actions/setup-python@v2
→ sets up Python
The number after @ is plugin version, not Python version.

The same pattern applies to Java, Node, Ruby, etc.
Only the plugin name changes.

The biggest advantage:
Very little code is needed because most work is done by plugins.

The disadvantage:
Plugins are still limited because GitHub Actions is newer compared to older tools like Jenkins.

Self-Hosted Runners

In GitHub repository settings, you can add self-hosted runners.

You may need this if:

• GitHub’s default runners are too small

• You need more compute for tasks like load testing

• You need internal security/compliance

Then the workflow runs on your own machines instead of GitHub’s machines.

Secrets Management

GitHub Actions allows securely storing secrets, such as:

• kubeconfig

• Sonar token

• Passwords or keys

These can be used inside workflows.

The Java + Maven + Sonar + Kubernetes example demonstrates this.

Comparing GitHub Actions with Jenkins

Disadvantage

GitHub Actions is platform-dependent.
If you move from GitHub to another platform (GitLab, AWS CodeCommit, Azure DevOps), your GitHub Actions pipelines cannot be reused.

Advantages

1. No hosting effort

   • No need to install Jenkins, setup EC2 instances, configure plugins, or maintain servers.

2. Less maintenance

   • No managing Jenkins updates or plugin compatibility.

3. Simple UI and easy pipeline creation

   • YAML based, plugin-driven, easy to understand.

4. Cost

   • Free for public repositories

   • Limited free minutes for private repositories

   • Still cheaper than maintaining Jenkins infrastructure

Because of this, ~90% of open-source projects prefer GitHub Actions.

Final Summary

GitHub Actions is an easy, plugin-driven CI/CD solution built for GitHub.
It is great when your codebase will stay on GitHub.
It removes maintenance overhead, provides free execution for public repos, supports secrets, supports custom runners, and is simpler than Jenkins.

However, it locks you to GitHub.
If your organization might switch to another platform, GitHub Actions is not ideal.