DEV Community: janak0ff

Day 47: Docker Python App

janak0ff — Mon, 10 Aug 2026 16:13:15 +0000

A python app needed to be Dockerized, and then it needs to be deployed on App Server 1. We have already copied a requirements.txt file (having the app dependencies) under /python_app/src/ directory on App Server 1. Further complete this task as per details mentioned below:

Create a Dockerfile under /python_app directory:
- Use any python image as the base image.
- Install the dependencies using requirements.txt file.
- Expose the port 6100.
- Run the server.py script using CMD.
Build an image named nautilus/python-app using this Dockerfile.
Once image is built, create a container named pythonapp_nautilus:
- Map port 6100 of the container to the host port 8099.
Once deployed, you can test the app using curl command on App Server 1.

curl http://localhost:8099/

Introduction

Welcome to Day 47 of my 100 Days of DevOps journey! Today, we're going to Dockerize a Python Flask application. This is a common real-world scenario where you need to package a Python app into a container for consistent deployment across different environments.

What We'll Build Today

We have a simple Flask application that returns a welcome message. Our task is to:

Create a Dockerfile to containerize the app
Build a Docker image
Deploy it as a running container
Test the application

📋 Prerequisites

Before we begin, make sure you have:

Access to App Server 1 (stapp01)
Docker installed on the server
Basic understanding of Python and Flask

🔍 Understanding the Application

Application Structure

/python_app/
└── src/
    ├── requirements.txt
    └── server.py

File 1: `requirements.txt`

flask

This file lists all Python dependencies. Here, we only need Flask.

File 2: `server.py` – The Flask Application

from flask import Flask

# the all-important app variable:
app = Flask(__name__)

@app.route("/")
def hello():
    return "Welcome to xFusionCorp Industries!"

if __name__ == "__main__":
    app.config['TEMPLATES_AUTO_RELOAD'] = True
    app.run(host='0.0.0.0', debug=True, port=6100)

Let's understand this code:

Line	Explanation
`from flask import Flask`	Import Flask framework
`app = Flask(__name__)`	Create Flask application instance
`@app.route("/")`	Define route for the root URL
`def hello():`	Function that runs when root URL is accessed
`return "Welcome to xFusionCorp Industries!"`	Response sent to the browser
`app.run(host='0.0.0.0', debug=True, port=6100)`	Run app on all interfaces, port 6100

🔧 Step-by-Step Dockerization

Step 1: SSH to App Server 1

First, let's connect to our server:

ssh tony@stapp01
# Password: Ir0nM@n

Switch to root user for administrative tasks:

sudo su -
# Password: Ir0nM@n

Step 2: Navigate to the Application Directory

cd /python_app

# Check the directory structure
ls -la

Expected Output:

total 12
drwxr-xr-x 3 root root 4096 Aug 10 16:01 .
dr-xr-xr-x 1 root root 4096 Aug 10 16:04 ..
drwxr-xr-x 2 root root 4096 Aug 10 16:01 src

Go into the src directory to see the files:

cd src
ls -la

Expected Output:

-rw-r--r-- 1 root root 6 Aug 10 16:01 requirements.txt
-rw-r--r-- 1 root root 200 Aug 10 16:01 server.py

Step 3: View the Application Files

# View requirements
cat requirements.txt
# Output: flask

# View the Python code
cat server.py

Step 4: Create the Dockerfile

Go back to the /python_app directory:

cd /python_app

Create the Dockerfile:

vi Dockerfile

Dockerfile Content:

# Use python image as base
FROM python:3.9-slim

# Set working directory inside container
WORKDIR /app

# Copy requirements.txt and install dependencies
COPY src/requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy the application code
COPY src/ .

# Expose port 6100
EXPOSE 6100

# Run the server.py script
CMD ["python", "server.py"]

📖 Understanding the Dockerfile

Instruction	Explanation
`FROM python:3.9-slim`	Base image – lightweight Python 3.9
`WORKDIR /app`	Create and switch to `/app` directory in container
`COPY src/requirements.txt .`	Copy requirements file to container
`RUN pip install --no-cache-dir -r requirements.txt`	Install Flask dependency
`COPY src/ .`	Copy all application code to container
`EXPOSE 6100`	Document that the app listens on port 6100
`CMD ["python", "server.py"]`	Command to run when container starts

Step 5: Build the Docker Image

docker build -t nautilus/python-app /python_app/

Let's break down this command:

docker build – Build an image from a Dockerfile
-t nautilus/python-app – Tag the image with name nautilus/python-app
/python_app/ – Build context (where Dockerfile is located)

Build Process Output:

[+] Building 8.0s (10/10) FINISHED
 => [internal] load build definition from Dockerfile
 => [internal] load metadata for docker.io/library/python:3.9-slim
 => [1/5] FROM docker.io/library/python:3.9-slim
 => [2/5] WORKDIR /app
 => [3/5] COPY src/requirements.txt .
 => [4/5] RUN pip install --no-cache-dir -r requirements.txt
 => [5/5] COPY src/ .
 => exporting to image
 => => naming to docker.io/nautilus/python-app

Step 6: Verify the Image

# List all images
docker images

# Filter for our image
docker images | grep nautilus

Expected Output:

nautilus/python-app   latest    c47a882442ec   30 seconds ago   180MB

Step 7: Create and Run the Container

docker run -d --name pythonapp_nautilus -p 8099:6100 nautilus/python-app

Understanding this command:

docker run – Create and start a container
-d – Run in background (detached mode)
--name pythonapp_nautilus – Name the container
-p 8099:6100 – Map host port 8099 to container port 6100
nautilus/python-app – The image to use

Step 8: Verify the Container is Running

docker ps | grep pythonapp_nautilus

Expected Output:

ab657a0c3818   nautilus/python-app   "python server.py"   5 seconds ago   Up 4 seconds   0.0.0.0:8099->6100/tcp   pythonapp_nautilus

Step 9: Test the Application

curl http://localhost:8099/

Expected Output:

Welcome to xFusionCorp Industries!

🔍 Additional Verification Commands

Check Container Logs

docker logs pythonapp_nautilus

Expected Output:

 * Serving Flask app 'server'
 * Debug mode: on
 * Running on all addresses (0.0.0.0)
 * Running on http://127.0.0.1:6100

Check Container Details

# Detailed container information
docker inspect pythonapp_nautilus

# Port mapping
docker port pythonapp_nautilus
# Output: 6100/tcp -> 0.0.0.0:8099

Get Shell Inside Container

# Enter container shell
docker exec -it pythonapp_nautilus /bin/bash

# Inside container, you can check:
ls -la
python --version
exit

📝 Complete Commands Summary

# SSH to App Server 1
ssh tony@stapp01
# Password: Ir0nM@n

# Switch to root
sudo su -
# Password: Ir0nM@n

# Navigate to directory
cd /python_app

# Create Dockerfile
cat > Dockerfile << 'EOF'
# Use python image as base
FROM python:3.9-slim

# Set working directory inside container
WORKDIR /app

# Copy requirements.txt and install dependencies
COPY src/requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Copy the application code
COPY src/ .

# Expose port 6100
EXPOSE 6100

# Run the server.py script
CMD ["python", "server.py"]
EOF

# Build the image
docker build -t nautilus/python-app /python_app/

# Create and run container
docker run -d --name pythonapp_nautilus -p 8099:6100 nautilus/python-app

# Verify
docker ps | grep pythonapp_nautilus

# Test
curl http://localhost:8099/

📊 Architecture Diagram

┌─────────────────────────────────────────────────────────────┐
│                      App Server 1                           │
│                                                             │
│  ┌──────────────────────────────────────────────────────┐   │
│  │            pythonapp_nautilus Container              │   │
│  │                                                      │   │
│  │  ┌────────────────────────────────────────────┐     │   │
│  │  │         Flask Application                   │     │   │
│  │  │         (server.py)                        │     │   │
│  │  │         Port: 6100                         │     │   │
│  │  └────────────────────────────────────────────┘     │   │
│  │                                                      │   │
│  │  Docker Image: nautilus/python-app                   │   │
│  └──────────────────────────────────────────────────────┘   │
│                          │                                  │
│                          ▼                                  │
│                Port Mapping: 8099:6100                     │
│                          │                                  │
│                          ▼                                  │
│           curl http://localhost:8099/                      │
│                                                             │
│           Response: "Welcome to xFusionCorp Industries!"   │
└─────────────────────────────────────────────────────────────┘

🎯 Key Concepts Explained

What is a Dockerfile?

A Dockerfile is a text file with instructions on how to build a Docker image. Think of it as a recipe:

Base Image: The starting point (like using a pre-made pizza crust)
Instructions: What to add and how to prepare (adding toppings)
Expose: What port the app uses (like the serving window)
CMD: What to run when the container starts (like turning on the oven)

Why Use `python:3.9-slim`?

python:3.9-slim is a lightweight version
It contains only what's necessary to run Python
Smaller image size → faster downloads and less storage

Port Mapping Explained

Host Port → Container Port
  8099    →     6100

The app runs on port 6100 inside the container
We access it on port 8099 from outside
This prevents port conflicts if multiple containers use the same port

✅ Task Summary

Requirement	Status	Command/File
Create Dockerfile	✅	`/python_app/Dockerfile`
Use Python base image	✅	`FROM python:3.9-slim`
Install dependencies	✅	`pip install -r requirements.txt`
Expose port 6100	✅	`EXPOSE 6100`
Run server.py	✅	`CMD ["python", "server.py"]`
Build image	✅	`docker build -t nautilus/python-app`
Create container	✅	`pythonapp_nautilus`
Port mapping	✅	`8099:6100`
Application accessible	✅	`curl http://localhost:8099/`

🔧 Troubleshooting Common Issues

Issue 1: Dockerfile Not Found

Error: open Dockerfile: no such file or directory
Solution: Make sure Dockerfile is in the correct directory (/python_app)

Issue 2: Port Already in Use

Error: port is already allocated
Solution: Use a different host port or stop the conflicting container

Issue 3: Flask Not Found

Error: ModuleNotFoundError: No module named 'flask'
Solution: Check that requirements.txt contains flask and pip install ran successfully

🎉 You Did It!

You've successfully Dockerized a Python Flask application! This is exactly how real-world applications are containerized and deployed in production.

What You Learned:

✅ How to write a Dockerfile for Python applications
✅ How to build Docker images
✅ How to run containers with port mapping
✅ How to test containerized applications

Day 46: Deploy an App on Docker Containers

janak0ff — Sun, 09 Aug 2026 09:02:15 +0000

The Nautilus Application development team recently finished development of one of the apps that they want to deploy on a containerized platform. The Nautilus Application development and DevOps teams met to discuss some of the basic pre-requisites and requirements to complete the deployment. The team wants to test the deployment on one of the app servers before going live and set up a complete containerized stack using a docker compose fie. Below are the details of the task:

On App Server 2 in Stratos Datacenter create a docker compose file /opt/data/docker-compose.yml (should be named exactly).
The compose should deploy two services (web and DB), and each service should deploy a container as per details below:

For web service:

a. Container name must be php_host.

b. Use image php with any apache tag. Check here for more details.

c. Map php_host container's port 80 with host port 6200

d. Map php_host container's /var/www/html volume with host volume /var/www/html.

For DB service:

a. Container name must be mysql_host.

b. Use image mariadb with any tag (preferably latest). Check here for more details.

c. Map mysql_host container's port 3306 with host port 3306

d. Map mysql_host container's /var/lib/mysql volume with host volume /var/lib/mysql.

e. Set MYSQL_DATABASE=database_host and use any custom user ( except root ) with some complex password for DB connections.

After running docker-compose up you can access the app with curl command curl <server-ip or hostname>:6200/

For more details check here.

Note: Once you click on FINISH button, all currently running/stopped containers will be destroyed and stack will be deployed again using your compose file.

Introduction

Welcome to Day 46 of my 100 Days of DevOps journey! Today, we're going to learn how to deploy a complete application using Docker Compose. Don't worry if you're new to this – I'll explain everything step by step in simple terms.

What is Docker Compose?

Think of Docker Compose like a recipe book for your applications. Instead of manually running multiple docker run commands, you write all the instructions in a single file, and Docker Compose does everything for you with one command.

Why Use Docker Compose?

One command to start everything
Easy to manage multiple containers
Consistent environment every time
Simple to share with your team

📋 Our Task Today

We need to deploy a web application with a database on App Server 2. The application has two parts:

Web Server (PHP) – serves the website
Database (MariaDB) – stores data

🔧 Step-by-Step Guide

Step 1: Connect to the Server

First, let's connect to our server:

ssh steve@stapp02
# Enter password: Am3ric@

Once connected, switch to root user (administrator):

sudo su -
# Enter password: Am3ric@

Step 2: Create the Working Directory

Let's create a folder for our Docker Compose file:

mkdir -p /opt/data
cd /opt/data

Step 3: Install Docker Compose

Docker Compose might not be installed by default. Let's install it:

# Download Docker Compose
curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

# Make it executable
chmod +x /usr/local/bin/docker-compose

# Fix missing library (if needed)
yum install -y libxcrypt-compat

# Verify installation
docker-compose --version

What's happening here?

curl downloads the Docker Compose binary
chmod makes it executable
yum install fixes any missing dependencies
The last command confirms it's working

Step 4: Create the Docker Compose File

Now, let's create our recipe file. Think of this as telling Docker what we want:

vi docker-compose.yml

Add this content:

version: '3.8'

services:
  web:
    image: php:apache
    container_name: php_host
    ports:
      - "6200:80"
    volumes:
      - "/var/www/html:/var/www/html"

  db:
    image: mariadb:latest
    container_name: mysql_host
    ports:
      - "3306:3306"
    volumes:
      - "/var/lib/mysql:/var/lib/mysql"
    environment:
      MYSQL_DATABASE: database_host
      MYSQL_USER: dbuser
      MYSQL_PASSWORD: 'ComplexPassword123!'
      MYSQL_ROOT_PASSWORD: 'RootPassword123!'

📖 Understanding the YAML File

Let me explain what each part means:

Web Service (the website)

web:
  image: php:apache          # Use PHP with Apache
  container_name: php_host   # Name our container
  ports:
    - "6200:80"              # Host port 6200 → Container port 80
  volumes:
    - "/var/www/html:/var/www/html"  # Share files between host and container

DB Service (the database)

db:
  image: mariadb:latest      # Use MariaDB database
  container_name: mysql_host # Name our container
  ports:
    - "3306:3306"            # Host port 3306 → Container port 3306
  volumes:
    - "/var/lib/mysql:/var/lib/mysql"  # Store database data
  environment:               # Set up database
    MYSQL_DATABASE: database_host
    MYSQL_USER: dbuser
    MYSQL_PASSWORD: 'ComplexPassword123!'
    MYSQL_ROOT_PASSWORD: 'RootPassword123!'

Step 5: Start the Application

Now the magic happens! Run this command to start everything:

docker-compose up -d

What this does:

docker-compose – runs Docker Compose
up – starts the containers
-d – runs in background (detached mode)

Step 6: Verify Everything is Working

Check if our containers are running:

# List running containers
docker-compose ps

Expected output:

   Name                 Command               State                    Ports                  
----------------------------------------------------------------------------------------------
mysql_host   docker-entrypoint.sh mariadbd    Up      0.0.0.0:3306->3306/tcp,:::3306->3306/tcp
php_host     docker-php-entrypoint apac ...   Up      0.0.0.0:6200->80/tcp,:::6200->80/tcp

