241. etcd in HA

etcd는 분산 시스템을 채용하는 K-V 데이터베이스임

• K-V 데이터베이스는 k-v 페어 여러 개로 구성된 페이지로 구성된다
• 쿠버의 여러 컴포넌트 중 etcd와 직접 통신하는 컴포넌트는 kube-apiserver뿐이다

etcd 서버는 1개만 존재할 수도 있지만, 여러 개의 분산형 구조를 할 수도 있음 (High Availability etcd 구성)

• 이 경우 모든 etcd 서버에 같은 데이터가 저장됨
  • 하지만 어떻게?

우선, Read operation의 경우, 모든 서버에 저장된 데이터가 동일하게 유지되므로, 아무 서버에서 Read를 하든 상관없음
하지만, Write 시에 데이터를 어떻게 consistent하게 유지할 수 있는가?

• 여러 etcd 서버 중 하나를 leader로 선출하여, write 작업이 들어오면 전부 leader로 보내버림
  • leader는 write 작업을 진행한 뒤 해당 작업을 나머지 노드(follower)들에 전파
    • 나머지 노드들에 전파되었는지 leader가 확인을 받으면 write 작업이 완료

 

리더 선출

클러스터가 시작되면, 노드별로 랜덤하게 정해진 타이머가 지난 뒤에, 리더 권한 요청을 다른 노드에게 보냄

• 한 노드로부터 리더 권한 요청을 받은 다른 노드들은, 해당 노드에 대한 리더 신임을 반환
  • 다른 노드들로부터 리더 신임을 받으면, 그 노드가 리더가 됨

리더가 선출된 뒤에도, 리더 노드는 일정 간격으로 다른 노드들에 리더를 계속하겠다는 요청을 보냄

• 만약 리더 노드가 죽어서 일정 기간이 지난 뒤에도 다른 노드들에 리더 계속 요청을 보내지 못하면, 다시 리더 선정이 시작됨

"나머지 노드들에 전파되었는지 leader가 확인을 받으면 write 작업이 완료" 라고 했다

• 하지만 노드 하나가 죽어서 응답이 안 오면 어떻게 할까?
  • 과반수가 응답했으면 해당 write 작업은 완료된 것으로 봄
  • 그렇다면 과반수란 어떻게 정하는가?

 

정족수(Quorum)

write 작업이 완료 처리되기 위해 필요한 최소 응답 노드의 수: (노드수/2) + 1

• 만약 2개의 노드가 있다면 Quorum은 (2/2 + 1 =) 2이다 => HA의 의미가 없다!
  • 따라서 etcd의 HA 구성에서는 최소 3개의 노드가 필요하다

etcd의 노드수는 홀수로 할 것이 권장되는데, 만약 네트워크가 쪼개지더라도 살아남을 확률이 더 높기 때문이다

• 예를 들어 7개 노드가 네트워크 장애로 4:3으로 쪼개지더라도 4개 쪽 클러스터는 살아남을 것이다 (Quorum=4)
• 하지만 6개 노드가 3:3으로 쪼개지면 클러스터 둘 다 살아남지 못한다 (Quorum=4)

 

실제 구성

etcd 바이너리를 받아서 적절한 위치 (/usr/local/bin)에 놓고 적절한 설정경로(/etc/etcd, /var/lib/etcd)를 만들어준다

이후 인증서 섹션에서 공부했던 것처럼 인증서를 만들고, SystemD Service를 생성한다

주의할 점은, etcd의 파라미터에, --initial-cluster peer-1=https://peer1:2380,peer-2=https://peer2:2380처럼, 초기 피어 정보를 넣어주어야 한다는 것이다

설치가 완료되었다면 etcdctl 명령어로 확인할 수 있다

• export ETCDCTL_API=3 (etcd API v3 사용)
• etcdctl put name john
• etcdctl get name
• etcdctl get / --prefix --keys-only