Phase 05 · Production & GitOpsChapter 28 of 33

Phase 05Read time ~14 minDifficulty intermediate

Local Kubernetes 🖥️

Warrior, now we move from Kubernetes theory → actually running Kubernetes on your own PC.

In this chapter (62 sections)

Since you're on Windows and already work with Docker/Node.js, we'll focus on a practical local setup.

1. Why run Kubernetes locally?#

Before deploying to:

AWS EKS
Google GKE
Azure AKS

you should be able to run:

Your PC
   ↓
Local Kubernetes Cluster
   ↓
Node
   ↓
Pod
   ↓
Container
   ↓
Your application

This lets you practice Kubernetes without paying for cloud infrastructure.

2. Three popular choices#

There are three common options:

Tool	Best for
Docker Desktop Kubernetes	Easiest for beginners
Minikube	Learning Kubernetes
Kind	Kubernetes testing/CI

Conceptually:

Docker Desktop
      ↓
Kubernetes cluster

Minikube
   ↓
Kubernetes cluster

Kind
 ↓
Kubernetes nodes inside containers

3. Which one should you use?#

For your learning journey:

Docker Desktop Kubernetes#

is the easiest starting point.

Why?

You already understand Docker.

You can have:

Windows
  │
  ↓
Docker Desktop
  │
  ↓
Kubernetes
  │
  ├── Control Plane
  │
  └── Worker Node

For more realistic multi-node testing later, Kind is excellent.

4. Docker Desktop Kubernetes#

Docker Desktop can provide a local Kubernetes cluster.

After installing Docker Desktop, open:

Docker Desktop
    ↓
Settings
    ↓
Kubernetes

Depending on your Docker Desktop version, the exact UI wording may differ.

Enable Kubernetes and create/start the cluster.

5. Verify kubectl#

Open PowerShell:

kubectl version --client

You should get client information.

Then:

kubectl cluster-info

If Kubernetes is running correctly, you'll see cluster/control-plane information.

6. Check your nodes#

Run:

kubectl get nodes

You might see:

NAME             STATUS   ROLES           AGE   VERSION
docker-desktop   Ready    control-plane   10m   v1.xx.x

The important part:

STATUS = Ready

means your node is available for scheduling.

7. Your first Kubernetes architecture#

Your laptop is now effectively hosting a Kubernetes cluster.

Conceptually:

             YOUR WINDOWS PC
                    │
              Docker Desktop
                    │
             Kubernetes Cluster
                    │
             ┌──────┴──────┐
             │             │
        Control Plane    Worker
                         Node
                           │
                         Pod
                           │
                       Container

Depending on the local distribution/version, control-plane and worker roles may be implemented differently. Don't assume every local setup exactly mirrors a multi-node cloud cluster.

8. Check all Pods#

Run:

kubectl get pods -A

You will probably see system components in namespaces such as:

kube-system

For example:

coredns
kube-proxy

These are Kubernetes infrastructure components.

9. Create your first Pod#

Let's create an NGINX Pod.

kubectl run nginx --image=nginx

Check:

kubectl get pods

You might initially see:

NAME    READY   STATUS              RESTARTS   AGE
nginx   0/1     ContainerCreating   0          2s

Wait a moment.

Then:

kubectl get pods

Eventually:

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          30s

Congratulations.

You just created a Kubernetes workload.

10. What happened internally?#

You ran:

kubectl run nginx --image=nginx

The flow is approximately:

kubectl
   │
   ↓
API Server
   │
   ↓
Pod object created
   │
   ↓
Scheduler
   │
   ↓
Node selected
   │
   ↓
kubelet
   │
   ↓
Container runtime
   │
   ↓
NGINX container

This is the architecture from Chapter 3 happening for real.

11. Inspect the Pod#

Run:

kubectl describe pod nginx

Look at:

Events

You may see events similar to:

Scheduled
Pulling
Pulled
Created
Started

This is extremely useful for debugging.

12. Check the Pod IP#

Run:

kubectl get pod nginx -o wide

Example:

NAME    READY   STATUS    IP           NODE
nginx   1/1     Running   10.1.0.15    docker-desktop

The Pod has its own cluster IP.

But remember:

Pod IPs are not meant to be your stable application endpoint.

That's why we learned Services.

13. Create a Service#

Expose NGINX internally:

kubectl expose pod nginx --port=80

Check:

kubectl get services

You should see something like:

NAME         TYPE        CLUSTER-IP     PORT(S)
kubernetes   ClusterIP   10.x.x.x       443/TCP
nginx        ClusterIP   10.x.x.x       80/TCP

14. Why can't your browser access it?#

Because:

ClusterIP

is normally accessible only inside the Kubernetes cluster.

Your browser is outside the cluster network.

Architecture:

Browser
   X
   │
   │
ClusterIP
   │
   ↓
Pod

We need an external access method.

15. Use NodePort locally#

Delete the current Service:

kubectl delete service nginx

