Kubernetes Cheatsheet: kubectl, Pods, Services and Helm
By DevShelfHub
Kubernetes (k8s) is the industry-standard container orchestration platform: you describe desired state in YAML, the control plane reconciles reality. This cheatsheet covers the daily kubectl surface, workload controllers, Services, Ingress, ConfigMaps, Secrets, volumes, health probes, RBAC, and Helm 3 — from first cluster to production ops.
98 items
◷ 8 min
kubectl
Deploy
Helm
Kubernetes (k8s) is an open-source container orchestration platform originally designed at Google and donated to the CNCF in 2014. It solves the problem of running containerised workloads at scale: instead of manually placing containers on servers, you describe the desired state of your application in YAML manifests and Kubernetes continuously reconciles the cluster toward that state. This declarative model — say what you want, not how to achieve it — is the conceptual foundation for everything else in k8s.
The cluster has two logical layers: the control plane (API server, etcd, scheduler, controller manager) and worker nodes where containers actually run. Every interaction goes through the API server — kubectl is simply a CLI wrapper around REST calls to that API. The smallest deployable unit is a Pod (one or more containers sharing a network namespace), but in practice you manage Pods through higher-level controllers: Deployments for stateless apps, StatefulSets for databases, DaemonSets for node-level agents, and Jobs for batch work.
Traffic routing uses Services (stable virtual IPs that load-balance across Pod replicas) and Ingress resources for HTTP hostname/path routing. Configuration is injected via ConfigMaps and Secrets — never baked into images. Helm 3 is the de facto package manager: a chart bundles all manifests for an application and values.yaml controls environment-specific overrides. This cheatsheet covers the daily kubectl surface, workload specs, networking primitives, storage, RBAC, and Helm — everything you need from first cluster to production.
Snippets target k8s 1.30+. The big shifts vs early-k8s: PodSecurityAdmission
replaces PSP; apps/v1 is the only stable workload API;
networking.k8s.io/v1 for Ingress;
storage.k8s.io/v1 for StorageClasses. Docker shim is gone —
containerd / CRI-O underneath.
install · contextsSetup
bash
# Install
brew install kubectl helm kind kustomize
brew install --cask docker # docker desktop has built-in single-node cluster
# Spin up a local cluster
kind create cluster --name dev
# or
minikube start --driver=docker
# Connect to a remote cluster
kubectl config view
kubectl config get-contexts
kubectl config use-context my-prod-cluster
kubectl config set-context --current --namespace=team-a
# Sanity check
kubectl cluster-info
kubectl get nodes -o wide
kubectl version --short
# Useful aliases
alias k=kubectl
alias kgp='kubectl get pods'
alias kdp='kubectl describe pod'
alias klog='kubectl logs -f --tail=200'
the daily CLIkubectl
kubectl get pods,svc,deploy
Multi-kind list.
kubectl get pods -A
All namespaces.
kubectl get pods -o wide
Includes node + IP.
kubectl get pods -o yaml / -o json
Full object body.
kubectl get pods --selector app=api
Label selector. -l short form.
kubectl describe pod NAME
Events, status, container details.
kubectl logs POD / -c container / --previous
Latest / pick a container / previous crashed instance.
kubectl exec -it POD -- bash
Shell inside the pod.
kubectl port-forward svc/api 8080:80
Tunnel to a service locally.
kubectl apply -f file.yaml / -k dir/
Declarative apply. Kustomize with -k.
kubectl delete -f file.yaml
Delete what the file declares.
kubectl rollout status / restart / undo deploy/api
Deployment lifecycle.
kubectl scale deploy/api --replicas=5
Manual scale.
kubectl top pod / node
Resource usage (needs metrics-server).
kubectl explain pod.spec.containers.resources
Field-level reference from the cluster.
kubectl get pods -w
Watch for changes.
kubectl debug node/N -it --image=alpine
Privileged debug pod on a node.
smallest deployable unitPods
apiVersion: v1, kind: Pod
Direct pod — mostly for debugging. Use Deployments in prod.
spec.containers[]
One or more containers, sharing network + volumes.
spec.initContainers[]
Run-to-completion before main containers. Migrations, file fetches.
spec.restartPolicy
Always (default) / OnFailure / Never.
spec.nodeSelector / affinity / tolerations
Where the pod is allowed to run.
spec.serviceAccountName
RBAC identity inside the cluster.
spec.securityContext / runAsNonRoot
Drop privileges. Required under restricted PSA.
spec.terminationGracePeriodSeconds
Wait between SIGTERM and SIGKILL on shutdown.
Sidecar containers (1.29+)
restartPolicy: Always on an init container. Native sidecar.
managed podsDeployments
apps/v1 Deployment
Preferred for long-running stateless services.
spec.replicas
Desired pod count. Pair with HPA for auto-scaling.
spec.strategy.type: RollingUpdate
Default. maxUnavailable / maxSurge tune the window.
spec.strategy.type: Recreate
Kill all old before new. For singleton / DB-style.
Always set requests + limits.
Without requests the scheduler can’t place pods correctly; without limits one pod can starve the
node. Set both, then iterate from observed P95 usage.
Readiness gates traffic, liveness restarts.
A common misuse: pointing liveness at /healthz that also depends on the DB.
A DB blip = kill-loop on every pod. Liveness should be cheap and process-local.
Use kubectl apply --server-side.
Tracks field ownership cleanly across teams + controllers. Avoids the “last apply wins, fields silently
vanish” class of bug.
Common trapsWatch out for
Selector / label drift on Services.
Service shows zero endpoints, traffic 503s. Either the deployment labels changed or the service selector
did. Compare kubectl get pods --show-labels with kubectl describe svc.
ConfigMap / Secret changes don’t restart pods.
Pods read the value at mount time. Bounce pods (kubectl rollout restart)
or use a controller that watches the configmap (Reloader).
OOMKilled isn’t logged loudly.kubectl describe pod shows it as a status code. Set memory requests
generously; observe P95 RSS for a week before tightening.
Kubernetes (k8s) is an open-source container orchestration platform that automates deployment, scaling, and management of containerised applications. It groups containers into Pods and manages them across a cluster of nodes. Kubernetes handles load balancing, self-healing, rolling updates, and secret management out of the box.
What is the difference between a Pod and a Deployment in Kubernetes?
A Pod is the smallest deployable unit in Kubernetes — one or more containers that share a network namespace and storage. A Deployment wraps Pods in a replication controller that maintains a desired replica count, performs rolling updates, and handles rollbacks. You almost never create Pods directly; use a Deployment, StatefulSet, or DaemonSet instead.
How do I expose a Kubernetes service externally?
Create a Service of type LoadBalancer to provision a cloud load balancer, or use NodePort to expose a port on every cluster node. For HTTP/HTTPS traffic, an Ingress resource with an ingress controller (NGINX, Traefik) routes domain names and paths to backend Services, avoiding the need for a load balancer per service.
What are ConfigMaps and Secrets in Kubernetes?
ConfigMaps store non-sensitive configuration as key-value pairs and can be mounted as environment variables or files inside a Pod. Secrets store sensitive data (passwords, API keys, TLS certs) in base64-encoded form and follow the same mounting patterns. For production, back Secrets with an external vault (AWS Secrets Manager, HashiCorp Vault) rather than etcd storage.
What is Helm in Kubernetes?
Helm is the package manager for Kubernetes. A Helm chart bundles all the Kubernetes manifests (Deployments, Services, ConfigMaps, etc.) for an application along with a values.yaml file that controls configuration. Install a chart with helm install, upgrade with helm upgrade, and manage releases with helm list and helm rollback.