Udemy CKA 강의 정리 236: Configure High Availability

해당 내용은 Udemy의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 공부한 내용입니다. 내용을 그대로 번역하기보다는, 제가 이해하기 쉬운 대로 수정한 부분들이 있습니다.

⚠️ 영어 독해가 많이 부족합니다. 틀린 내용이 있으면 알려주시면 감사하겠습니다.

---

이제 쿠버네티스의 고가용성(HA)을 살펴보겠습니다.

클러스터의 마스터 노드를 잃어버리면 어떻게 될까요?

워커노드들이 작동하고 컨테이너가 살아 있는 한 어플리케이션은 작동합니다. 사용자는 실패할 때까지 앱에 접속할 수 있습니다. 컨테이너나 파드가 고장 나면 어떻게 될까요? 파드가 레플리카 세트의 일부라면 마스터의 레플리케이션 컨트롤러가 워커노드에게 새 파드를 로드하라고 지시해야 합니다 하지만 지금 마스터는 사용할 수 없죠. 마스터의 컨트롤러와 스케쥴링매니저도 마찬가지고요. 파드를 재현할 사람도 없고 노드에 스케쥴링할 컴포넌트도 없습니다. kube-apiserver도 사용 가능하지 않기 때문에, 관리 목적으로 kubectl 툴이나 API를 통해 외부적으로 클러스터에 액세스할 수 없습니다. 그래서 프로덕션 환경에서 고가용성 구성에서 다중 마스터 노드를 고려해야 하는 것입니다.

고가용성 구성이란 클러스터 내 모든 컴포넌트에 걸쳐 중복을 갖는 것입니다. 단일 실패 지점을 피하기 위해서입니다. 마스터 노드, 워커 노드, 컨트롤 플레인 컴포넌트, 애플리케이션 등이 해당됩니다. 레플리카셋 및 서비스의 형식으로 이미 여러 개의 복사본을 갖고 있습니다.

이번 강의에서는 마스터와 컨트롤플레인 컴포넌트를 중점으로 살펴봅니다. 어떻게 작동하는지 자세히 살펴보겠습니다. 지금까지 3개의 노드가 있는 클러스터에 마스터 1개와 2개의 워커 노드가 있었습니다.

이번 강의에서는 마스터 노드만 집중적으로 살펴보겠습니다. 이미 배웠듯이 마스터 노드는 컨트롤 플레인 컴포넌트를 호스팅합니다 API, 컨트롤러 매니저, 스케줄러, 기타 서버를 포함해서요.

추가 마스터 노드를 설치하면 새로운 마스터에서도 같은 구성 요소가 실행됩니다. 이것은 어떻게 작동할까요? 같은 컴포넌트의 여러 인스턴스를 실행하면 같은 일을 두 번 할까요? 일을 분담할까요? 이것은 어떤 것을 하느냐에 따라 다릅니다.

API 서버는 요청을 수신하고 프로세싱하고 클러스터에 관한 정보를 제공할 책임이 있습니다. 한 번에 하나씩 요청에 따라 작업됩니다. 클러스터 노드 전체의 API 서버가 액티브 모드에서 동시에 실행되는 것입니다. 지금까지는 kubectl 유틸리티가 API 서버와 교신해 작업을 완료했습니다. 그 kubectl 유틸리티를 마스터 노드의  포트 6443로 보내도록 했습니다. API 서버가 listening하는 곳입니다. 이건 kube config 파일에서 구성되어 있습니다. 마스터가 둘인데 kbuectl2는 어디 있죠? 어느 쪽이든 요청할 수 있지만 양쪽 다 같은 요청을 해선 안 됩니다. 그래서 API 서버 간의 트래픽을 분할하는 마스터 노드 앞에 일종의 로드밸런서를 갖는 게 좋습니다. 그런 다음 kubectl 유틸리티가 로드밸런서를 가리키게 합니다. 이 목적으로 Nginx나 HA 프록시 또는 다른 로드밸런서를 사용할 수 있습니다.

스케줄러랑 컨트롤러 매니저는 어떨까요? 이 컨트롤러는 클러스터 상태를 보고 행동을 취합니다. 예를 들어 컨트롤러 매니저는 컨트롤러로 구성되어 있는데, 그 중 replication 컨트롤러는 파드 상태를 계속 관찰하다가 파드 하나가 고장 나면 새 파드를 만드는 등 필요한 조치를 취합니다. 다수의 인스턴스가 병렬로 실행되면 작업을 중복하여 필요 이상으로 파드를 늘릴 수 있습니다. 스케쥴러도 마찬가지입니다. 따라서 병렬로 실행되면 안되고, active standby mode로 실행되어야 합니다. 그럼 둘 중 누가 active이고 누가 passive인지 어떻게 결정할까요?