Now create:

kubectl expose pod nginx `
  --port=80 `
  --target-port=80 `
  --type=NodePort

Check:

kubectl get service nginx

Example:

NAME    TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)
nginx   NodePort   10.x.x.x      <none>        80:30080/TCP

The important part is:

80:30080

Meaning:

Service port = 80
NodePort     = 30080

16. Access it#

Depending on your local Kubernetes implementation, you may be able to access:

http://localhost:30080

If that doesn't work with your specific local setup, inspect the cluster's networking behavior or use the convenient method in the next section.

17. `kubectl port-forward`#

This is one of the most useful local-development commands.

Run:

kubectl port-forward pod/nginx 8080:80

You should see:

Forwarding from 127.0.0.1:8080 -> 80

Now open:

http://localhost:8080

You'll see the NGINX page.

The architecture is:

Browser
   │
   │ localhost:8080
   ↓
kubectl port-forward
   │
   ↓
Pod:80
   │
   ↓
NGINX

18. Port-forward is extremely useful#

Suppose you have:

PostgreSQL
Redis
Node.js API
Grafana
Prometheus

running inside Kubernetes.

You can temporarily access them locally.

For example:

kubectl port-forward svc/backend 3000:80

Then:

localhost:3000
       ↓
backend Service
       ↓
backend Pod

This is excellent for development and debugging.

19. But don't confuse port-forward with production networking#

kubectl port-forward is primarily a development/debugging mechanism.

Production architecture is normally:

Internet
   ↓
Load Balancer / Ingress
   ↓
Service
   ↓
Pods

Not:

Internet
   ↓
kubectl port-forward

20. Create a Deployment instead of a Pod#

Earlier we created:

kubectl run nginx --image=nginx

That's a direct Pod.

Production applications usually use:

Deployment
   ↓
ReplicaSet
   ↓
Pods

Create one:

kubectl create deployment nginx `
  --image=nginx

Check:

kubectl get deployments

Then:

kubectl get pods

21. Scale it#

Run:

kubectl scale deployment nginx --replicas=3

Check:

kubectl get pods

You'll see three Pods:

nginx-xxxxx
nginx-yyyyy
nginx-zzzzz

Architecture:

              Deployment
                  │
              ReplicaSet
          ┌───────┼───────┐
          ↓       ↓       ↓
        Pod     Pod     Pod

22. Expose the Deployment#

Create a Service:

kubectl expose deployment nginx `
  --port=80 `
  --type=NodePort

Check:

kubectl get svc

Now:

Browser
   ↓
NodePort
   ↓
Service
   ↓
┌──────┬──────┬──────┐
Pod    Pod    Pod

The Service distributes traffic across eligible Pods.

23. Your first YAML deployment#

Now let's stop using imperative commands.

Create:

deployment.yaml

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

Apply:

kubectl apply -f deployment.yaml

Check:

kubectl get deployment
kubectl get pods

24. Create the Service YAML#

Create:

service.yaml

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

Apply:

kubectl apply -f service.yaml

Check:

kubectl get svc nginx

25. Why labels matter#

Our Deployment:

labels:
  app: nginx

Service:

selector:
  app: nginx

The Service finds Pods using the label.

Pod
labels:
  app=nginx
       ↑
       │
       │ matches
       │
Service
selector:
  app=nginx

If you accidentally write:

selector:
  app: backend

the Service won't find those Pods.

Then:

Service
   ↓
No endpoints

This is one of the most common Kubernetes mistakes.

26. Check Endpoints#

Run:

kubectl get endpoints nginx

or, on modern clusters:

kubectl get endpointslices

If your Service has three ready Pods, you should see corresponding backend endpoints.

This is a great debugging technique.

27. Create a local Node.js application#

Now let's make this relevant to your stack.

Suppose your Node.js API is:

const express = require("express");
 
const app = express();
 
app.get("/", (req, res) => {
  res.json({
    message: "Hello Kubernetes"
  });
});
 
app.get("/health", (req, res) => {
  res.json({
    status: "ok"
  });
});
 
app.listen(3000, "0.0.0.0", () => {
  console.log("Server running on port 3000");
});

Notice:

app.listen(3000, "0.0.0.0")

This matters.

Inside containers, don't accidentally bind the server only to:

127.0.0.1

because then other network interfaces may not be able to reach it.

28. Dockerize it#

Dockerfile:

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

Build:

docker build -t node-api:1.0 .

Now you have:

node-api:1.0

29. Important local-cluster issue#

Here's something beginners often encounter.

You built:

node-api:1.0

on your machine.

But Kubernetes might use a container runtime/environment where that locally built image isn't automatically available in the way you expect.

Then you get:

ErrImagePull

or:

ImagePullBackOff

Why?

Kubernetes may try to pull:

node-api:1.0

from a registry.

But your image exists only locally.

30. Solutions#

You have several options.

Option 1 — Use Docker Desktop Kubernetes#

