Kubernetes Architecture

A Kubernetes cluster has two parts: the Control Plane (kube-apiserver, etcd, kube-scheduler, kube-controller-manager) and Worker Nodes (kubelet, kube-proxy, container runtime). The control plane makes decisions about scheduling and state management; worker nodes run the actual workloads.

etcd is a distributed, consistent key-value store that serves as Kubernetes' backing store for all cluster data. Every pod definition, service, secret, and config is stored in etcd. If etcd is lost without a backup, the entire cluster state is gone. That's why etcd backups are critical in production.

The kubelet is an agent that runs on every worker node. It receives pod specifications (PodSpecs) from the API server, ensures the containers described in those specs are running and healthy, and reports node/pod status back to the control plane. It's the bridge between the control plane and the container runtime.

The kube-apiserver is the front-end for the Kubernetes control plane. It exposes the Kubernetes API (REST). All external communication (kubectl, dashboards, CI/CD) and internal communication (scheduler, controller-manager) goes through the API server. It handles authentication, authorization, admission control, and validation.

kube-proxy is a network proxy running on each node. It maintains network rules (using iptables or IPVS) that allow network communication to pods from inside and outside the cluster. It implements the Kubernetes Service concept — routing traffic to the right pod backends.

No — running pods continue running. The kubelet on each worker node manages containers locally. However, no new scheduling, no self-healing (crashed pods aren't replaced), no new deployments, and no scaling will work. kubectl commands will fail. This is why production clusters run multiple master nodes for high availability.

The scheduler follows a two-phase process: Filtering — eliminates nodes that can't run the pod (insufficient resources, taints, node selectors, affinity rules). Scoring — ranks remaining nodes by criteria like resource balance, data locality, and spreading. The highest-scored node wins. You can influence this with nodeSelector, affinity/anti-affinity, taints/tolerations, and priority classes.

iptables: Default mode. Creates iptables rules for each Service/endpoint. Simple but performance degrades with thousands of services (O(n) rule matching). IPVS: Uses Linux kernel IPVS (IP Virtual Server). Hash-table based, O(1) lookup. Better performance at scale. Supports more load-balancing algorithms (round-robin, least connections, etc.). Use IPVS for large clusters with 1000+ services.

etcd uses the Raft consensus algorithm to maintain data consistency across multiple replicas. A distributed etcd cluster (3 or 5 members) provides high availability — if one member fails, the cluster continues operating as long as a majority (quorum) is alive. A single etcd instance is a single point of failure and unacceptable for production.

The kube-controller-manager runs multiple controllers in a single process. Each controller is a control loop that watches the cluster state via the API server and makes changes to move from current state → desired state. Examples: ReplicaSet controller ensures correct replica count; Node controller marks unreachable nodes; Job controller manages batch jobs. This watch-and-reconcile pattern is fundamental to Kubernetes' declarative model.

1) Check network connectivity to the API server: curl -k https://<api-server>:6443/healthz. 2) Verify kubeconfig is correct: kubectl config view. 3) Check if API server is running: kubectl get pods -n kube-system (from another context or on the master). 4) Check if etcd is healthy — if etcd is down, API server can't serve requests. 5) For managed K8s: check cloud provider status. 6) Check if it's a DNS issue — try using the IP directly in kubeconfig.

1) kubectl describe node <name> — check Conditions section (MemoryPressure, DiskPressure, PIDPressure, NetworkUnavailable, Ready). 2) SSH into the node and check kubelet: systemctl status kubelet, journalctl -u kubelet --since "5 min ago". 3) Check container runtime: systemctl status containerd. 4) Check disk: df -h. 5) Check memory: free -m. 6) Check networking: can the node reach the API server? 7) Check for kernel/OS issues: dmesg | tail.

Run 3 master nodes (odd number for etcd quorum). Use a load balancer in front of API servers. Run etcd as a 3-member cluster (or 5 for larger setups). Spread worker nodes across availability zones. Use Pod Disruption Budgets to ensure minimum replicas during node maintenance. For managed K8s (AKS/EKS), the control plane HA is handled by the provider — focus on multi-AZ node pools and PDB configurations.

etcd compacts revisions automatically, but the space isn't freed until defragmentation. Steps: 1) Check space: etcdctl endpoint status --write-out=table. 2) Compact old revisions: etcdctl compact <revision>. 3) Defrag: etcdctl defrag. 4) Check if too many objects exist (excessive ConfigMaps, Secrets, Events). 5) Set up etcd quota with --quota-backend-bytes. 6) Ensure regular snapshots and lifecycle management.

1) Check node capacity: kubectl describe nodes | grep -A 5 "Allocated resources". 2) Check if resource requests on the pod exceed any node's allocatable capacity. 3) Check taints on nodes: kubectl get nodes -o json | jq '.items[].spec.taints' — pods without matching tolerations won't schedule. 4) Check nodeSelector or affinity rules on the pod spec. 5) Check if PersistentVolumeClaims are bound (unbound PVCs prevent pod scheduling). 6) Consider adding nodes or adjusting resource requests.