Skip to main content

Command Palette

Search for a command to run...

Kubernetes Day-2: From Docker Containers to Self-Healing Kubernetes Applications

Published
5 min read
Kubernetes Day-2: From Docker Containers to Self-Healing Kubernetes Applications
N
DevOps and Cloud engineer passionate about building resilient, secure, and scalable systems. I work extensively with AWS, Terraform, Docker, Kubernetes, and CI/CD pipelines, focusing on real-world deployments rather than theory. I write about infrastructure design, debugging production issues, and simplifying complex tools into practical, actionable knowledge. Driven by curiosity and hands-on learning.

In Kubernetes Day-1, we discussed why Kubernetes exists and how it solves one of the biggest challenges in the container world — monitoring and scaling infrastructure automatically.

In Day-2, we raise the bar.

Today, Kubernetes stops being just a “buzzword” and starts feeling like a real production tool. We’ll move from Docker limitations to Kubernetes solutions and understand how Kubernetes manages containers the right way.


Why Modern Applications Need More Than Docker

Today’s applications are rarely simple.

Your application might be:

  • Single-tier or multi-tier

  • Monolithic or microservices-based

  • Spread across multiple layers and services

No matter how it’s architected, deploying such applications requires:

  • Infrastructure (CPU, RAM, Disk, Network)

  • Continuous monitoring

  • Security & isolation

  • Storage management

  • Scalability

Docker helps us run applications inside containers, but Docker alone is not enough to manage large or production-grade systems.

This is where Kubernetes enters the picture.


What Exactly Is Kubernetes?

Kubernetes (K8s) is a container management and orchestration tool.

It:

  • Manages containers running on Docker, CRI-O, or Podman

  • Monitors application health

  • Restarts failed workloads

  • Scales applications up and down

  • Provides networking, security, and resource control

Important clarification
- Kubernetes does not fix application bugs.
- It manages infrastructure and containers, not your code logic.

Topics like security, storage, quotas, limits, and policies are handled by Kubernetes and we’ll cover them in dedicated chapters later.


Docker vs Kubernetes (The Real Difference)

Docker and Kubernetes are often compared, but they solve different problems.

DockerKubernetes
Runs containersManages containers
Manual monitoringAutomatic monitoring
No self-healingSelf-healing
Limited scalingEasy scaling
Single-host focusedMulti-node ready

Docker is great at creating containers.
Kubernetes is great at taking responsibility for them.


Hands-On Demo: Docker Without Kubernetes

Let’s look at a real scenario.

  • We have a Docker image stored on Docker Hub

  • We launch a container running a PHP application

  • The application works fine and is accessible using the container IP

But then…

  • The container stops

  • The container is deleted

  • The OS shuts down

What happens?

The application is completely unavailable.

To fix this, a human has to:

  • Run docker ps

  • Check container status

  • Restart or recreate the container

This kind of manual monitoring is not practical in real production environments.


The Biggest Challenge: Container Monitoring

Docker does not continuously monitor containers.

Once a container is down:

  • Client connectivity is lost

  • The application becomes unavailable

  • Recovery is manual

This is exactly the problem Kubernetes was designed to solve.

That’s why Kubernetes is also known as a container management platform.


Setting Up Kubernetes for Learning (Minikube)

Kubernetes is a program, and like any program, it needs an OS to run.

For learning purposes:

  • We use a single-node Kubernetes cluster

  • Both Master and Worker nodes run on the same VM

To simplify this setup, we use Minikube.

Why Minikube?

  • Perfect for beginners

  • Automatically configures Kubernetes

  • Works well with VirtualBox on Windows

  • Ideal for testing and practice

Minikube downloads a pre-configured VM with Kubernetes already installed and ready to use.


Talking to Kubernetes: kubectl

Once Kubernetes is running, we need a way to communicate with it.

That tool is kubectl.

kubectl is the client-side command-line tool used to send instructions to the Kubernetes server.

Almost 99% of Kubernetes users interact with clusters using kubectl.

Think of it like this:

  • Docker CLI → Docker Engine

  • kubectl → Kubernetes Cluster


Containers vs Pods (Very Important Concept)

Here’s a mindset shift you must make:

Kubernetes does NOT manage containers directly.

Instead, Kubernetes manages Pods.

Simple mapping:

DockerKubernetes
ContainerPod
docker runkubectl
docker pskubectl get pods

A Pod is the smallest unit in Kubernetes.

Inside a Pod:

  • One or more containers can run

  • Containers share networking and storage

Kubernetes only sees Pods not containers directly.


Creating a Pod in Kubernetes

You can create a Pod directly using kubectl:

kubectl run myweb1 --image=vimal13/apache-webserver-php

What happens internally:

  1. Command goes to the Kubernetes server

  2. Kubernetes pulls the image

  3. A container is created

  4. The container is wrapped inside a Pod

You can verify it using:

kubectl get pods

Why Didn’t Kubernetes Restart My Pod?

If you delete the Pod:

kubectl delete pod myweb1

Kubernetes does not recreate it automatically.

Why?

Because Pods alone are not self-healing.

This is a common beginner confusion — and an important one.


Deployments: The Real Power of Kubernetes

To get:

  • Auto-healing

  • Continuous monitoring

  • Desired state management

You must use a Deployment.

Creating a Deployment

kubectl create deployment myweb1 --image=vimal13/apache-webserver-php

Now Kubernetes:

  • Monitors Pods continuously

  • Recreates Pods if they crash

  • Ensures the application is always running

Pod names now look like:

myweb1-55dbb57599-cjb2t

These random names are created by Kubernetes internally — we’ll discuss this later.


Inspecting Pods in Detail

To see deep details about a Pod:

kubectl describe pod <pod-name>

This shows:

  • Image details

  • Namespace

  • Node information

  • Events and status

This command is extremely useful for debugging.


Kubernetes Dashboard (Web UI)

Minikube also provides a web-based Kubernetes Dashboard.

minikube dashboard

From the dashboard, you can:

  • View Pods and Deployments

  • Scale applications

  • Delete resources

  • Monitor cluster health


Exposing Applications in Kubernetes (Services)

By default, Pods are not accessible from outside the cluster.

To expose an application:

kubectl expose deployment myweb1 --port=80 --type=NodePort

This creates a Kubernetes Service that:

  • Routes traffic to Pods

  • Uses a NodePort (30000–32767)

  • Allows external access via Node IP

To get the URL:

minikube service myweb1 --url

Paste it into your browser, your app is live


Scaling Applications in Kubernetes

Scaling in Kubernetes is incredibly simple.

kubectl scale deployment myweb1 --replicas=4

What happens:

  • 4 Pods are created instantly

  • Traffic is automatically load-balanced

  • No downtime

Kubernetes already has built-in load balancing on the backend.


If this blog helped you understand Kubernetes better, give it a like or drop a comment. It really motivates me to continue this series.

More from this blog

D

DevOps in Practice

29 posts