Core & Control Plane Knowledge

The kube-apiserver is the central control-plane component that exposes the Kubernetes API. kubectl, controllers, scheduler, admission webhooks, and kubelets all communicate through it. If the API server is unavailable, normal cluster management is unavailable even if existing workloads keep running.

kubectl sends the object to the API server. The API server authenticates the request, authorizes it, runs admission, validates schema, and stores desired state in etcd. Controllers notice desired state, the scheduler binds unscheduled Pods to nodes, and the kubelet on the chosen node asks the container runtime to start containers and report status.

The scheduler assigns unscheduled Pods to nodes. It filters and scores nodes using resource requests, taints and tolerations, node selectors, affinity, topology spread, volume constraints, and scheduling policy. It writes the binding back through the API server.

The scheduler is the first place to think. Check kubectl describe pod for scheduling events such as insufficient CPU, insufficient memory, taints without tolerations, node affinity mismatch, PVC binding problems, or topology spread constraints. If no events appear, verify scheduler health.

etcd is the distributed key-value store that holds Kubernetes cluster state. It stores objects such as Pods, Deployments, Secrets, ConfigMaps, RBAC rules, node status, and controller state. If etcd is lost or corrupted without a good snapshot, the cluster state is effectively lost.

Use etcdctl v3 with the local etcd endpoint and certificates: ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-snap.db --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --key=/etc/kubernetes/pki/etcd/server.key. Verify the snapshot file exists and protect it like sensitive cluster data.

Use TLS certificates for client and peer traffic, restrict access to port 2379, limit host access, enable encryption at rest for Secrets, monitor etcd health, and take regular tested snapshots. etcd access is cluster-admin-level access in practice.

The kubelet manages Pods on a node: it watches assigned Pods, starts containers through the runtime, mounts volumes, runs probes, and reports node and Pod status. kube-proxy manages Service networking rules, or delegates that behavior depending on the dataplane, so traffic can reach Service backends.

A static Pod is managed directly by the kubelet from a manifest on the node, commonly under /etc/kubernetes/manifests/. Control-plane components in kubeadm clusters often run this way. The kubelet mirrors static Pods into the API server so they are visible with kubectl.

Place a Pod manifest in the kubelet static manifest path, usually /etc/kubernetes/manifests/static-nginx.yaml. The manifest can be: apiVersion: v1; kind: Pod; metadata: {name: static-nginx}; spec: {containers: [{name: nginx, image: nginx}]}. The kubelet should create it automatically.

A Pod CIDR is the IP range assigned for Pods, often per node. It must line up with the CNI configuration and cluster networking design. If Pod CIDRs, node routes, or CNI settings disagree, Pod-to-Pod routing breaks.

Apply the provider manifest or Helm chart that matches the cluster design. For example, a Calico install may use kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml, but production clusters should pin a reviewed version and verify the current install docs.

Common causes include kubelet crash or misconfiguration, CNI failure, container runtime failure, disk pressure, memory pressure, certificate expiration, network partition, DNS or routing issues, and inability to reach the API server. Start with node conditions, events, kubelet logs, and CNI/runtime health.

Use journalctl -u kubelet -f to follow live logs, or journalctl -u kubelet --since '30 minutes ago' for a recent window. Kubelet logs are key for node registration, static Pods, volume mounts, runtime errors, CNI setup, and certificate issues.

kubeadm bootstraps Kubernetes clusters using sensible defaults. It initializes control-plane nodes, creates certificates and kubeconfigs, configures static Pod manifests for control-plane components, and generates join commands for workers.

Use kubectl cluster-info for API and core service endpoints, and kubectl get nodes -o wide for node state. kubectl get componentstatuses exists in some environments but is deprecated and not a complete health signal; prefer component logs, health endpoints, and managed control-plane status where available.

A DaemonSet runs one Pod on every matching node, or every node in a selected group. It is used for node-local agents such as log collectors, CNI components, storage plugins, monitoring agents, and security scanners.

Check version skew and release notes, back up etcd or managed state, upgrade kubeadm where applicable, run kubeadm upgrade plan, apply the control-plane upgrade, then upgrade kubelet and kubectl. For worker nodes, drain one node or node pool at a time, upgrade components, restart kubelet, validate, then uncordon.

Use kubectl drain node01 --ignore-daemonsets --delete-emptydir-data when it is acceptable to evict Pods using emptyDir. Always check PodDisruptionBudgets, local data, replacement capacity, and critical workloads before draining.

Cordoning marks a node unschedulable so new Pods do not land there. Draining cordons the node and evicts existing evictable Pods so maintenance can proceed. DaemonSet Pods are ignored by normal drain behavior because their controller expects them on the node.

Use kubectl uncordon node01 after validating kubelet, runtime, CNI, CSI, node conditions, and any maintenance work. Then watch that new Pods can schedule and become Ready.

The controller-manager runs many controllers, including the Node controller, Deployment controller, ReplicaSet controller, Job controller, EndpointSlice controller, namespace controller, and service account token controllers. These loops compare desired and observed state and take corrective action.

Control-plane nodes run components that manage cluster state and decisions: API server, scheduler, controller-manager, and usually etcd in self-managed clusters. Worker nodes run kubelet, kube-proxy or equivalent dataplane components, the container runtime, and application workloads.

Desired state is what the object spec asks for. Observed state is what the cluster reports in status. A healthy controller keeps moving observed state toward desired state. Debugging often means finding why status cannot catch up with spec.