Level 1 Operational Track

Your Kubernetes Experience

Kubernetes Core Concepts & Headlamp Local Setup

Duration: 2 Weeks (10 Days)

20–30 Mins / Day • 5 Days / Week

Objective: Establish local Minikube/Kind, master primitives (Pods, Deployments, Services, ConfigMaps, Namespaces), and run Headlamp Desktop & In-Cluster.

Headlamp v1.25.15 • Cluster: dev-cluster

Context: minikube / in-cluster A

Navigation

• Home

Cluster

Namespaces

Nodes

Custom Resources

• Workloads (Deployments & Pods)

• Configuration & Storage

+ Create

Nodes

Headlamp interactive hardware & condition inspector

Filter: 1-1 of 1 Ready: 100%

NAME	CPU LOAD	MEMORY	STATUS	ROLES	VERSION
minikube-control-plane	24% (2 Cores)	38% (3.2 GiB)	Ready	control-plane	v1.28.3

$ kubectl apply -f https://raw.githubusercontent.com/headlamp-k8s/headlamp/main/autogen-artifacts/headlamp-k8s.yaml

In-Cluster Sync

Time Allocation Formula

Daily Schedule Structure (Days 1–10)

Each day consists of two synchronized learning phases designed to build both theoretical knowledge and muscle memory.

5-10m

Micro-Concept & Architecture Breakdown

Deconstruct Kubernetes internal control plane mechanics, API schemas, isolation patterns, and Headlamp architectural contracts before executing commands.

15-20m

5-Step Hands-on Drill

Execute exactly 5 progressive operational tasks switching between terminal CLI and Headlamp visual inspection to cross-validate results.

Curriculum Drills

10-Day Hands-on Learning Path

Comprehensive step-by-step drills covering local clusters, web deployment, declarative YAML, storage, and authentication.

DAY 1

Local Cluster Provisioning & Headlamp Desktop Setup

20–30 Mins

Micro-Concept: Headlamp Desktop runs natively on your workstation and automatically parses cluster credentials and contexts from your local ~/.kube/config file.

5-Step Hands-on Drill:

1. Provision local cluster

minikube start --driver=docker Alternative: kind create cluster --name dev-cluster

2. Verify CLI control plane

kubectl cluster-info && kubectl get nodes

3. Launch Headlamp Desktop

Open Headlamp Desktop application and select your active cluster context from the top navigation dropdown.

4. Inspect Node details

Navigate to Cluster > Nodes in Headlamp to review CPU, memory capacity, conditions, and kernel versions.

5. Cross-verify with CLI

kubectl describe node

Compare the hardware capacity and status conditions with the visual metrics displayed in Headlamp.

DAY 2

In-Cluster Headlamp Deployment & Web UI Navigation

20–30 Mins

Micro-Concept: In-cluster Headlamp runs as a Deployment inside the Kubernetes cluster, providing centralized browser access without needing desktop client installations.

5-Step Hands-on Drill:

1. Deploy test workload

kubectl create deployment demo-web --image=nginx:alpine --replicas=3

2. Deploy Headlamp in-cluster

kubectl apply -f https://raw.githubusercontent.com/headlamp-k8s/headlamp/main/autogen-artifacts/headlamp-k8s.yaml

3. Establish port-forward

kubectl port-forward -n headlamp service/headlamp 8080:80

4. Access Web UI

Open http://localhost:8080 in your browser and locate the demo-web Deployment under Workloads > Deployments.

5. Scale workload via UI

Increase replicas from 3 to 5 directly in Headlamp UI, then verify in your terminal via kubectl get pods -w.

DAY 3

Namespaces & Resource Scoping

20–30 Mins

Micro-Concept: Namespaces partition cluster resources logically. Headlamp provides global or single-namespace views depending on user access rights.

5-Step Hands-on Drill:

1. Create isolation boundary: Run kubectl create namespace dev-team and kubectl create namespace staging-team.

2. Deploy isolated workloads: Run kubectl create deployment app-v1 --image=redis:alpine -n dev-team and kubectl create deployment app-v1 --image=memcached:alpine -n staging-team.

3. Filter in Headlamp UI: Use the Namespace Selector dropdown in the top navigation bar of Headlamp to isolate dev-team.

4. Verify isolation: Confirm that only Redis pods appear under the filtered namespace view.

5. CLI verification: Run kubectl get pods -A and match the cross-namespace output against Headlamp's All Namespaces view.

DAY 4

Declarative YAML Management & Headlamp Editor

