Kubernetes Fundamentals
Core model
Kubernetes is a declarative system: you submit desired state to the API server, and controllers continuously reconcile actual state toward it. The control plane consists of the kube-apiserver (the only component that talks to etcd and the front door for all clients), etcd (the consistent key-value store holding cluster state), the kube-scheduler (binds unscheduled Pods to Nodes), and the controller-manager (runs reconciliation loops). Nodes run the kubelet (ensures containers described in PodSpecs are running), a container runtime, and kube-proxy or an equivalent dataplane for Service networking.
Objects to know
Understand Pods as the smallest deployable unit, ReplicaSets for replica count, Deployments for rolling updates and rollback, StatefulSets for stable identity, DaemonSets for one Pod per Node, Jobs/CronJobs for run-to-completion work, and Services for stable virtual IPs and load balancing. Labels and selectors connect objects; annotations hold non-identifying metadata. ConfigMaps and Secrets inject configuration, and Namespaces provide scope and quota boundaries.
Traps
Questions often imply the kubelet is a control-plane component (it is not), that the scheduler starts containers (it only binds Pods), or that etcd stores application data (it stores cluster state). Remember that a Service selects Pods by label, not by name, and that ClusterIP, NodePort, LoadBalancer, and ExternalName behave differently.
Rule of thumb
If a question asks “who ensures the desired number of Pods exists?”, answer the controller-manager/ReplicaSet controller, not the scheduler. If it asks “who talks to the container runtime on a Node?”, answer the kubelet.