Step 7: Test the Application

Finally, let's test if our application is working:

curl http://localhost:6200

If everything is working, you should see the default Apache welcome page or your website content.

🎯 Understanding What We Just Built

Container Architecture

┌─────────────────────────────────────────────┐
│              App Server 2                    │
│                                               │
│  ┌──────────────────┐  ┌──────────────────┐   │
│  │   php_host       │  │   mysql_host     │   │
│  │                  │  │                  │   │
│  │  Port: 6200      │  │  Port: 3306      │   │
│  │  Website:        │  │  Database:       │   │
│  │  /var/www/html   │  │  /var/lib/mysql  │   │
│  └──────────────────┘  └──────────────────┘   │
│                                               │
│  ┌─────────────────────────────────────────┐   │
│  │   Host Volumes (persistent storage)     │   │
│  │   - /var/www/html (web files)           │   │
│  │   - /var/lib/mysql (database)           │   │
│  └─────────────────────────────────────────┘   │
└─────────────────────────────────────────────┘

Key Concepts Explained

1. Images vs Containers

Image: The blueprint/template (like a recipe)
Container: Running instance of an image (like the cooked meal)

2. Port Mapping

"6200:80" means: When you access port 6200 on your server, it goes to port 80 in the container
This is how we access services from outside the container

3. Volumes

Think of volumes as external hard drives
They keep your data even if containers are deleted
Both containers can access the same files

4. Environment Variables

Settings that configure the database
Like setting up a new user and database automatically

🔧 Troubleshooting Common Issues

Issue 1: Docker Compose Not Found

Error: docker-compose: command not found
Solution: Install Docker Compose (Step 3 above)

Issue 2: libcrypt.so.1 Error

Error: libcrypt.so.1: cannot open shared object file
Solution: yum install -y libxcrypt-compat

Issue 3: Permission Denied

Error: Permission denied while trying to connect to the Docker daemon
Solution: Add user to docker group:

usermod -aG docker steve
newgrp docker

Issue 4: Port Already in Use

Error: port is already allocated
Solution: Change the host port in the YAML file or stop the other service

📊 Quick Reference: Docker Compose Commands

Command	Description
`docker-compose up -d`	Start containers in background
`docker-compose down`	Stop and remove containers
`docker-compose ps`	List running containers
`docker-compose logs`	View container logs
`docker-compose logs web`	View logs for web service
`docker-compose restart`	Restart containers
`docker-compose exec web bash`	Get shell inside web container

✅ Summary

Today we learned:

What is Docker Compose – A tool to manage multiple containers
How to write a docker-compose.yml – Define services, ports, volumes
How to deploy – One command to start everything
How to verify – Check containers and test the application

Quick Command Summary

# Create directory
mkdir -p /opt/data && cd /opt/data

# Create compose file
vi docker-compose.yml

# Start everything
docker-compose up -d

# Check status
docker-compose ps

# Test
curl http://localhost:6200

Revert Deployment to Previous Version in Kubernetes

janak0ff — Sun, 09 Aug 2026 08:44:53 +0000

Earlier today, the Nautilus DevOps team deployed a new release for an application. However, a customer has reported a bug related to this recent release. Consequently, the team aims to revert to the previous version.
There exists a deployment named nginx-deployment; initiate a rollback to the previous revision.

Understanding Rollbacks

What is a Rollback?

A rollback is the process of reverting a deployment to a previous version. Think of it like the "Undo" button in a text editor, but for your entire application!

Why Rollbacks Matter

Scenario	Without Rollback	With Rollback
Buggy release	Application broken, users unhappy	Quick revert to stable version
Security issue	Vulnerability exposed	Immediate fix by reverting
Performance degradation	Slow application	Restore to fast version
Configuration error	Application crashes	Rollback to working config

How Rollbacks Work in Kubernetes

When you update a Deployment, Kubernetes:

Creates a new ReplicaSet with the new image
Gradually replaces old pods with new ones
Keeps the old ReplicaSet as a backup

This means rolling back is as simple as telling Kubernetes to use the old ReplicaSet again!

┌─────────────────────────────────────────────────────┐
│                  Deployment                        │
│            Revision History: 1, 2, 3              │
└────────────────────┬────────────────────────────────┘
                     │
        ┌────────────┼────────────┐
        │            │            │
        ▼            ▼            ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Revision 1   │ │ Revision 2   │ │ Revision 3   │
│ (Stable)     │ │ (Buggy)      │ │ (New)        │
│ ReplicaSet   │ │ ReplicaSet   │ │ ReplicaSet   │
│ 3 pods ✅    │ │ 0 pods ❌    │ │ 0 pods ⏳    │
└──────────────┘ └──────────────┘ └──────────────┘
       ▲                │                │
       │                │                │
       └────────────────┴────────────────┘
                Rollback goes here!

The Scenario: When Things Go Wrong

Imagine this: You're the DevOps engineer at Nautilus. You've just deployed a new version of your application using nginx:alpine. Your users start reporting bugs. The team is panicking. What do you do?

You rollback to the previous stable version!

Our Setup

We have a deployment called nginx-deployment with two revisions:

REVISION  CHANGE-CAUSE
1         <none>                                    ← Previous stable version
2         kubectl set image ... nginx:alpine ...    ← Current buggy version

Goal: Rollback from Revision 2 to Revision 1

Step-by-Step Rollback Guide

Step 1: Check Your Current Deployment

First, let's see what we're working with:

kubectl get deployments

Output:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           15m

This shows we have a deployment called nginx-deployment with 3 running pods.

Step 2: View the Rollout History

Before rolling back, let's see the history of changes:

kubectl rollout history deployment nginx-deployment

Output:

deployment.apps/nginx-deployment 
REVISION  CHANGE-CAUSE
1         <none>
2         kubectl set image deployment nginx-deployment nginx-container=nginx:alpine --record=true

What this tells us:

Revision 1: The original deployment (stable)
Revision 2: The current deployment (buggy, using nginx:alpine)

Step 3: Examine the Previous Revision

Let's check what Revision 1 looked like:

kubectl rollout history deployment nginx-deployment --revision=1

Output:

deployment.apps/nginx-deployment with revision #1
Pod Template:
  Labels:   app=nginx-deployment
  Containers:
   nginx-container:
    Image:  nginx:1.16

Great! Revision 1 uses nginx:1.16 - this was our stable version.

Step 4: Check the Current Revision

For comparison, let's check Revision 2:

kubectl rollout history deployment nginx-deployment --revision=2

Output:

deployment.apps/nginx-deployment with revision #2
Pod Template:
  Labels:   app=nginx-deployment
  Annotations:  kubernetes.io/change-cause: kubectl set image deployment nginx-deployment nginx-container=nginx:alpine --record=true
  Containers:
   nginx-container:
    Image:  nginx:alpine

The problem: Revision 2 uses nginx:alpine which has a bug.

Step 5: Perform the Rollback

Now let's rollback to the previous revision:

kubectl rollout undo deployment nginx-deployment

Output:

deployment.apps/nginx-deployment rolled back

What just happened? Kubernetes reverted to Revision 1!

Step 6: Monitor the Rollback

Watch the rollback in progress:

kubectl rollout status deployment nginx-deployment

Output:

deployment "nginx-deployment" successfully rolled out

This confirms the rollback completed successfully.

Step 7: Verify the Rollback

Now let's verify everything is back to normal:

kubectl get deployment nginx-deployment

Output:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           20m

All 3 pods are ready!

Step 8: Check the Current Image

Let's confirm we're using the correct image:

kubectl get deployment nginx-deployment -o jsonpath='{.spec.template.spec.containers[0].image}'

Output:

nginx:1.16

Success! We're back to the stable version.

Step 9: Check the New History

Look at the updated rollout history:

kubectl rollout history deployment nginx-deployment

Output:

REVISION  CHANGE-CAUSE
2         kubectl set image deployment nginx-deployment nginx-container=nginx:alpine --record=true
3         <none>

Important: A new revision (3) was created for the rollback. Revision 1 is still referenced internally.

Step 10: Verify Pods are Running

Check all pods are healthy:

kubectl get pods

Output:

NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-fc677cbc9-4tg9t   1/1     Running   0          46s
nginx-deployment-fc677cbc9-hxg9s   1/1     Running   0          50s
nginx-deployment-fc677cbc9-vg76c   1/1     Running   0          48s

All pods are running with the correct ReplicaSet (fc677cbc9)!

Verification Commands Cheat Sheet

Here are all the commands you need to verify a successful rollback:

# Quick status overview
kubectl get deployment,rs,pods -l app=nginx-deployment

# Check image version
kubectl get deployment nginx-deployment -o jsonpath='{.spec.template.spec.containers[0].image}'

# Detailed pod info
kubectl describe pod -l app=nginx-deployment | grep -E "Name:|Image:|Status:"

# Check events
kubectl get events --field-selector involvedObject.name=nginx-deployment

# Full deployment details
kubectl describe deployment nginx-deployment

Common Rollback Scenarios

Scenario 1: Rollback to Previous Revision

This is the most common case - just undo the last change:

kubectl rollout undo deployment nginx-deployment

Scenario 2: Rollback to a Specific Revision

If you want to go back to a specific version:

# First, check what revision you want
kubectl rollout history deployment nginx-deployment

# Then rollback to that revision
kubectl rollout undo deployment nginx-deployment --to-revision=1

Scenario 3: Rollback with Annotations

Track why you rolled back:

kubectl annotate deployment nginx-deployment kubernetes.io/change-cause="Rollback to nginx:1.16 due to bug in alpine version"
kubectl rollout undo deployment nginx-deployment

Scenario 4: Rollback with Different Image

Manually set the image if you want to test a different version:

kubectl set image deployment nginx-deployment nginx-container=nginx:1.17 --record=true

Troubleshooting Rollback Issues

Issue 1: "No rollout history found"

Error:

Error: no rollout history found for deployment "nginx-deployment"

Solution:

# Check if revisionHistoryLimit is set to 0
kubectl get deployment nginx-deployment -o yaml | grep revisionHistoryLimit

# If it's 0, set it to a higher number
kubectl patch deployment nginx-deployment -p '{"spec":{"revisionHistoryLimit":5}}'

# Then manually set the image
kubectl set image deployment nginx-deployment nginx-container=nginx:1.16

Issue 2: Rollback Stuck

Symptoms:

Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...

Solution:

# Check pod status
kubectl get pods

# Check pod events
kubectl describe pod -l app=nginx-deployment

# If stuck, force rollback
kubectl rollout undo deployment nginx-deployment --to-revision=1

Issue 3: Container Not Found

Error:

error: unable to find container named "nginx"

Solution:

# Find the correct container name
kubectl get deployment nginx-deployment -o jsonpath='{.spec.template.spec.containers[0].name}'

# Use the correct name
kubectl set image deployment nginx-deployment [correct-name]=nginx:1.16

Issue 4: Rollback Creates New Revision

Observation:

REVISION  CHANGE-CAUSE
2         Update to nginx:alpine
3         <none>  # Rollback created this

Explanation: This is normal behavior! Rollbacks create new revisions so you can:

See exactly what was rolled back
Roll forward again if needed
Maintain a complete audit trail

Best Practices for Rollbacks

✅ DO's

1. Always Check History First

# Never rollback blindly
kubectl rollout history deployment nginx-deployment

2. Use Change Cause Annotations

kubectl annotate deployment nginx-deployment kubernetes.io/change-cause="Update to nginx:1.19"

3. Monitor During Rollback

kubectl rollout status deployment nginx-deployment

4. Keep Revision History

spec:
  revisionHistoryLimit: 5  # Keep last 5 versions

5. Test in Staging First

# Test in staging
kubectl set image deployment/nginx-staging nginx=nginx:alpine
kubectl rollout status deployment/nginx-staging

# Then deploy to production
kubectl set image deployment/nginx-production nginx=nginx:alpine

6. Have a Rollback Plan

Know who can perform rollbacks
Document the process
Practice in a test environment

❌ DON'Ts

1. Don't Delete Old ReplicaSets

# BAD - You lose rollback capability
kubectl delete rs nginx-deployment-xxxxxxxxxx

# GOOD - Let Kubernetes manage them
# Just leave them alone, they'll be cleaned up automatically

2. Don't Rollback During Peak Hours

# Consider the impact on users
# Schedule during maintenance windows if possible

3. Don't Forget to Communicate

# Notify your team about the rollback
# Document why it happened

4. Don't Ignore the Root Cause

# Don't just rollback and move on
# Investigate what caused the bug
# Test the fix in staging
# Then try the update again

Complete Rollback Script

Here's a complete rollback script you can use:

#!/bin/bash
# rollback.sh - Complete rollback procedure

echo "=== Kubernetes Rollback Procedure ==="

# 1. Get current state
echo -e "\n1. Current Deployment Status:"
kubectl get deployment nginx-deployment

# 2. Check rollout history
echo -e "\n2. Rollout History:"
kubectl rollout history deployment nginx-deployment

# 3. Check current image
CURRENT_IMAGE=$(kubectl get deployment nginx-deployment -o jsonpath='{.spec.template.spec.containers[0].image}')
echo -e "\n3. Current Image: $CURRENT_IMAGE"

# 4. Ask for confirmation
echo -e "\n4. Are you sure you want to rollback? (y/n)"
read -r CONFIRM

if [ "$CONFIRM" != "y" ]; then
    echo "Rollback cancelled."
    exit 1
fi

# 5. Perform rollback
echo -e "\n5. Performing Rollback..."
kubectl rollout undo deployment nginx-deployment

# 6. Monitor rollback
echo -e "\n6. Monitoring Rollback Status:"
kubectl rollout status deployment nginx-deployment

# 7. Verify after rollback
echo -e "\n7. After Rollback:"
kubectl get deployment nginx-deployment

# 8. Check new image
NEW_IMAGE=$(kubectl get deployment nginx-deployment -o jsonpath='{.spec.template.spec.containers[0].image}')
echo -e "\n8. New Image: $NEW_IMAGE"

# 9. Check pods
echo -e "\n9. Pod Status:"
kubectl get pods

echo -e "\n=== Rollback Completed ==="

Real-World Example: Complete Rollback

Here's a complete example with all commands:

# 1. Check current state
kubectl get deployment nginx-deployment

# 2. Check history
kubectl rollout history deployment nginx-deployment

# 3. Check current image
kubectl get deployment nginx-deployment -o jsonpath='{.spec.template.spec.containers[0].image}'
# Output: nginx:alpine

# 4. Annotate why we're rolling back
kubectl annotate deployment nginx-deployment kubernetes.io/change-cause="Rolling back due to bug in alpine version"

# 5. Perform rollback
kubectl rollout undo deployment nginx-deployment

# 6. Monitor rollback
kubectl rollout status deployment nginx-deployment

# 7. Verify image
kubectl get deployment nginx-deployment -o jsonpath='{.spec.template.spec.containers[0].image}'
# Output: nginx:1.16

# 8. Check history
kubectl rollout history deployment nginx-deployment

# 9. Check pods
kubectl get pods

# 10. Check events
kubectl get events --sort-by='.lastTimestamp' | tail -10

Quick Reference Card

Rollback Commands