Depending on your Docker Desktop configuration, locally built images may be available to the local cluster.

This is one reason Docker Desktop is convenient for beginners.

Option 2 — Use a local registry#

You can run a local container registry:

Your machine
   │
   ├── Docker build
   │
   ↓
Local Registry
   │
   ↓
Kubernetes

Option 3 — Kind#

Kind supports workflows where images can be loaded into the cluster.

Conceptually:

docker build -t node-api:1.0 .

then:

kind load docker-image node-api:1.0

Now Kind nodes can use that image.

Option 4 — Push to a registry#

For example:

Docker Hub
ECR
GHCR
GCR/Artifact Registry
ACR

Then Kubernetes pulls it.

Production typically uses a registry.

31. Node.js Deployment#

Example:

apiVersion: apps/v1
kind: Deployment
 
metadata:
  name: node-api
 
spec:
  replicas: 2
 
  selector:
    matchLabels:
      app: node-api
 
  template:
    metadata:
      labels:
        app: node-api
 
    spec:
      containers:
        - name: node-api
          image: node-api:1.0
 
          ports:
            - containerPort: 3000
 
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
 
            limits:
              cpu: "500m"
              memory: "512Mi"
 
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
 
            initialDelaySeconds: 5
            periodSeconds: 10

This combines concepts you've already learned:

Deployment
+
replicas
+
resources
+
readinessProbe

32. Node.js Service#

apiVersion: v1
kind: Service
 
metadata:
  name: node-api
 
spec:
  selector:
    app: node-api
 
  ports:
    - port: 80
      targetPort: 3000
 
  type: ClusterIP

Notice:

Service: 80
Pod:     3000

So:

node-api:80
      ↓
Pod:3000

33. Test the Node.js Service#

Because it's a ClusterIP Service, create a temporary debugging Pod:

