Port 2380: etcd Peer Communication — The Consensus Port

Port 2380 carries the conversations between etcd nodes. These are not client requests. These are the murmurs of consensus, the messages that allow a cluster of machines to agree on a single version of reality.

Every Kubernetes cluster in the world depends on what flows through this port.

What Port 2380 Does

etcd is a distributed key-value store. Port 2379 handles client traffic (applications reading and writing data). Port 2380 handles something more fundamental: peer-to-peer communication between etcd nodes themselves.¹

Through port 2380, etcd nodes:

• Elect leaders using the Raft consensus algorithm
• Replicate log entries so all nodes maintain the same data
• Send heartbeats to detect when nodes fail
• Synchronize state during cluster membership changes

This is the port where distributed consensus actually happens. When you have three or five etcd nodes forming a cluster, port 2380 is how they decide, together, what is true.

How Raft Consensus Works

etcd implements the Raft consensus algorithm, developed by Diego Ongaro and John Ousterhout at Stanford University. Their 2014 paper was titled "In Search of an Understandable Consensus Algorithm"², and that title tells you everything about why Raft exists.

Before Raft, the standard algorithm for distributed consensus was Paxos, created by Leslie Lamport. Paxos works. It's also notoriously difficult to understand and implement correctly. Ongaro and Ousterhout designed Raft specifically to be comprehensible to humans.

The core mechanism is elegant:

1. Leader Election: One node is elected leader. All others are followers. If the leader stops sending heartbeats, followers wait a randomized timeout, then call for a new election.

2. Log Replication: The leader receives all client writes, appends them to its log, and replicates those entries to followers through port 2380. Once a majority acknowledges an entry, it's committed.

3. Quorum: Nothing is committed without a majority. In a five-node cluster, three nodes must agree. This is why odd-numbered clusters make sense: a five-node cluster tolerates two failures, but so would a four-node cluster, so why pay for the extra machine?³

The randomized election timeout is the secret to avoiding split votes. When a leader fails, servers don't all become candidates at the same instant. One times out first, calls an election, wins, and starts sending heartbeats before others can challenge it.

The History: CoreOS and the Need for Coordination

In July 2013, Brandon Philips, Alex Polvi, and Xiang Li at CoreOS faced a specific problem: how do you safely coordinate automatic software updates across a cluster of Linux machines?⁴

They looked at existing solutions. Google's Chubby was proprietary. Apache ZooKeeper was mature but complex, written in Java, and overkill for what they needed. So they wrote their own.

The name "etcd" comes from "/etc" (the configuration directory on Unix systems) plus "d" for daemon. It's the configuration directory for your distributed system.⁵

CoreOS open-sourced etcd in 2014 and shipped version 1.0 in 2015. Red Hat acquired CoreOS in 2018 and contributed etcd to the Cloud Native Computing Foundation (CNCF), where it graduated in November 2020.⁶

According to Brandon Philips: "Etcd has become successful beyond our wildest aspirations when we started the project five years ago."⁷

Why Kubernetes Depends on Port 2380

etcd is the only stateful component in the Kubernetes control plane. Everything else (the API server, scheduler, controller manager) is stateless. They can crash and restart. etcd cannot lose data.

What etcd stores for Kubernetes:

• Pod specifications
• Service definitions
• Secret configurations
• Deployment details
• ConfigMaps
• The entire desired state of your cluster⁸

Without etcd, Kubernetes doesn't know what applications to run, where to run them, or how they should be configured. The API server writes to etcd. Controllers read from etcd. Every kubectl command ultimately becomes an etcd operation.

The recommended maximum size for an etcd database is 8 GiB. Exceed that, and etcd can't accept new data. Your Kubernetes cluster becomes inoperable.⁹

This is why port 2380 matters so profoundly. When peer communication fails, when the Raft consensus breaks down, when etcd nodes can't elect a leader, your Kubernetes cluster doesn't just slow down. It stops knowing what it believes.

The Protocol: gRPC Over HTTP/2

etcd v3 uses gRPC with Protocol Buffers over HTTP/2.¹⁰ This is not accidental. HTTP/2 multiplexes requests over a single TCP connection, allowing many messages to be in flight simultaneously. Protocol Buffers are binary, compact, and fast.

For peer communication on port 2380, etcd nodes exchange:

• AppendEntries: The leader sends log entries to followers
• RequestVote: Candidates request votes during elections
• Heartbeats: The leader proves it's still alive
• Snapshot transfers: When a follower falls too far behind, it receives a snapshot of the full state

The protocol is designed for low latency. etcd is benchmarked at 10,000 writes per second.¹¹ In a distributed system, every millisecond of consensus delay is a millisecond your application waits.

Security: What Happens When 2380 Is Exposed

Port 2380 should never be exposed to the public Internet. Unlike port 2379 (client traffic), which at least has authentication mechanisms, port 2380 is for trusted peers only.

And yet, misconfigured etcd instances appear regularly in Shodan scans. Attackers scan for exposed etcd on ports 2379 and 2380. Misconfigured instances without TLS or authentication have been ransomed, looted for Kubernetes secrets and cloud credentials, and abused for cryptomining deployments.¹²

The common mistake: configuring listen-peer-urls to 0.0.0.0:2380, which makes etcd listen on all interfaces, exposing peer communication to the public network.

Key CVEs:

• CVE-2018-16886: In etcd 3.2.x and 3.3.x, improper authentication allowed attackers to authenticate as any valid RBAC user if their client certificate's Common Name matched a username.¹³

• CVE-2023-44487: Unauthenticated peer attacks; the etcd documentation now explicitly recommends enabling peer client certificate authentication to prevent forged peer attacks.¹⁴

Security best practices:

• Enable mutual TLS for all peer communication
• Use a dedicated certificate authority for the etcd cluster
• Never expose port 2380 to untrusted networks
• Enable peer client certificate authentication
• Verify IP addresses in Subject Alternative Name (SAN) fields¹⁵

The Port Registration

IANA officially registered port 2380 as "etcd-server" for server-to-server communication, alongside port 2379 as "etcd-client" for client traffic.¹⁶

Before these official assignments, etcd used legacy ports 4001 (client) and 7001 (peer). The IANA registration formalized what the community had already adopted.

Related Ports