Command	Description
`kubectl rollout history deployment/NAME`	View all revisions
`kubectl rollout history deployment/NAME --revision=N`	View specific revision
`kubectl rollout undo deployment/NAME`	Rollback to previous
`kubectl rollout undo deployment/NAME --to-revision=N`	Rollback to specific
`kubectl rollout status deployment/NAME`	Check rollback status
`kubectl rollout pause deployment/NAME`	Pause rollback
`kubectl rollout resume deployment/NAME`	Resume rollback

Verification Commands

Command	Purpose
`kubectl get deployment NAME`	Check deployment status
`kubectl get pods`	Check pod status
`kubectl get rs`	Check ReplicaSets
`kubectl describe deployment NAME`	Detailed info
`kubectl get events`	View events

Conclusion

You've just learned how to safely rollback Kubernetes deployments! This is a critical skill that will save you when things go wrong.

Key Takeaways

Rollbacks are easy: One command is all it takes
Zero downtime: Rolling updates and rollbacks are gradual
History matters: Kubernetes keeps track of changes
Verify everything: Always check the rollback worked
Communicate: Let your team know what happened

What You Learned

✅ How to view deployment history
✅ How to perform a rollback
✅ How to verify a rollback
✅ Common rollback scenarios
✅ Troubleshooting techniques
✅ Best practices

Next Steps

Now that you've mastered rollbacks, explore these related topics:

Blue-Green Deployments - Advanced deployment strategy
Canary Deployments - Gradual rollouts
Feature Flags - Control features without redeploying
GitOps - Declarative deployment management
CI/CD Pipelines - Automate deployments and rollbacks

Final Words

Remember: It's not about avoiding failures, it's about being prepared to handle them gracefully. With Kubernetes rollbacks, you have a powerful tool to quickly recover from bad deployments.

Happy rolling back! 🚀

Day 45: Fixing a Broken Docker Build – KodeKloud Engineer Challenge

janak0ff — Sat, 08 Aug 2026 15:32:07 +0000

The Nautilus DevOps team is working to create new images per requirements shared by the development team. One of the team members is working to create a Dockerfile on App Server 1 in Stratos DC. While working on it she ran into issues in which the docker build is failing and displaying errors. Look into the issue and fix it to build an image as per details mentioned below:
a. The Dockerfile is placed on App Server 1 under /opt/docker directory.

b. Fix the issues with this file and make sure it is able to build the image.

c. Do not change base image, any other valid configuration within Dockerfile, or any of the data been used — for example, index.html.

Note: Please note that once you click on FINISH button all the existing containers will be destroyed and new image will be built from your Dockerfile.

Introduction

Welcome back to my 100 Days of DevOps journey! Today marks Day 45, and we're diving into Dockerfile troubleshooting – a critical skill for any DevOps engineer working with containerized applications.

📋 Challenge Overview

The Nautilus DevOps team is working to create new images per requirements shared by the development team. One of the team members ran into issues where the docker build was failing and displaying errors. Our task was to fix the Dockerfile on App Server 1 in Stratos DC and ensure the image builds successfully.

Task Requirements:

Dockerfile is placed on App Server 1 under /opt/docker directory
Fix the issues with this file and make sure it is able to build the image
Do not change the base image, any other valid configuration, or any data being used (e.g., index.html)

🔍 The Problem

The original Dockerfile had the following issues:

FROM httpd:2.4.43

RUN sed -i "s/Listen 80/Listen 8080/g" /usr/local/apache2/conf/httpd.conf

RUN sed -i '/LoadModule\ ssl_module modules\/mod_ssl.so/s/^#//g' conf/httpd.conf

RUN sed -i '/LoadModule\ socache_shmcb_module modules\/mod_socache_shmcb.so/s/^#//g' conf/httpd.conf

RUN sed -i '/Include\ conf\/extra\/httpd-ssl.conf/s/^#//g' conf/httpd.conf

RUN cp certs/server.crt /usr/local/apache2/conf/server.crt

RUN cp certs/server.key /usr/local/apache2/conf/server.key

RUN cp html/index.html /usr/local/apache2/htdocs/

❌ Issue 1: Incorrect Paths in `sed` Commands

The sed commands were using conf/httpd.conf instead of the full path /usr/local/apache2/conf/httpd.conf. Since the working directory inside the container is not guaranteed to be /usr/local/apache2, the commands would fail.

Fix: Use full paths in all sed commands:

RUN sed -i '/LoadModule\ ssl_module modules\/mod_ssl.so/s/^#//g' /usr/local/apache2/conf/httpd.conf

❌ Issue 2: Using `RUN cp` Instead of `COPY`

This was the main issue:

RUN cp certs/server.crt /usr/local/apache2/conf/server.crt

Why this fails:

RUN executes commands inside the container during build time
At that moment, the container doesn't know about local files like certs/ or html/
RUN cp fails because the files aren't inside the container yet

Fix: Use COPY to transfer files from the local build context:

COPY certs/server.crt /usr/local/apache2/conf/server.crt

❌ Issue 3: Missing Directories and Files

The certs and html directories didn't exist, and SSL certificates and index.html were not present.

Fix: Create directories and generate required files:

mkdir -p certs html
echo "<h1>Welcome to Nautilus</h1>" > html/index.html
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -keyout certs/server.key \
    -out certs/server.crt \
    -subj "/C=US/ST=State/L=City/O=Organization/CN=localhost"

🛠️ The Solution

Step 1: SSH to App Server 1

ssh tony@stapp01
# Password: Ir0nM@n

Step 2: Navigate to Docker Directory

cd /opt/docker

Step 3: Create Required Directories and Files

# Create directories
mkdir -p certs html

# Create index.html
echo "<h1>Welcome to Nautilus</h1>" > html/index.html

# Generate SSL certificates
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -keyout certs/server.key \
    -out certs/server.crt \
    -subj "/C=US/ST=State/L=City/O=Organization/CN=localhost"

Step 4: Fix the Dockerfile

FROM httpd:2.4.43

RUN sed -i "s/Listen 80/Listen 8080/g" /usr/local/apache2/conf/httpd.conf

RUN sed -i '/LoadModule\ ssl_module modules\/mod_ssl.so/s/^#//g' /usr/local/apache2/conf/httpd.conf

RUN sed -i '/LoadModule\ socache_shmcb_module modules\/mod_socache_shmcb.so/s/^#//g' /usr/local/apache2/conf/httpd.conf

RUN sed -i '/Include\ conf\/extra\/httpd-ssl.conf/s/^#//g' /usr/local/apache2/conf/httpd.conf

COPY certs/server.crt /usr/local/apache2/conf/server.crt

COPY certs/server.key /usr/local/apache2/conf/server.key

COPY html/index.html /usr/local/apache2/htdocs/index.html

Step 5: Build the Image

docker build -t httpd:custom /opt/docker/

📊 Expected Output

[root@stapp01 docker]# docker build -t httpd:custom /opt/docker/
[+] Building 9.0s (13/13) FINISHED
 => [internal] load build definition from Dockerfile
 => [internal] load metadata for docker.io/library/httpd:2.4.43
 => [1/8] FROM docker.io/library/httpd:2.4.43
 => [2/8] RUN sed -i "s/Listen 80/Listen 8080/g" /usr/local/apache2/conf/httpd.conf
 => [3/8] RUN sed -i '/LoadModule\ ssl_module modules\/mod_ssl.so/s/^#//g' /usr/local/apache2/conf/httpd.conf
 => [4/8] RUN sed -i '/LoadModule\ socache_shmcb_module modules\/mod_socache_shmcb.so/s/^#//g' /usr/local/apache2/conf/httpd.conf
 => [5/8] RUN sed -i '/Include\ conf\/extra\/httpd-ssl.conf/s/^#//g' /usr/local/apache2/conf/httpd.conf
 => [6/8] COPY certs/server.crt /usr/local/apache2/conf/server.crt
 => [7/8] COPY certs/server.key /usr/local/apache2/conf/server.key
 => [8/8] COPY html/index.html /usr/local/apache2/htdocs/index.html
 => exporting to image
 => => writing image sha256:31aa770b164e
 => => naming to docker.io/library/httpd:custom

🔑 Key Learnings

1. RUN vs COPY

RUN executes commands inside the container during build time
COPY transfers files from the local build context into the image
Use COPY for files that exist on your host machine

2. Always Use Full Paths

When modifying files inside a container, always use absolute paths
This ensures the command works regardless of the current working directory

3. Image Tagging

Always use -t to give your image a meaningful name
This makes it easier to reference and run containers later

4. Build Context

All files used in COPY commands must exist in the build context
The build context is the directory specified in the docker build command

📋 Final Dockerfile

FROM httpd:2.4.43

RUN sed -i "s/Listen 80/Listen 8080/g" /usr/local/apache2/conf/httpd.conf

RUN sed -i '/LoadModule\ ssl_module modules\/mod_ssl.so/s/^#//g' /usr/local/apache2/conf/httpd.conf

RUN sed -i '/LoadModule\ socache_shmcb_module modules\/mod_socache_shmcb.so/s/^#//g' /usr/local/apache2/conf/httpd.conf

RUN sed -i '/Include\ conf\/extra\/httpd-ssl.conf/s/^#//g' /usr/local/apache2/conf/httpd.conf

COPY certs/server.crt /usr/local/apache2/conf/server.crt

COPY certs/server.key /usr/local/apache2/conf/server.key

COPY html/index.html /usr/local/apache2/htdocs/index.html

✅ Task Summary

Requirement	Status
Dockerfile in `/opt/docker`	✅
Fixed `sed` paths with full paths	✅
Created `certs` directory	✅
Generated SSL certificates	✅
Created `html` directory	✅
Created `index.html`	✅
Changed `RUN cp` to `COPY`	✅
Docker image builds successfully	✅

Execute Rolling Updates in Kubernetes

janak0ff — Sat, 08 Aug 2026 15:14:27 +0000

An application currently running on the Kubernetes cluster employs the nginx web server. The Nautilus application development team has introduced some recent changes that need deployment. They've crafted an image nginx:1.19 with the latest updates.

Execute a rolling update for this application, integrating the nginx:1.19 image. The deployment is named nginx-deployment.

Ensure all pods are operational post-update.

Note: The kubectl utility on the jump-host has been configured to work with the Kubernetes cluster.

Solution

Step 1: Check Current Deployment Status

First, let's verify the current state of the deployment:

kubectl get deployments
kubectl get pods
kubectl get rs

Expected output:

NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           5m

NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-7c5d8bf9f7-xxx    1/1     Running   0          5m
nginx-deployment-7c5d8bf9f7-yyy    1/1     Running   0          5m
nginx-deployment-7c5d8bf9f7-zzz    1/1     Running   0          5m

Step 2: Check Current Image Version

Verify the current image version:

kubectl describe deployment nginx-deployment | grep Image

Step 3: Perform the Rolling Update

Update the deployment to use the nginx:1.19 image:

kubectl set image deployment/nginx-deployment nginx=nginx:1.19

Expected output:

deployment.apps/nginx-deployment image updated

Step 4: Check Rollout Status

Monitor the rollout progress:

kubectl rollout status deployment/nginx-deployment

Expected output:

Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 2 out of 3 new replicas have been updated...
Waiting for deployment "nginx-deployment" rollout to finish: 3 out of 3 new replicas have been updated...
deployment "nginx-deployment" successfully rolled out

Step 5: Verify the Update

Check that all pods are updated and running:

# Check deployment status
kubectl get deployments

# Check pods
kubectl get pods

# Verify the new image
kubectl describe deployment nginx-deployment | grep Image

# Check pods with the new image
kubectl get pods -o jsonpath='{.items[*].spec.containers[0].image}'

Expected output:

nginx:1.19

Step 6: Check ReplicaSets

Verify the old and new ReplicaSets:

kubectl get rs

Expected output:

NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-7c5d8bf9f7   0         0         0       5m    # Old ReplicaSet (scaled down)
nginx-deployment-8d9f4b5c6    3         3         3       1m    # New ReplicaSet (scaled up)

Alternative Methods

Method 1: Using `kubectl edit`

Edit the deployment directly:

kubectl edit deployment nginx-deployment

Then change:

spec:
  containers:
  - image: nginx:1.19

Save and exit. The deployment will automatically roll out the update.

Method 2: Using `kubectl patch`

Patch the deployment with a strategic merge:

kubectl patch deployment nginx-deployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:1.19"}]}}}}'

Method 3: Using `kubectl apply` with YAML

Update the YAML file and reapply:

# Edit the YAML file
nano nginx-deployment.yaml

# Change image to nginx:1.19
# Apply the updated YAML
kubectl apply -f nginx-deployment.yaml

Method 4: Using `kubectl replace`

# Get current deployment YAML
kubectl get deployment nginx-deployment -o yaml > nginx-deployment.yaml

# Edit the file
nano nginx-deployment.yaml

# Replace with the updated YAML
kubectl replace -f nginx-deployment.yaml

Verification Commands

1. Check Deployment Status

# Detailed status
kubectl rollout status deployment/nginx-deployment

# Deployment details
kubectl describe deployment nginx-deployment

# Show deployment with custom columns
kubectl get deployment nginx-deployment -o custom-columns=NAME:.metadata.name,REPLICAS:.spec.replicas,UPDATED:.status.updatedReplicas,READY:.status.readyReplicas

2. Verify Pod Status

# List all pods
kubectl get pods

# Get detailed pod information
kubectl get pods -o wide

# Check pod status with labels
kubectl get pods --show-labels

# Verify all pods are running
kubectl get pods -l app=nginx-deployment

3. Check Image Version

# Check image of all pods
kubectl get pods -o jsonpath='{.items[*].spec.containers[0].image}'

# Check image for specific pod
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[0].image}'

# Check image via describe
kubectl describe deployment nginx-deployment | grep -i image

4. Monitor the Update Process

# Watch pods during update
kubectl get pods -w

# Watch deployments during update
kubectl get deployments -w

# Watch ReplicaSets during update
kubectl get rs -w

5. Check Events

# Check events related to the deployment
kubectl get events --field-selector involvedObject.name=nginx-deployment

# Check all events sorted by time
kubectl get events --sort-by='.lastTimestamp'

6. View Logs

# View logs from updated pods
kubectl logs deployment/nginx-deployment

# View logs from specific pod
kubectl logs -l app=nginx-deployment

Understanding Rolling Updates

How Rolling Updates Work

┌─────────────────────────────────────────────────────────┐
│                     Deployment                          │
│                    Desired: 3 pods                      │
└────────────────────┬────────────────────────────────────┘
                     │
        ┌────────────┴────────────┐
        │                         │
        ▼                         ▼
┌───────────────────┐   ┌───────────────────┐
│   Old ReplicaSet  │   │   New ReplicaSet  │
│   (nginx:latest)  │   │   (nginx:1.19)    │
│   ┌───┐ ┌───┐     │   │   ┌───┐           │
│   │ 1 │ │ 2 │     │ → │   │ 3 │           │
│   └───┘ └───┘     │   │   └───┘           │
│   ┌───┐           │   │   ┌───┐           │
│   │ 3 │           │ → │   │ 2 │           │
│   └───┘           │   │   └───┘           │
│   ┌───┐           │   │   ┌───┐           │
│   │ 4 │           │ → │   │ 1 │           │
│   └───┘           │   │   └───┘           │
└───────────────────┘   └───────────────────┘

Update Strategy Options

1. RollingUpdate (Default)

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1        # Maximum extra pods during update
    maxUnavailable: 0  # Maximum unavailable pods during update

