한눈에 요약
- 쿠버네티스 클러스터의 상태가 실제로 저장되는 분산 키-값 저장소다. 여러 대에 같은 데이터를 복제해 한 대가 죽어도 살아남는 구조다.
- 쿠버네티스 공식 문서는 etcd를 별도 인프라가 아니라 컨트롤 플레인 컴포넌트로 분류한다 34.
- 문서가 붙인 역할 설명은 "모든 API 서버 데이터를 위한 일관성·고가용성 키-값 저장소"다 34.
- 홀수 대수로 묶어야 하고 쓰기가 잦아 느린 디스크에서 병목이 된다는 두 가지가 운영의 핵심이다.
정족수는 왜 홀수를 요구하나
여러 대가 같은 데이터를 나눠 갖는 시스템은 "몇 대가 동의해야 결정으로 치나"를 정해야 한다. 그 기준이 **정족수(quorum)**다. 서버 n대라면 (n/2)+1대가 살아 있어야 클러스터가 돌아간다 32.
여기서 짝수가 손해인 이유가 나온다. 홀수 클러스터에 한 대를 더하면 정족수 기준도 같이 올라간다. 대수는 늘었는데 견딜 수 있는 장애 대수는 그대로다. 고장 날 수 있는 기계만 늘어난 셈이다 32.
K3s에서의 자리
K3s는 etcd를 두 가지 방식으로 쓴다. 서버 안에 끼워 넣은 내장 etcd(서버 3대 이상)와 바깥에 따로 세운 외부 etcd다. 외부 저장소로는 etcd 3.5.21이 인증돼 있다 (2026-08 기준) 32.
내장 etcd HA에서는 서버끼리 2379·2380 포트가 열려 있어야 한다. 메트릭은 2381, 레거시 HTTP API는 2382 로컬 포트를 쓴다 32.
라즈베리 파이처럼 SD 카드·eMMC로 도는 장비에서는 성능 문제가 난다. etcd가 쓰기 집약적이라 IO를 감당하지 못하기 때문이다. 문서는 외장 SSD를 쓰라고 권고한다 32.
백업은 k3s etcd-snapshot 명령으로 뜬다. 스냅샷만으로는 부족하고 서버 토큰까지 같이 보관해야 복원할 수 있다 32.