20–30 Mins

Micro-Concept: Kubernetes objects are managed declaratively using structured YAML manifests. Headlamp contains an inline YAML editor for immediate visual diffing and updating.

5-Step Hands-on Drill:

1. Generate manifest: Create web-pod.yaml via imperative dry-run:
kubectl run static-web --image=nginx:latest --dry-run=client -o yaml > web-pod.yaml

2. Apply manifest: Run kubectl apply -f web-pod.yaml.

3. Edit via Headlamp: Open static-web Pod in Headlamp UI, click Edit, add label environment: staging, and save changes.

4. Verify live update: Check pod labels in terminal via kubectl get pod static-web --show-labels.

5. Inspect Event Stream: View the Events section in Headlamp to trace the Pulled, Created, and Started lifecycle milestones.

DAY 5

Pod Lifecycle, Logs & Live Diagnostics

20–30 Mins

Micro-Concept: Pods transition through Pending, Running, Succeeded, or Failed phases. Diagnostic visibility requires streaming stdout/stderr logs and inspecting status conditions.

5-Step Hands-on Drill:

1. Deploy logging app: Run:
kubectl run log-producer --image=busybox -- sh -c "while true; do echo 'Processing batch task...'; sleep 2; done"

2. Stream logs in CLI: Execute kubectl logs -f log-producer.

3. Stream logs in Headlamp: Select log-producer under Workloads > Pods in Headlamp, click Logs, and test the auto-scroll and log filter features.

4. Simulate container crash: Deploy a broken pod: kubectl run failing-pod --image=invalid-image-name.

5. Diagnose via UI: Observe the ImagePullBackOff status in Headlamp UI, inspect the Pod's Events tab to locate the missing image error, and delete the pod using the UI trash icon.

DAY 6

Deployments, Rolling Updates & Rollbacks

20–30 Mins

Micro-Concept: Deployments provide declarative updates for Pods via ReplicaSets, enabling zero-downtime rolling updates and rollbacks.

5-Step Hands-on Drill:

1. Deploy initial version: Run kubectl create deployment web-app --image=nginx:1.21 --replicas=4.

2. Perform rolling update: Update image to nginx:1.25 via CLI: kubectl set image deployment/web-app nginx=nginx:1.25.

3. Track rollout in Headlamp: Watch the old ReplicaSet scale down while the new ReplicaSet scales up under Workloads > Deployments > web-app.

4. Trigger deliberate failure: Set image to non-existent tag nginx:badtag.

5. Rollback via CLI: Identify the stall in Headlamp, then run kubectl rollout undo deployment/web-app and verify recovery in the UI.

DAY 7

ClusterIP & NodePort Networking

20–30 Mins

Micro-Concept: Services route internal and external network traffic to dynamic Pod IP addresses using selector labels.

5-Step Hands-on Drill:

1. Expose deployment internally: Run kubectl expose deployment web-app --port=80 --targetport=80 --type=ClusterIP --name=web-internal.

2. Inspect endpoints: Check active endpoints in Headlamp UI under Network > Services > web-internal.

3. Test internal DNS: Launch temporary curl pod: kubectl run test-curl --rm -it --image=curlimages/curl -- curl http://web-internal.

4. Change Service type: Convert service to NodePort: kubectl patch svc web-internal -p '{"spec": {"type": "NodePort"}}'.

5. UI & CLI verification: Obtain NodePort assignment using kubectl get svc web-internal and verify the assigned port is reflected in Headlamp's Service details page.

DAY 8

ConfigMaps & Environment Variable Injection

20–30 Mins

Micro-Concept: ConfigMaps separate environment configuration from container images, making applications portable across environments.

5-Step Hands-on Drill:

1. Create ConfigMap: Run kubectl create configmap app-config --from-literal=APP_COLOR=blue --from-literal=LOG_LEVEL=debug.

2. Inspect in Headlamp: Navigate to Config > ConfigMaps in Headlamp UI and select app-config to view key-value pairs.

3. Inject into Pod: Apply a Pod referencing app-config:

apiVersion: v1
kind: Pod
metadata:
  name: config-demo
spec:
  containers:
    - name: web
      image: nginx:alpine
      envFrom:
        - configMapRef:
            name: app-config

4. Verify execution environment: Run kubectl exec config-demo -- printenv | grep APP_COLOR.

5. Update ConfigMap: Edit app-config in Headlamp UI to change APP_COLOR to green.

DAY 9

Storage Primitives — PVs, PVCs, and Storage Classes