2. Recreate

strategy:
  type: Recreate

RollingUpdate Parameters

Parameter	Description	Default	Example
maxSurge	Max extra pods during update	25%	1 or 25%
maxUnavailable	Max unavailable pods during update	25%	0 or 25%

Advanced Operations

1. Pause a Rollout

# Pause the rollout
kubectl rollout pause deployment/nginx-deployment

# Check status (will show paused)
kubectl rollout status deployment/nginx-deployment

2. Resume a Rollout

# Resume the rollout
kubectl rollout resume deployment/nginx-deployment

3. Check Rollout History

# View all revisions
kubectl rollout history deployment/nginx-deployment

# View specific revision details
kubectl rollout history deployment/nginx-deployment --revision=1
kubectl rollout history deployment/nginx-deployment --revision=2

4. Rollback to Previous Version

# Rollback to previous version
kubectl rollout undo deployment/nginx-deployment

# Rollback to specific revision
kubectl rollout undo deployment/nginx-deployment --to-revision=1

# Check status after rollback
kubectl rollout status deployment/nginx-deployment

5. Change Update Strategy

# Change to Recreate strategy
kubectl patch deployment nginx-deployment -p '{"spec":{"strategy":{"type":"Recreate"}}}'

# Change RollingUpdate parameters
kubectl patch deployment nginx-deployment -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":2,"maxUnavailable":1}}}}'

6. Set Update Parameters

# Set maxSurge and maxUnavailable
kubectl patch deployment nginx-deployment -p '{"spec":{"strategy":{"rollingUpdate":{"maxSurge":"50%","maxUnavailable":"25%"}}}}'

Common Issues and Troubleshooting

Issue 1: Rollout Stuck

Symptoms:

Rollout status shows waiting indefinitely
Pods remain in "Pending" or "CrashLoopBackOff"

Solutions:

# Check rollout status
kubectl rollout status deployment/nginx-deployment

# Check pod status
kubectl get pods

# Check pod events
kubectl describe pod -l app=nginx-deployment

# Check deployment events
kubectl describe deployment nginx-deployment

# If stuck, try resuming
kubectl rollout resume deployment/nginx-deployment

# If still stuck, undo the rollout
kubectl rollout undo deployment/nginx-deployment

Issue 2: Image Pull Error

Error:

ImagePullBackOff or ErrImagePull

Solutions:

# Check if image exists
docker pull nginx:1.19

# Check pod details
kubectl describe pod <pod-name>

# If image doesn't exist, update to correct image
kubectl set image deployment/nginx-deployment nginx=nginx:1.19.10

# Or rollback to working version
kubectl rollout undo deployment/nginx-deployment

Issue 3: CrashLoopBackOff

Error:

Pod crashes continuously

Solutions:

# Check pod logs
kubectl logs <pod-name> --previous

# Check pod events
kubectl describe pod <pod-name>

# Try rolling back
kubectl rollout undo deployment/nginx-deployment

# Or investigate the image
kubectl run test --image=nginx:1.19 --rm -it -- /bin/bash

Issue 4: Insufficient Resources

Error:

0/1 nodes are available: 1 Insufficient cpu

Solutions:

# Check node resources
kubectl describe nodes

# Scale down temporarily
kubectl scale deployment nginx-deployment --replicas=2

# After update, scale back up
kubectl scale deployment nginx-deployment --replicas=3

# Or use maxUnavailable to reduce load
kubectl patch deployment nginx-deployment -p '{"spec":{"strategy":{"rollingUpdate":{"maxUnavailable":"50%"}}}}'

Issue 5: Pods Not Ready

Error:

Pods running but not ready (0/1)

Solutions:

# Check readiness probe
kubectl describe pod <pod-name> | grep -A 5 Readiness

# Check application logs
kubectl logs <pod-name>

# If probes are failing, consider:
# 1. Increasing initialDelaySeconds
# 2. Adjusting failureThreshold
# 3. Rolling back if application issues
kubectl rollout undo deployment/nginx-deployment

Monitoring During Rolling Update

1. Real-time Monitoring Script

#!/bin/bash
echo "=== Monitoring Rolling Update ==="
while true; do
    clear
    echo "=== Deployment Status ==="
    kubectl get deployment nginx-deployment
    echo ""
    echo "=== Pod Status ==="
    kubectl get pods -l app=nginx-deployment
    echo ""
    echo "=== ReplicaSets ==="
    kubectl get rs -l app=nginx-deployment
    sleep 2
done

2. Watch Commands

# Watch deployment status
watch -n 2 'kubectl get deployment nginx-deployment'

# Watch pod status
watch -n 2 'kubectl get pods -l app=nginx-deployment'

# Watch ReplicaSets
watch -n 2 'kubectl get rs -l app=nginx-deployment'

3. Metrics Monitoring

# Monitor pod metrics during update
kubectl top pods -l app=nginx-deployment

# Monitor node metrics
kubectl top nodes

Testing the Update

1. Test Nginx Version

# Get a shell in one of the pods
kubectl exec -it $(kubectl get pods -l app=nginx-deployment -o jsonpath='{.items[0].metadata.name}') -- /bin/bash

# Check nginx version
nginx -v
# Should show: nginx version: nginx/1.19.0

2. Test Application Functionality

# Port forward to test
kubectl port-forward deployment/nginx-deployment 8080:80

# Test the application
curl http://localhost:8080
# Should show the default nginx welcome page

# Check response headers
curl -I http://localhost:8080

3. Load Testing

# Run a simple load test
kubectl run load-test --image=busybox --rm -it -- /bin/sh -c "while true; do wget -q -O- http://nginx-deployment:80; sleep 1; done"

Complete Example with Deployment

Here's a complete deployment YAML with rolling update configuration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: default
  labels:
    app: nginx
    environment: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  minReadySeconds: 10
  revisionHistoryLimit: 5
  template:
    metadata:
      labels:
        app: nginx
        environment: production
    spec:
      containers:
      - name: nginx
        image: nginx:1.19
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
          name: http
          protocol: TCP
        resources:
          requests:
            cpu: "100m"
            memory: "64Mi"
          limits:
            cpu: "200m"
            memory: "128Mi"
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 3

Best Practices for Rolling Updates

✅ DO's

Use version tags, not latest

   # GOOD
   image: nginx:1.19

   # BAD
   image: nginx:latest

Test in staging first

   # Deploy to staging
   kubectl set image deployment/nginx-staging nginx=nginx:1.19
   kubectl rollout status deployment/nginx-staging

   # Test
   curl http://nginx-staging:80

   # Then deploy to production
   kubectl set image deployment/nginx-production nginx=nginx:1.19

Set appropriate update strategy

   strategy:
     type: RollingUpdate
     rollingUpdate:
       maxSurge: 1
       maxUnavailable: 0

Add health checks

   readinessProbe:
     httpGet:
       path: /health
       port: 80
     initialDelaySeconds: 10
     periodSeconds: 5

Use minReadySeconds

   minReadySeconds: 10

Monitor during rollout

   # Watch the update
   kubectl rollout status deployment/nginx-deployment
   kubectl get pods -w

Prepare rollback plan

   # Know how to rollback quickly
   kubectl rollout undo deployment/nginx-deployment

❌ DON'Ts

Don't update without testing
- Always test images before deployment
- Use staging environment
Don't use too aggressive parameters

   # BAD - Too aggressive
   maxSurge: 100%
   maxUnavailable: 100%

   # GOOD - Conservative
   maxSurge: 25%
   maxUnavailable: 25%

Don't ignore readiness probes
- Without probes, traffic may be sent to unready pods
- Implement proper readiness checks
Don't forget to monitor
- Monitor application metrics during and after update
- Set up alerts for errors
Don't delete old ReplicaSets
- Keep at least 2-3 revisions for rollback

   revisionHistoryLimit: 5

Clean Up

# Delete the deployment
kubectl delete deployment nginx-deployment

# Or delete using YAML
kubectl delete -f nginx-deployment.yaml

# Verify deletion
kubectl get deployments
kubectl get pods

Lab Completion Summary

✅ Task Requirements Checklist

[x] Deployment identified: nginx-deployment
[x] Image updated: nginx:1.19
[x] Rolling update performed: Using kubectl set image
[x] Update verified: All pods operational
[x] Image version confirmed: nginx:1.19

Final Verification Commands

echo "=== Deployment Status ==="
kubectl get deployment nginx-deployment
echo ""
echo "=== Pod Status ==="
kubectl get pods -l app=nginx-deployment
echo ""
echo "=== Image Version ==="
kubectl get pods -o jsonpath='{.items[*].spec.containers[0].image}' -l app=nginx-deployment
echo ""
echo "=== Rollout History ==="
kubectl rollout history deployment nginx-deployment
echo ""
echo "=== Current ReplicaSets ==="
kubectl get rs -l app=nginx-deployment

Expected output:

=== Deployment Status ===
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   3/3     3            3           10m

=== Pod Status ===
NAME                                READY   STATUS    RESTARTS   AGE
nginx-deployment-8d9f4b5c6-abc     1/1     Running   0          1m
nginx-deployment-8d9f4b5c6-def     1/1     Running   0          1m
nginx-deployment-8d9f4b5c6-ghi     1/1     Running   0          1m

=== Image Version ===
nginx:1.19 nginx:1.19 nginx:1.19

=== Rollout History ===
REVISION  STATUS
1         Superseded
2         Current

=== Current ReplicaSets ===
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-8d9f4b5c6   3         3         3       1m

Success! 🎉

You have successfully:

✅ Performed a rolling update from nginx:latest to nginx:1.19
✅ Verified the update completed successfully
✅ Ensured all pods are operational
✅ Checked rollout history and ReplicaSets
✅ Verified the new image is running

The Nautilus application development team's changes have been successfully deployed using a rolling update strategy! The application is now running the nginx:1.19 image with zero downtime.

Pull Docker Image

janak0ff — Thu, 06 Aug 2026 16:39:54 +0000

Nautilus project developers are planning to start testing on a new project. As per their meeting with the DevOps team, they want to test containerized environment application features. As per details shared with DevOps team, we need to accomplish the following task:

a. Pull busybox:musl image on App Server 2 in Stratos DC and re-tag (create new tag) this image as busybox:news.

Step-by-Step Instructions

1. SSH into Application Server 2

ssh steve@stapp02

Password: Am3ric@

2. Switch to root or use sudo

sudo su -

or prefix all commands with sudo

3. Pull the Docker image

Pull the busybox:musl image from Docker Hub:

sudo docker pull busybox:musl

4. Verify the image was pulled successfully

sudo docker images | grep busybox

Or specifically:

sudo docker images busybox:musl

5. Retag the image

Create a new tag busybox:news for the existing image:

sudo docker tag busybox:musl busybox:news

6. Verify the new tag was created

sudo docker images | grep busybox

You should see both busybox:musl and busybox:news with the same IMAGE ID.

7. Confirm both tags point to the same image (optional)

# Get image ID of original
sudo docker images busybox:musl -q

# Get image ID of new tag
sudo docker images busybox:news -q

# Both should show the same ID

Complete Execution Summary

# SSH to App Server 2
ssh steve@stapp02

# Switch to root
sudo su -

# Pull the image
docker pull busybox:musl

# Verify pull
docker images busybox:musl

# Retag the image
docker tag busybox:musl busybox:news

# Verify both tags
docker images | grep busybox

# Confirm same image ID
echo "Original ID: $(docker images busybox:musl -q)"
echo "New ID: $(docker images busybox:news -q)"

Verification Script

Run this to verify everything is correct:

echo "=== Pulling busybox:musl image ==="
docker pull busybox:musl

echo -e "\n=== Verifying image was pulled ==="
docker images busybox:musl

echo -e "\n=== Retagging as busybox:news ==="
docker tag busybox:musl busybox:news

echo -e "\n=== All busybox images ==="
docker images | grep busybox

echo -e "\n=== Comparing image IDs ==="
ORIGINAL_ID=$(docker images busybox:musl -q)
NEW_ID=$(docker images busybox:news -q)

if [ "$ORIGINAL_ID" = "$NEW_ID" ]; then
    echo "✅ Both tags point to the same image ID: $ORIGINAL_ID"
    echo "✅ Task completed successfully!"
else
    echo "❌ Image IDs do not match!"
fi

echo -e "\n=== Full image details ==="
docker images --format "table {{.Repository}}:{{.Tag}}\t{{.ID}}\t{{.Size}}" | grep busybox

Important Notes

Retagging does NOT create a new image; it just adds another tag to the same image
The image ID remains the same for both tags
Both tags refer to the same underlying layers
This is useful for versioning or creating aliases for images

Understanding BusyBox

BusyBox is a software suite that provides several stripped-down Unix tools in a single executable file. It's commonly used in minimal Docker images.

busybox:musl uses the musl libc (a lightweight C standard library)
busybox:glibc uses the glibc (GNU C library)
busybox:latest typically uses glibc

If You Want to Remove the Original Tag (Optional)

After retagging, you can keep both tags or remove the original:

# Remove the original tag (only if you want to)
docker rmi busybox:musl

# Note: This only removes the tag, not the image
# The image remains as long as it has at least one tag (busybox:news)

Quick One-Liner

sudo docker pull busybox:musl && sudo docker tag busybox:musl busybox:news && sudo docker images | grep busybox

Troubleshooting

If the image fails to pull:

# Check Docker daemon status
systemctl status docker

# Check network connectivity
ping -c 3 registry-1.docker.io

# Try pulling with verbose output
docker pull busybox:musl --debug

If you get a permission error:

# Use sudo
sudo docker pull busybox:musl
sudo docker tag busybox:musl busybox:news

If the tag already exists and you want to overwrite:

Docker automatically overwrites existing tags, so just run the command again.

To see all tags for an image:

docker images --filter=reference='busybox:*'

Set Resource Limits in Kubernetes Pods

janak0ff — Thu, 06 Aug 2026 16:27:30 +0000

The Nautilus DevOps team has noticed performance issues in some Kubernetes-hosted applications due to resource constraints. To address this, they plan to set limits on resource utilization. Here are the details:

Create a pod named httpd-pod with a container named httpd-container. Use the httpd image with the latest tag (specify as httpd:latest). Configure the following container-level resource requests and limits for the container:

Requests: Memory: 15Mi, CPU: 100m
Limits: Memory: 20Mi, CPU: 100m

Note: The kubectl utility on the jump-host has been configured to work with the Kubernetes cluster.

Mastering Kubernetes Resource Management: A Complete Guide to Setting Pod Limits

Introduction

Resource management is one of the most critical aspects of running applications in Kubernetes. Without proper resource limits, a single misbehaving application can consume all available cluster resources, causing performance degradation or complete failure of other applications. This is exactly the challenge the Nautilus DevOps team faced, and in this comprehensive guide, we'll explore how to solve it.

In this blog post, we'll walk through a real-world scenario of setting resource limits in Kubernetes pods, understanding the theory behind resource requests and limits, and learning best practices for production environments.

The Problem: Why Resource Limits Matter

Imagine this scenario: You're running multiple microservices in your Kubernetes cluster. One of them, let's say a logging agent, has a memory leak. Without resource limits, it will continue consuming memory until the node runs out of RAM, causing the entire node to fail and taking down all other applications running on it.

This is exactly the kind of problem the Nautilus DevOps team was facing. Their applications were experiencing performance issues due to resource constraints, and they needed a solution to prevent any single application from overwhelming the cluster.

