Your Kubernetes Experience

Multi-Level Learning Roadmap: transition from Linux/Docker fundamentals to a professional Kubernetes and Headlamp operator.

Explore 4-Level Roadmap or

20–30 mins/day • 5 days/week

Modes covered: Desktop App (Local Kubeconfig) & In-Cluster Web Deployment.

Headlamp v1.25.15 • Cluster: design-test-cluster

Active Context: minikube A

Navigation

Cluster Overview

• Namespaces

• Nodes (Active Drill)

• Workloads (Pods/Deployments)

• Security & RBAC

+ Create Manifest

Cluster Nodes

Headlamp visual metrics & capacity inspector

Filter: 1-1 of 1 Ready: 100%

NAME	CPU LOAD	MEMORY	STATUS	ROLES	VERSION
dev-cluster-control-plane	28% (2 Cores)	44% (3.8 GiB)	Ready	control-plane	v1.28.3

$ kubectl get nodes -o wide

Synchronized with Headlamp UI

Curriculum Architecture

Four Progressive Operator Levels

Structured trajectory from local development to production enterprise extension

LEVEL 1 2 WEEKS

Core & Setup

Kubernetes Core Concepts & Headlamp Local Setup

10 Days • 20-30 min/day

LEVEL 2 3 WEEKS

Workloads & UI

Cluster Management, Workloads & UI Navigation

15 Days • 20-30 min/day

LEVEL 3 3 WEEKS

RBAC & Multi-Cluster

RBAC, Security & Multi-Cluster Management

15 Days • 20-30 min/day

LEVEL 4 4 WEEKS

Plugins & Enterprise

Advanced Plugin Development & Enterprise Operations

20 Days • 20-30 min/day

Level 1: Kubernetes Core Concepts & Headlamp Local Setup

Foundation Stage • Duration: 2 Weeks (10 Days)

20–30 Mins / Day

Objective

Master core Kubernetes primitives (Pods, Services, Deployments) and configure Headlamp across its two core deployment modes.

Headlamp Focus

Headlamp is an extensible Kubernetes web UI designed to combine standard resource listing with enhanced operational functionality. It runs in two distinct modes: as a desktop application (using local kubeconfig files) or deployed in-cluster (accessed via a web browser).

เปิดแผน Level 1 →

Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Day 8 Day 9 Day 10

Level 2: Cluster Management, Workloads & Headlamp UI Navigation

Operational Stage • Duration: 3 Weeks (15 Days)

20–30 Mins / Day

Objective

Deploy, manage, and troubleshoot containerized workloads using kubectl alongside the Headlamp UI.

Headlamp Focus

Resource inspection, viewing Pod logs/events, scaling workloads directly from the UI, and continuous health monitoring.

Level 3: RBAC, Security & Multi-Cluster Management

Security & Fleet Stage • Duration: 3 Weeks (15 Days)

20–30 Mins / Day

Objective

Configure Kubernetes Role-Based Access Control (RBAC), secure cluster access, and manage multi-cluster environments with unified access control.

Headlamp Focus

Authenticating to Headlamp via bearer tokens and kubeconfig contexts, scoping user permissions in the UI, and managing multi-cluster views seamlessly.

Level 4: Advanced Headlamp Plugin Development & Enterprise Operations

Extensibility Stage • Duration: 4 Weeks (20 Days)

20–30 Mins / Day

Objective

Extend Headlamp functionality and integrate it into enterprise platform workflows.

Headlamp Focus

Building custom UI plugins using Headlamp's plugin architecture (React/TypeScript), customizing resource views, and managing enterprise deployments.

Time Allocation Formula

Daily Routine Structure

Optimized for busy engineers with sustainable 20–30 minute daily sessions.

Part 1 5–10 Mins

Micro-Concept & Architecture Breakdown

Review Kubernetes internal mechanisms, declarative control loops, API resource schemas, or Headlamp architectural contracts before jumping into code.

Focus: Mental models & architectural rationale

Part 2 15–20 Mins

Hands-on Drills

Execute exactly 5 targeted steps or operational tasks switching between terminal CLI commands and Headlamp's visual interface.

Focus: Muscle memory with 5 progressive tasks

Practical Scenarios

Sample Daily Drills

Two foundational drills showing dual-channel mastery via CLI and Headlamp UI.

DAY 1

Local Cluster & Headlamp Desktop

Setup & Discovery

Micro-Concept: Headlamp Desktop runs locally on your workstation and automatically reads cluster credentials from your local kubeconfig file (~/.kube/config).

5 Targeted Steps:

Provision cluster

minikube start --driver=docker or kind create cluster --name dev-cluster

Verify CLI connectivity

kubectl cluster-info && kubectl get nodes

Launch Headlamp Desktop

Open the Headlamp desktop application and verify it detects your active kubeconfig context.

Inspect Node details

Navigate to the Nodes section in Headlamp UI to view CPU/memory capacity and status.

Cross-verify with CLI

kubectl describe node

Compare terminal output against visual metrics shown in Headlamp.

Status: Ready for Day 1 ✓ 20 Mins

DAY 2

In-Cluster Headlamp & Workload Inspection

Web Deployment

Micro-Concept: In-cluster Headlamp runs as a deployment within the Kubernetes cluster and serves the web UI directly to browser clients.

5 Targeted Steps:

Deploy test workload

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

Deploy Headlamp in-cluster