이는 주도적인 선거 과정을 통해 이뤄집니다. 컨트롤러 매니저를 예로 들어보겠습니다.

컨트롤러 매니저 프로세스가 구성되면 --leader-elect 옵션을 지정할 수 있습니다. default로 True으로 설정됩니다. 컨트롤러 매니저 프로세스가 시작되면 kube-controller-manager endpoint이라는 이름의 endpoint 오브젝트에 lease나 lock를 얻으려고 합니다. 어떤 프로세스든 해당 정보와 함께 endpoint를 업데이트하는 쪽이 lease를 획득해 둘 중 하나가 활성화되고, 다른 한 명은 passive가 됩니다. default 설정 15초인 --leader-elect-lease-duration 옵션을 이용하여 지정된 lease(임대) 기간을 위한 lock을 설정합니다. active 프로세스가 10초마다 lease를 갱신하는데, 이는 옵션 --leader-elect-renew-deadline 의 default값입니다. 두 과정 모두 leader elect retry period 옵션에서 정한 2초마다 리더가 되려고 노력합니다. 그래야 첫 번째 마스터가 실패해도 두 번째 마스터가 lease를 획득해 리더가 될 수 있습니다. 스케쥴러는 유사한 접근법을 따르고 커맨드라인 옵션은 동일합니다.

다음 단계는 etcd입니다. 앞서 이 코스에서 etcd에 관해 얘기했습니다. 그 과정을 다시 보는것도 좋습니다. 기억을 단축시키기 위해 이 강의에서는 etcd가 어떻게 작동하는지에 관련된 주제를 좀 더 다루겠습니다. 쿠버네티스에서 구성할 수 있는 형태는 두 가지입니다.

Stacked Topology

하나는 여기 보이는 것처럼 우리가 이 과정 내내 따라온 동일한 아키텍처입니다. etcd가 쿠버네티스 마스터 노드의 일부입니다. 이를 stacked control plane nodes topology라고 합니다. 설정과 관리가 더 쉽고 노드도 적게 요구합니다. 하지만 한 노드가 다운되면 etcd와 control plane 인스턴스는 둘 다 분실되고 중복은 손상됩니다.

External ETCD Topology

또다른 형태는 etcd가 컨트롤 플레인 노드에서 분리되어 그 자체 서버 세트에서 실행되는 것입니다. topology with external etcd servers입니다. 이전 토폴로지와 비교하면 이것은 덜 위험합니다. 실패한 controlplne이 etcd 클러스터와 저장된 데이터에 영향을 주지 않습니다. 하지만 셋업은 더 어렵고 외부 노드에 대한 서버 수도 두 배가 필요합니다. API 서버는 etcd 서버에 통신하는 유일한 컴포넌트임을 기억하세요.  API 서비스 config 옵션을 보면 etcd 서버 위치를 지정하는 옵션 집합이 있습니다. 토폴로지에 상관없이 ETCD 서버 구성 장소가 동일 서버든 분리된 서버든 궁극적으로 API 서버가 etcd 서버의 올바른 주소를 가리키도록 해야만 합니다. etcd는 분산 시스템이란 걸 기억하세요. 따라서 API 서버나, 통신하고자 하는 다른 컴포넌트는 그 인스턴스에서 해당 etcd서버에 도달할 수 있습니다. 이용 가능한 etcd 서버 인스턴스를 통해 데이터를 읽고 쓸 수 있습니다. 이것이 kupe-apiserver configuration에서 etcd 서버 리스트를 명시하는 이유입니다.

다음 강의에서는 etcd 서버가 클러스터 셋업에서 어떻게 작동하는지와 클러스터에서 권장하는 노드의 개수에 따라 모범 사례를 더 논의하겠습니다.

Our Design

다시 디자인으로 돌아가서, 원래는 클러스터의 단일 마스터 노드로 계획했었습니다. 그러나 HA와 함께 여러 마스터를 구성하기로 했습니다. API 서버에 대한 로드밸런서도 언급했습니다. 그것도 다룰 예정입니다. 이제 우리 클러스터엔 총 5개의 노드가 있습니다.