Real-World Impact

Issue	Without Limits	With Limits
Memory Leak	Node crashes, all pods affected	Only the leaking pod is OOM-killed
CPU Spike	Other applications starve	Pod is throttled, others remain unaffected
Resource Exhaustion	Cluster becomes unresponsive	Resources are fairly distributed
Cost	Over-provisioning leads to waste	Efficient resource utilization

Understanding Resource Requests and Limits

Before diving into the implementation, let's understand the core concepts:

What are Resource Requests?

Requests are the minimum amount of resources a container needs to run. Kubernetes uses these for scheduling decisions.

resources:
  requests:
    memory: "15Mi"    # Minimum memory guaranteed
    cpu: "100m"       # Minimum CPU guaranteed (0.1 CPU core)

What are Resource Limits?

Limits are the maximum amount of resources a container can use. If a container exceeds these limits:

Memory: The container will be terminated (OOMKilled)
CPU: The container will be throttled (slowed down)

resources:
  limits:
    memory: "20Mi"    # Maximum memory allowed
    cpu: "100m"       # Maximum CPU allowed (0.1 CPU core)

Resource Units Explained

CPU Units:

1 = 1 CPU core
100m = 100 millicores (0.1 CPU core)
500m = 500 millicores (0.5 CPU core)
1000m = 1 CPU core

Memory Units:

Ki = Kibibyte (1024 bytes)
Mi = Mebibyte (1024 KiB)
Gi = Gibibyte (1024 Mi)
Ti = Tebibyte (1024 Gi)

Why Both Requests and Limits?

┌─────────────────────────────────────────┐
│          Node Resources                  │
│  ┌─────────────────────────────────────┐ │
│  │      Total Available                │ │
│  │  ┌───────┐  ┌───────┐  ┌───────┐  │ │
│  │  │ App 1 │  │ App 2 │  │ App 3 │  │ │
│  │  │ R:15Mi│  │ R:10Mi│  │ R:20Mi│  │ │
│  │  │ L:20Mi│  │ L:15Mi│  │ L:25Mi│  │ │
│  │  └───────┘  └───────┘  └───────┘  │ │
│  └─────────────────────────────────────┘ │
└─────────────────────────────────────────┘

Requests guarantee resources for scheduling
Limits prevent resource abuse
Together they ensure fair resource distribution

Step-by-Step Implementation

Prerequisites

Kubernetes cluster
kubectl configured on your jump-host
Basic understanding of Kubernetes concepts

Step 1: Generate the Pod YAML

First, let's generate a base YAML manifest:

kubectl run httpd-pod \
  --image=httpd:latest \
  --restart=Never \
  --dry-run=client -o yaml > httpd-pod.yaml

Step 2: Edit the YAML to Add Resource Limits

Open the file and add the resource specifications:

nano httpd-pod.yaml

Before:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: httpd-pod
  name: httpd-pod
spec:
  containers:
  - image: httpd:latest
    name: httpd-pod
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

After:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: httpd-pod
  name: httpd-pod
spec:
  containers:
  - image: httpd:latest
    name: httpd-container
    resources:
      requests:
        memory: "15Mi"
        cpu: "100m"
      limits:
        memory: "20Mi"
        cpu: "100m"
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}

Step 3: Apply the Configuration

Create the pod with resource limits:

kubectl apply -f httpd-pod.yaml

Expected output:

pod/httpd-pod created

Step 4: Quick Verification

Check if the pod is running:

kubectl get pods

Output:

NAME         READY   STATUS    RESTARTS   AGE
httpd-pod   1/1     Running   0          10s

Verification and Validation

1. Using `kubectl describe`

Get detailed information about the pod:

kubectl describe pod httpd-pod

Look for the resources section:

Containers:
  httpd-container:
    Container ID:   containerd://...
    Image:          httpd:latest
    State:          Running
    Limits:
      cpu:     100m
      memory:  20Mi
    Requests:
      cpu:     100m
      memory:  15Mi

2. Using JSONPath

Extract specific resource values:

# CPU Request
kubectl get pod httpd-pod -o jsonpath='{.spec.containers[0].resources.requests.cpu}'
# Output: 100m

# Memory Request
kubectl get pod httpd-pod -o jsonpath='{.spec.containers[0].resources.requests.memory}'
# Output: 15Mi

# CPU Limit
kubectl get pod httpd-pod -o jsonpath='{.spec.containers[0].resources.limits.cpu}'
# Output: 100m

# Memory Limit
kubectl get pod httpd-pod -o jsonpath='{.spec.containers[0].resources.limits.memory}'
# Output: 20Mi

3. Using YAML Output

View the full pod specification:

kubectl get pod httpd-pod -o yaml | grep -A 6 resources

Expected output:

resources:
  limits:
    cpu: 100m
    memory: 20Mi
  requests:
    cpu: 100m
    memory: 15Mi

4. Check Pod Events

Verify no resource-related errors:

kubectl get events --field-selector involvedObject.name=httpd-pod

5. Comprehensive Verification Script

Here's a complete verification script:

#!/bin/bash
echo "=== Pod Resource Verification ==="
echo "Pod Status: $(kubectl get pod httpd-pod -o jsonpath='{.status.phase}')"
echo "CPU Request: $(kubectl get pod httpd-pod -o jsonpath='{.spec.containers[0].resources.requests.cpu}')"
echo "Memory Request: $(kubectl get pod httpd-pod -o jsonpath='{.spec.containers[0].resources.requests.memory}')"
echo "CPU Limit: $(kubectl get pod httpd-pod -o jsonpath='{.spec.containers[0].resources.limits.cpu}')"
echo "Memory Limit: $(kubectl get pod httpd-pod -o jsonpath='{.spec.containers[0].resources.limits.memory}')"
echo "QoS Class: $(kubectl get pod httpd-pod -o jsonpath='{.status.qosClass}')"

Quality of Service (QoS) Classes Explained

Based on the resource requests and limits you set, Kubernetes assigns a QoS class to each pod. This determines the pod's priority when resources are scarce.

1. Guaranteed QoS (Highest Priority)

Conditions: Requests = Limits for ALL resources

resources:
  requests:
    cpu: "100m"
    memory: "15Mi"
  limits:
    cpu: "100m"
    memory: "15Mi"

Characteristics:

Highest priority in the cluster
Least likely to be evicted
Best for critical applications

2. Burstable QoS (Medium Priority)

Conditions: Requests < Limits for at least one resource

resources:
  requests:
    cpu: "50m"
    memory: "10Mi"
  limits:
    cpu: "100m"
    memory: "20Mi"

Characteristics:

Can use more resources when available
Moderate priority
Most common for production applications

3. BestEffort QoS (Lowest Priority)

Conditions: No requests or limits specified

resources: {}

Characteristics:

Lowest priority
Most likely to be evicted
Only use for non-critical workloads

QoS Class Comparison

QoS Class	CPU	Memory	Priority	Use Case
Guaranteed	Requests = Limits	Requests = Limits	Highest	Critical apps (control plane, databases)
Burstable	Requests < Limits	Requests = Limits	Medium	Most production workloads
Burstable	Requests = Limits	Requests < Limits	Medium	Most production workloads
Burstable	Requests < Limits	Requests < Limits	Medium	Most production workloads
BestEffort	No limits	No limits	Lowest	Batch jobs, testing

Advanced Resource Management

1. Namespace-Level Resource Quotas

Limit total resources in a namespace:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: development
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "10"

Apply the quota:

kubectl apply -f resource-quota.yaml

View quota usage:

kubectl describe quota -n development

2. Default Resource Limits with LimitRange

Set default resource limits for all pods in a namespace:

apiVersion: v1
kind: LimitRange
metadata:
  name: resource-limits
  namespace: development
spec:
  limits:
  - max:
      cpu: "500m"
      memory: "256Mi"
    min:
      cpu: "50m"
      memory: "64Mi"
    default:
      cpu: "200m"
      memory: "128Mi"
    defaultRequest:
      cpu: "100m"
      memory: "64Mi"
    type: Container

Apply the limit range:

kubectl apply -f limit-range.yaml

3. Pod with Multiple Containers

Different containers can have different resource limits:

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: web-server
    image: httpd:latest
    resources:
      requests:
        cpu: "100m"
        memory: "64Mi"
      limits:
        cpu: "200m"
        memory: "128Mi"
  - name: logger
    image: busybox
    command: ["sh", "-c", "tail -f /dev/null"]
    resources:
      requests:
        cpu: "50m"
        memory: "32Mi"
      limits:
        cpu: "100m"
        memory: "64Mi"

4. Horizontal Pod Autoscaler (HPA)

Automatically scale pods based on resource usage:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: httpd-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: httpd-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

Monitoring Resource Usage

1. Using `kubectl top`

Monitor real-time resource usage:

# View pod resource usage
kubectl top pod httpd-pod

# View all pods resource usage
kubectl top pods

# View node resource usage
kubectl top nodes

# View with specific namespace
kubectl top pods -n production

2. Setting Up Metrics Server

If kubectl top is not available:

# Install metrics server
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# Verify installation
kubectl get deployment metrics-server -n kube-system

3. Continuous Monitoring

# Monitor pod usage every 5 seconds
watch -n 5 'kubectl top pod httpd-pod'

# Monitor all pods in namespace
watch -n 5 'kubectl top pods -n production'

# Monitor node usage
watch -n 5 'kubectl top nodes'

4. Using Prometheus and Grafana

For enterprise monitoring, set up Prometheus:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: httpd-monitor
spec:
  selector:
    matchLabels:
      app: httpd
  endpoints:
  - port: metrics
    interval: 30s

Common Issues and Troubleshooting

Issue 1: Pod Stuck in Pending State

Error:

0/1 nodes are available: 1 Insufficient cpu

Solution:

# Check node resources
kubectl describe nodes

# Check pod events
kubectl describe pod httpd-pod | grep -A 10 Events

# Reduce resource requests
kubectl patch pod httpd-pod -p '{"spec":{"containers":[{"name":"httpd-container","resources":{"requests":{"cpu":"50m","memory":"10Mi"}}}]}}'

Issue 2: Container Terminated with OOMKilled

Error:

State: Terminated
Reason: OOMKilled

Solution:

# Check pod status
kubectl get pod httpd-pod

# View termination reason
kubectl describe pod httpd-pod | grep -A 5 "State"

# Increase memory limit
kubectl patch pod httpd-pod -p '{"spec":{"containers":[{"name":"httpd-container","resources":{"limits":{"memory":"256Mi"}}}]}}'

# Or check for memory leaks in the application
kubectl logs httpd-pod --previous

Issue 3: CPU Throttling

Symptoms:

Application performance degradation
Increased response times

Diagnosis:

# Check CPU usage
kubectl top pod httpd-pod

# Check CPU throttling from inside container
kubectl exec httpd-pod -- cat /sys/fs/cgroup/cpu/cpu.stat

Solution:

# Increase CPU limit
kubectl patch pod httpd-pod -p '{"spec":{"containers":[{"name":"httpd-container","resources":{"limits":{"cpu":"200m"}}}]}}'

Issue 4: Resource Quota Exceeded

Error:

error: failed to create: pods "httpd-pod" is forbidden: exceeded quota: compute-quota

Solution:

# Check current quota usage
kubectl describe resourcequota compute-quota -n development

# Either reduce resource requests or increase quota
kubectl patch resourcequota compute-quota -n development -p '{"spec":{"hard":{"requests.cpu":"8"}}}'

Issue 5: Pod Not Respecting Limits

Verification:

# Check if limits are properly applied
kubectl exec httpd-pod -- cat /sys/fs/cgroup/memory/memory.limit_in_bytes
kubectl exec httpd-pod -- cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us

Best Practices for Production

✅ DO's

1. Always Set Both Requests and Limits

# GOOD - Both set
resources:
  requests:
    cpu: "100m"
    memory: "64Mi"
  limits:
    cpu: "200m"
    memory: "128Mi"

# BAD - No resources set
resources: {}

2. Use Appropriate Resource Values

Application Type	CPU Request	CPU Limit	Memory Request	Memory Limit
Static Web	50m	100m	10Mi	20Mi
API Service	100m	200m	64Mi	128Mi
Database	500m	1000m	1Gi	2Gi
Data Processing	500m	2000m	2Gi	4Gi

3. Implement Liveness and Readiness Probes

livenessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 30
  periodSeconds: 10

readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 15
  periodSeconds: 5

4. Use Namespace Defaults

Create LimitRange and ResourceQuota at the namespace level:

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
spec:
  limits:
  - default:
      cpu: 200m
      memory: 128Mi
    defaultRequest:
      cpu: 100m
      memory: 64Mi
    type: Container

5. Monitor Resource Usage Regularly

# Regular monitoring
kubectl top pods

# Setup alerts for resource thresholds
# Use monitoring tools like Prometheus, Grafana, or Datadog

6. Test Resource Limits in Staging

Always test resource limits in a staging environment before production:

# Test memory limit
kubectl exec httpd-pod -- /bin/bash -c "dd if=/dev/zero of=/dev/null bs=1M count=100"

# Test CPU limit
kubectl exec httpd-pod -- /bin/bash -c "while true; do :; done"

7. Document Resource Requirements

Create a document specifying resource requirements for each microservice:

Microservice: httpd-web
CPU Request: 100m
CPU Limit: 200m
Memory Request: 64Mi
Memory Limit: 128Mi
Reason: Average load is 50m CPU and 32Mi memory

❌ DON'Ts

1. Don't Use `:latest` Tag in Production

# BAD - Unpredictable versions
image: httpd:latest

# GOOD - Specific version
image: httpd:2.4.54

2. Don't Overcommit Resources

# BAD - Limits exceed node capacity
resources:
  limits:
    cpu: "4"
    memory: "16Gi"

# GOOD - Appropriate limits
resources:
  limits:
    cpu: "1"
    memory: "2Gi"

3. Don't Set Requests Too High

# BAD - Wastes resources
requests:
  cpu: "2"
  memory: "4Gi"
# Actual usage: 50m CPU, 128Mi memory

# GOOD - Realistic requests
requests:
  cpu: "100m"
  memory: "256Mi"

4. Don't Ignore Memory Limits

Memory is a more critical resource than CPU:

CPU overuse → throttling
Memory overuse → OOM kill

# GOOD - Memory limits set
resources:
  limits:
    memory: "128Mi"

# BAD - Missing memory limits
resources:
  limits:
    cpu: "100m"

5. Don't Use Burstable for Critical Apps

For critical applications, use Guaranteed QoS:

# GOOD - Guaranteed QoS (for critical apps)
requests:
  cpu: "100m"
  memory: "128Mi"
limits:
  cpu: "100m"
  memory: "128Mi"

# BAD - Burstable (for critical apps)
requests:
  cpu: "50m"
  memory: "64Mi"
limits:
  cpu: "100m"
  memory: "128Mi"

Real-World Examples

Example 1: E-commerce Application

apiVersion: v1
kind: Pod
metadata:
  name: web-frontend
  namespace: production
  labels:
    app: ecommerce
    tier: frontend
spec:
  containers:
  - name: nginx
    image: nginx:1.21.6
    ports:
    - containerPort: 80
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
    livenessProbe:
      httpGet:
        path: /health
        port: 80
      initialDelaySeconds: 20
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5

Example 2: Data Processing Application

apiVersion: v1
kind: Pod
metadata:
  name: data-processor
  namespace: production
  labels:
    app: data-pipeline
    tier: backend
