☸ kubectl Zero-To-Hero

You don't need any Kubernetes experience. You just need:

• A terminal (Linux / macOS / WSL on Windows)
• Basic command-line comfort (cd, ls, cat)
• A cluster to practice on — pick one:

1. Fork or clone this repo to track your progress
2. Work through one day at a time — don't skip ahead
3. Run every command yourself — reading is not enough
4. Complete the checkpoint at the end of each day
5. Commit your work — push your YAML files and notes as you go

Suggested Repo Structure

kubectl-learning/
├── README.md
├── day-01/
│   └── notes.md
├── day-02/
│   └── notes.md
├── day-03/
│   ├── my-first-pod.yaml
│   └── notes.md
├── day-04/
│   ├── deployment.yaml
│   └── notes.md
...
└── day-10/
    ├── deployment.yaml
    ├── service.yaml
    ├── configmap.yaml
    ├── secret.yaml
    └── notes.md

Concepts

• Kubernetes manages containers across multiple machines. It has two parts:
  • Control plane — the brain (API server, scheduler, etcd)
  • Nodes — the workers that actually run your containers
• kubectl is a command-line tool that talks to the Kubernetes API server
• Declarative vs Imperative:
  • Imperative — "Do this now" (kubectl run, kubectl delete)
  • Declarative — "Here's what I want, make it so" (kubectl apply -f file.yaml)

Setup

# macOS
brew install kubectl

# Linux
curl -LO "https://dl.k8s.io/release/$(curl -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl && sudo mv kubectl /usr/local/bin/

# Verify
kubectl version --client

# Start a local cluster (choose one)
minikube start       # Minikube
kind create cluster  # Kind

# Verify cluster access
kubectl cluster-info
kubectl get nodes

Core Commands

# List resources
kubectl get pods
kubectl get nodes
kubectl get all

# Get more details
kubectl get pods -o wide          # shows IP, node
kubectl get pods -o yaml          # full YAML output

# Inspect a specific resource
kubectl describe pod <pod-name>   # human-readable details + events

# Understand any resource
kubectl explain pod
kubectl explain pod.spec
kubectl explain deployment.spec.template

Namespaces

Namespaces are like folders — they group and isolate resources.

kubectl get namespaces
kubectl get pods --namespace kube-system   # system pods
kubectl get pods -n kube-system            # shorthand
kubectl get pods --all-namespaces          # everything

Contexts & Clusters

A context = cluster + user + namespace. Useful when you have multiple clusters.

kubectl config view                        # see all contexts
kubectl config current-context            # which context is active
kubectl config use-context <name>         # switch context
kubectl config get-contexts               # list all contexts

What is a Pod?

• The smallest deployable unit in Kubernetes
• Wraps one or more containers that share network and storage
• Pods are ephemeral — they die and don't come back on their own
• You rarely create pods directly in production (use Deployments instead)

Pod Lifecycle

Create a Pod (Declarative YAML)

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: demo
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

# Apply the manifest
kubectl apply -f day-03/my-first-pod.yaml

# Logs & exec
kubectl logs my-pod
kubectl logs my-pod -f                    # follow live
kubectl logs my-pod --previous            # last crashed container
kubectl exec -it my-pod -- /bin/bash

# Clean up
kubectl delete pod my-pod

Why Not Just Use Pods?

Deployments solve all of this. A ReplicaSet ensures N copies of a pod always run; a Deployment manages ReplicaSets and handles updates.

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

# Scale
kubectl scale deployment my-app --replicas=5

# Rolling update
kubectl set image deployment/my-app nginx=nginx:1.26
kubectl rollout status deployment/my-app
kubectl rollout history deployment/my-app

# Rollback
kubectl rollout undo deployment/my-app
kubectl rollout undo deployment/my-app --to-revision=1

Pods have IP addresses, but they change when pods restart. You need a stable endpoint to reach your app — that's what a Service is.

Service Types

apiVersion: v1
kind: Service
metadata:
  name: my-app-svc
spec:
  selector:
    app: my-app        # matches pods with this label
  ports:
  - port: 80           # service port
    targetPort: 80     # container port
  type: NodePort

kubectl apply -f day-05/service.yaml

# On Minikube
minikube service my-app-svc --url

# Port-forward (works on any cluster)
kubectl port-forward svc/my-app-svc 8080:80
# Open http://localhost:8080

ConfigMaps

Store non-sensitive config (URLs, feature flags, settings).

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_ENV: "production"
  LOG_LEVEL: "info"
  DATABASE_URL: "postgres://db-service:5432/mydb"

Secrets

Store sensitive data (passwords, tokens, API keys). Values are base64-encoded — but can be encrypted at rest.