kubectl run curl `
  --image=curlimages/curl `
  -it `
  --rm `
  --restart=Never `
  -- sh

Inside:

curl http://node-api

You should receive:

{
  "message": "Hello Kubernetes"
}

Now you've actually tested Kubernetes Service discovery.

34. Test DNS#

Inside the debug container:

nslookup node-api

You'll see the Kubernetes DNS resolve the Service.

This demonstrates:

node-api
   ↓
CoreDNS
   ↓
ClusterIP

35. Local Kubernetes project architecture#

At this point you can build:

                 Browser
                    │
                    ↓
               NodePort
                    │
                    ↓
              Frontend Service
                    │
                    ↓
              Next.js Pods
                    │
                    ↓
             Backend Service
                    │
                    ↓
              Node.js Pods
                │       │
                ↓       ↓
             Redis   PostgreSQL

And eventually:

                   Ingress
                      │
             ┌────────┴────────┐
             ↓                 ↓
        Next.js Service    API Service
             ↓                 ↓
        Next.js Pods       Node Pods
                               │
                         ┌─────┴─────┐
                         ↓           ↓
                       Redis      PostgreSQL

36. Docker Compose vs Kubernetes#

You may already know Docker Compose.

Compare:

Docker Compose#

docker-compose.yml
 
frontend
backend
redis
postgres

Kubernetes#

Deployment
Service
ConfigMap
Secret
Ingress
PVC
HPA
NetworkPolicy

Compose is usually simpler for local multi-container development.

Kubernetes is designed for orchestration and production-scale management.

37. Minikube#

Now let's understand Minikube.

Minikube is a tool that runs a local Kubernetes cluster.

Typical architecture:

Windows
   ↓
Minikube
   ↓
Kubernetes

You can check:

minikube status

Start:

minikube start

Check:

kubectl get nodes

38. Minikube dashboard#

Minikube can provide a dashboard:

minikube dashboard

This can help beginners visually understand:

Namespaces
Deployments
Pods
Services
ConfigMaps
Secrets

However, don't rely entirely on the UI.

You should become comfortable with:

kubectl

because that's what you'll use heavily in real environments.

39. Kind#

Kind means:

Kubernetes IN Docker

It runs Kubernetes nodes as containers.

Architecture:

Docker
 │
 ├── control-plane container
 ├── worker container
 └── worker container

Create:

kind create cluster

Check:

kubectl get nodes

Kind is particularly useful for:

Kubernetes testing
CI pipelines
multi-node experiments
local development

40. Docker Desktop vs Minikube vs Kind#

For your learning:

Docker Desktop
      ↓
 easiest beginning

Minikube
      ↓
 Kubernetes learning

Kind
      ↓
 multi-node/testing/CI

You don't need to install all three immediately.

Start with one.

41. Your first complete local workflow#

You should understand this entire sequence:

1. Write Node.js application
          ↓
2. Dockerfile
          ↓
3. docker build
          ↓
4. Docker image
          ↓
5. Kubernetes Deployment
          ↓
6. Pod
          ↓
7. Service
          ↓
8. port-forward / NodePort / Ingress
          ↓
9. Browser/client

And if you use a registry:

Docker image
     ↓
Container Registry
     ↓
Kubernetes
     ↓
Pod

42. Useful commands to memorize#

Cluster#

kubectl cluster-info
kubectl get nodes
kubectl get nodes -o wide

Pods#

kubectl get pods
kubectl get pods -o wide
kubectl describe pod <pod>
kubectl logs <pod>

Deployments#

kubectl get deployments
kubectl describe deployment <deployment>
kubectl scale deployment <deployment> --replicas=3

Services#

kubectl get svc
kubectl describe svc <service>

Debugging#

kubectl get events --sort-by=.lastTimestamp
kubectl exec -it <pod> -- /bin/sh

Local access#

kubectl port-forward pod/<pod> 8080:80

or:

kubectl port-forward svc/<service> 3000:80

43. Your local Kubernetes debugging workflow#

When something doesn't work:

Application not working
        ↓
kubectl get pods
        ↓
Is Pod Running?
     /       \
   NO         YES
   ↓           ↓
describe      Service?
logs             ↓
events        Endpoint?
                 ↓
              Ingress?
                 ↓
                DNS?

This connects directly to Chapter 23.

44. Important local-learning exercise 🚀#

Build this:

Node.js API
     │
     ↓
Deployment
     │
     ├── Pod 1
     └── Pod 2
     │
     ↓
Service
     │
     ↓
localhost

Requirements:

Application#

GET /

returns:

{
  "message": "Hello Kubernetes"
}

Health#

GET /health

returns:

{
  "status": "ok"
}

Kubernetes#

Use:

Deployment
2 replicas
Service
readinessProbe
resource requests
resource limits

Then access it with:

kubectl port-forward svc/node-api 3000:80

Open:

http://localhost:3000

If you can do this successfully, you've gone from:

Kubernetes theory
        ↓
Running Kubernetes application

🧠 Chapter 27 Cheat Sheet#

Docker Desktop
    ↓
Local Kubernetes
 
kubectl get nodes
    ↓
Check cluster
 
kubectl get pods
    ↓
Check workloads
 
kubectl describe
    ↓
Inspect details/events
 
kubectl logs
    ↓
Application logs
 
Deployment
    ↓
Manages Pods
 
Service
    ↓
Stable networking
 
ClusterIP
    ↓
Internal access
 
NodePort
    ↓
External node-level access
 
port-forward
    ↓
Local development/debugging
 
Ingress
    ↓
HTTP/HTTPS routing
 
Minikube
    ↓
Local Kubernetes learning
 
Kind
    ↓
Kubernetes-in-Docker / testing

The most important mental model:#

                    LOCAL PC
                       │
                    Docker
                       │
                 Kubernetes
                       │
                 Deployment
                       │
                  ReplicaSet
                       │
              ┌────────┴────────┐
              ↓                 ↓
             Pod               Pod
              │                 │
           Container         Container
              └────────┬────────┘
                       ↓
                    Service
                       ↓
                Local Client

Next → Chapter 28: Kubernetes on AWS — EKS ☁️#

This is where local Kubernetes becomes real cloud Kubernetes.

We'll cover:

What AWS EKS actually is
EKS architecture
Control plane vs worker nodes
EC2 node groups
Managed node groups
EKS networking
VPC, subnets and security groups
Load Balancer
IAM + Kubernetes RBAC
ECR + EKS
Deploying your Node.js application
HPA + Cluster Autoscaler on EKS
Production architecture
Approximate cost considerations
Complete flow:

Developer
   ↓
Docker
   ↓
ECR
   ↓
EKS
   ↓
Deployment
   ↓
Pods
   ↓
Service
   ↓
AWS Load Balancer
   ↓
Internet

Finished this chapter?

Mark it as complete to track your mastery.

Previous ChapterChapter 26 — Kustomize 🧩Next ChapterChapter 28 — Kubernetes on AWS: EKS ☁️

Prev Next

Since you're on Windows and already work with Docker/Node.js, we'll focus on a practical local setup.

1. Why run Kubernetes locally?#

Before deploying to:

AWS EKS
Google GKE
Azure AKS

you should be able to run:

Your PC
   ↓
Local Kubernetes Cluster
   ↓
Node
   ↓
Pod
   ↓
Container
   ↓
Your application

This lets you practice Kubernetes without paying for cloud infrastructure.

2. Three popular choices#

There are three common options:

Tool	Best for
Docker Desktop Kubernetes	Easiest for beginners
Minikube	Learning Kubernetes
Kind	Kubernetes testing/CI

Conceptually:

Docker Desktop
      ↓
Kubernetes cluster

Minikube
   ↓
Kubernetes cluster

Kind
 ↓
Kubernetes nodes inside containers

3. Which one should you use?#

For your learning journey:

Docker Desktop Kubernetes#

is the easiest starting point.

Why?

You already understand Docker.

You can have:

Windows
  │
  ↓
Docker Desktop
  │
  ↓
Kubernetes
  │
  ├── Control Plane
  │
  └── Worker Node

For more realistic multi-node testing later, Kind is excellent.

4. Docker Desktop Kubernetes#

Docker Desktop can provide a local Kubernetes cluster.

After installing Docker Desktop, open:

Docker Desktop
    ↓
Settings
    ↓
Kubernetes

Depending on your Docker Desktop version, the exact UI wording may differ.

Enable Kubernetes and create/start the cluster.

5. Verify kubectl#

Open PowerShell:

kubectl version --client

You should get client information.

Then:

kubectl cluster-info

If Kubernetes is running correctly, you'll see cluster/control-plane information.

6. Check your nodes#

Run:

kubectl get nodes

You might see:

NAME             STATUS   ROLES           AGE   VERSION
docker-desktop   Ready    control-plane   10m   v1.xx.x

The important part:

STATUS = Ready

means your node is available for scheduling.

7. Your first Kubernetes architecture#

Your laptop is now effectively hosting a Kubernetes cluster.

Conceptually:

             YOUR WINDOWS PC
                    │
              Docker Desktop
                    │
             Kubernetes Cluster
                    │
             ┌──────┴──────┐
             │             │
        Control Plane    Worker
                         Node
                           │
                         Pod
                           │
                       Container

Depending on the local distribution/version, control-plane and worker roles may be implemented differently. Don't assume every local setup exactly mirrors a multi-node cloud cluster.

8. Check all Pods#

Run:

kubectl get pods -A

You will probably see system components in namespaces such as:

kube-system

For example:

coredns
kube-proxy

These are Kubernetes infrastructure components.

9. Create your first Pod#

Let's create an NGINX Pod.

kubectl run nginx --image=nginx

Check:

kubectl get pods

You might initially see:

NAME    READY   STATUS              RESTARTS   AGE
nginx   0/1     ContainerCreating   0          2s

Wait a moment.

Then:

kubectl get pods

Eventually:

NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          30s

Congratulations.

You just created a Kubernetes workload.

10. What happened internally?#

You ran:

kubectl run nginx --image=nginx

The flow is approximately:

kubectl
   │
   ↓
API Server
   │
   ↓
Pod object created
   │
   ↓
Scheduler
   │
   ↓
Node selected
   │
   ↓
kubelet
   │
   ↓
Container runtime
   │
   ↓
NGINX container

This is the architecture from Chapter 3 happening for real.

11. Inspect the Pod#

Run:

kubectl describe pod nginx

Look at:

Events

You may see events similar to:

Scheduled
Pulling
Pulled
Created
Started

This is extremely useful for debugging.

12. Check the Pod IP#

Run:

kubectl get pod nginx -o wide

Example:

NAME    READY   STATUS    IP           NODE
nginx   1/1     Running   10.1.0.15    docker-desktop

The Pod has its own cluster IP.

But remember:

Pod IPs are not meant to be your stable application endpoint.

That's why we learned Services.

13. Create a Service#

Expose NGINX internally:

kubectl expose pod nginx --port=80

Check:

kubectl get services

You should see something like:

NAME         TYPE        CLUSTER-IP     PORT(S)
kubernetes   ClusterIP   10.x.x.x       443/TCP
nginx        ClusterIP   10.x.x.x       80/TCP

14. Why can't your browser access it?#

Because:

ClusterIP

is normally accessible only inside the Kubernetes cluster.

Your browser is outside the cluster network.

Architecture:

Browser
   X
   │
   │
ClusterIP
   │
   ↓
Pod

We need an external access method.

15. Use NodePort locally#

Delete the current Service:

kubectl delete service nginx

Now create:

kubectl expose pod nginx `
  --port=80 `
  --target-port=80 `
  --type=NodePort