spec:
  containers:
  - name: processor
    image: data-processor:2.1.0
    resources:
      requests:
        cpu: "500m"
        memory: "2Gi"
      limits:
        cpu: "1000m"
        memory: "4Gi"
    env:
    - name: JVM_OPTS
      value: "-Xmx3g -Xms1g"
    volumeMounts:
    - name: data
      mountPath: /data
  restartPolicy: Always
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: data-pvc

Example 3: Microservices with Different Requirements

apiVersion: apps/v1
kind: Deployment
metadata:
  name: microservice-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: microservice
  template:
    metadata:
      labels:
        app: microservice
    spec:
      containers:
      # API Gateway (lightweight)
      - name: api-gateway
        image: api-gateway:1.0.0
        resources:
          requests:
            cpu: "50m"
            memory: "64Mi"
          limits:
            cpu: "100m"
            memory: "128Mi"

      # User Service (medium)
      - name: user-service
        image: user-service:1.0.0
        resources:
          requests:
            cpu: "100m"
            memory: "256Mi"
          limits:
            cpu: "200m"
            memory: "512Mi"

      # Search Service (heavy)
      - name: search-service
        image: search-service:1.0.0
        resources:
          requests:
            cpu: "500m"
            memory: "1Gi"
          limits:
            cpu: "1000m"
            memory: "2Gi"

Capacity Planning and Right-Sizing

Step 1: Monitor Current Usage

# Monitor for a week to understand patterns
kubectl top pod --all-namespaces --no-headers > resource-usage.log

Step 2: Analyze Usage Patterns

#!/usr/bin/env python3
import json
import subprocess

# Get pod resource usage
def get_pod_usage():
    cmd = "kubectl top pods --all-namespaces -o json"
    output = subprocess.check_output(cmd, shell=True)
    data = json.loads(output)

    for item in data['items']:
        name = item['metadata']['name']
        namespace = item['metadata']['namespace']
        cpu = item['containers'][0]['usage']['cpu']
        memory = item['containers'][0]['usage']['memory']
        print(f"{namespace}/{name}: CPU={cpu}, Memory={memory}")

Step 3: Set Appropriate Requests and Limits

Based on usage patterns:

Metric	Request	Limit
CPU	Average + 10%	Peak + 20%
Memory	Average + 20%	Peak + 30%

Step 4: Validate with Load Testing

# Test with increased load
kubectl run load-test --image=busybox --rm -it -- /bin/sh

# Inside the container:
wget -O /dev/null http://httpd-pod:80/index.html
# Or use tools like Apache Bench
ab -n 10000 -c 100 http://httpd-pod:80/

Advanced: Resource Quotas and Limit Ranges

Complete Namespace Configuration

---
# Namespace
apiVersion: v1
kind: Namespace
metadata:
  name: development
  labels:
    environment: dev
    owner: engineering
---
# Resource Quota
apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: development
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "20"
    persistentvolumeclaims: "5"
---
# Limit Range
apiVersion: v1
kind: LimitRange
metadata:
  name: dev-limits
  namespace: development
spec:
  limits:
  - max:
      cpu: "500m"
      memory: "256Mi"
    min:
      cpu: "50m"
      memory: "64Mi"
    default:
      cpu: "200m"
      memory: "128Mi"
    defaultRequest:
      cpu: "100m"
      memory: "64Mi"
    type: Container
---
# Network Policy
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: dev-network-policy
  namespace: development
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          environment: dev
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          environment: dev

Security Implications of Resource Limits

Preventing Resource Exhaustion Attacks

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
  - name: app
    image: app:1.0
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
        add:
        - NET_BIND_SERVICE
      runAsNonRoot: true
      runAsUser: 1000

Best Practices for Security

Set CPU limits to prevent CPU starvation attacks
Set memory limits to prevent memory exhaustion attacks
Use LimitRanges to enforce limits at the namespace level
Implement ResourceQuotas to limit total consumption
Use PodSecurityPolicies to restrict privileged containers
Monitor resource usage for unusual patterns
Set appropriate requests to prevent scheduling on nodes with insufficient resources

Troubleshooting Resource Issues

Common Error Messages

Error	Cause	Solution
`0/1 nodes are available: 1 Insufficient cpu`	Not enough CPU	Reduce CPU requests or add nodes
`0/1 nodes are available: 1 Insufficient memory`	Not enough memory	Reduce memory requests or add nodes
`The pod was OOMKilled`	Exceeded memory limit	Increase memory limit or optimize app
`Container is being throttled`	CPU limit too low	Increase CPU limit
`exceeded quota`	Resource quota exceeded	Reduce resource requests or increase quota
`pod stuck in Pending`	Various scheduling issues	Check node resources and events

Debugging Commands

# Check node capacity
kubectl describe nodes

# Check node resource usage
kubectl top nodes

# Check pod events
kubectl describe pod httpd-pod

# Check all events
kubectl get events --sort-by='.lastTimestamp'

# Check resource usage
kubectl top pod httpd-pod

# Check container logs
kubectl logs httpd-pod --previous

Clean Up

# Delete the pod
kubectl delete pod httpd-pod

# Delete using YAML
kubectl delete -f httpd-pod.yaml

# Delete namespace and all resources
kubectl delete namespace development

# Verify cleanup
kubectl get pods --all-namespaces

Conclusion

Resource management is a fundamental skill for any Kubernetes administrator or DevOps engineer. By properly setting resource requests and limits, you can:

✅ Prevent resource starvation - Ensure fair distribution of cluster resources
✅ Improve cluster stability - Prevent a single application from impacting others
✅ Optimize costs - Right-size your applications for efficient resource utilization
✅ Ensure predictable performance - Guarantee resources for critical applications
✅ Implement proper scheduling - Help Kubernetes make better placement decisions

Day 44: Write a Docker Compose File – KodeKloud Engineer Challenge

janak0ff — Thu, 06 Aug 2026 11:44:55 +0000

The Nautilus application development team shared static website content that needs to be hosted on the httpd web server using a containerised platform. The team has shared details with the DevOps team, and we need to set up an environment according to those guidelines. Below are the details:

a. On App Server 3 in Stratos DC create a container named httpd using a docker compose file /opt/docker/docker-compose.yml (please use the exact name for file).

b. Use httpd (preferably latest tag) image for container and make sure container is named as httpd; you can use any name for service.

c. Map 80 number port of container with port 8088 of docker host.

d. Map container's /usr/local/apache2/htdocs volume with /opt/dba volume of docker host which is already there. (please do not modify any data within these locations).

Introduction

Welcome back to my 100 Days of DevOps journey! Today marks Day 44, and we're diving into Docker Compose – a powerful tool for defining and running multi-container Docker applications.

📋 Challenge Overview

The Nautilus application development team shared static website content that needs to be hosted on an httpd web server using a containerized platform. The team has shared details with the DevOps team, and we need to set up an environment according to those guidelines.

Task Requirements:

On App Server 3 in Stratos DC
Create a container named httpd using a docker compose file /opt/docker/docker-compose.yml
Use httpd:latest image for the container
Map port 80 of container with port 8088 of docker host
Map container's /usr/local/apache2/htdocs with host's /opt/dba volume

🔧 Step-by-Step Solution

Step 1: SSH to App Server 3

ssh banner@stapp03
# Password: BigGr33n

Step 2: Switch to Root User

sudo su -
# Password: BigGr33n

Step 3: Create the Directory Structure

# Create the /opt/docker directory
mkdir -p /opt/docker

# Navigate to the directory
cd /opt/docker

Step 4: Install Docker Compose (if not already installed)

Docker Compose was not installed on the server, so I installed it:

# Download Docker Compose
curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

# Grant execution permissions
chmod +x /usr/local/bin/docker-compose

# Verify installation
docker-compose --version

Output:

Docker Compose version v5.4.0

Step 5: Create the Docker Compose File

vi docker-compose.yml

Content:

version: '3'

services:
  httpd-service:
    image: httpd:latest
    container_name: httpd
    ports:
      - "8088:80"
    volumes:
      - /opt/dba:/usr/local/apache2/htdocs

Step 6: Start the Container

docker-compose up -d

Output:

WARN[0000] /opt/docker/docker-compose.yml: the attribute `version` is obsolete
[+] up 9/9
 ✔ Image httpd:latest     Pulled
 ✔ Network docker_default Created
 ✔ Container httpd        Started

Step 7: Verify the Container

# Check container status
docker-compose ps

Output:

NAME      IMAGE          COMMAND              SERVICE         CREATED        STATUS                  PORTS
httpd     httpd:latest   "httpd-foreground"   httpd-service   1 second ago   Up Less than a second   0.0.0.0:8088->80/tcp

# Check with docker commands
docker ps | grep httpd

Output:

8f97bad02398   httpd:latest   "httpd-foreground"   1 second ago   Up Less than a second   0.0.0.0:8088->80/tcp   httpd

# Check port mapping
docker port httpd

Output:

80/tcp -> 0.0.0.0:8088
80/tcp -> [::]:8088

Step 8: Test the Web Server

curl http://localhost:8088

Output:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
 <head>
  <title>Index of /</title>
 </head>
 <body>
<h1>Index of /</h1>
<ul><li><a href="index1.html"> index1.html</a></li>
</ul>
</body></html>

📋 Complete Commands Summary

# SSH to App Server 3
ssh banner@stapp03
# Password: BigGr33n

# Switch to root
sudo su -
# Password: BigGr33n

# Create directory
mkdir -p /opt/docker
cd /opt/docker

# Create docker-compose.yml
cat > docker-compose.yml << 'EOF'
version: '3'

services:
  httpd-service:
    image: httpd:latest
    container_name: httpd
    ports:
      - "8088:80"
    volumes:
      - /opt/dba:/usr/local/apache2/htdocs
EOF

# Install Docker Compose (if not installed)
curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

# Start the container
docker-compose up -d

# Verify
docker-compose ps
docker ps | grep httpd
docker port httpd
curl http://localhost:8088

Day 43: Docker Ports Mapping

janak0ff — Wed, 05 Aug 2026 06:13:54 +0000

The Nautilus DevOps team is planning to host an application on a nginx-based container. There are number of tickets already been created for similar tasks. One of the tickets has been assigned to set up a nginx container on Application Server 3 in Stratos Datacenter. Please perform the task as per details mentioned below:

a. Pull nginx:alpine docker image on Application Server 3.

b. Create a container named cluster using the image you pulled.

c. Map host port 3001 to container port 80. Please keep the container in running state.

📋 Docker Ports Mapping

Challenge Requirements:

On App Server 3
Pull nginx:alpine image
Create container named cluster
Map host port 3001 to container port 80
Keep container running

🔧 Step-by-Step Solution

Step 1: SSH to App Server 3

ssh banner@stapp03
# Password: BigGr33n

Step 2: Switch to Root (if needed)

sudo -i
# Password: BigGr33n

Step 3: Check Docker Status

# Check Docker version
docker --version

# Check Docker service status
sudo systemctl status docker

Step 4: Pull the Nginx Alpine Image

# Pull the nginx:alpine image
docker pull nginx:alpine

# Verify the image is pulled
docker images | grep nginx

Step 5: Create and Run the Container with Port Mapping

# Create and run container with port mapping
docker run -d --name cluster -p 3001:80 nginx:alpine

# The syntax is: docker run -d --name <container-name> -p <host-port>:<container-port> <image>

Step 6: Verify the Container

# Check container is running
docker ps

# Check specific container
docker ps | grep cluster

# Verify port mapping
docker port cluster

# Test the container
curl http://localhost:3001

🔍 Additional Verification

# Check container details
docker inspect cluster

# Check container logs
docker logs cluster

# Check container IP
docker inspect cluster | grep IPAddress

# Check port mapping details
docker inspect cluster | grep -A 5 "PortBindings"

# Test from external (if accessible)
curl http://stapp03:3001

🛠️ Troubleshooting

If Port 3001 is Already in Use:

# Check what's using port 3001
sudo ss -tulpn | grep 3001
sudo lsof -i :3001

# Stop the container using the port
docker stop <container-name>
docker rm <container-name>

# Or use a different port
docker run -d --name cluster -p 3002:80 nginx:alpine

If Container Fails to Start:

# Check container logs
docker logs cluster

# Remove and recreate
docker rm -f cluster
docker run -d --name cluster -p 3001:80 nginx:alpine

If Image Pull Fails:

# Check internet connectivity
ping -c 4 google.com

# Try pulling with different registry
docker pull docker.io/nginx:alpine

🔑 Key Points

Parameter	Value	Description
Image	`nginx:alpine`	Lightweight nginx image
Container Name	`cluster`	Name of the container
Host Port	`3001`	Port on the host machine
Container Port	`80`	Port inside the container
Mapping Format	`-p 3001:80`	host-port:container-port

✅ Task Summary

Requirement	Status	Command Used
SSH to App Server 3	✅	`ssh banner@stapp03`
Switch to root	✅	`sudo -i`
Pull nginx:alpine image	✅	`docker pull nginx:alpine`
Create container named `cluster`	✅	`docker run -d --name cluster`
Map host port 3001 to container port 80	✅	`-p 3001:80`
Container in running state	✅	`docker ps` shows `Up` status
Test successful	✅	`curl http://localhost:3001`

KodeKloud Kubernetes level 1 - Setup Kubernetes Namespaces and PODs

janak0ff — Wed, 05 Aug 2026 05:59:05 +0000

The Nautilus DevOps team is planning to deploy some micro services on Kubernetes platform. The team has already set up a Kubernetes cluster and now they want to set up some namespaces, deployments etc. Based on the current requirements, the team has shared some details as below:

Create a namespace named dev and deploy a POD within it. Name the pod dev-nginx-pod and use the nginx image with the latest tag. Ensure to specify the tag as nginx:latest.

Note: The kubectl utility on the jump-host has been configured to work with the Kubernetes cluster.

Setup Kubernetes Namespaces and PODs: Complete Guide

Solution

Step 1: Create the Namespace

First, let's create the dev namespace:

kubectl create namespace dev

Expected output:

namespace/dev created

Step 2: Verify the Namespace

Check that the namespace was created:

kubectl get namespaces

Output:

NAME              STATUS   AGE
default           Active   10d
dev               Active   5s
kube-node-lease   Active   10d
kube-public       Active   10d
kube-system       Active   10d

Step 3: Create the Pod in the dev Namespace

Now create the pod named dev-nginx-pod using the nginx:latest image in the dev namespace:

kubectl run dev-nginx-pod \
  --image=nginx:latest \
  --namespace=dev \
  --restart=Never \
  --port=80

Expected output:

pod/dev-nginx-pod created

Step 4: Verify the Pod

Check if the pod is running in the dev namespace:

kubectl get pods -n dev

Output:

NAME             READY   STATUS    RESTARTS   AGE
dev-nginx-pod   1/1     Running   0          10s

Step 5: Get Detailed Information

Check pod details:

kubectl describe pod dev-nginx-pod -n dev

Step 6: Verify Everything

Let's verify all requirements are met:

# Check pod in dev namespace
kubectl get pods -n dev --show-labels

# Check pod image
kubectl get pod dev-nginx-pod -n dev -o jsonpath='{.spec.containers[0].image}'

# Check pod name
kubectl get pod dev-nginx-pod -n dev -o jsonpath='{.metadata.name}'

Alternative Methods

