ETCD in Kubernetes

etcd is a distributed and reliable key-value store used by Kubernetes to store the cluster’s configuration, state, and metadata.

It act as the database of the Kubernetes cluster.

Kubernetes stores information about almost every cluster object in etcd, including:

• Nodes
• Pods
• Deployments
• ReplicaSets
• Services
• Configurations
• Secrets
• Service Accounts
• Roles and RoleBindings

Whenever we create, update, or delete a Kubernetes object, the change is stored in etcd.

kubectl apply
     │
     ▼
kube-apiserver
     │
     ▼
    etcd
     │
     ▼
Cluster state updated

ETCD and the Kubernetes API Server

The Kubernetes API Server communicates directly with etcd to read and store cluster data.

For example:

kubectl get pods -A

The API Server retrieves the requested cluster information from etcd and returns it to the user.

Important: etcd is the source of truth for the Kubernetes cluster state.

ETCD as a Key-Value Store

Unlike a traditional relational database that organizes data into tables, rows, and columns, etcd stores data as key-value pairs.

Example:

Key:   /registry/pods/default/nginx
Value: Pod configuration and state

Kubernetes organizes its data in etcd under registry paths for different Kubernetes resources.

etcdctl

etcdctl is the command-line client used to interact with etcd.

Common ETCD v3 commands:

# Set a value
etcdctl put key1 value1

# Get a value
etcdctl get key1

To ensure that etcdctl uses API v3:

export ETCDCTL_API=3

In older API v2 versions, the set command was used instead of put.

API v2 → etcdctl set key value
API v3 → etcdctl put key value

ETCD Ports

etcd commonly uses:

• 2379 — Client communication
• 2380 — Communication between etcd members in an etcd cluster

The Kubernetes API Server communicates with etcd through the client endpoint.

ETCD Deployment in Kubernetes

There are two common ways to deploy etcd:

Manual Installation

In a manually configured Kubernetes cluster, etcd is installed and configured directly as a service.

This provides more control over:

• TLS certificates
• Cluster configuration
• Peer communication
• Data directories
• High availability

kubeadm Installation

When using kubeadm, etcd is usually deployed automatically as a static Pod on the control plane node.

We can view it with:

kubectl get pods -n kube-system

Example:

etcd-control-plane
kube-apiserver-control-plane
kube-controller-manager-control-plane
kube-scheduler-control-plane

High Availability

For a highly available Kubernetes cluster, multiple etcd members can run as an etcd cluster.

The members communicate with each other and maintain a consistent copy of the cluster data using a consensus mechanism called Raft.

A simplified architecture looks like this:

                Kubernetes Cluster
                       │
                       ▼
                 kube-apiserver
                       │
                       ▼
             ┌─────────────────┐
             │   ETCD Cluster  │
             ├─────────────────┤
             │     etcd-1      │
             │     etcd-2      │
             │     etcd-3      │
             └─────────────────┘
                       │
                       ▼
              Kubernetes Cluster
                State & Metadata

Running multiple etcd members improves availability because the cluster can continue operating even if one member fails, as long as the cluster maintains quorum.

Summary

etcd is a critical component of Kubernetes because it stores the entire state of the cluster.

Component	Responsibility
etcd	Stores Kubernetes cluster state and configuration
kube-apiserver	Reads and writes cluster data to etcd
etcdctl	Command-line tool for interacting with etcd
Raft	Maintains consistency between etcd members

Key takeaway: Without etcd, Kubernetes would not have a reliable source of truth for the cluster’s state.