The most important relationship to understand is:

Your Application
      ↓
   Dockerfile
      ↓
  Docker Image
      ↓
 Docker Container
      ↓
     Pod
      ↓
  Kubernetes

Let's understand each part.

1. What is a Container?#

Suppose you have a Node.js application.

Your application needs:

Node.js
npm packages
Environment variables
Application code
Configuration

Normally, if you give your application to another developer, they might have:

Node.js 20

while you have:

Node.js 22

Or you have a package installed that they don't.

Then you get the famous:

"It works on my machine."

Containers solve much of this problem by packaging the application and its runtime dependencies into a standardized environment.

┌─────────────────────────────┐
│         Container           │
│                             │
│   Node.js                   │
│   Application code          │
│   npm dependencies          │
│   Configuration             │
│                             │
└─────────────────────────────┘

2. Container vs Virtual Machine#

This is a very common interview question.

Virtual Machine#

A VM contains an entire guest operating system.

Physical Server
│
├── Host OS
│
├── VM 1
│    └── Guest OS
│         └── Application
│
├── VM 2
│    └── Guest OS
│         └── Application

Container#

Containers share the host operating system's kernel.

Physical Server
│
├── Host OS
│
├── Container 1
│    └── Application
│
├── Container 2
│    └── Application
│
└── Container 3
     └── Application

Therefore containers are generally:

• Lightweight
• Fast to start
• Portable
• Easy to replicate

Simple comparison#

Don't interpret this as "containers are always better." VMs and containers solve somewhat different problems and are often used together.

3. What is Docker?#

Docker is a platform for building, packaging, distributing, and running containers.

For example:

docker run nginx

Docker downloads the Nginx image if necessary and starts a container from it.

Think:

Docker
 ├── Build image
 ├── Download image
 ├── Run container
 ├── Stop container
 ├── Remove container
 └── Manage containers

4. What is a Docker Image?#

An image is a packaged, immutable template used to create containers.

For example:

Node.js Image
     ↓
Container 1
Container 2
Container 3

One image can create many containers.

Think of an image like a blueprint.

Image = Blueprint
 
Container = Running instance created from that blueprint

5. Image vs Container#

This is extremely important.

Image#

Template / Blueprint

Container#

Running instance of the image

Example:

nginx:latest
      ↓
   Image
      ↓
 ┌────┼────┐
 ↓    ↓    ↓
C1   C2   C3

All three containers can be created from the same image.

6. What is a Dockerfile?#

A Dockerfile contains instructions for building your image.

For example:

FROM node:22-alpine
 
WORKDIR /app
 
COPY package*.json ./
 
RUN npm install
 
COPY . .
 
EXPOSE 3000
 
CMD ["npm", "start"]

Let's understand this line by line.

7. FROM#

FROM node:22-alpine

This tells Docker:

Start with the Node.js 22 Alpine image.

You're building on top of an existing image.

Conceptually:

node:22-alpine
       ↓
Your image

8. WORKDIR#

WORKDIR /app

Sets the working directory inside the container.

So commands after this operate from:

/app

9. COPY#

COPY package*.json ./

Copies package files from your computer into the image.

Then:

RUN npm install

installs dependencies.

Then:

COPY . .

copies the rest of your application.

10. RUN#

RUN npm install

This executes a command while building the image.

This distinction matters:

docker build
      ↓
RUN commands execute
      ↓
Image created

11. EXPOSE#

EXPOSE 3000

This documents that the application uses port 3000.

Important:

EXPOSE does not by itself publish the port to your host machine.

You still need something such as:

docker run -p 3000:3000 my-app

12. CMD#

CMD ["npm", "start"]

This defines the default command that runs when the container starts.

So:

Container starts
      ↓
npm start
      ↓
Node.js application

13. Let's build a real application#

Create a simple project:

node-docker-demo/
│
├── package.json
├── server.js
└── Dockerfile

server.js#

const http = require("http");
 
const server = http.createServer((req, res) => {
  res.end("Hello from Docker!");
});
 
server.listen(3000, () => {
  console.log("Server running on port 3000");
});

package.json#

{
  "name": "node-docker-demo",
  "version": "1.0.0",
  "scripts": {
    "start": "node server.js"
  }
}

Dockerfile#

FROM node:22-alpine
 
WORKDIR /app
 
COPY package*.json ./
 
RUN npm install
 
COPY . .
 
EXPOSE 3000
 
CMD ["npm", "start"]

14. Build the Docker Image#

Run:

docker build -t node-docker-demo .

Break this down:

docker build
      ↓
Build an image
 
-t node-docker-demo
      ↓
Give image a name
 
.
      ↓
Use current directory as build context

Now:

docker images

You should see something similar to:

REPOSITORY          TAG       IMAGE ID
node-docker-demo    latest    abc123

15. Run the Container#

Run:

docker run -p 3000:3000 node-docker-demo

The port mapping:

-p 3000:3000
   │     │
   │     └── Container port
   └──────── Host port

So:

Your computer
localhost:3000
      ↓
Docker
      ↓
Container
      ↓
Node.js :3000

Open:

http://localhost:3000

You should get:

Hello from Docker!

16. What happened internally?#

You ran:

docker run -p 3000:3000 node-docker-demo

Conceptually:

Docker Image
     ↓
Create Container
     ↓
Start Container
     ↓
Run npm start
     ↓
Node.js server
     ↓
Port 3000

17. Container Lifecycle#

A container can be:

Created
   ↓
Running
   ↓
Stopped
   ↓
Removed

Useful commands:

docker ps

Shows running containers.

docker ps -a

Shows all containers.

docker stop <container>

Stops a container.

docker start <container>