Apply official Headlamp in-cluster manifest or Helm chart to your cluster.

Access Headlamp UI

kubectl port-forward -n headlamp service/headlamp 8080:80 Open http://localhost:8080 in your browser.

Examine Pods in UI

Locate the demo-web deployment in Headlamp, view individual pod statuses, and inspect container logs.

Scale workload via UI

Use Headlamp UI to scale demo-web to 5 replicas, then verify via CLI with kubectl get pods.

Status: Ready for Day 2 ✓ 20 Mins

Self Assessment

Weekly Review Quiz

Validate operational understanding for Levels 1 & 2 across 10 scenarios.

1 Scenario 1: Headlamp Desktop fails to connect to your cluster upon launching. What default file location does it inspect for cluster contexts? ↓

Answer: It checks the user's default kubeconfig file located at ~/.kube/config on Linux/macOS or %USERPROFILE%\.kube\config on Windows, or the file path defined in the KUBECONFIG environment variable.

2 Scenario 2: You need to deploy Headlamp for a central team where users log in via a web URL rather than running local apps. Which deployment model must you use? ↓

Answer: The In-Cluster deployment model. In this mode, Headlamp is deployed as a Kubernetes Deployment/Service/Ingress inside the cluster and accessed directly via standard web browsers.

3 Scenario 3: A pod enters a CrashLoopBackOff state. What steps do you take in Headlamp UI to view container stdout logs and failure events? ↓

Answer: Click on Workloads → Pods, select the crashing Pod name to open its detail page, scroll to the Events table to inspect backoff reasons, and click the terminal/logs icon on the container section to read stdout/stderr logs.

4 Scenario 4: What key design feature distinguishes Headlamp from traditional, static Kubernetes web dashboards? ↓

Answer: Its plugin architecture and extensibility. Developers can write modular React/TypeScript plugins to introduce brand new views, customize menus, and integrate proprietary internal tools directly into the UI.

5 Scenario 5: A user needs read-only access to view workloads in Headlamp. Which two Kubernetes RBAC resources are required to grant this? ↓

Answer: A ClusterRole (or Role) defining read permissions (e.g. verbs ["get", "list", "watch"]) and a corresponding ClusterRoleBinding (or RoleBinding) mapping the user/ServiceAccount to that role.

6 Scenario 6: How does Headlamp Desktop switch between multiple Kubernetes clusters? ↓

Answer: Headlamp reads all configured cluster contexts from your kubeconfig and displays a cluster selector menu in the top bar, allowing one-click instant context switching without restarting the app.

7 Scenario 7: When you edit a Deployment replica count in the Headlamp UI, what API call is dispatched to the Kubernetes API server? ↓

Answer: A HTTP PATCH or PUT request to the /apis/apps/v1/namespaces/{ns}/deployments/{name}/scale subresource or workload spec modifying spec.replicas.

8 Scenario 8: What primary frontend technology stack is used to write Headlamp plugins? ↓

Answer: React and TypeScript, utilizing Headlamp's official plugin SDK (@kinvolk/headlamp-plugin) along with Material UI components.

9 Scenario 9: A Service is configured with Type: ClusterIP. Why can you not open its IP address directly in an external web browser? ↓

Answer: ClusterIP allocates a virtual internal IP routable solely within the Kubernetes internal cluster network. External clients require an Ingress, LoadBalancer, NodePort, or kubectl port-forward.

10 Scenario 10: Where can you join official community discussions and seek help regarding Headlamp development? ↓

Answer: The #headlamp channel on the official Kubernetes Slack (kubernetes.slack.com), GitHub Issues under kubernetes-sigs/headlamp, and the Monthly Community Meetings on Zoom.

Milestone Checkpoint

Level 1 & 2 Graduation Exam

Comprehensive hands-on qualification before progressing to RBAC and Plugin development.

Real-World Operational Scenario

"You are tasked with deploying a multi-tier application stack (frontend Deployment and backend Service), installing Headlamp in-cluster, configuring a dedicated ServiceAccount with bearer token access, and verifying workload health via Headlamp UI."

Execution Tasks

5 Interactive Tasks

1. Cluster Verification Confirm a local Minikube or Kind cluster is active via kubectl get nodes.

2. Headlamp In-Cluster Installation Deploy Headlamp to the cluster and expose it locally via port-forwarding (kubectl port-forward -n headlamp service/headlamp 8080:80).

3. Authentication Setup Create a headlamp-admin ServiceAccount and generate a bearer token for secure web UI login.

4. Workload Deployment Deploy a 3-replica Nginx frontend deployment and an Apache backend service in the target namespace.

5. UI Operations & Troubleshooting Log into Headlamp UI using the generated token, inspect pod logs, simulate a pod crash (kubectl delete pod), and verify automatic pod recovery on the UI dashboard.

Progress: 0 of 5 completed

✓

PASS CRITERIA

Headlamp in-cluster deployment is running cleanly and accessible via browser.
ServiceAccount authentication successfully grants authenticated UI access.
All workloads, container logs, and lifecycle events are visible and manageable within Headlamp UI.

FAIL CONDITIONS

Headlamp cannot communicate with the Kubernetes API server.
Invalid RBAC token setup prevents UI login authentication.
Unable to inspect live logs or perform replica scaling actions from the UI dashboard.

Tip: Always test token generation with kubectl create token headlamp-admin on Kubernetes 1.24+ rather than manually searching secrets.