[Kubernetes] 쿠버네티스의 etcd 개념

쿠버네티스의 etcd

쿠버네티스(Kubernetes)에서 etcd는 클러스터 상태를 영구적으로 저장하기 위한 분산 Key-Value 저장소임.

모든 Kubernetes 오브젝트(네임스페이스, 파드, 서비스, 컨피그맵, 시크릿, RBAC, CRD 등)의 메타데이터와 상태 정보가 etcd에 저장되므로, etcd가 멈추면 쿠버네티스의 컨트롤 플레인 전체가 동작할 수 없게 됨.

따라서 etcd는 쿠버네티스에서 가장 중요한 컴포넌트 중 하나임.

 

etcd의 특징 및 아키텍처

1. Key-Value 모델

etcd는 key → value 형태로 데이터를 저장함.

쿠버네티스의 모든 리소스 정보는 특정 경로(Key)에 직렬화된 형태(주로 JSON 등)로 저장됨.

예를 들면 다음과 같음.

/registry/pods/<namespace>/<podname>, /registry/deployments/<namespace>/<deployname> 등

 

2. 일관성(Consistency) 보장

etcd는 분산 합의 알고리즘인 Raft를 사용하여 Strong Consistency(강한 일관성)를 구현함.

클라이언트가 요청했을 때, Leader 노드가 합의를 거쳐 해당 변경사항을 복제(Follower 노드에 Commit)하고, Commit 완료 후에 응답을 반환함.

 

3. 고가용성(High Availability)

etcd는 다중 노드(일반적으로 홀수 개, 예: 3개, 5개, 7개)로 구성된 클러스터 형태로 동작함.

Leader-Follower 구조를 취하며, Leader 노드 장애 시 Follower 중 하나가 자동으로 Leader 자리를 승계함(Raft의 Leader Election).

 

4. Watch(감시) 기능

etcd는 Key(혹은 Key의 prefix)에 대한 변경 사항을 실시간으로 구독(Watch)할 수 있음.

쿠버네티스의 각 컨트롤러, 스케줄러, kubelet 등이 etcd를 Watch하여, 클러스터 상태 변화(새로운 리소스 생성/삭제, 업데이트 등)를 빠르게 인지하고 동작할 수 있음.

 

5. 버전 관리

etcd는 모든 Key에 대해 Revision(버전)을 관리함.

특정 시점(Revision)을 기준으로 데이터를 읽거나, 변경 내용을 트랜잭션(Transaction) 방식으로 처리하는 등 높은 수준의 기능을 제공함.

 

etcd의 클러스터 구성

1. 홀수 개 노드 구성

etcd는 합의 알고리즘(Raft)에서 과반수(Majority) 투표가 필요함.

일반적으로 노드를 홀수 개로 구성함(3, 5, 7대 등).

3개 구성이 가장 흔하며, 장애 허용 범위(1개 노드 장애)를 만족할 수 있음.

5개 이상 구성 시, 클라이언트-서버 간 지연(Latency)나 운영 복잡성이 증가할 수 있으므로 트래픽 수준 및 안정성 요구사항을 고려해야 함.

 

2. Leader-Follower 구조

클러스터 내에서 하나의 Leader 노드가 쓰기 요청(Write)을 전담하며, Follower 노드는 Leader로부터 변경 사항을 복제(Replication)받아 저장함.

Leader 장애 시, Follower 노드들이 새 Leader를 선출하기 위한 투표(Quorum)를 진행하여 자동으로 리더를 선정함.

 

3. 심플한 통신 구조

클라이언트가 etcd에 접근할 때는 보통 Leader 노드로 직접 요청을 보내거나(Write), Follower 노드로 Read 요청을 보내기도 함(단, Strong Consistency를 위해서는 Leader를 거치는 것이 일반적).

내부적으로 etcd 노드들 간에는 Raft 프로토콜을 통해 로그를 동기화하고, 선출 과정을 진행함.

 

4. 엔드포인트 구성

