Skip to content

kubectl Essentials and Workflows

Overview

Operate a cluster with declarative kubectl apply, inspect objects, stream logs, and exec for debugging — without guessing flags under pressure.

Prefer apply + Git over imperative create for anything lasting. Imperative commands are fine for labs and break-glass.

This is a core tutorial in Module 2 · Cluster Setup of the REBASH Academy Kubernetes for Cloud & DevOps Engineers series — written for Cloud, DevOps, Platform, and SRE engineers.

Prerequisites

Learning Objectives

By the end of this tutorial, you will be able to:

  • get, describe, apply, delete
  • logs, exec, port-forward
  • Use -n / contexts safely
  • Dry-run client/server

Architecture

This topic’s control points and relationships are shown below.

Control plane path

Theory

What it is

kubectl is how DevOps engineers inspect and change cluster state day to day. It speaks the Kubernetes API: create or update objects, read status, stream logs, open a shell in a container, and forward ports for local debugging. Mastery is less about memorising every flag and more about a reliable workflow under pressure.

Why it matters

Incidents are won by disciplined inspection: Events before guesswork, describe before delete-and-recreate, declarative apply before snowflake imperative edits. Teams that standardise on Git + kubectl apply (or GitOps) reduce configuration drift. Imperative commands remain useful for labs and break-glass fixes.

How it works (mental model)

Prefer a loop:

  1. Orient — kubectl config current-context, kubectl get ns, confirm the right place.
  2. List — get with labels and namespaces (-n, -A, -l).
  3. Explain — describe for Events and conditions; get -o yaml for full object.
  4. Change — edit manifests, apply -f, watch rollout; use --dry-run=client|server to preview.
  5. Observe — logs, exec, port-forward for live behaviour.

Server-side apply and field managers matter in advanced teams; for this course, treat apply as “merge this desired state into the API”.

Key concepts / comparisons

Task Command pattern
List kubectl get pods -A
Detail kubectl describe pod NAME
Apply kubectl apply -f app.yaml
Logs kubectl logs deploy/NAME -f
Shell kubectl exec -it POD -- sh
Local port kubectl port-forward svc/NAME 8080:80
Preview kubectl apply --dry-run=server -f app.yaml
Style When
Declarative (apply -f) Anything that should last
Imperative (create, run, expose) Labs, exploration, emergencies

Common pitfalls

  • Forgetting -n and operating in default while the app lives elsewhere.
  • Using kubectl edit on live objects with no Git record — drift accumulates.
  • Relying on logs alone; CrashLoop often needs logs --previous and Events.
  • port-forward is a debug tunnel, not a production exposure path.
  • Running delete without confirming selectors — label mistakes wipe the wrong workloads.

Hands-on Lab

Create a workspace for this tutorial.

mkdir -p ~/rebash-k8s/module-02-kubectl && cd ~/rebash-k8s/module-02-kubectl

Focus: Practise everyday kubectl workflows: get, describe, logs, exec, apply

Step 1 – Apply a manifest and explore resources

kubectl create namespace rebash-lab
cat > app.yaml <<'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: tools
  namespace: rebash-lab
  labels:
    app: tools
spec:
  containers:
  - name: tools
    image: busybox:1.36
    command: ["sleep", "3600"]
EOF
kubectl apply -f app.yaml
kubectl -n rebash-lab get pods -l app=tools -o wide
kubectl -n rebash-lab describe pod tools | head -n 30

Step 2 – Logs, exec, and output formats

kubectl -n rebash-lab exec tools -- uname -a
kubectl -n rebash-lab get pod tools -o yaml | head -n 20
kubectl -n rebash-lab get pod tools -o jsonpath='{.status.phase}{"
"}'
kubectl api-resources | head -n 15

Final step – Cleanup note

kubectl delete namespace rebash-lab --ignore-not-found
# Workspace kept for notes; remove with: rm -rf "$(pwd)" when finished

Validation

  • Lab commands run under ~/rebash-k8s/module-02-kubectl/
  • You can explain each Theory section in your own words
  • You used modern tooling where it applies to this topic
  • You can describe one production failure mode for this topic

Code Walkthrough

Production practice for kubectl Essentials and Workflows always combines:

  1. Inspect before you change (status, plan, logs, dry-run)
  2. Prefer reversible, documented changes (Git, IaC, drop-ins, version pins)
  3. Capture evidence (command output, pipeline logs) for handovers
  4. Prefer current tools and APIs over legacy shortcuts
  5. Least privilege — escalate credentials only when required

Keep runbooks short enough to follow under pressure. Automate checks; keep humans for judgement.

Security Considerations

  • Treat credentials and tokens for kubernetes as privileged — never commit them
  • Prefer short-lived auth (OIDC, roles, SSO) over long-lived keys
  • Validate blast radius before apply/deploy/delete operations
  • Restrict who can approve production changes
  • Collect audit logs; limit who can read sensitive traces

Common Mistakes

Forgetting -n and operating in default while the app lives elsewhere.

Validate assumptions against the Theory section and official docs before changing production.

Using kubectl edit on live objects with no Git record — drift accumulates.

Lab shortcuts (open security groups, admin roles, skip approvals) must not ship unchanged.

Changing production without a rollback path

Always know how to revert (previous artefact, prior release, state rollback, DNS failback).

Best Practices

  • Encode kubectl Essentials and Workflows changes as code and review them in pull requests
  • Pin versions (images, modules, actions, provider plugins)
  • Separate environments with clear promotion gates
  • Alert on symptoms with runbooks attached
  • Destroy lab resources; tag everything with owner and expiry where possible

Troubleshooting

Symptom Likely cause Fix
Auth / permission denied Wrong identity, policy, or scope Check caller identity, roles, and least-privilege policies
Timeout / no route Network, DNS, security group, or endpoint Trace path, DNS, and allow-lists before retrying
Drift / unexpected plan Manual change or wrong state/workspace Reconcile desired vs actual; avoid click-ops on managed resources
Pipeline/job red Flaky step, cache, or missing secret Read failing step logs; bisect recent workflow/config changes
Cost spike Idle load balancer, NAT, oversized compute Inventory billable resources; stop/delete labs promptly

Summary

kubectl Essentials and Workflows is essential for Cloud and DevOps engineers working with kubernetes. Practise the lab until the inspection and change path is muscle memory, then continue the track.

Interview Questions

  1. What is the difference between imperative kubectl run and declarative kubectl apply?
  2. When should you use kubectl describe versus kubectl logs?
  3. How do labels and selectors help day-to-day operations?
  4. Why is applying manifests from version control safer than one-off imperative edits?
  5. What does --dry-run=client help you validate?

Sample answer — question 2

describe shows object state, events, and configuration; logs show container stdout/stderr. Use describe for scheduling and probe issues, logs for application errors.

Sample answer — question 4

Git-backed manifests give review, history, and repeatable environments. Imperative edits drift from documented intent and are hard to audit after incidents.

References