Kubernets - ETCD

etcd는 Kubernetes에서 핵심적인 역할을 하는 분산형 Key-Value 저장소로, 클러스터의 상태 및 설정 데이터를 안전하게 저장하고 관리하는 역할을 합니다. Kubernetes의 모든 컨트롤러, 컴포넌트, API 서버는 etcd를 사용하여 클러스터의 최신 상태를 지속적으로 추적하고 변경 사항을 저장합니다. 

Kubernetes에서 etcd의 역할

1. 클러스터 상태 저장소
   • etcd는 Kubernetes 클러스터의 상태를 저장하는 중앙 데이터 저장소 역할을 합니다. 이는 클러스터 내의 모든 리소스(예: Pod, Service, ConfigMap, Deployment 등)에 대한 정보, 구성, 상태 데이터를 포함합니다.
   • 모든 Kubernetes의 상태 변화는 etcd에 기록되며, API 서버는 이 데이터를 기반으로 클러스터의 상태를 관리합니다.
2. 분산된 데이터 일관성 보장
   • etcd는 Raft 합의 알고리즘을 통해 분산 시스템에서의 데이터 일관성을 보장합니다. Kubernetes 클러스터는 여러 노드로 구성되어 있지만, 모든 노드가 동일한 상태를 가져야 하므로, etcd는 이를 위해 강한 일관성 모델을 제공합니다.
   • 예를 들어, 새로운 Pod가 생성되거나 삭제될 때, etcd는 그 변경 사항을 모든 노드에 동기화합니다.
3. Kubernetes API와 연동
   • Kubernetes API 서버는 클러스터의 모든 상태 변경 요청(예: Pod 생성, 서비스 변경 등)을 받으면, 이를 처리한 후 etcd에 기록합니다.
   • kube-apiserver는 읽기 요청에 대해서도 etcd에 접근하여 현재 상태를 조회합니다. 이는 클러스터의 상태가 언제나 최신 상태로 유지되도록 보장합니다.
4. 클러스터 재시작 시 상태 복구
   • 만약 Kubernetes 클러스터가 재시작되거나 특정 노드에서 장애가 발생하더라도, etcd에 저장된 데이터를 기반으로 클러스터의 상태가 복구됩니다. etcd는 클러스터의 영구적인 상태 저장소이기 때문에 재시작 후에도 클러스터는 이전 상태로 돌아갈 수 있습니다.
5. 고가용성 및 장애 복구
   • etcd는 고가용성을 보장하기 위해 클러스터 내에 여러 개의 노드로 배포됩니다. 장애가 발생하여 하나의 etcd 노드가 다운되더라도, 나머지 노드들이 정상적으로 동작하여 데이터의 가용성과 일관성을 유지합니다.

Kubernetes에서의 etcd 사용 사례

1. Pod 생성
   • 사용자가 Kubernetes API를 통해 새로운 Pod를 생성하면, 이 요청은 kube-apiserver에 전달됩니다.
   • kube-apiserver는 이 요청을 처리하고, 최종적으로 새로운 Pod 정보를 etcd에 저장하여, 클러스터의 상태를 업데이트합니다.
   • 이 상태 정보는 이후 스케줄러, 컨트롤러, kubelet 등 다른 컴포넌트가 참조하게 됩니다.
2. ConfigMap, Secrets 저장
   • ConfigMap과 Secrets와 같은 Kubernetes 설정 정보도 모두 etcd에 저장됩니다.
   • 이 데이터는 클러스터 내 모든 노드와 애플리케이션이 참조할 수 있으며, 안전하게 저장 및 관리됩니다.
3. 클러스터 상태 변경
   • 노드 추가, 삭제 또는 리소스 배치 등의 모든 클러스터 상태 변화는 etcd에 기록됩니다. 이렇게 기록된 데이터는 클러스터의 현재 상태를 정확하게 반영하며, 장애 발생 시에도 이 데이터를 기반으로 복구가 가능합니다.

 

요약

Kubernetes에서 etcd는 중앙 데이터 저장소로서 클러스터의 상태와 설정을 영구적으로 관리합니다. etcd는 Raft 합의 알고리즘을 통해 일관성과 가용성을 보장하며, Kubernetes의 API 서버, 스케줄러, 컨트롤러 등 주요 구성 요소들이 이를 통해 클러스터의 상태를 추적하고 제어할 수 있습니다.

 

 

-------------------------- Optional -------------------------------

 

etcd의 동작 원리

1. Raft Consensus Algorithm (합의 알고리즘)
   • etcd는 Raft 합의 알고리즘을 사용하여 데이터의 일관성과 가용성을 보장합니다. Raft는 리더(Leader)와 팔로워(Follower)로 구성된 분산형 클러스터 구조를 사용합니다.
   • **리더(Leader)**는 클러스터 내에서 모든 쓰기 작업을 담당하며, 데이터를 팔로워 노드들에 복제합니다. 팔로워 노드들은 리더에게 데이터를 복제받아 읽기 작업을 처리할 수 있습니다.
   • Raft는 리더가 쓰기 작업을 수행할 때, 과반수의 노드가 해당 데이터를 복제하고 동의할 때만 데이터를 커밋하여, 데이터의 일관성을 보장합니다.
2. 쓰기 작업 흐름
   • etcd에 새로운 쓰기 작업이 발생하면, 요청은 리더 노드로 전달됩니다.
   • 리더 노드는 해당 쓰기 작업을 로그에 기록한 후, 클러스터 내 팔로워 노드들에게 복제 요청을 보냅니다.
   • 과반수 이상의 노드가 복제에 성공하면 리더는 해당 작업을 커밋하고, 클라이언트에게 성공 여부를 응답합니다. 이 과정을 통해 etcd는 강한 일관성을 유지합니다.
3. 읽기 작업 흐름
   • etcd는 선택적 일관성을 제공할 수 있습니다. 일반적으로 읽기 작업은 리더뿐만 아니라 팔로워 노드에서도 처리할 수 있어, 클러스터의 부하를 분산할 수 있습니다.
   • 만약 사용자가 최신 데이터가 반드시 필요하다면, 리더 노드를 통해 최신 상태의 데이터를 조회하는 선거 기반 읽기를 사용할 수 있습니다.
4. Snapshot 및 로그 압축
   • etcd는 시간이 지남에 따라 많은 트랜잭션 로그를 기록하게 되며, 모든 로그를 저장하는 것은 비효율적입니다. 이를 해결하기 위해 etcd는 스냅샷(Snapshot) 기능을 사용합니다. 스냅샷은 특정 시점의 클러스터 상태를 저장하여, 이후에 로그를 압축할 수 있도록 돕습니다.
   • 주기적으로 스냅샷을 찍고, 오래된 로그는 제거하여 저장소의 공간을 효율적으로 관리합니다.
5. 고가용성 및 장애 복구
   • etcd는 클러스터에 다중 노드로 배포되며, 이를 통해 노드가 일부 장애를 겪더라도 클러스터가 계속 작동할 수 있습니다. 만약 리더 노드가 장애를 겪으면, Raft 알고리즘에 의해 새로운 리더가 선출됩니다.
   • 새로운 리더가 선출되면 클러스터는 즉시 정상 상태로 돌아가며, 클러스터 내 모든 데이터는 일관성 있게 유지됩니다.