Part 1: Foundations

Part 1: Foundations

This section gets your local environment set up and teaches you the core tools you will use every day. By the end of Part 1 you will have k0s running, kubectl configured, Helm installed, and k9s available for day-to-day monitoring.

1.1 Prerequisites

Before starting, make sure you have the following installed:

Tool	Purpose	Install
k0s	Lightweight Kubernetes distribution	k0s.io — follow their quickstart
kubectl	CLI for interacting with the cluster	kubernetes.io/docs/tasks/tools/
Helm	Package manager for Kubernetes	helm.sh/docs/intro/install/
k9s	Terminal UI for cluster monitoring	k9scli.io
mkcert	Local CA for trusted dev certs	github.com/FiloSottile/mkcert

Tip: Install mkcert now even though you won’t use it until Part 4. Running mkcert -install early ensures your local CA root is trusted by your browser and OS.

1.2 Verify Your k0s Cluster

After installing k0s, confirm the cluster is running and kubectl can reach it:

# Check cluster status
sudo k0s status

# Export kubeconfig (adjust path if needed)
sudo k0s kubeconfig admin > ~/.kube/config
chmod 600 ~/.kube/config

# Verify connectivity
kubectl cluster-info
kubectl get nodes

You should see your node listed with status Ready. If not, check that the k0s service is running and your kubeconfig path is correct.

1.3 Your Toolkit Mental Model

These tools work together but serve different purposes:

Tool	What It Does	When You Use It
kubectl	Talks to the Kubernetes API	Scripting, one-off commands, debugging
Helm	Deploys and manages app releases	Installing, upgrading, and templating apps
k9s	TUI for browsing cluster state	Day-to-day monitoring and interactive debugging

Key relationships: Helm and kubectl both talk directly to the Kubernetes API server. Helm does not call kubectl. k9s is a visual layer over what kubectl shows you. For deploying apps, pick either Helm or raw kubectl for a given resource, not both. See Helm vs Kustomize for guidance on when to use each.

1.4 Essential kubectl Commands

These commands cover 90% of daily use:

# Viewing resources
kubectl get pods                    # list pods in current namespace
kubectl get pods -A                 # all namespaces
kubectl get deployments
kubectl get services
kubectl get ingress

# Inspecting
kubectl describe pod <name>         # detailed info
kubectl logs <pod-name>             # container logs
kubectl logs <pod-name> -f          # follow/stream logs

# Debugging
kubectl exec -it <pod> -- /bin/sh   # shell into a pod
kubectl port-forward svc/<name> 8080:80

# Understanding resources
kubectl explain deployment          # schema docs
kubectl explain pod.spec.containers # drill into fields

# Generating starter YAML
kubectl create deployment my-app --image=nginx \
  --dry-run=client -o yaml > deployment.yaml

Tip: kubectl explain is your best friend. It gives you the full spec for any Kubernetes object right in your terminal.

1.5 Namespaces

Namespaces are logical partitions within your cluster. You will use them to isolate dev, staging, and production workloads.

Note

Don’t set up namespaces yet, this is a reference. Let the .yaml files do it.

# Create namespaces for your environments
kubectl create namespace dev
kubectl create namespace staging
kubectl create namespace production

# List namespaces
kubectl get namespaces

# Set a default namespace for your session
kubectl config set-context --current --namespace=dev

---