쿠버네티스 클러스터 구성 요소 및 동작 이해 - (1) etcd

쿠버네티스 클러스터 구성요소(component)

이전 글

쿠버네티스 etcd

쿠버네티스는는 기본 데이터 저장소로 etcd를 채택했다.

etcd 는 분산 시스템에서 사용할 수 있는 분산형 키-값 (key-value) 저장소로, 공식 문서는 다음과 같다: https://etcd.io/docs/

쿠버네티스에서 etcd는 클러스터의 상태를 저장하고 있다. 클러스터에 필요한 설정 정보와, 포드와 서비스 같은 각 리소스들의 명세와 상태 정보 등을 저장한다. 모든 클러스터 데이터를 담는 쿠버네티스 뒷단의 저장소로 사용되는 일관성·고가용성 키-값 저장소이다.

카카오 테크에서 정리한 etcd
참고 etcd 블로그 글

쿠버네티스가 etcd를 사용하는 방법

쿠버네티스가 클러스터 상태와 메타데이터를 저장하는 유일한 장소가 etcd.
API 서버만이 etcd와 직접적으로 통신하는 유일한 구성 요소이다. -> 낙관적 동시성 제어, 유효성 검사 등의 이점을 얻을 수 있다.(각 이점에 대한 내용은 아래에 나온다.)

쿠버네티스는 모든 데이터를 /registry 아래에 저장한다. /regsitry 아래 저장돼 있는 키 목록을 볼 수 있다.

# Input
etcdctl ls /registry

# Output
/registry/configmaps
/registry/daemonsets
/registry/deployments
/registry/events
/registry/namespaces
/registry/pods
...

# Input
etcdctl ls /registry/pods

# Output
/registry/pods/default
/registry/pods/kube-system

# Input
etcdctl ls /registry/pods/default

# Output
/registry/pods/default/podName-xk0vc
/registry/pods/default/podName-hp2o5

# Input
etcdctl get /registry/pods/default/podName-xk0vc

# Output
{"kind":"Pod","apiVersion":"v1","metadata":{"name":"podName-xk0vc",...

위에서 저장된 내용이 JSON 형식의 파드 정의라는 것을 알 수 있다. API 서버는 리소스의 완전한 JSON 표현을 etcd에 저장한다.

이처럼 etcd에서 키들이 계층적인 구조로 이름이 저장되어 있음을 볼 수 있다. (키는 슬래시를 포함할 수 있다.)
etcd의 계층적 키 공간 때문에, 저장된 모든 리소스를 단순하게 파일시스템에 있는 JSON 파일로 생각할 수 있다.

etcd는 key:value 형태의 데이터를 저장하는 스토리지이다.

etcd의 일관성 보장

쿠버네티스는 다른 모든 구성 요소가 API 서버를 통해 etcd에 접근하도록 했다. 이를 통해 API 서버 한 곳에서 낙관적 잠금 메커니즘을 구현해서 클러스터의 상태를 업데이트하기 때문에, 오류가 발생할 가능성을 줄이고 항상 일관성을 가질 수 있다. 또한 API 서버는 저장소에 기록된 데이터가 항상 유효하고 데이터의 변경이 올바른 권한을 가진 클라이언트에 의해서만 수행되도록 한다.

낙관적 동시성 제어

낙관적 동시성 제어는 데이터에 버전 번호를 포함하는 방법이다. 데이터가 업데이트될 때마다 버전 번호는 증가된다. 데이터를 업데이트할 때, 클라이언트가 데이터를 읽은 시간과 업데이트를 제출하는 시간 사이에서 버전 번호가 증가했는지 여부를 체크한다. 만약에 버전 번호가 증가했다면 수정된 내용은 거부되고 클라이언트는 다시 새 데이터를 읽고, 다시 업데이트를 시도해야 한다.

결과적으로 두 클라이언트가 동일한 데이터 항목을 업데이트를 시도하면, 첫 번째 시도만 성공한다.

모든 쿠버네티스 리소스에는 클라이언트가 오브젝트를 업데이트할 때, API 서버로 같이 넘겨줘야 하는 metadata.resourceVersion 필드가 있다. 만약 etcd에 저장돼 있는 버전과 일치하지 않을 경우 API 서버는 수정 요청을 거부한다.

고가용성을 보장하기 위해 ectd 인스턴스를 두 개 이상 실행할 수 있다.

ETCD 서버가 여러개 있을 때, 여러 ETCD에 대해 어떻게 싱크를 맞출까?
→ ETCD는 하나의 인스턴스만 write을 실행할 수 있다. leader만 write을 할 수 있고, 나머지 follower들은 못한다.
만약 follower에게 write 실행이 들어왔으면, 그것을 리더에게 forward하고 리더가 write을 수행한다.
write이 수행되면 리더는 copies of write가 다른 인스턴스에게 distribute될 수 있도록 한다.

<RAFT 알고리즘>

ETCD 리더를 뽑기 위한 과정:
ETCD가 최초 구축되면, 각 노드의 ETCD에서 random timer를 돌림.
-> timer가 가장 먼저 만료된 ETCD가 다른 ETCD들에 자기 자신을 리더로 뽑겠다는 request를 보냄.
-> 요청을 받은 다른 노드들은 vote를 한다.그리고 다른 마스터 노드들에게 일정 시간 간격으로 자신이 리더를 맡고 있는 것에 대한 notification을 날린다. 리더 vote 관련해서 요청을 못 받은 노드가 있으면 reelection을 한다.

write 작업을 한 이후, 다른 노드들에게 copies of write을 distritbute를 할 때, 과반수(N/2 +1)이상의 노드가 그 copy를 받았다면 write작업이 complete 되었다고 한다.
(Quorum(Majority): 일부 ETCD가 다운된 경우, write 작업이 완료된 ETCD 개수 >= Quorum 일 경우에만 write 작업 완료로 처리함. *Quorum = /2 + 1)

관련해서 master node 개수가 odd number일 때, cluster 장애 발생률(etcd, 클러스터 상태를 변경할 수 없는 상태)이 더 낮아, 홀수 개의 etcd 노드 개수가 권장된다.

그외 ) ETCDCT 커맨드: etcd에 직접 접근&데이터 가져오기 가능
https://etcd.io/docs/