Check:

kubectl get service nginx

Example:

NAME    TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)
nginx   NodePort   10.x.x.x      <none>        80:30080/TCP

The important part is:

80:30080

Meaning:

Service port = 80
NodePort     = 30080

16. Access it#

Depending on your local Kubernetes implementation, you may be able to access:

http://localhost:30080

If that doesn't work with your specific local setup, inspect the cluster's networking behavior or use the convenient method in the next section.

17. `kubectl port-forward`#

This is one of the most useful local-development commands.

Run:

kubectl port-forward pod/nginx 8080:80

You should see:

Forwarding from 127.0.0.1:8080 -> 80

Now open:

http://localhost:8080

You'll see the NGINX page.

The architecture is:

Browser
   │
   │ localhost:8080
   ↓
kubectl port-forward
   │
   ↓
Pod:80
   │
   ↓
NGINX

18. Port-forward is extremely useful#

Suppose you have:

PostgreSQL
Redis
Node.js API
Grafana
Prometheus

running inside Kubernetes.

You can temporarily access them locally.

For example:

kubectl port-forward svc/backend 3000:80

Then:

localhost:3000
       ↓
backend Service
       ↓
backend Pod

This is excellent for development and debugging.

19. But don't confuse port-forward with production networking#

kubectl port-forward is primarily a development/debugging mechanism.