kubectl create secret generic db-secret \
  --from-literal=DB_PASSWORD=supersecret \
  --from-literal=API_KEY=myapikey123

# Decode a value
kubectl get secret db-secret -o jsonpath='{.data.DB_PASSWORD}' | base64 -d

Use Config in a Deployment

env:
- name: APP_ENV
  valueFrom:
    configMapKeyRef:
      name: app-config
      key: APP_ENV
- name: DB_PASSWORD
  valueFrom:
    secretKeyRef:
      name: db-secret
      key: DB_PASSWORD

The Debug Workflow

1. kubectl get pods           → Is the pod running?
2. kubectl describe pod       → What events happened?
3. kubectl logs               → What did the app say?
4. kubectl exec               → Can I get inside?

Common Problems

# Watch pods in real time
kubectl get pods -w

# Get events for the whole namespace
kubectl get events --sort-by=.lastTimestamp

# Run a temporary debug pod
kubectl run debug --image=busybox --rm -it --restart=Never -- sh

# Check resource usage (requires metrics-server)
kubectl top pods
kubectl top nodes

The 4 Top-Level Fields

apiVersion: apps/v1   # API group + version
kind: Deployment      # resource type
metadata:             # name, namespace, labels, annotations
  name: my-app
  namespace: default
  labels:
    app: my-app
    env: production
  annotations:
    description: "My production app"
spec:                 # desired state — differs per resource type
  ...

Labels vs Annotations

Resource Requests & Limits

resources:
  requests:          # minimum guaranteed
    cpu: "100m"      # 100 millicores = 0.1 CPU
    memory: "128Mi"
  limits:            # maximum allowed
    cpu: "500m"
    memory: "256Mi"

Liveness & Readiness Probes

livenessProbe:       # if this fails → restart container
  httpGet:
    path: /healthz
    port: 80
  initialDelaySeconds: 10
  periodSeconds: 5
readinessProbe:      # if this fails → remove from Service endpoints
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 3

# Dry run — validate without applying
kubectl apply -f my-file.yaml --dry-run=client
kubectl apply -f my-file.yaml --dry-run=server

# See what would change
kubectl diff -f my-file.yaml

# Create namespaces
kubectl create namespace dev
kubectl create namespace staging
kubectl create namespace production

# Deploy to a specific namespace
kubectl apply -f deployment.yaml -n dev
kubectl apply -f deployment.yaml -n staging

# View resources per namespace
kubectl get all -n dev

Context Switching

kubectl config get-contexts
kubectl config use-context my-prod-cluster
kubectl config set-context --current --namespace=dev
kubectl config rename-context old-name new-name

What You'll Build

nginx (web server)
  ├── Deployment (3 replicas)
  ├── Service (NodePort)
  ├── ConfigMap (app settings)
  └── Secret (fake API key)

Step 1 — Create the Namespace

kubectl create namespace mini-project

Step 2 — Apply All Manifests

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  APP_NAME: "My kubectl App"
  LOG_LEVEL: "info"

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  API_KEY: bXlzZWNyZXRrZXkxMjM=   # base64 of "mysecretkey123"

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
        env:
        - name: APP_NAME
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: APP_NAME
        - name: API_KEY
          valueFrom:
            secretKeyRef:
              name: app-secret
              key: API_KEY
        resources:
          requests:
            cpu: "100m"
            memory: "64Mi"
          limits:
            cpu: "200m"
            memory: "128Mi"
        readinessProbe:
          httpGet:
            path: /
            port: 80
          initialDelaySeconds: 5
          periodSeconds: 5

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

Step 3 — Verify & Access

kubectl apply -f day-10/ -n mini-project
kubectl get all -n mini-project
kubectl port-forward svc/my-app-svc 8080:80 -n mini-project
curl http://localhost:8080

Step 4 — Rolling Update

kubectl set image deployment/my-app nginx=nginx:1.26 -n mini-project
kubectl rollout status deployment/my-app -n mini-project

Step 5 — Break It & Debug It

# Set a bad image
kubectl set image deployment/my-app nginx=nginx:thisdoesnotexist -n mini-project

# Debug
kubectl get pods -n mini-project
kubectl describe pod <pod-name> -n mini-project

# Roll back
kubectl rollout undo deployment/my-app -n mini-project
kubectl rollout status deployment/my-app -n mini-project

• Confident with kubectl in daily use
• Understand Kubernetes primitives: Pod, Deployment, Service, ConfigMap, Secret
• Debug real production issues systematically
• Manage apps across multiple environments
• Write clean, production-ready YAML
• Ready for real Kubernetes work