Kubernetes is a platform for running containerized applications across a cluster of computers. This cheat sheet helps students connect the main Kubernetes objects to the jobs they perform, such as scheduling, networking, scaling, and updating apps. It is useful because Kubernetes has many parts, and clear relationships make troubleshooting and exam review easier.
The core idea is that users describe the desired state of an application, and Kubernetes works to keep the actual state matching it. Pods run containers, Deployments manage repeated Pods, and Services provide stable network access. Commands such as kubectl get pods, kubectl apply -f file.yaml, and kubectl describe service name help inspect and manage resources.
Key Facts
- A cluster is a set of machines that run Kubernetes, with a control plane managing worker nodes.
- The control plane includes the API server, scheduler, controller manager, and etcd database.
- A node is a worker machine that runs Pods using components such as kubelet, kube-proxy, and a container runtime.
- A Pod is the smallest deployable Kubernetes unit and can contain one or more tightly connected containers.
- A Deployment manages replicated Pods and supports rolling updates using the relationship Deployment -> ReplicaSet -> Pods.
- A Service gives Pods a stable network name and IP, even when the actual Pods are replaced.
- A ConfigMap stores nonsecret configuration data, while a Secret stores sensitive values such as passwords or tokens.
- The command kubectl apply -f file.yaml creates or updates Kubernetes resources from a YAML file.
Vocabulary
- Cluster
- A group of machines managed by Kubernetes to run containerized applications.
- Control Plane
- The set of Kubernetes components that makes scheduling decisions and maintains the desired state of the cluster.
- Node
- A worker machine in a Kubernetes cluster that runs Pods and reports its status to the control plane.
- Pod
- The smallest Kubernetes object that can run containers, usually representing one instance of an application.
- Deployment
- A Kubernetes object that manages replicas of an application and updates Pods safely over time.
- Service
- A Kubernetes object that provides stable networking access to a changing set of Pods.
Common Mistakes to Avoid
- Confusing Pods with containers is wrong because a Pod is a Kubernetes wrapper that may contain one or more containers.
- Deleting a Pod managed by a Deployment does not permanently remove the app because the Deployment will usually create a replacement Pod.
- Using a Pod IP for long-term communication is wrong because Pod IPs can change when Pods restart or are replaced.
- Putting passwords in a ConfigMap is unsafe because ConfigMaps are meant for nonsecret configuration data, not sensitive credentials.
- Assuming kubectl create and kubectl apply are always the same is incorrect because apply updates resources declaratively from the saved configuration.
Practice Questions
- 1 A Deployment is configured with replicas: 4. One Pod crashes and is deleted. How many replacement Pods should Kubernetes create?
- 2 A Service routes traffic to 3 healthy Pods. If a rolling update temporarily creates 2 new Pods while 3 old Pods still exist, how many Pods might receive traffic if all 5 match the Service selector?
- 3 Write the kubectl command to display all Pods in the current namespace.
- 4 Explain why a web app should usually be exposed through a Service instead of having users connect directly to individual Pod IP addresses.
Understanding Kubernetes Concepts Reference
Kubernetes behaves like a collection of control loops. A controller watches information stored through the API and compares it with the rules in a resource definition. If a running application differs from those rules, the controller takes action.
For example, if a machine fails and some application copies disappear, the ReplicaSet controller notices fewer copies than required and requests replacements. The scheduler then chooses suitable machines for the new Pods. This separation of jobs is important.
One part decides that a Pod is needed, while another part decides where it can run. Students should see YAML files as structured instructions, not as scripts that run line by line.
Labels are a major connection between Kubernetes objects. A label is a small piece of identifying data, such as an app name, version, or environment. Selectors use labels to find matching objects.
A Deployment uses selectors to know which Pods it manages. A Service uses selectors to send traffic to the right Pods. This makes labels powerful but risky.
If labels and selectors do not match exactly, a Service can have no usable endpoints even though Pods appear healthy. In a school project, this can look like a web app is running but cannot be reached. Checking labels is often faster than searching through application code.
Each Pod can request CPU and memory. A request tells the scheduler the minimum capacity that should be available on a node. A limit sets a maximum amount the container may use.
These settings affect reliability because a node cannot safely accept unlimited work. If a container tries to use more memory than its limit, Kubernetes may stop it. CPU limits usually slow a container rather than stopping it.
Health checks matter too. A readiness probe tells Kubernetes when a Pod can receive network traffic.
A liveness probe tells Kubernetes when a stuck container should be restarted. Poorly chosen probes can cause restart loops, so they need enough time for an application to start normally.
Updates and troubleshooting become clearer when students follow the path of a request. A user reaches a Service name. The Service selects ready Pod endpoints.
The request reaches one selected Pod, where the container process handles it. A failure can occur at any point along this path. Useful checks include the current resource status, event messages, container logs, and the selector labels.
Configuration should stay separate from container images so the same image can run in testing or production with different settings. Secrets need extra care because encoding is not the same as encryption.
Teams should limit who can read them, avoid placing them in public repositories, and rotate exposed passwords or tokens. Namespaces and permissions help separate projects and reduce accidental changes in shared clusters.