Kubernetes Fundamentals

By OpsBreakFix · Last reviewed: 2026-10-23

Prerequisites

Basic Linux and container concepts; a local cluster helps.

Learning objectives

• Relate Deployments, Pods, and Services.
• Read events and prior logs.
• Diagnose restarts, image pull errors, and scheduling constraints.

Follow these lessons

1. Lesson 1: Inspect Kubernetes Pods, Deployments, and Services

   Confirm cluster context, compare desired and observed replicas, then inspect service selectors, configuration references, and endpoints. Read the before-you-begin notes, follow the diagnosis in order, and pause before any state-changing step. Record the observation that supports your next decision. If the guide does not match your system, stop and compare its official reference with your installed version.

   Practice task: use an isolated lab or read-only access to identify the target, run one diagnostic check, and write down what result would send you to the next step. Do not invent output or paste sensitive values. The lesson is complete when you can explain what the command measures and what it cannot prove.

2. Lesson 2: Troubleshoot a Kubernetes Pod that keeps restarting

   Collect events, restart count, last termination reason, previous logs, probes, and resource limits to diagnose CrashLoopBackOff. Read the before-you-begin notes, follow the diagnosis in order, and pause before any state-changing step. Record the observation that supports your next decision. If the guide does not match your system, stop and compare its official reference with your installed version.

   Practice task: use an isolated lab or read-only access to identify the target, run one diagnostic check, and write down what result would send you to the next step. Do not invent output or paste sensitive values. The lesson is complete when you can explain what the command measures and what it cannot prove.

3. Lesson 3: Troubleshoot Kubernetes ImagePullBackOff

   Check the exact image reference, registry response, pull credentials, namespace, node network, and platform compatibility. Read the before-you-begin notes, follow the diagnosis in order, and pause before any state-changing step. Record the observation that supports your next decision. If the guide does not match your system, stop and compare its official reference with your installed version.

   Practice task: use an isolated lab or read-only access to identify the target, run one diagnostic check, and write down what result would send you to the next step. Do not invent output or paste sensitive values. The lesson is complete when you can explain what the command measures and what it cannot prove.

4. Lesson 4: Troubleshoot a Kubernetes Pod stuck Pending

   Trace a Pending Pod through scheduler events, node capacity, taints, affinity, and persistent volume binding before changing its workload. Read the before-you-begin notes, follow the diagnosis in order, and pause before any state-changing step. Record the observation that supports your next decision. If the guide does not match your system, stop and compare its official reference with your installed version.

   Practice task: use an isolated lab or read-only access to identify the target, run one diagnostic check, and write down what result would send you to the next step. Do not invent output or paste sensitive values. The lesson is complete when you can explain what the command measures and what it cannot prove.

How to work through this path

Use the lessons in order, but return to an earlier topic when its prerequisite appears in a later incident. For each lesson, identify the system and account, note whether the command is read-only, and decide what evidence would change your next action. A command that returns successfully is evidence about one layer only; pair it with a second check when the guide calls for one.

1. Read the problem statement and safety note before opening a shell.
2. Run the initial inspection only on a system you are authorized to access. Capture the time and scope without collecting secrets.
3. Explain the result in your own words. If it is ambiguous, consult the linked upstream manual and inspect a second signal.
4. Practice changes in a disposable environment. State the rollback before applying the change.
5. Repeat the original check and verify the user-facing behavior before recording the lesson complete.

This is a self-paced reading sequence, not a claim of certification or supervised lab completion. The linked provider exercises have separate access, account, and cost conditions. Review them before launching any hosted environment.

Command-line warm-up

These examples come from the first lessons in this path. They are illustrative starting points; replace sample targets with values from an authorized environment. Follow each lesson’s full context rather than copying a command without reading its safety notes.

# First lesson inspection command
kubectl config current-context

# Second lesson inspection command
kubectl get nodes

Keep a learning record

For each topic, write down the question, the exact target, the command used, the observed result, and the next safe decision. Remove hostnames, usernames, addresses, tokens, and customer data before sharing notes. Revisit the official reference when a tool changes or a distribution uses a different service name. This record helps distinguish what you confirmed from what you inferred.

Stop when evidence conflicts, the action could affect a user, or you cannot state a safe rollback. Ask the environment owner to review the plan. When the path is complete, choose one lab, check its current prerequisites and pricing, and clean up only resources that you created.

Evidence checkpoints for this path

At the midpoint, revisit the objectives and choose one earlier lesson that another topic depends on. Explain how its observation narrows the next decision. For a systems path, compare the local state with a user-facing check; for a delivery path, compare the reviewed source with the artifact or resource that was actually produced. For a security path, use synthetic credentials and show where they are allowed to flow without printing their value. These checks turn a sequence of links into a practical learning plan.

At the end, write a short runbook of your own in a disposable environment: symptom, scope, two diagnostic signals, a reversible practice change, and verification. Do not copy real host information into a public repository. Ask a peer or system owner to challenge the assumptions and identify any command that could affect shared state. Keep uncertain platform-specific behavior as an open research question until the upstream documentation or environment confirms it.

Official documentation

kubernetes.io ↗

Practice and next steps

Practice on Minikube; LFS158 is a free introduction and LFS258 is a paid intermediate course.

Explore the hands-on lab directory and official training recommendations. Certification exams require separate registration and passing the applicable exam.

Use this sequence as a map, not a substitute for your organization’s procedures. Tool defaults, permissions, and platform versions vary. Check current upstream documentation before a change and record what you verified.

Checkpoint: connect the lessons

Choose two related lessons and draw the dependency between them. Write what you would inspect first, what result would change your hypothesis, and which owner controls the next action. Keep the diagram focused on names and relationships rather than secrets or production identifiers. This exercise exposes gaps in the sequence: if a later lesson assumes knowledge that an earlier one never introduces, revisit the source material and submit a correction.

Next, repeat the diagnostic exercise using an isolated lab that matches your intended environment. Record the installed tool release, the system or cluster context, and the command documentation you followed. These notes let you separate a general concept from a platform-specific behavior. Never treat a result from a local lab as evidence about a separate production system.