Production architecture is normally:

Internet
   ↓
Load Balancer / Ingress
   ↓
Service
   ↓
Pods

Not:

Internet
   ↓
kubectl port-forward

20. Create a Deployment instead of a Pod#

Earlier we created:

kubectl run nginx --image=nginx

That's a direct Pod.

Production applications usually use:

Deployment
   ↓
ReplicaSet
   ↓
Pods

Create one:

kubectl create deployment nginx `
  --image=nginx

Check:

kubectl get deployments

Then:

kubectl get pods

21. Scale it#

Run:

kubectl scale deployment nginx --replicas=3

Check:

kubectl get pods

You'll see three Pods:

nginx-xxxxx
nginx-yyyyy
nginx-zzzzz

Architecture:

              Deployment
                  │
              ReplicaSet
          ┌───────┼───────┐
          ↓       ↓       ↓
        Pod     Pod     Pod

22. Expose the Deployment#

Create a Service:

kubectl expose deployment nginx `
  --port=80 `
  --type=NodePort

Check:

kubectl get svc

Now:

Browser
   ↓
NodePort
   ↓
Service
   ↓
┌──────┬──────┬──────┐
Pod    Pod    Pod

The Service distributes traffic across eligible Pods.

23. Your first YAML deployment#

Now let's stop using imperative commands.

Create:

deployment.yaml

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

Apply:

kubectl apply -f deployment.yaml

Check:

kubectl get deployment
kubectl get pods

24. Create the Service YAML#

Create:

service.yaml

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

Apply:

kubectl apply -f service.yaml

Check:

kubectl get svc nginx

25. Why labels matter#

Our Deployment:

labels:
  app: nginx

Service:

selector:
  app: nginx

The Service finds Pods using the label.

Pod
labels:
  app=nginx
       ↑
       │
       │ matches
       │
Service
selector:
  app=nginx

If you accidentally write:

selector:
  app: backend

the Service won't find those Pods.

Then:

Service
   ↓
No endpoints

This is one of the most common Kubernetes mistakes.

26. Check Endpoints#

Run:

kubectl get endpoints nginx

or, on modern clusters:

kubectl get endpointslices

If your Service has three ready Pods, you should see corresponding backend endpoints.

This is a great debugging technique.

27. Create a local Node.js application#

Now let's make this relevant to your stack.

Suppose your Node.js API is:

const express = require("express");
 
const app = express();
 
app.get("/", (req, res) => {
  res.json({
    message: "Hello Kubernetes"
  });
});
 
app.get("/health", (req, res) => {
  res.json({
    status: "ok"
  });
});
 
app.listen(3000, "0.0.0.0", () => {
  console.log("Server running on port 3000");
});

Notice:

app.listen(3000, "0.0.0.0")

This matters.

Inside containers, don't accidentally bind the server only to:

127.0.0.1

because then other network interfaces may not be able to reach it.

28. Dockerize it#

Dockerfile:

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

Build:

docker build -t node-api:1.0 .

Now you have:

node-api:1.0

29. Important local-cluster issue#

Here's something beginners often encounter.

You built:

node-api:1.0

on your machine.

But Kubernetes might use a container runtime/environment where that locally built image isn't automatically available in the way you expect.

Then you get:

ErrImagePull

or:

ImagePullBackOff

Why?

Kubernetes may try to pull:

node-api:1.0

from a registry.

But your image exists only locally.

30. Solutions#

You have several options.

Option 1 — Use Docker Desktop Kubernetes#

Depending on your Docker Desktop configuration, locally built images may be available to the local cluster.

This is one reason Docker Desktop is convenient for beginners.

Option 2 — Use a local registry#

You can run a local container registry:

Your machine
   │
   ├── Docker build
   │
   ↓
Local Registry
   │
   ↓
Kubernetes

Option 3 — Kind#

Kind supports workflows where images can be loaded into the cluster.

Conceptually:

docker build -t node-api:1.0 .

then:

kind load docker-image node-api:1.0

Now Kind nodes can use that image.

Option 4 — Push to a registry#

For example:

Docker Hub
ECR
GHCR
GCR/Artifact Registry
ACR

Then Kubernetes pulls it.

Production typically uses a registry.

31. Node.js Deployment#

Example:

apiVersion: apps/v1
kind: Deployment
 
metadata:
  name: node-api
 
spec:
  replicas: 2
 
  selector:
    matchLabels:
      app: node-api
 
  template:
    metadata:
      labels:
        app: node-api
 
    spec:
      containers:
        - name: node-api
          image: node-api:1.0
 
          ports:
            - containerPort: 3000
 
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
 
            limits:
              cpu: "500m"
              memory: "512Mi"
 
          readinessProbe:
            httpGet:
              path: /health
              port: 3000
 
            initialDelaySeconds: 5
            periodSeconds: 10

This combines concepts you've already learned:

Deployment
+
replicas
+
resources
+
readinessProbe

32. Node.js Service#

apiVersion: v1
kind: Service
 
metadata:
  name: node-api
 
spec:
  selector:
    app: node-api
 
  ports:
    - port: 80
      targetPort: 3000
 
  type: ClusterIP

Notice:

Service: 80
Pod:     3000

So:

node-api:80
      ↓
Pod:3000

33. Test the Node.js Service#

Because it's a ClusterIP Service, create a temporary debugging Pod:

kubectl run curl `
  --image=curlimages/curl `
  -it `
  --rm `
  --restart=Never `
  -- sh