프로덕션 환경에서는 etcd 서버(다중 노드)와 kube-apiserver가 서로 통신하기 위해, 각 etcd 노드의 peer/client Endpoint(예: https://etcd1:2379, https://etcd2:2379)를 설정함.

인증서 기반 통신(mTLS)을 적용하여 보안을 강화하는 것이 일반적임.

 

고가용성 및 장애 대응

1. 물리적인 분산

클러스터 노드들을 서로 다른 가용 영역(Availability Zone) 혹은 데이터센터에 분산하여 배치하면, 특정 영역 장애 시에도 etcd가 계속 동작하도록 보장할 수 있음.

 

2. 백업(Snapshot) 전략

etcd 데이터는 쿠버네티스 전체 상태를 담고 있으므로, 주기적인 스냅샷(backup)이 필수임.

장애나 데이터 손실이 발생할 경우, etcd 스냅샷으로부터 복구를 수행할 수 있어야 함.

etcdctl snapshot save / etcdctl snapshot restore 등의 커맨드를 사용하거나, 자동화된 백업 툴을 사용할 수 있음.

 

3. MoM(Mean of Monitoring)

etcd의 상태(리더 여부, Follower 동기화 지연, 디스크 IOPS, 네트워크 지연, DB 사이즈 등)를 지속적으로 모니터링해야 함.

Prometheus + Grafana 등 Observability 스택을 활용하여 알림(Alerts) 체계를 구축하는 것이 좋음.

 

4. Quorum 손실 방지

Leader 노드를 포함하여 과반수 노드가 동시에 장애 발생하지 않도록 인프라를 설계해야 함.

예를 들어, 3노드 구성에서 2대가 동시에 장애 나면 Quorum을 만족하지 못해 쓰기 요청은 물론이고, 클러스터 동작이 사실상 불가능해짐.

 

성능 및 보안 고려 사항

1. 디스크 I/O 및 네트워크 레이턴시

etcd는 Write 요청 시 디스크에 Commit하는 과정을 포함하므로, 고성능 SSD를 사용하는 것이 좋음.

노드 간에 지연 시간이 낮은 네트워크(로컬 LAN 수준)여야 합의 과정이 빠르게 이뤄질 수 있음.

 

2. 리소스 할당

CPU, 메모리 자원이 부족하면, 리더가 Raft 프로토콜을 수행하는 과정에서 병목이 생길 수 있음.

프로덕션 환경에서는 독립된(혹은 충분한 리소스가 할당된) 노드에서 etcd를 운영하는 것이 일반적임.

Kubernetes HA 구성을 위한 컨트롤 플레인 노드와 etcd 노드를 물리적으로 분리할 수도 있고, 혹은 동일 노드에 올리더라도 리소스 우선순위를 높게(bookmark) 설정함.

 

3. 보안(Encryption & 인증서)

etcd 통신은 TLS(Transport Layer Security)로 암호화하여 중간자 공격(Man-in-the-middle) 및 스니핑(Sniffing)을 방지해야 함.

인증서 기반(mTLS) 설정으로 클라이언트와 서버 간 상호 인증을 수행하여, 신뢰할 수 있는 노드/클라이언트만 etcd에 접근할 수 있도록 해야함.

etcd 내에 저장되는 시크릿(Secret) 등 민감 데이터에 대해서는 KMS(키 관리 서비스) 연동 등을 통해 저장 시점에 암호화를 적용할 수도 있음(쿠버네티스의 Secret 암호화 기능).

 

4. 데이터 크기 관리

etcd는 모든 Kubernetes 리소스의 메타데이터를 저장하므로, CRD(사용자 정의 리소스)나 Events 등이 지나치게 누적되어서 저장 용량이 커질 수 있음.

오래된 이벤트를 정리(Cleanup)하거나, 불필요한 CRD 데이터를 주기적으로 정리해주어야 성능 저하를 방지할 수 있음.

 

업그레이드 및 운영 시나리오

1. 버전 호환성

쿠버네티스 버전에 따라 지원되는 etcd 버전이 다르므로, Kubernetes 매뉴얼을 참고하여 호환성을 맞춰야 함.

일반적으로는 컨트롤 플레인 업그레이드 시, etcd 버전도 함께 올리거나, 사전에 업그레이드하는 전략을 사용함.

 

2. 롤링 업그레이드

다중 노드 etcd 클러스터에서 한 노드씩 업그레이드를 수행하고, 안정화/동기화가 완료되면 다음 노드로 넘어가는 과정을 반복함.

Leader 노드를 업그레이드하는 경우, Leader가 다른 노드로 즉시 넘어가므로 서비스는 중단되지 않음.

업그레이드 전에 스냅샷 백업을 반드시 수행해야 함.

 

3. 데이터 정리(Compaction)

etcd는 Revision 이력을 관리하므로, 오래된 Revision이 쌓이면 디스크 사용량이 늘어나고 성능이 저하될 수 있음.

정기적으로 Compaction을 수행해 불필요한 이력 데이터를 정리해야 함.

etcdctl compaction <revision> 명령어를 사용하거나, 일정 주기로 자동화 스크립트 혹은 Operator를 통해 Compaction하는 방안을 고려할 수 있음.

 

모범 사례

1. 3노드 이상의 클러스터 구성

최소 3노드로 구성해 장애 허용 범위(1대 장애 시 동작 유지)를 확보함.

 

2. 주기적인 Snapshot 백업 & 복구 테스트

백업만 해놓고 실제 복구가 제대로 되는지 검증하지 않으면, 긴급 상황에서 복구가 실패할 수 있음.

 

3. 고성능 SSD 및 빠른 네트워크

낮은 레이턴시와 충분한 IOPS를 보장할 수 있도록 물리/클라우드 인프라 설계를 신중히 해야 함.

 

4. 보안 강화를 위한 TLS/mTLS 적용

인증서 기반 통신, 방화벽, 네트워크 접근 제어 등 다단계 보안을 구성함.

 

5. 정기적인 데이터 용량 모니터링 및 Compaction

이벤트나 CRD가 많아지는 환경에서는 주기적으로 용량 상태를 점검하고, 고도화된 모니터링 지표를 운영함.

 

6. 업그레이드 시나리오 문서화

업그레이드와 마이그레이션 절차를 문서화하고, 테스트 환경에서 시뮬레이션 후 프로덕션에 적용함.

 

정리

쿠버네티스에서 etcd는 모든 클러스터 상태를 저장하고 관리하는 가장 중요한 데이터베이스임.

강력한 일관성(Strong Consistency)과 고가용성(HA)을 제공하며, Watch 기능을 통해 Kubernetes의 선언적 모델(Desired State)을 실시간으로 유지할 수 있게 해줌.

운영 환경에서 etcd를 안정적으로 유지하기 위해서는 다음과 같은 전략이 필요함.

 

1. 안정적이고 고성능의 물리(또는 가상) 인프라 및 네트워크

2. 3노드 이상의 HA 클러스터 구성과 정기적인 스냅샷 백업

3. TLS/mTLS 보안 통신, 인증·인가 제어, 데이터 암호화 방안

4. 데이터 정리(Compaction), 노드 모니터링, 프로퍼 업그레이드 시나리오

 

이러한 요소들을 종합적으로 잘 설계하고 운영해야, 쿠버네티스 클러스터가 장애 없이 원하는 상태를 계속 유지할 수 있음.

etcd를 제대로 이해하고 관리한다는 것은 곧 Kubernetes 운영의 근간을 탄탄하게 만드는 일임.