Kubernetes is a control system. You say, for example, run 3 replicas of this API image, expose them using a Service, only send traffic to ready Pods, and restart unhealthy containers. Kubernetes keeps watching the cluster and reacts when actual state differs from desired state. If a Pod dies, a controller creates a replacement. If you scale to 5 replicas, the scheduler places new Pods on nodes. If a rollout fails, you can inspect events, logs, and rollout status.

A good learning order is Docker first, Docker Compose second, Kubernetes third. Kubernetes uses container images, so image and container knowledge still matters. A real team may use Docker to build an image, Compose to run local API plus database, CI to push the image to a registry, and Kubernetes to run it in dev, QA, and production clusters. Kubernetes has more objects because it solves more operational problems than docker run or Compose.

The control plane exposes the API, stores state, schedules Pods, and runs controllers. Worker nodes run kubelet, kube-proxy, runtime, and Pods. Troubleshooting often means knowing which layer failed: API access, scheduling, node readiness, runtime, or networking.

API server is the front door. etcd stores state. Scheduler chooses nodes. Controller manager runs reconciliation loops. Cloud controller integrates with cloud provider resources. Managed Kubernetes hides some operations, but the concepts still matter.

Every Kubernetes object change goes through the API server. Authentication, authorization, schema validation, and admission happen there. Controllers, scheduler, and kubelets watch the API server. If kubectl says forbidden, invalid, or connection refused, think API path.

The API server normally talks to etcd; users do not edit etcd directly. In self-managed clusters, etcd backup and restore are critical. Secrets may be stored in etcd, so encryption at rest and access control matter.

The scheduler considers resource requests, node selectors, affinity, taints, tolerations, volumes, and other constraints. Pending Pods often mean scheduling failed, not app code failed.

A Deployment controller ensures desired replicas exist. A Job controller ensures tasks complete. Node controllers watch node health. This is why a deleted Pod managed by Deployment comes back.

kubelet receives Pod specs assigned to the node and ensures containers run. The container runtime starts containers. kube-proxy helps implement Service networking. Node health affects scheduling and Pod availability.

Many accidents happen because kubectl points to the wrong cluster or namespace. Always check current context before applying important changes. Namespaces are logical areas inside a cluster.

apiVersion selects API version. kind says resource type. metadata names and labels the object. spec describes what you want. status is written by Kubernetes to show what actually happened. Store manifests in Git for repeatability.

Production teams prefer YAML stored in Git because changes are reviewable and repeatable. kubectl diff shows changes before apply. Generated YAML from dry-run can help students start manifests.

Namespaces organize resources and support scoped RBAC, quotas, and policies. They are not strong security by themselves, but they become useful with RBAC, NetworkPolicy, and quotas.

A Service selector must match Pod labels to send traffic. Deployment selectors must match template labels to manage Pods. Annotations are for tool metadata, not selection.

A Pod has one IP and is scheduled to one node. Containers in the same Pod can share localhost and volumes. In production, Pods are usually created by Deployments or other controllers because standalone Pods are not self-healing.

Sidecars are used for logging, proxying, service mesh, config reloaders, and helper tasks. Do not put unrelated services together just to reduce YAML. If services scale independently, use separate workloads.

Init containers run sequentially. Each must finish successfully. They are useful for setup, validation, or waiting logic, but not for long-running services. If an init container fails, the app container never starts.

ReplicaSets use label selectors. Deployments create new ReplicaSets during rollouts. You should understand ReplicaSet to understand Deployment behavior, but usually create Deployments directly.

A Deployment defines replicas, selector, and Pod template. It supports scaling, rolling updates, rollback, and self-healing. It is best for stateless workloads where replicas are interchangeable.

Rolling updates use maxUnavailable and maxSurge to control rollout speed. Readiness probes are important because Kubernetes should not send traffic to an unready Pod. Rollback helps recover, but it must be planned with database changes and image tags.

StatefulSet Pods get predictable names like db-0 and db-1. They can use volumeClaimTemplates to create stable PVCs. StatefulSet helps with mechanics but does not replace database backup, replication, or administration.

Log collectors, monitoring agents, CNI components, and security agents often use DaemonSets. When a new node joins, the DaemonSet can create a Pod there. DaemonSets may need tolerations or special permissions, so security review matters.

Jobs are for batch or one-time tasks. CronJobs are scheduled tasks. Design jobs to be idempotent if possible. Consider retries, concurrency, missed schedules, and cleanup history.

Services select Pods using labels and route traffic to ready endpoints. Types include ClusterIP, NodePort, LoadBalancer, and ExternalName. A Service with no matching Pods has no endpoints.

ClusterIP gives a stable internal virtual IP and DNS name. It is usually the right choice for backend APIs, databases, and internal services.