Method 1: Using YAML Manifest (Recommended for Production)

Create a file named dev-namespace-pod.yaml:

# Create namespace
apiVersion: v1
kind: Namespace
metadata:
  name: dev
---
# Create pod in dev namespace
apiVersion: v1
kind: Pod
metadata:
  name: dev-nginx-pod
  namespace: dev
  labels:
    app: nginx
    environment: dev
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80
  restartPolicy: Never

Apply the configuration:

kubectl apply -f dev-namespace-pod.yaml

Method 2: One-Liner with Namespace

Create namespace and pod in one line:

kubectl create namespace dev && kubectl run dev-nginx-pod --image=nginx:latest --namespace=dev --restart=Never

Method 3: Using YAML Generation

Generate YAML for the pod in the namespace:

kubectl run dev-nginx-pod \
  --image=nginx:latest \
  --namespace=dev \
  --restart=Never \
  --dry-run=client -o yaml > dev-nginx-pod.yaml

kubectl apply -f dev-nginx-pod.yaml

Verification Commands

Complete Verification Checklist

# 1. Check namespace exists
kubectl get namespace dev

# 2. List pods in dev namespace
kubectl get pods -n dev

# 3. Check pod status
kubectl get pod dev-nginx-pod -n dev -o wide

# 4. Check pod image
kubectl get pod dev-nginx-pod -n dev -o jsonpath='{.spec.containers[0].image}'

# 5. Check pod events
kubectl describe pod dev-nginx-pod -n dev | grep -A 5 Events

# 6. Check pod logs (if needed)
kubectl logs dev-nginx-pod -n dev

# 7. Check all resources in dev namespace
kubectl get all -n dev

Quick Status Check

# One command to see everything
kubectl get namespace dev && kubectl get pods -n dev

Pod Operations in the Namespace

Access the Nginx Web Server

# Port forward to access nginx
kubectl port-forward dev-nginx-pod 8080:80 -n dev

# Then access http://localhost:8080 in browser
# Or use curl in another terminal
curl http://localhost:8080

Execute Commands in the Pod

# Get a shell in the pod
kubectl exec -it dev-nginx-pod -n dev -- /bin/bash

# Check nginx version
kubectl exec dev-nginx-pod -n dev -- nginx -v

# List files in nginx web directory
kubectl exec dev-nginx-pod -n dev -- ls -la /usr/share/nginx/html

View Pod Logs

# View logs
kubectl logs dev-nginx-pod -n dev

# Follow logs in real-time
kubectl logs -f dev-nginx-pod -n dev

# View previous logs (if pod restarted)
kubectl logs dev-nginx-pod -n dev --previous

Clean Up

Delete the Pod

# Delete the pod
kubectl delete pod dev-nginx-pod -n dev

Delete the Namespace (and all resources in it)

# Delete the namespace (will delete all resources in it)
kubectl delete namespace dev

Delete Using YAML

kubectl delete -f dev-namespace-pod.yaml

Advanced Namespace Management

1. Create Multiple Namespaces

kubectl create namespace dev
kubectl create namespace staging
kubectl create namespace production

2. Set Default Namespace

# Set default namespace for current context
kubectl config set-context --current --namespace=dev

# Now all commands without -n will use dev namespace
kubectl get pods

3. Switch Between Namespaces

# View current context
kubectl config view --minify | grep namespace

# Switch to a different namespace
kubectl config set-context --current --namespace=staging

4. List All Pods in All Namespaces

kubectl get pods --all-namespaces
# or
kubectl get pods -A

5. Resource Quotas in Namespace

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "10"

6. Limit Ranges in Namespace

apiVersion: v1
kind: LimitRange
metadata:
  name: dev-limits
  namespace: dev
spec:
  limits:
  - max:
      cpu: "2"
      memory: 4Gi
    min:
      cpu: "100m"
      memory: 128Mi
    default:
      cpu: "500m"
      memory: 256Mi
    defaultRequest:
      cpu: "250m"
      memory: 128Mi
    type: Container

Namespace Best Practices

✅ DO's

Use namespaces for environment separation
- dev, staging, production
- Isolates resources and configurations
Use namespaces for team separation
- team-engineering, team-data
- Prevents resource conflicts
Apply resource quotas
- Prevents one namespace from consuming all resources
- Ensures fair resource distribution
Use RBAC with namespaces
- Limit access to specific namespaces
- Implement least privilege principle
Use labels for categorization
- environment: dev
- owner: team-engineering

❌ DON'Ts

Don't use default namespace for production
- Harder to manage and secure
- Can cause resource conflicts
Don't create too many namespaces
- Maintenance overhead
- Can become confusing
Don't ignore resource limits
- Can cause cluster instability
- Impacts other namespaces
Don't use namespaces for very small environments
- Overhead not worth it
- Use labels instead

Troubleshooting Namespace Issues

Issue 1: Pod Not Found

# Error: pod not found
# Solution: Check namespace
kubectl get pods -n dev

Issue 2: Namespace Not Found

# Error: namespace "dev" not found
# Solution: Create namespace
kubectl create namespace dev

Issue 3: Permission Denied

# Error: unauthorized to access namespace
# Solution: Check RBAC permissions
kubectl auth can-i get pods --namespace=dev

Issue 4: Resource Quota Exceeded

# Error: exceeded quota
# Solution: Check quota usage
kubectl describe quota -n dev

Issue 5: Pod Stuck in Pending

# Pod stays in Pending state
# Check events
kubectl describe pod dev-nginx-pod -n dev

Complete Example: Multi-Environment Setup

Here's a complete example with multiple namespaces:

# dev-namespace.yaml
---
apiVersion: v1
kind: Namespace
metadata:
  name: dev
  labels:
    environment: development
    type: non-production
---
apiVersion: v1
kind: Namespace
metadata:
  name: staging
  labels:
    environment: staging
    type: pre-production
---
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    environment: production
    type: production
---
# Deploy dev pod
apiVersion: v1
kind: Pod
metadata:
  name: dev-nginx-pod
  namespace: dev
  labels:
    app: nginx
    environment: dev
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80
---
# Deploy staging pod (different image version)
apiVersion: v1
kind: Pod
metadata:
  name: staging-nginx-pod
  namespace: staging
  labels:
    app: nginx
    environment: staging
spec:
  containers:
  - name: nginx
    image: nginx:1.21.6
    ports:
    - containerPort: 80

Apply everything:

kubectl apply -f dev-namespace.yaml

Quick Reference Commands

Namespace Commands

# Create namespace
kubectl create namespace <name>

# List namespaces
kubectl get namespaces

# Delete namespace
kubectl delete namespace <name>

# Get namespace details
kubectl describe namespace <name>

Pod Commands with Namespace

# Create pod in namespace
kubectl run <pod-name> --image=<image> --namespace=<ns>

# List pods in namespace
kubectl get pods -n <ns>

# Get pod details
kubectl describe pod <pod-name> -n <ns>

# Delete pod from namespace
kubectl delete pod <pod-name> -n <ns>

# Get logs
kubectl logs <pod-name> -n <ns>

# Exec into pod
kubectl exec -it <pod-name> -n <ns> -- /bin/bash

Lab Completion Summary

✅ Task Requirements Checklist

[x] Namespace created: dev namespace exists
[x] Pod created: dev-nginx-pod in dev namespace
[x] Image specified: Using nginx:latest
[x] Pod running: Status is Running with 1/1 READY
[x] Proper tagging: Image tag is nginx:latest

Final Verification Command

# Show everything in one go
echo "=== Namespaces ===" && \
kubectl get namespace dev && \
echo -e "\n=== Pods in dev namespace ===" && \
kubectl get pods -n dev && \
echo -e "\n=== Pod Details ===" && \
kubectl get pod dev-nginx-pod -n dev -o wide && \
echo -e "\n=== Container Image ===" && \
kubectl get pod dev-nginx-pod -n dev -o jsonpath='{.spec.containers[0].image}' && echo

Expected output:

=== Namespaces ===
NAME   STATUS   AGE
dev    Active   1m

=== Pods in dev namespace ===
NAME             READY   STATUS    RESTARTS   AGE
dev-nginx-pod   1/1     Running   0          45s

=== Pod Details ===
NAME             READY   STATUS    RESTARTS   AGE   IP           NODE
dev-nginx-pod   1/1     Running   0          45s   10.22.0.10   jump-host

=== Container Image ===
nginx:latest

Success! 🎉

You have successfully:

✅ Created the dev namespace
✅ Deployed the dev-nginx-pod pod with nginx:latest image
✅ Verified the pod is running in the correct namespace
✅ Demonstrated various operations within the namespace

The Nautilus DevOps team's requirement has been fully satisfied!

KodeKloud Level 1 - Kubernetes - Deploy Applications with Kubernetes Deployments

janak0ff — Wed, 05 Aug 2026 05:37:10 +0000

The Nautilus DevOps team is delving into Kubernetes for app management. One team member needs to create a deployment following these details:

Create a deployment named nginx to deploy the application nginx using the image nginx:latest (ensure to specify the tag)

Note: The kubectl utility on the jump-host has been configured to work with the Kubernetes cluster.

Deploy Applications with Kubernetes Deployments: A Complete Guide

Introduction

Kubernetes has become the de facto standard for container orchestration, and Deployments are one of its most powerful and essential resources. In this comprehensive guide, we'll explore how to deploy applications using Kubernetes Deployments, covering everything from basic concepts to advanced strategies used in production environments.

Whether you're preparing for the CKA certification, managing applications in production, or just starting your Kubernetes journey, this guide will provide you with the knowledge and hands-on experience needed to master Kubernetes Deployments.

What are Kubernetes Deployments?

A Deployment is a Kubernetes resource that provides declarative updates for Pods and ReplicaSets. Think of it as a higher-level concept that manages the lifecycle of your application instances, ensuring that the desired state of your application matches the actual state in the cluster.

Key Features of Deployments:

✅ Declarative Updates: Define the desired state, and Kubernetes handles the rest
✅ Rolling Updates: Zero-downtime updates with controlled rollout strategies
✅ Rollbacks: Easy revert to previous versions if something goes wrong
✅ Scaling: Simple horizontal scaling with a single command
✅ Self-Healing: Automatically replaces failed or unhealthy pods
✅ History & Auditing: Track deployment revisions and changes

Understanding the Architecture

Deployment Components

┌─────────────────────────────────────────┐
│         Deployment (nginx)              │
│  - Desired Replicas: 3                  │
│  - Update Strategy: RollingUpdate       │
│  - Selector: app=nginx                  │
└──────────────┬──────────────────────────┘
               │
               ▼
┌─────────────────────────────────────────┐
│       ReplicaSet (nginx-7c5d8bf9f7)    │
│  - Current Replicas: 3                  │
│  - Ready Replicas: 3                    │
│  - Owner: Deployment                    │
└──────────────┬──────────────────────────┘
               │
     ┌─────────┼─────────┐
     │         │         │
     ▼         ▼         ▼
┌────────┐┌────────┐┌────────┐
│  Pod 1 ││  Pod 2 ││  Pod 3 │
│        ││        ││        │
│ nginx  ││ nginx  ││ nginx  │
└────────┘└────────┘└────────┘

Relationship Between Resources

Deployment → Manages ReplicaSets
ReplicaSet → Manages Pods
Pods → Run the actual container(s)

Creating Your First Deployment

Method 1: Imperative Command

The quickest way to create a deployment:

kubectl create deployment nginx --image=nginx:latest

Method 2: Declarative YAML (Recommended)

Generate the YAML first:

kubectl create deployment nginx \
  --image=nginx:latest \
  --dry-run=client -o yaml > nginx-deployment.yaml

Then apply it:

kubectl apply -f nginx-deployment.yaml

Method 3: Complete YAML Manifest

Here's a complete deployment manifest with all configurations:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: production
  labels:
    app: nginx
    environment: production
    version: "1.0"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
      environment: production
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  revisionHistoryLimit: 10
  paused: false
  progressDeadlineSeconds: 600
  template:
    metadata:
      labels:
        app: nginx
        environment: production
        version: "1.0"
    spec:
      containers:
      - name: nginx
        image: nginx:1.21.6
        ports:
        - containerPort: 80
          name: http
          protocol: TCP
        env:
        - name: ENVIRONMENT
          value: "production"
        - name: NGINX_VERSION
          value: "1.21.6"
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 10
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 3
        startupProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5
          failureThreshold: 30
      imagePullSecrets:
      - name: registry-credentials
      restartPolicy: Always
      terminationGracePeriodSeconds: 30

Understanding Each Section

1. API Version and Kind

apiVersion: apps/v1
kind: Deployment

apps/v1 is the stable API version for Deployments
Kind defines the resource type

2. Metadata

metadata:
  name: nginx
  namespace: production
  labels:
    app: nginx

name: Unique identifier for the deployment
namespace: Logical grouping (defaults to "default")
labels: Key-value pairs for organization and selection

3. Spec Section

spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx

replicas: Number of desired pod instances
selector: How the deployment finds its pods

4. Pod Template

template:
  metadata:
    labels:
      app: nginx
  spec:
    containers:
    - name: nginx
      image: nginx:1.21.6

Defines the blueprint for pods
Contains container specifications

5. Update Strategy

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 0

Recreate: Delete all pods, then recreate
RollingUpdate: Gradually replace pods

Common Operations

1. Viewing Deployments

# List all deployments
kubectl get deployments

# Get detailed info
kubectl describe deployment nginx

# Get deployment status
kubectl rollout status deployment nginx

# Show deployment YAML
kubectl get deployment nginx -o yaml

# Get deployment in JSON
kubectl get deployment nginx -o json

# Show deployment with additional information
kubectl get deployment nginx -o wide

2. Scaling

# Scale to 5 replicas
kubectl scale deployment nginx --replicas=5

# Scale using YAML
kubectl patch deployment nginx -p '{"spec":{"replicas":5}}'

# Scale based on load (using HPA - Horizontal Pod Autoscaler)
kubectl autoscale deployment nginx --min=3 --max=10 --cpu-percent=80

3. Updating Applications

# Update image
kubectl set image deployment/nginx nginx=nginx:1.22.0

# Update multiple images
kubectl set image deployment/nginx nginx=nginx:1.22.0 sidecar=sidecar:2.0

# Update environment variables
kubectl set env deployment/nginx ENVIRONMENT=staging

# Update resources
kubectl set resources deployment/nginx -c=nginx --limits=cpu=500m,memory=256Mi

# Update all containers at once
kubectl patch deployment nginx -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:1.22.0"}]}}}}'

4. Rollbacks

# View rollout history
kubectl rollout history deployment nginx

# View specific revision
kubectl rollout history deployment nginx --revision=2

# Rollback to previous version
kubectl rollout undo deployment nginx

# Rollback to specific revision
kubectl rollout undo deployment nginx --to-revision=2

# Pause and resume rollout
kubectl rollout pause deployment nginx
kubectl rollout resume deployment nginx

5. Deleting

# Delete deployment
kubectl delete deployment nginx

# Delete using YAML
kubectl delete -f nginx-deployment.yaml

# Delete with force
kubectl delete deployment nginx --force --grace-period=0

Advanced Deployment Strategies

1. Rolling Update Strategy

The default strategy that provides zero-downtime updates:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 25%          # Maximum extra pods allowed during update
    maxUnavailable: 25%    # Maximum unavailable pods during update

How it works:

