How is ETCD used in the Kubernetes architecture?

How is ETCD used in the Kubernetes architecture?

• A. It is used as the source of truth and the backing store for all data
• B. It runs containers on each node
• C. It handles scheduling decisions
• D. It provides DNS services

Answer: (A)

Etcd acts as Kubernetes' distributed key-value store and serves as the cluster's source of truth. The entire state of the cluster—namespaces, pods, deployments, services, config maps, secrets, and other objects—is stored in etcd. The API server is the only component that writes to and reads from etcd, and controllers watch etcd via the API server to reconcile the actual state with the desired state. Because etcd uses Raft to maintain consensus, all master components share a consistent view of the cluster state. This central store is critical: losing etcd means losing access to the cluster’s state. It’s not used to run containers, make scheduling decisions, or provide DNS—those responsibilities belong to the node runtime, the scheduler, and DNS add-ons, respectively.

Etcd acts as Kubernetes' distributed key-value store and serves as the cluster's source of truth. The entire state of the cluster—namespaces, pods, deployments, services, config maps, secrets, and other objects—is stored in etcd. The API server is the only component that writes to and reads from etcd, and controllers watch etcd via the API server to reconcile the actual state with the desired state. Because etcd uses Raft to maintain consensus, all master components share a consistent view of the cluster state. This central store is critical: losing etcd means losing access to the cluster’s state. It’s not used to run containers, make scheduling decisions, or provide DNS—those responsibilities belong to the node runtime, the scheduler, and DNS add-ons, respectively.