Inside:

curl http://node-api

You should receive:

{
  "message": "Hello Kubernetes"
}

Now you've actually tested Kubernetes Service discovery.

34. Test DNS#

Inside the debug container:

nslookup node-api

You'll see the Kubernetes DNS resolve the Service.

This demonstrates:

node-api
   ↓
CoreDNS
   ↓
ClusterIP

35. Local Kubernetes project architecture#

At this point you can build:

                 Browser
                    │
                    ↓
               NodePort
                    │
                    ↓
              Frontend Service
                    │
                    ↓
              Next.js Pods
                    │
                    ↓
             Backend Service
                    │
                    ↓
              Node.js Pods
                │       │
                ↓       ↓
             Redis   PostgreSQL

And eventually:

                   Ingress
                      │
             ┌────────┴────────┐
             ↓                 ↓
        Next.js Service    API Service
             ↓                 ↓
        Next.js Pods       Node Pods
                               │
                         ┌─────┴─────┐
                         ↓           ↓
                       Redis      PostgreSQL

36. Docker Compose vs Kubernetes#

You may already know Docker Compose.

Compare:

Docker Compose#

docker-compose.yml
 
frontend
backend
redis
postgres

Kubernetes#

Deployment
Service
ConfigMap
Secret
Ingress
PVC
HPA
NetworkPolicy

Compose is usually simpler for local multi-container development.

Kubernetes is designed for orchestration and production-scale management.

37. Minikube#

Now let's understand Minikube.

Minikube is a tool that runs a local Kubernetes cluster.

Typical architecture:

Windows
   ↓
Minikube
   ↓
Kubernetes

You can check:

minikube status

Start:

minikube start

Check:

kubectl get nodes

38. Minikube dashboard#

Minikube can provide a dashboard:

minikube dashboard

This can help beginners visually understand:

Namespaces
Deployments
Pods
Services
ConfigMaps
Secrets

However, don't rely entirely on the UI.

You should become comfortable with:

kubectl

because that's what you'll use heavily in real environments.

39. Kind#

Kind means:

Kubernetes IN Docker

It runs Kubernetes nodes as containers.

Architecture:

Docker
 │
 ├── control-plane container
 ├── worker container
 └── worker container

Create:

kind create cluster

Check:

kubectl get nodes

Kind is particularly useful for:

Kubernetes testing
CI pipelines
multi-node experiments
local development

40. Docker Desktop vs Minikube vs Kind#

For your learning:

Docker Desktop
      ↓
 easiest beginning

Minikube
      ↓
 Kubernetes learning

Kind
      ↓
 multi-node/testing/CI

You don't need to install all three immediately.

Start with one.

41. Your first complete local workflow#

You should understand this entire sequence:

1. Write Node.js application
          ↓
2. Dockerfile
          ↓
3. docker build
          ↓
4. Docker image
          ↓
5. Kubernetes Deployment
          ↓
6. Pod
          ↓
7. Service
          ↓
8. port-forward / NodePort / Ingress
          ↓
9. Browser/client

And if you use a registry:

Docker image
     ↓
Container Registry
     ↓
Kubernetes
     ↓
Pod

42. Useful commands to memorize#

Cluster#

kubectl cluster-info
kubectl get nodes
kubectl get nodes -o wide

Pods#

kubectl get pods
kubectl get pods -o wide
kubectl describe pod <pod>
kubectl logs <pod>

Deployments#

kubectl get deployments
kubectl describe deployment <deployment>
kubectl scale deployment <deployment> --replicas=3

Services#

kubectl get svc
kubectl describe svc <service>

Debugging#

kubectl get events --sort-by=.lastTimestamp
kubectl exec -it <pod> -- /bin/sh

Local access#

kubectl port-forward pod/<pod> 8080:80

or:

kubectl port-forward svc/<service> 3000:80

43. Your local Kubernetes debugging workflow#

When something doesn't work:

Application not working
        ↓
kubectl get pods
        ↓
Is Pod Running?
     /       \
   NO         YES
   ↓           ↓
describe      Service?
logs             ↓
events        Endpoint?
                 ↓
              Ingress?
                 ↓
                DNS?

This connects directly to Chapter 23.

44. Important local-learning exercise 🚀#

Build this:

Node.js API
     │
     ↓
