Kubernetes Cheat Sheet

Updated 2026-07-16

Next Topic: KubeVirt Virtual Machines on Kubernetes Cheat Sheet

🎯Take a practice test on this topic6 practice tests · 206 questions→

🧠Study flashcards on this topic143 cards · spaced repetition→

Kubernetes is an open-source container orchestration platform originally developed by Google, now governed by the Cloud Native Computing Foundation. It automates the deployment, scaling, and management of containerized applications across clusters of machines, abstracting infrastructure complexity while maintaining declarative configuration and self-healing capabilities. Understanding Kubernetes requires recognizing that everything is managed through declarative YAML manifests describing desired state. The system continuously reconciles actual state to match, creating resilient distributed systems that can scale from development laptops to planet-scale infrastructure.

What This Cheat Sheet Covers

This topic spans 18 focused tables and 156 indexed concepts, 143 flashcards, 6 practice tests with 206 questions. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core Architecture ComponentsTable 2: Workload ResourcesTable 3: Networking and Service DiscoveryTable 4: Configuration and Secrets ManagementTable 5: Storage and PersistenceTable 6: Scheduling and PlacementTable 7: Autoscaling and Resource ManagementTable 8: Health Checks and ProbesTable 9: Security and Access ControlTable 10: kubectl CommandsTable 11: Namespaces and Resource IsolationTable 12: Advanced Workload PatternsTable 13: Configuration Management ToolsTable 14: Deployment StrategiesTable 15: Observability and MonitoringTable 16: Container Network Interface (CNI)Table 17: Service MeshTable 18: Best Practices and Patterns

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Core Architecture Components

Every Kubernetes cluster splits into a control plane that makes decisions and worker nodes that run your containers. The pieces below are that split in practice: the API server as the single front door, etcd as the store behind it, the scheduler and controllers that push the cluster toward the state you asked for, and the kubelet and kube-proxy doing the work on each node. One rule ties it all together and explains most debugging: only the API server talks to etcd, and everything else goes through the API server.

Component	Example	Description
kube-apiserver	`kubectl get pods`	• Front door of the control plane: exposes the Kubernetes API and authenticates, authorizes, and admission-checks every request before it is persisted • the only component that reads and writes etcd, so every other component goes through it.
etcd	Stores cluster state	• Consistent, highly-available key-value store holding all cluster data: objects, configuration, and Secrets • the cluster's source of truth, so an etcd snapshot is a full backup of cluster state and needs the same protection as one.
kube-scheduler	Assigns pods to nodes	• Picks a node for each pod that has none, filtering on resources and constraints, then scoring the survivors • only writes a binding through the API server; the node's kubelet is what pulls images and starts containers.
kube-controller-manager	Runs controllers	• Runs the built-in control loops (node, Job, EndpointSlice, ServiceAccount and more), each driving current state toward desired state • all compiled into a single binary and run as one process • controllers act by calling the API server, never by contacting nodes.
kubelet	Runs on worker nodes	• Primary node agent: takes PodSpecs from the API server and makes sure those containers are running and healthy • reports node and pod status back to the control plane, and ignores any container Kubernetes did not create.
kube-proxy	Maintains Service rules	• Programs each node's kernel rules for Service traffic, in iptables, nftables (GA in v1.33), or IPVS mode • packets are matched and forwarded by the kernel, not through the kube-proxy process.
Container runtime	`containerd`, `CRI-O`	• Runs the containers: pulls images and manages container lifecycle on the node • speaks the Container Runtime Interface (CRI) over gRPC, with the kubelet as the client • takes any OCI image, including ones built by `docker build`.
cloud-controller-manager	Manages cloud resources	• Runs the cloud-specific control loops (node, route, and service controllers) against your provider's APIs • keeps cloud logic out of core Kubernetes; a bare-metal cluster has none, which is why `type: LoadBalancer` stays pending there.
Lease	`coordination.k8s.io/v1` `kind: Lease`	• Lightweight coordination object used for node heartbeats and leader election • kubelet renews its node Lease every 10 seconds, far cheaper than writing full node status • HA control plane components hold a Lease so only one is active at a time.

Table 2: Workload Resources

You rarely create a bare Pod. Instead you pick the controller that matches how your app behaves: Deployments for stateless services, StatefulSets for databases that need stable identity and storage, DaemonSets for one pod on every node, and Jobs or CronJobs for work that runs to completion. Keep the ownership chain in mind as you read: a Deployment manages ReplicaSets, ReplicaSets manage Pods, and the kubelet restarts the containers inside them.

Resource	Example	Description
Pod	`apiVersion: v1` `kind: Pod`	• Smallest deployable unit, one or more containers sharing one network namespace, one IP, and storage • containers inside reach each other on `localhost` and are always co-scheduled on a single node • typically created through higher-level controllers, not directly.

