1. 개요
etcd는 쿠버네티스가 클러스터의 모든 데이터를 저장하는 키-값 저장소다. 공식 문서의 표현으로는 “모든 클러스터 데이터를 위한 백킹 스토어“이며, API 서버가 유일하게 말을 거는 상대다.
Pod, Deployment, Secret, ConfigMap, 노드 목록, RBAC 규칙 — kubectl get 으로 볼 수 있는 것은 전부 여기 들어 있다. 여기 없으면 클러스터에 없는 것이다.
2. 접근 권한의 무게
공식 문서가 한 문장으로 못 박는다.
“Access to etcd is equivalent to root permission in the cluster.”
etcd 를 읽을 수 있다는 것은 클러스터의 root 라는 뜻이다. RBAC 를 아무리 촘촘히 짜도 그것 역시 etcd 안의 데이터일 뿐이라, etcd 에 직접 닿는 사람 앞에서는 의미가 없다.
그래서 공식 문서는 API 서버만 etcd 에 접근하게 하고, TLS 클라이언트 인증으로 그 외를 막으라고 권한다.
3. Secret 과의 관계
Secret 은 기본적으로 암호화되지 않은 채 etcd 에 저장된다. base64 는 인코딩이지 암호화가 아니다.
Secret 저장 경로
kubectl apply → API 서버 → etcd 에 base64 그대로
↑ 여기를 읽으면 평문
대응은 두 층이다.
| 대책 | 막는 것 | 못 막는 것 |
|---|---|---|
etcd 암호화 (EncryptionConfiguration) | 디스크·백업 파일 유출 | 클러스터 관리자 (API 서버가 복호화해서 보여줌) |
| Secret 을 아예 안 만들기 (CSI·사이드카 주입) | 관리자까지 | 파드 메모리에 접근하는 root |
“etcd 에 아무것도 남기지 않는다"는 접근이 나오는 배경이 이것이다. 저장하지 않으면 저장소를 털려도 나올 게 없다.
4. 백업
etcd 를 잃는 것은 클러스터를 잃는 것이다. 노드가 멀쩡해도 무엇을 어떻게 돌려야 하는지 아무도 모르게 된다.
ETCDCTL_API=3 etcdctl snapshot save snapshot.db \
--endpoints=https://127.0.0.1:2379 \
--cacert=/etc/kubernetes/pki/etcd/ca.crt \
--cert=/etc/kubernetes/pki/etcd/server.crt \
--key=/etc/kubernetes/pki/etcd/server.key
공식 문서는 백업 방법을 셋으로 나눈다 — 내장 스냅샷, 볼륨 스냅샷, etcdctl 옵션을 이용한 스냅샷. 관리형 클러스터(EKS·GKE·AKS)는 클라우드가 대신 하므로 사용자가 신경 쓰지 않는다.
5. 홀수 멤버
etcd 는 과반수 합의(Raft)로 동작하므로 멤버 수를 홀수로 둔다. 공식 문서는 프로덕션에서 5대를 권한다.
| 멤버 | 과반수 | 견딜 수 있는 장애 |
|---|---|---|
| 3 | 2 | 1대 |
| 4 | 3 | 1대 — 3대와 같다 |
| 5 | 3 | 2대 |
| 6 | 4 | 2대 — 5대와 같다 |
짝수를 더해도 장애 내성이 늘지 않는다. 4대는 3대와 똑같이 1대까지만 견디면서 통신 비용만 늘어난다.
6. 디스크 지연
공식 문서가 경고하는 지점이다.
“Performance and stability of the cluster is sensitive to network and disk I/O. Any resource starvation can lead to heartbeat timeout, causing instability of the cluster.”
etcd 는 쓰기를 디스크에 확정한 뒤 응답하므로 디스크가 느리면 클러스터 전체가 느려진다. 하트비트가 늦으면 리더 선출이 다시 일어나고, 그동안 API 서버가 멈춘 것처럼 보인다. 그래서 SSD 를 쓰고 전용 머신에 격리하라고 권한다.
7. 관련 문서
- apiVersion — 저장되는 객체의 그룹과 버전
- CRD — 커스텀 리소스도 결국 etcd 에 저장된다
- Secret — 암호화 설정과 대안 (예정)
8. 출처
역할, 접근 권한 경고, 홀수 멤버, 디스크 민감도는 공식 문서에 근거한다.
“etcd is a consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data.”
“Access to etcd is equivalent to root permission in the cluster so ideally only the API server should have access to it.”
“You should run etcd as a cluster with an odd number of members. … A five-member cluster is recommended in production.”