Gradually replaces old pods with new ones
Ensures application availability during updates
Configurable speed with maxSurge and maxUnavailable

2. Recreate Strategy

Simple strategy that replaces all pods at once:

strategy:
  type: Recreate

When to use:

Applications that don't support multiple versions simultaneously
When downtime is acceptable
Stateful applications with database migrations

3. Blue-Green Deployment

Not native to Kubernetes but can be implemented with Deployments:

# Blue (current) deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-blue
  labels:
    app: nginx
    version: blue
# ... rest of config

---
# Green (new) deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-green
  labels:
    app: nginx
    version: green
# ... rest of config

4. Canary Deployment

Gradually roll out to a subset of users:

# Main deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  replicas: 9
  # ... rest of config

---
# Canary deployment (10% of traffic)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-canary
  labels:
    app: nginx
    version: canary
spec:
  replicas: 1
  # ... rest of config

Health Checks and Probes

Types of Probes

Liveness Probe: Checks if the container is still running
Readiness Probe: Checks if the container is ready to serve traffic
Startup Probe: Checks if the application has started (for slow-starting apps)

Probe Configuration Examples

# HTTP Get Probe
livenessProbe:
  httpGet:
    path: /health
    port: 8080
    httpHeaders:
    - name: Custom-Header
      value: Awesome
  initialDelaySeconds: 15
  periodSeconds: 20
  timeoutSeconds: 5
  successThreshold: 1
  failureThreshold: 3

# TCP Socket Probe
readinessProbe:
  tcpSocket:
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10

# Command Probe
startupProbe:
  exec:
    command:
    - cat
    - /tmp/healthy
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 30

Resource Management

CPU and Memory Limits

resources:
  requests:
    memory: "128Mi"
    cpu: "250m"
  limits:
    memory: "256Mi"
    cpu: "500m"

Understanding:

requests: Minimum guaranteed resources
limits: Maximum resources allowed
cpu: Measured in millicores (1000m = 1 CPU core)
memory: Measured in Mi (Mebibytes) or Gi

Quality of Service (QoS) Classes

Guaranteed: When requests = limits for all resources
Burstable: When requests < limits
BestEffort: No requests or limits set

Monitoring and Debugging

1. Viewing Logs

# Logs from a specific pod
kubectl logs nginx-7c5d8bf9f7-nb2sz

# Logs from all pods in deployment
kubectl logs deployment/nginx

# Follow logs
kubectl logs -f deployment/nginx

# Previous container logs (if crashed)
kubectl logs nginx-7c5d8bf9f7-nb2sz --previous

2. Executing Commands

# Execute command in pod
kubectl exec -it nginx-7c5d8bf9f7-nb2sz -- /bin/bash

# Run a single command
kubectl exec nginx-7c5d8bf9f7-nb2sz -- ls -la /usr/share/nginx/html

# Copy files to/from pod
kubectl cp nginx-7c5d8bf9f7-nb2sz:/var/log/nginx/access.log access.log

3. Checking Events

# All events
kubectl get events

# Events for specific deployment
kubectl get events --field-selector involvedObject.name=nginx

# Sort events by time
kubectl get events --sort-by='.lastTimestamp'

4. Troubleshooting Pods

# Detailed pod description
kubectl describe pod nginx-7c5d8bf9f7-nb2sz

# Check pod status
kubectl get pod nginx-7c5d8bf9f7-nb2sz -o yaml

# Check pod logs
kubectl logs nginx-7c5d8bf9f7-nb2sz

# Check pod events
kubectl get events --field-selector involvedObject.name=nginx-7c5d8bf9f7-nb2sz

Best Practices

✅ DO's

Use Declarative Manifests
- Version control your YAML files
- Enable audit trail and rollback capability
Pin Image Versions
- Avoid :latest in production
- Use semantic versioning or commit hashes
Set Resource Limits
- Prevent resource exhaustion
- Ensure QoS class assignment
Add Health Checks
- Implement liveness and readiness probes
- Use startup probes for slow-starting apps
Use Multiple Replicas
- Ensure high availability
- Enable rolling updates
Implement Monitoring
- Set up logging and metrics
- Use monitoring tools like Prometheus
Use Namespaces
- Organize deployments logically
- Implement RBAC and resource quotas
Implement Security
- Use ServiceAccounts with minimal permissions
- Set security contexts
- Use image pull secrets for private registries

❌ DON'Ts

Don't use :latest in production - Unpredictable updates
Don't ignore resource limits - Can crash the cluster
Don't skip health checks - Missing self-healing
Don't use single replicas - Single point of failure
Don't delete pods directly - Let the deployment manage them
Don't make direct updates to pods - Use the deployment
Don't store secrets in manifests - Use Kubernetes secrets
Don't run as root - Use security contexts

Production-Ready Example

Here's a complete production-ready deployment:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: production
  labels:
    app: web-app
    environment: production
    tier: frontend
    version: v1.2.3
  annotations:
    kubernetes.io/change-cause: "Updated to v1.2.3 with security patches"
    prometheus.io/scrape: "true"
    prometheus.io/port: "8080"
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: web-app
  revisionHistoryLimit: 10
  progressDeadlineSeconds: 600
  template:
    metadata:
      labels:
        app: web-app
        environment: production
        tier: frontend
        version: v1.2.3
    spec:
      containers:
      - name: web-app
        image: registry.example.com/web-app:v1.2.3
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
          name: http
          protocol: TCP
        env:
        - name: ENVIRONMENT
          value: "production"
        - name: LOG_LEVEL
          value: "info"
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: db-secrets
              key: url
        - name: REDIS_HOST
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: redis_host
        resources:
          requests:
            memory: "128Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "1000m"
        livenessProbe:
          httpGet:
            path: /health/live
            port: 8080
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
          failureThreshold: 3
        readinessProbe:
          httpGet:
            path: /health/ready
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 3
        startupProbe:
          httpGet:
            path: /health/startup
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 5
          failureThreshold: 30
        volumeMounts:
        - name: app-data
          mountPath: /data
        - name: app-config
          mountPath: /etc/config
        securityContext:
          runAsUser: 1000
          runAsGroup: 1000
          capabilities:
            drop:
            - ALL
            add:
            - NET_BIND_SERVICE
      volumes:
      - name: app-data
        persistentVolumeClaim:
          claimName: app-data-pvc
      - name: app-config
        configMap:
          name: app-config
      imagePullSecrets:
      - name: registry-credentials
      restartPolicy: Always
      terminationGracePeriodSeconds: 60
      securityContext:
        fsGroup: 1000
        runAsNonRoot: true
      serviceAccountName: web-app-sa
      nodeSelector:
        node-type: application
      tolerations:
      - key: "critical"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-app
              topologyKey: kubernetes.io/hostname

Common Error Scenarios and Solutions

1. ImagePullBackOff

Error: Pod stuck in ImagePullBackOff
Solution:

# Check image name and tag
kubectl describe pod -l app=nginx | grep Image

# Fix by updating image
kubectl set image deployment/nginx nginx=nginx:1.21.6

2. CrashLoopBackOff

Error: Pod constantly crashing
Solution:

# Check logs
kubectl logs deployment/nginx --previous

# Check events
kubectl describe pod -l app=nginx | grep -A 10 Events

3. Deployment Stuck

Error: Deployment progress is stuck
Solution:

# Check rollout status
kubectl rollout status deployment nginx

# Check events
kubectl get events --field-selector involvedObject.name=nginx

# Restart deployment
kubectl rollout restart deployment nginx

4. Insufficient Resources

Error: Pods pending due to resource constraints
Solution:

# Check node resources
kubectl describe nodes

# Reduce resource requests
kubectl patch deployment nginx -p '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","resources":{"requests":{"cpu":"100m","memory":"64Mi"}}}]}}}}'

Integration with Other Kubernetes Resources

1. Service

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
  - port: 80
    targetPort: 80
  type: ClusterIP

2. ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-config
data:
  nginx.conf: |
    server {
      listen 80;
      server_name example.com;
      location / {
        root /usr/share/nginx/html;
        index index.html;
      }
    }

3. Secret

apiVersion: v1
kind: Secret
metadata:
  name: nginx-secrets
type: Opaque
data:
  username: dXNlcm5hbWU=  # base64 encoded
  password: cGFzc3dvcmQ=  # base64 encoded

4. Ingress

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

CI/CD Integration

Example GitLab CI Pipeline

stages:
  - build
  - deploy

variables:
  IMAGE_TAG: $CI_COMMIT_SHORT_SHA
  K8S_NAMESPACE: production

build:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG .
    - docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG

deploy:
  stage: deploy
  script:
    - kubectl set image deployment/web-app web-app=$CI_REGISTRY_IMAGE:$IMAGE_TAG
    - kubectl rollout status deployment/web-app
  only:
    - main

Monitoring with Prometheus/Grafana

ServiceMonitor for Prometheus

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: nginx-monitor
  namespace: production
spec:
  selector:
    matchLabels:
      app: nginx
  endpoints:
  - port: metrics
    path: /metrics
    interval: 30s

Conclusion

Kubernetes Deployments are the backbone of modern application deployment strategies. They provide the control, flexibility, and reliability needed for production-grade applications. In this guide, we've covered:

✅ Understanding Deployment architecture and components
✅ Creating and managing Deployments
✅ Implementing different update strategies
✅ Configuring health checks and resource management
✅ Best practices for production environments
✅ Troubleshooting common issues
✅ Integrating with other Kubernetes resources
✅ CI/CD automation

Key Takeaways

Always use declarative YAML manifests for reproducibility
Implement health checks for self-healing applications
Use rolling updates for zero-downtime deployments
Set resource limits to prevent resource exhaustion
Pin image versions for predictable deployments
Monitor your deployments for proactive maintenance
Implement proper security practices from the start

Next Steps

Now that you've mastered Kubernetes Deployments, consider exploring:

Horizontal Pod Autoscaler (HPA) - Automatic scaling based on metrics
Vertical Pod Autoscaler (VPA) - Automatic resource adjustment
Helm Charts - Package management for Kubernetes
Kustomize - Template-free configuration management
GitOps - Git as the source of truth for infrastructure
Service Mesh - Advanced networking and security features
Pod Disruption Budgets - Ensuring application availability during maintenance

Resources

KodeKloud - 100 Days of DevOps - Day 41: Write a Docker File

janak0ff — Mon, 03 Aug 2026 10:49:15 +0000

As per recent requirements shared by the Nautilus application development team, they need custom images created for one of their projects. Several of the initial testing requirements are already been shared with DevOps team. Therefore, create a docker file /opt/docker/Dockerfile (please keep D capital of Dockerfile) on App server 1 in Stratos DC and configure to build an image with the following requirements:

a. Use ubuntu:24.04 as the base image.

b. Install apache2 and configure it to work on 6000 port. (do not update any other Apache configuration settings like document root etc).

Step-by-Step Solution

Step 1: SSH to App Server 1

ssh tony@stapp01
# Password: Ir0nM@n

Step 2: Switch to Root (if needed)

sudo su -
# Password: Ir0nM@n

Step 3: Create the Directory

# Create the /opt/docker directory
mkdir -p /opt/docker

# Navigate to the directory
cd /opt/docker

Step 4: Create the Dockerfile

# Create Dockerfile with capital D
vi Dockerfile

Step 5: Add Content to Dockerfile

# Use ubuntu:24.04 as base image
FROM ubuntu:24.04

# Update package list and install apache2
RUN apt-get update && \
    apt-get install -y apache2 && \
    apt-get clean

# Expose port 6000
EXPOSE 6000

# Configure Apache to listen on port 6000
RUN sed -i 's/Listen 80/Listen 6000/g' /etc/apache2/ports.conf && \
    sed -i 's/:80>/:6000>/g' /etc/apache2/sites-available/000-default.conf

# Start Apache in foreground
CMD ["/usr/sbin/apache2ctl", "-D", "FOREGROUND"]

📊 Verification Commands

Check Dockerfile:

# Check file exists
ls -la /opt/docker/Dockerfile

# View content
cat /opt/docker/Dockerfile

Build and Test Image (Optional):

# Build the image
docker build -t apache2:6000 /opt/docker/

# Run the container
docker run -d --name apache2-test -p 6000:6000 apache2:6000

# Test Apache
curl http://localhost:6000

# Clean up
docker stop apache2-test
docker rm apache2-test

✅ Task Summary

Requirement	Status
SSH to App Server 1	✅
Create /opt/docker directory	✅
Create Dockerfile (capital D)	✅
Use ubuntu:24.04 base image	✅
Install apache2	✅
Configure Apache port 6000	✅
No other configuration changes	✅

DEV Community: janak0ff

Day 47: Docker Python App

Introduction

What We'll Build Today

📋 Prerequisites

🔍 Understanding the Application

Application Structure

File 1: requirements.txt

File 2: server.py – The Flask Application

🔧 Step-by-Step Dockerization

Step 1: SSH to App Server 1

Step 2: Navigate to the Application Directory

Step 3: View the Application Files

Step 4: Create the Dockerfile

📖 Understanding the Dockerfile

Step 5: Build the Docker Image

Step 6: Verify the Image

Step 7: Create and Run the Container

Step 8: Verify the Container is Running

Step 9: Test the Application

🔍 Additional Verification Commands

Check Container Logs

Check Container Details

Get Shell Inside Container

📝 Complete Commands Summary

📊 Architecture Diagram

🎯 Key Concepts Explained

What is a Dockerfile?

Why Use python:3.9-slim?

Port Mapping Explained

✅ Task Summary

🔧 Troubleshooting Common Issues

Issue 1: Dockerfile Not Found

Issue 2: Port Already in Use

Issue 3: Flask Not Found

🎉 You Did It!

What You Learned:

Day 46: Deploy an App on Docker Containers

Introduction

What is Docker Compose?

Why Use Docker Compose?

📋 Our Task Today

🔧 Step-by-Step Guide

Step 1: Connect to the Server

Step 2: Create the Working Directory

Step 3: Install Docker Compose

Step 4: Create the Docker Compose File

📖 Understanding the YAML File

Web Service (the website)

DB Service (the database)

Step 5: Start the Application

Step 6: Verify Everything is Working

Step 7: Test the Application

🎯 Understanding What We Just Built

Container Architecture

Key Concepts Explained

1. Images vs Containers

2. Port Mapping

3. Volumes

4. Environment Variables

🔧 Troubleshooting Common Issues

Issue 1: Docker Compose Not Found

Issue 2: libcrypt.so.1 Error

Issue 3: Permission Denied

Issue 4: Port Already in Use

📊 Quick Reference: Docker Compose Commands

✅ Summary

Quick Command Summary

Revert Deployment to Previous Version in Kubernetes

Understanding Rollbacks

What is a Rollback?

Why Rollbacks Matter

How Rollbacks Work in Kubernetes

The Scenario: When Things Go Wrong

Our Setup

Step-by-Step Rollback Guide

Step 1: Check Your Current Deployment

Step 2: View the Rollout History

Step 3: Examine the Previous Revision

Step 4: Check the Current Revision

File 1: `requirements.txt`

File 2: `server.py` – The Flask Application

Why Use `python:3.9-slim`?

❌ Issue 1: Incorrect Paths in `sed` Commands

❌ Issue 2: Using `RUN cp` Instead of `COPY`

Method 1: Using `kubectl edit`

Method 2: Using `kubectl patch`

Method 3: Using `kubectl apply` with YAML

Method 4: Using `kubectl replace`