Deployment
     │
     ├── Pod 1
     └── Pod 2
     │
     ↓
Service
     │
     ↓
localhost

Requirements:

Application#

GET /

returns:

{
  "message": "Hello Kubernetes"
}

Health#

GET /health

returns:

{
  "status": "ok"
}

Kubernetes#

Use:

Deployment
2 replicas
Service
readinessProbe
resource requests
resource limits

Then access it with:

kubectl port-forward svc/node-api 3000:80

Open:

http://localhost:3000

If you can do this successfully, you've gone from:

Kubernetes theory
        ↓
Running Kubernetes application

🧠 Chapter 27 Cheat Sheet#

Docker Desktop
    ↓
Local Kubernetes
 
kubectl get nodes
    ↓
Check cluster
 
kubectl get pods
    ↓
Check workloads
 
kubectl describe
    ↓
Inspect details/events
 
kubectl logs
    ↓
Application logs
 
Deployment
    ↓
Manages Pods
 
Service
    ↓
Stable networking
 
ClusterIP
    ↓
Internal access
 
NodePort
    ↓
External node-level access
 
port-forward
    ↓
Local development/debugging
 
Ingress
    ↓
HTTP/HTTPS routing
 
Minikube
    ↓
Local Kubernetes learning
 
Kind
    ↓
Kubernetes-in-Docker / testing

The most important mental model:#

                    LOCAL PC
                       │
                    Docker
                       │
                 Kubernetes
                       │
                 Deployment
                       │
                  ReplicaSet
                       │
              ┌────────┴────────┐
              ↓                 ↓
             Pod               Pod
              │                 │
           Container         Container
              └────────┬────────┘
                       ↓
                    Service
                       ↓
                Local Client

Next → Chapter 28: Kubernetes on AWS — EKS ☁️#

This is where local Kubernetes becomes real cloud Kubernetes.

We'll cover:

What AWS EKS actually is
EKS architecture
Control plane vs worker nodes
EC2 node groups
Managed node groups
EKS networking
VPC, subnets and security groups
Load Balancer
IAM + Kubernetes RBAC
ECR + EKS
Deploying your Node.js application
HPA + Cluster Autoscaler on EKS
Production architecture
Approximate cost considerations
Complete flow:

Developer
   ↓
Docker
   ↓
ECR
   ↓
EKS
   ↓
Deployment
   ↓
Pods
   ↓
Service
   ↓
AWS Load Balancer
   ↓
Internet

1. Why run Kubernetes locally?#

2. Three popular choices#

3. Which one should you use?#

Docker Desktop Kubernetes#

4. Docker Desktop Kubernetes#

5. Verify kubectl#

6. Check your nodes#

7. Your first Kubernetes architecture#

8. Check all Pods#

9. Create your first Pod#

10. What happened internally?#

11. Inspect the Pod#

12. Check the Pod IP#

13. Create a Service#

14. Why can't your browser access it?#

15. Use NodePort locally#

16. Access it#

17. kubectl port-forward#

18. Port-forward is extremely useful#

19. But don't confuse port-forward with production networking#

20. Create a Deployment instead of a Pod#

21. Scale it#

22. Expose the Deployment#

23. Your first YAML deployment#

24. Create the Service YAML#

25. Why labels matter#

26. Check Endpoints#

27. Create a local Node.js application#

28. Dockerize it#

29. Important local-cluster issue#

30. Solutions#

Option 1 — Use Docker Desktop Kubernetes#

Option 2 — Use a local registry#

Option 3 — Kind#

Option 4 — Push to a registry#

31. Node.js Deployment#

32. Node.js Service#

33. Test the Node.js Service#

34. Test DNS#

35. Local Kubernetes project architecture#

36. Docker Compose vs Kubernetes#

Docker Compose#

Kubernetes#

37. Minikube#

38. Minikube dashboard#

39. Kind#

40. Docker Desktop vs Minikube vs Kind#

41. Your first complete local workflow#

42. Useful commands to memorize#

Cluster#

Pods#

Deployments#

Services#

Debugging#

Local access#

43. Your local Kubernetes debugging workflow#

44. Important local-learning exercise 🚀#

Application#

Health#

Kubernetes#

🧠 Chapter 27 Cheat Sheet#

The most important mental model:#

Next → Chapter 28: Kubernetes on AWS — EKS ☁️#

Finished this chapter?

1. Why run Kubernetes locally?#

2. Three popular choices#

3. Which one should you use?#

Docker Desktop Kubernetes#

4. Docker Desktop Kubernetes#

5. Verify kubectl#

6. Check your nodes#

7. Your first Kubernetes architecture#

8. Check all Pods#

9. Create your first Pod#

10. What happened internally?#

11. Inspect the Pod#

12. Check the Pod IP#

13. Create a Service#

14. Why can't your browser access it?#

15. Use NodePort locally#

17. `kubectl port-forward`#

17. `kubectl port-forward`#