kubernetes kubernetes/cka

Understanding etcd in Kubernetes: A Beginner’s Guide
v3.5 docs | etcd

Core Idea

etcd is the distributed key-value store that holds all cluster state as the single source of truth, kept consistent by Raft: writes need a leader and a majority, reads may forward to the leader.

  • Properties: replicated (every node has the full store), strongly consistent, highly available with no single point of failure, fast up to disk speed, TLS-secured, and simple HTTP/JSON API.
  • Ports: 2379 is the client API that the API server and etcdctl connect to; 2380 is peer-to-peer cluster sync only.
  • Ops covered in the note: etcdctl testing, HA cluster topology, and how a follower forwards a stale read to the leader before answering.

etcd is a key-value data store used to store and manage the critical information that distributed systems need. It provides a reliable way of storing the configuration data.

To achieve that reliable coordination, k8s needs a data source that can help with the information about all the components, their required configuration, state data, etc. That data store must provide a consistent, single source of truth at any given point in time. In Kubernetes, that job is done by etcd. etcd is the data store used to create and maintain the version of the truth.

Raft

etcd is built on the Raft consensus algorithm to ensure data storage consistency across all nodes in a cluster for a fault-tolerant distributed system.

Raft

👉 Split Brain Condition

etcd Overview

  1. Replicated
    • Each node in an etcd cluster has full access to the entire data store.
  2. Consistent
    • Every read operation returns the most recent write, ensuring etcd is strongly consistent.
  3. Highly Available
    • etcd is fault-tolerant, with no single point of failure, and can handle network partitions while maintaining availability as long as a majority of nodes are reachable.
  4. Fast
    • The upper bound for etcd’s speed is determined by the storage speed of individual nodes, ensuring low-latency reads and writes.
  5. Secured
    • Communication between etcd nodes is encrypted using Transport Layer Security (SSL), ensuring the protection of data during transit.
  6. Simple
    • etcd provides a simple HTTP API using JSON encoding, making it easy to integrate with applications.

How etcd works ?

When Reading from a Follower That’s Not Yet Updated:

  1. Client Request:
    The client makes a request to a follower node.
  2. Forwarding the Request:
    The follower node forwards the request to the leader node
  3. Leader Response:
    The leader node retrieves the most recent data and returns it to the follower.
  4. Follower Returns to Client:
    The follower sends the updated value back to the client.

When Writing Data:

  1. Client Write Request:
    The client sends the write request to the leader node.
  2. Leader Forwards Request to Followers:
    The leader node forwards the write request to its follower nodes
  3. Followers Update Data:
    Each follower node updates its local data store based on the write request.
  4. Followers Acknowledge Update:
    The followers return success to the leader once their data store is updated.
  5. Leader Finalizes Update:
    Once a majority of followers have updated their values successfully, the leader updates its own data store.
  6. Leader Responds to Client:
    The leader node sends a success response back to the client.

etcd ports

service-names-port-numbers.txt
Configuration flags | etcd

2379 is the port of ETCD to which all control plane components connect to. 2380 is only for etcd peer-to-peer connectivity.

PortPurposeUsed ByDirectionSecurity
2379Client API (reads/writes data)Kubernetes API Server, etcdctl, External ClientsInboundTLS, Authentication
2380Peer communication (cluster sync)etcd cluster members/nodesInbound/OutboundTLS, Authentication
Metrics Port (Custom)Exposes etcd metrics (for monitoring)Prometheus, Monitoring ToolsInboundNone (unless secured manually)

ETCDTL

K8s-Learn/06-ETCD-Testing at master · nmdra/K8s-Learn · GitHub

HA etcd cluster

Options for Highly Available Topology | Kubernetes