Starts a stopped container.

docker rm <container>

Removes a container.

18. Viewing Logs#

If your application prints:

console.log("Server started");

you can see it using:

docker logs <container>

For live logs:

docker logs -f <container>

This becomes very important when we start debugging Kubernetes.

19. Environment Variables#

Never hardcode things such as:

const dbPassword = "mypassword";

Instead:

const dbPassword = process.env.DB_PASSWORD;

Then:

docker run \
  -e DB_PASSWORD=mysecret \
  node-docker-demo

Docker passes:

DB_PASSWORD
     ↓
Container
     ↓
Node.js
     ↓
process.env.DB_PASSWORD

Later Kubernetes will provide configuration using ConfigMaps and Secrets.

20. Why Containers are useful for Kubernetes#

Now we're getting to the important part.

Suppose you have:

Node.js application

You create:

Docker Image

Then Kubernetes can run multiple instances:

Docker Image
      ↓
 ┌────┼────┐
 ↓    ↓    ↓
Pod  Pod  Pod
 │    │    │
Container
Container
Container

So Kubernetes doesn't replace containers.

It orchestrates containerized workloads.

21. Docker → Kubernetes#

Here's the complete relationship:

Developer
    ↓
Application
    ↓
Dockerfile
    ↓
Docker Build
    ↓
Docker Image
    ↓
Container Registry
    ↓
Kubernetes
    ↓
Pod
    ↓
Container

For example:

Your Node.js app
       ↓
Docker image
       ↓
Docker Hub / ECR / Artifact Registry
       ↓
Kubernetes pulls image
       ↓
Pod
       ↓
Container starts

22. What is a Container Registry?#

A registry stores Docker images.

Examples include:

• Docker Hub
• Amazon ECR
• Google Artifact Registry
• Azure Container Registry
• GitHub Container Registry

Think:

GitHub
  ↓
Stores source code
 
Container Registry
  ↓
Stores container images

For example:

mycompany/node-api:v1
mycompany/node-api:v2

Kubernetes can pull the image from the registry.

23. Important: Kubernetes doesn't magically create your application#

Suppose you tell Kubernetes:

image: mycompany/node-api:v1

Kubernetes needs to obtain that image.

Conceptually:

Kubernetes
     ↓
"I need mycompany/node-api:v1"
     ↓
Container Registry
     ↓
Download image
     ↓
Create container
     ↓
Run inside Pod

24. Why Kubernetes Pods restart#

Suppose:

Pod
└── Node.js Container

The application crashes.

Kubernetes can detect that the workload isn't in the desired state and take corrective action depending on how the workload is configured.

This is one reason Kubernetes is called a self-healing system.

25. One important correction about Kubernetes#

A common beginner misconception is:

"Kubernetes manages Docker."

Historically, Kubernetes commonly used Docker through the container runtime interface, but modern Kubernetes does not require Docker Engine as its runtime.

Kubernetes works with container runtimes such as:

containerd
CRI-O

The important concept is:

Kubernetes
     ↓
Container Runtime
     ↓
Container

You don't need to worry about the runtime details yet. Just remember this distinction.

26. The complete picture#

Now combine Chapter 1 and Chapter 2:

                    Kubernetes Cluster
                           │
                ┌──────────┴──────────┐
                │                     │
          Control Plane          Worker Node
                                      │
                                  Deployment
                                      │
                              ┌───────┼───────┐
                              ↓       ↓       ↓
                             Pod     Pod     Pod
                              │       │       │
                              ↓       ↓       ↓
                         Container Container Container
                              │       │       │
                              └───────┼───────┘
                                      │
                              Docker Image
                                      │
                              Container Registry

The flow you'll repeatedly see is:

Code
 ↓
Dockerfile
 ↓
Image
 ↓
Registry
 ↓
Kubernetes
 ↓
Pod
 ↓
Container

🧠 Interview Questions#

Q1. What is a container?#

A lightweight, isolated environment for running an application and its dependencies.

Q2. What is a Docker image?#

A packaged, immutable template from which containers are created.

Q3. Image vs container?#

Image = blueprint

Container = running instance of that image

Q4. What is Dockerfile?#

A text file containing instructions used to build a Docker image.

Q5. What does FROM do?#

Specifies the base image.

Q6. What does RUN do?#

Executes a command during image construction.

Q7. What does CMD do?#

Defines the default command executed when the container starts.

Q8. Does EXPOSE 3000 publish the port?#

No. It documents the intended container port. Port publishing is typically done with -p.

Q9. Why use containers?#

They provide a consistent, portable environment for applications and their dependencies.

Q10. Does Kubernetes require Docker Engine?#

No. Modern Kubernetes uses container runtimes such as containerd or CRI-O.

🎯 Mini Exercise#

Before moving to Chapter 3, make sure you can explain this without looking:

Dockerfile
    ↓
Docker Image
    ↓
Container
    ↓
Pod
    ↓
Deployment
    ↓
Kubernetes

And answer:

If I have one Docker image and I want 5 copies of my Node.js application running in Kubernetes, what Kubernetes object will we eventually use to manage those copies?

Answer: Deployment.

We'll properly understand why in the next chapters.

🚀 Next: Chapter 3 — Kubernetes Architecture#

This is a very important chapter. We'll open up Kubernetes and understand:

Kubernetes Cluster
│
├── Control Plane
│   ├── API Server
│   ├── Scheduler
│   ├── Controller Manager
│   └── etcd
│
└── Worker Node
    ├── kubelet
    ├── kube-proxy
    ├── Container Runtime
    └── Pods

Most importantly, I'll explain exactly what happens inside Kubernetes when you run kubectl apply -f deployment.yaml.