20–30 Mins

Micro-Concept: PersistentVolumeClaims (PVCs) request durable storage assets provisioned dynamically by cluster StorageClasses.

5-Step Hands-on Drill:

1. Request dynamic storage: Save and apply pvc.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

2. Inspect binding status: View data-pvc status in Headlamp under Storage > PersistentVolumeClaims.

3. Attach PVC to Pod: Create pod storage-pod mounting data-pvc at /usr/share/nginx/html.

4. Verify PV binding: Confirm the dynamically provisioned PersistentVolume (PV) details in Headlamp UI.

5. Write test data: Execute kubectl exec storage-pod -- sh -c "echo 'Headlamp Storage Test' > /usr/share/nginx/html/index.html" and verify file retention across pod restarts.

DAY 10

Headlamp Authentication & ServiceAccount Tokens

20–30 Mins

Micro-Concept: When running in-cluster, Headlamp enforces Kubernetes RBAC by authenticating user sessions via bearer tokens.

5-Step Hands-on Drill:

1. Create admin ServiceAccount: Run kubectl create serviceaccount headlamp-admin -n kube-system.

2. Bind cluster permissions:

kubectl create clusterrolebinding headlamp-admin-binding --clusterrole=cluster-admin --serviceaccount=kube-system:headlamp-admin

3. Generate Bearer Token: kubectl create token headlamp-admin -n kube-system --duration=24h

4. Authenticate in Web UI: Open Headlamp browser window (http://localhost:8080), paste the token into the login screen, and submit.

5. Confirm access level: Verify full read/write visibility across all namespaces in Headlamp.

Knowledge Check

Level 1 Checkpoint Quiz

Validate your understanding of local setup, in-cluster routing, and troubleshooting.

1 How does Headlamp Desktop determine which cluster to connect to upon launch? ↓

Answer: It automatically checks the default location ~/.kube/config (or the KUBECONFIG environment variable) for available context definitions.

2 What is the key difference between running Headlamp as a Desktop App versus In-Cluster? ↓

Answer: Desktop App runs locally on the user's workstation using local kubeconfig files. In-Cluster runs inside the Kubernetes cluster as a Deployment/Service, accessed through a web browser and authenticated via RBAC tokens.

3 If a Pod is stuck in ImagePullBackOff, where in Headlamp UI do you locate the exact diagnostic error message? ↓

Answer: Under the Pod details view in the Events tab, which lists container runtime messages (e.g., Failed to pull image: manifest unknown).

4 Why is kubectl port-forward used during local testing of in-cluster Headlamp deployments? ↓

Answer: It forwards a local port from your workstation to the Headlamp Service port inside the cluster without requiring external LoadBalancers or Ingress controllers.

5 What Kubernetes primitive must be created alongside a ClusterRoleBinding to generate a login token for Headlamp in-cluster access? ↓

Answer: A ServiceAccount.

Graduation Checkpoint

Level 1 Graduation Exam

Comprehensive hands-on validation scenario required before progressing to Level 2.

Real-World Operational Scenario

"You must provision a local Minikube/Kind cluster, install Headlamp in-cluster, set up a token-authenticated ServiceAccount, deploy a 2-tier application (Nginx frontend + Redis backend), and verify application health and event streams exclusively through Headlamp UI."

Required Artifacts & Deliverables

Interactive Checklist

1. Cluster Provisioning Running Minikube or Kind cluster verified via kubectl get nodes.

2. In-Cluster UI Deployment Deployed Headlamp installation accessible locally on http://localhost:8080 via port-forwarding.

3. Authentication Setup Working headlamp-admin ServiceAccount bearer token successfully generated and authorized.

4. Target Namespace & Workload Deployments Isolated namespace: production containing:

App 1: frontend-nginx (3 replicas, port 80)
App 2: backend-redis (1 replica, port 6379)

5. UI Operations & Verification Confirm health status, view logs, and monitor event streams exclusively inside the Headlamp web interface.

Progress: 0 of 5 tasks verified

✓

PASS CRITERIA

Headlamp web UI opens cleanly in browser and accepts the generated ServiceAccount token.
All workloads inside the production namespace report Running status with zero container crashes.
Scaling and log inspection tasks can be executed fluidly from both Headlamp UI and kubectl.

FAIL CONDITIONS

Inability to establish port-forward or log into Headlamp UI.
Invalid RBAC bindings preventing Headlamp from reading cluster resources.
Misconfigured pod specifications causing CrashLoopBackOff or ErrImagePull states.