NodePort is simple but exposes node ports. LoadBalancer is common in cloud clusters. For many HTTP apps, Ingress or Gateway is often better than one LoadBalancer per app.

If a Service selector matches Pods, Kubernetes creates EndpointSlices. Empty endpoints usually mean label mismatch or Pods not ready. EndpointSlices are very useful for troubleshooting Service failures.

You need an Ingress Controller to implement Ingress. Ingress can route by host/path and terminate TLS depending on controller. Annotations are often controller-specific.

Controller choice matters: NGINX, cloud provider, Traefik, HAProxy, etc. Gateway API separates infrastructure and app routing with GatewayClass, Gateway, and route resources. Learn Ingress first, then Gateway API.

CoreDNS commonly provides DNS. Service names work inside the cluster, such as api or api.default.svc.cluster.local. DNS failures can break apps even when Pods are running.

ConfigMaps decouple non-secret config from images. Pods can consume them as environment variables, command arguments, or mounted files. Do not store passwords in ConfigMaps.

Secrets reduce exposure but are not magic. Access must be restricted with RBAC, and production clusters often use encryption at rest or external secret managers. Base64 is not the same as strong encryption.

Kubernetes env values can be direct, from ConfigMaps, from Secrets, or from Pod fields. Document required env vars. Large config files may be better as mounted ConfigMaps.

Volumes are defined at Pod level and mounted into containers. emptyDir is temporary. ConfigMap and Secret volumes expose files. PVC volumes connect to persistent storage. Not every volume is persistent.

This separates app needs from storage implementation. StorageClass can dynamically provision cloud disks or other storage. Deleting PVC may delete or retain underlying storage depending on policy. Always understand data lifecycle.

Readiness controls Service traffic. Liveness restarts stuck containers. Startup protects slow-starting apps from early liveness failure. Bad probes can cause outages, so design health endpoints carefully.

CPU can be throttled at limits. Memory over limit can cause OOMKilled. Requests that are too high cause Pending. No requests can cause noisy-neighbor problems. Tune using metrics.

HPA needs metrics and usually resource requests. Apps must be horizontally scalable. Set min/max replicas and test behavior under load. Autoscaling does not fix slow code or database bottlenecks.

nodeSelector is simple required matching. Affinity is more expressive. Anti-affinity can spread replicas across nodes or zones for availability. Too many strict rules can leave Pods Pending.

Toleration does not force placement, it only allows it. Combine toleration with nodeSelector/affinity for dedicated nodes. Effects include NoSchedule, PreferNoSchedule, and NoExecute.

Use dedicated ServiceAccounts for workloads that access the Kubernetes API. Connect permissions with RBAC. Avoid giving powerful permissions to default ServiceAccount.

Role is namespace-scoped. ClusterRole is cluster-scoped or reusable. RoleBinding grants in a namespace. ClusterRoleBinding grants cluster-wide. Verbs include get, list, create, update, delete.

Policies select Pods by labels and define allowed ingress/egress. If a Pod is selected for a direction, traffic not allowed is denied. DNS must often be allowed explicitly.

Restricted policies encourage non-root, no privileged mode, limited capabilities, and safer defaults. Apply policies carefully with audit/warn before enforce in important namespaces.

Quota prevents one namespace from using all CPU, memory, Pods, Services, or PVCs. LimitRange can set default requests/limits. These policies may block Pod creation if requests are missing or quota is exceeded.

Charts contain templates and values. Values differ by environment. Helm tracks releases and supports upgrade/rollback. Learn raw Kubernetes YAML first so Helm templates make sense.

A base contains common manifests. Overlays patch replicas, images, labels, namespaces, or config for dev/prod. kubectl apply -k can apply a kustomization directory.

Use get for status, describe for details/events, logs for container output, events for timeline, top for metrics, and exec for inside-container checks. Pending Pods need events; CrashLoopBackOff needs logs; Service failures need endpoints.

Pending often means scheduling/volume constraints. CrashLoopBackOff means container starts then crashes. ImagePullBackOff means image cannot be pulled. Use describe for Pending/image issues and logs for crashes.

Check Pods ready, Service selector, EndpointSlices, port/targetPort, DNS, Ingress controller, Ingress rules, TLS, and backend Service. Debug from inside the cluster before blaming external DNS.

Create deployment.yaml and service.yaml. Add labels, replicas, readiness probe, resources, and versioned image tag. README should include apply, verify, logs, scale, update, rollback, and cleanup.

Build API + database. API reads ConfigMap/Secret. Database uses PVC. Service connects components. Ingress exposes HTTP. Add README architecture, commands, screenshots, troubleshooting, and cleanup.

Use this answer format: definition, why it matters, real example, command/YAML, common mistake, troubleshooting. Prepare examples for Pod states, Service endpoints, rollouts, ConfigMaps/Secrets, PVC Pending, RBAC forbidden, and Ingress routing.