Kubernetes etcd 이해하기 — 클러스터의 상태 저장소 들여다보기

AI 요약

etcd는 Kubernetes 클러스터의 데이터를 보관하는 일관성·고가용성 키-값 저장소입니다. Go로 작성됐으며 Raft 합의 알고리즘을 사용합니다. 리더 노드가 상태 변경을 처리하고 팔로워 노드에 복제합니다. 과반수 합의가 필요하므로 운영 환경에서는 보통 3개나 5개 노드로 구성합니다. Kubernetes 구성요소는 etcd에 직접 접속하지 않고 API 서버를 거칩니다. API 서버가 인증과 검증을 담당하고, 스케줄러와 컨트롤러 매니저는 API 서버를 통해 변경 사항을 확인합니다.

계층처럼 보이는 평면 키 공간

etcd에는 실제 디렉터리가 없습니다. Kubernetes는 루트 접두사 /registry 아래에 슬래시로 구분한 키를 만들어 리소스를 정리합니다. 네임스페이스 리소스는 /registry/{리소스}/{네임스페이스}/{이름} 형식입니다. 예를 들어 default 네임스페이스의 nginx-demo 배포는 /registry/deployments/default/nginx-demo에 저장됩니다. 노드나 네임스페이스처럼 클러스터 범위에 속하는 리소스는 네임스페이스 항목 없이 /registry/{리소스}/{이름} 형식을 씁니다.

Minikube에서 배포 데이터 확인하기

글은 nginx 이미지로 복제본 3개를 실행하는 배포를 만든 뒤, Minikube의 etcd 파드에서 etcdctl을 실행해 해당 키를 조회합니다. 인증서 경로와 엔드포인트를 지정하고 --write-out=fields로 키와 값을 확인합니다. 저장 데이터는 Protobuf 바이너리로 인코딩되므로 출력에서 일부 정보는 읽기 어렵지만, 배포 생성 상태를 나타내는 내용을 확인할 수 있습니다.

MVCC와 revision

etcd는 Multi-Version Concurrency Control(MVCC)을 사용합니다. 객체를 수정할 때 기존 값을 덮어쓰는 대신 새 버전을 기록하고 전역 revision 번호를 증가시킵니다. 글의 실습에서는 배포 키를 JSON 형식으로 조회했을 때 ModRevision이 2814였고, 배포 이미지를 nginx:1.25로 변경한 뒤에는 작성자 환경에서 3854로 바뀌었습니다. 이 값은 변경 이력을 확인할 때 참고할 수 있습니다.

dev.to 반응

• @anh_nguynvn_0478e614ba — 계층을 평면 키 공간으로 표현하는 방식은 상태 문제를 처음 디버깅할 때 많은 사람이 놓치는 부분입니다. 키의 슬래시는 실제 디렉터리가 아니라 논리적 추상화라는 점을 잊기 쉽습니다. 키 이름 규칙이 엄격하지 않으면 접두사 검색이 지저분해질 수 있습니다. 키 패턴이 비효율적이라 접두사 조회 때 엔진이 너무 많은 작업을 하면서 watch 연산이 느려진 운영 장애를 몇 차례 봤습니다. 압축(compaction) 주기도 살펴봐야 합니다. MVCC 이력이 불어나면 유지보수 작업을 적절히 조정하지 않았을 때 디스크 I/O와 지연 시간이 빠르게 악화될 수 있습니다.
  • @pravesh_sudha_3c2b0c2b5e0 — MVCC 이력이 불어나는 문제를 글에 추가하려고 했지만, 초보자에게 글이 너무 복잡해질 것 같았습니다. 다음 시리즈 글에 꼭 반영하겠습니다. 유익한 피드백 감사합니다 ☺️

원문: dev.to / 번역·요약: Trawling