The rest of this section is part of the full cheat sheet

Table 3: Networking and Service Discovery

Pods are replaced constantly and get new IPs each time, so a Service gives your workload one address that stays put. The types form a ladder: ClusterIP for traffic inside the cluster, NodePort and LoadBalancer to let the outside in, and Ingress or the newer Gateway API for HTTP routing by host and path. Network Policies sit alongside them and decide which pods are allowed to talk at all.

Type	Example	Description
ClusterIP	`type: ClusterIP` `port: 80`	• Default service type, exposes the service on an internal cluster IP • only reachable within the cluster • the IP is virtual: kube-proxy picks a backend pod per connection, so keep-alive, HTTP/2, and gRPC clients pin to one pod.

The rest of this section is part of the full cheat sheet

Table 4: Configuration and Secrets Management

Good Kubernetes practice keeps configuration out of your container images, so the same image runs in dev, staging, and prod. ConfigMaps hold the non-sensitive settings and Secrets hold the credentials, and both can reach a container as environment variables or as mounted files. Watch the two traps that bite everyone: a Secret is base64-encoded rather than encrypted, and an environment variable is fixed when the container starts.

Resource	Example	Description
ConfigMap	`data:` `app.conf: "key=value"`	• Stores non-sensitive configuration as key-value pairs or files • consumed as environment variables, command-line arguments, or mounted volumes • the Pod and the ConfigMap must be in the same namespace.

The rest of this section is part of the full cheat sheet

Table 1: Core Architecture Components

Component	Example	Description
kube-apiserver	`kubectl get pods`	• Front door of the control plane: exposes the Kubernetes API and authenticates, authorizes, and admission-checks every request before it is persisted • the only component that reads and writes etcd, so every other component goes through it.
etcd	Stores cluster state	• Consistent, highly-available key-value store holding all cluster data: objects, configuration, and Secrets • the cluster's source of truth, so an etcd snapshot is a full backup of cluster state and needs the same protection as one.
kube-scheduler	Assigns pods to nodes	• Picks a node for each pod that has none, filtering on resources and constraints, then scoring the survivors • only writes a binding through the API server; the node's kubelet is what pulls images and starts containers.
kube-controller-manager	Runs controllers	• Runs the built-in control loops (node, Job, EndpointSlice, ServiceAccount and more), each driving current state toward desired state • all compiled into a single binary and run as one process • controllers act by calling the API server, never by contacting nodes.
kubelet	Runs on worker nodes	• Primary node agent: takes PodSpecs from the API server and makes sure those containers are running and healthy • reports node and pod status back to the control plane, and ignores any container Kubernetes did not create.
kube-proxy	Maintains Service rules	• Programs each node's kernel rules for Service traffic, in iptables, nftables (GA in v1.33), or IPVS mode • packets are matched and forwarded by the kernel, not through the kube-proxy process.
Container runtime	`containerd`, `CRI-O`	• Runs the containers: pulls images and manages container lifecycle on the node • speaks the Container Runtime Interface (CRI) over gRPC, with the kubelet as the client • takes any OCI image, including ones built by `docker build`.
cloud-controller-manager	Manages cloud resources	• Runs the cloud-specific control loops (node, route, and service controllers) against your provider's APIs • keeps cloud logic out of core Kubernetes; a bare-metal cluster has none, which is why `type: LoadBalancer` stays pending there.
Lease	`coordination.k8s.io/v1` `kind: Lease`	• Lightweight coordination object used for node heartbeats and leader election • kubelet renews its node Lease every 10 seconds, far cheaper than writing full node status • HA control plane components hold a Lease so only one is active at a time.

Table 2: Workload Resources

Resource	Example	Description
Pod	`apiVersion: v1` `kind: Pod`	• Smallest deployable unit, one or more containers sharing one network namespace, one IP, and storage • containers inside reach each other on `localhost` and are always co-scheduled on a single node • typically created through higher-level controllers, not directly.

Table 3: Networking and Service Discovery

Type	Example	Description
ClusterIP	`type: ClusterIP` `port: 80`	• Default service type, exposes the service on an internal cluster IP • only reachable within the cluster • the IP is virtual: kube-proxy picks a backend pod per connection, so keep-alive, HTTP/2, and gRPC clients pin to one pod.

Table 4: Configuration and Secrets Management

Resource	Example	Description
ConfigMap	`data:` `app.conf: "key=value"`	• Stores non-sensitive configuration as key-value pairs or files • consumed as environment variables, command-line arguments, or mounted volumes • the Pod and the ConfigMap must be in the same namespace.