[k8s] Control Plane과 가용성

control plane은 쿠버네티스의 심장이라고 할 수 있는 존재다.
각 노드에 서버를 프로비저닝하고, 그 서버들의 상태를 저장하는 가장 중요한 상태 저장소이기 때문이다.

그래서 control plane이 다운된다면 쿠버네티스 클러스터 전체의 신뢰도가 사라지게 된다.
여기서는 control plane을 구성하고 관리하는 방법들, 선택지들에 대해서 간단히 정리해본다.

Basic 아키텍쳐

대부분의 k8s 배포판에서는 전형적인 master-slave 구조로 구성을 해준다.
master 노드에 control plane 서버와 etcd 저장소를 세팅하고, control plane 서버가 etcd에 데이터를 저장하면서 워커 노드들을 통제하는 것이다.

가용성이 매우 중요한 경우가 아니라면 이 정도로도 충분하다.

하지만 상기했듯이 이건 리스크가 제법 크다.
control plane에 장애가 발생한다면 Pod에 대한 스케줄링이 일단 중단된다. 개별 Pod들은 개별 Node의 컨테이너 런타임이 관리하니까 기존 Pod들도 죽진 않지만, 지속적인 안정성을 담보할 수 없는 것이다. 장애가 발생한 Pod의 재실행이라든지, 신규 리소스의 재할당 등이 망가진다.

그리고 마스터 노드의 디스크에 문제가 생긴다면 쿠버네티스의 상태 자체가 영구적으로 망가질 수도 있다.
쿠버네티스라고 뭘 마법처럼 잘 저장해주는게 아니라, etcd라는 데이터베이스에 그냥 API 서버들처럼 서버들의 상태를 저장하는 것이기 때문이다.
저게 소실되면 그냥 서버 전체 정보가 전부 증발하는 것이다.

참고: 여기서는 etcd를 계속 언급하지만, 하나의 예시일 뿐이다. etcd 말고 다른 DB를 쓸 수도 있다.

고가용성 구조

아무튼 그래서 정말 가용성이 중요한 경우에는 Control Plane을 다중으로 구성하는 것을 권장한다.
이론적인 고가용성을 달성하려면 최소 3개의 Control Plain 노드가 필요하다.

그림으로 표현하면 대충 이런 식이 될 것이다.

근데 여기서도 갈림길이 생긴다. 사실 Control Plane 자체를 다중화하는 것은 그렇게 어려운 문제는 아니다.
Control Plane 자체는 상태 저장소가 아니라 API 서버이기 때문에 상태에 대한 문제가 없기 때문이다.

결국 중요한 것은 상태를 어디 저장하는지다. 그러면 이 상황에서 데이터를 어디에 저장해야 할까?
2가지 선택지가 있다.

고가용성 - 외부 DB

가장 단순하고 직관적인 선택지는, 그냥 etcd 클러스터를 별도로 구성하는 것이다.

일반적인 DB 클러스터 구성하듯이 적절히 멀티노드 구성하고, 그 DB 클러스터를 Control Plane들이 참조하게 한다. 우리가 흔히 생각하는 API 서버와 DB의 관계다.

이러면 control plane이 하나 죽거나, etcd 노드가 하나 뻗더라도 전체 가용성을 저해하지 않고 서비스 운영이 가능해진다. 나머지 노드들이 대신 처리해줄 수 있기 때문이다.

이 경우 ETCD 클러스터가 설치된 노드들은 독립적인 별도 장비를 사용하는 편이다.그래서 대체로 하드웨어가 좀 더 많이 필요하다.

kubeadm으로 외부 etcd를 구성하려면, init/join할때 다음과 같이 외부 etcd 접속정보만 적절히 넣어주면 된다.

---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: stable
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" # change this (see below)
etcd:
  external:
    endpoints:
      - https://ETCD_0_IP:2379 # change ETCD_0_IP appropriately
      - https://ETCD_1_IP:2379 # change ETCD_1_IP appropriately
      - https://ETCD_2_IP:2379 # change ETCD_2_IP appropriately
    caFile: /etc/kubernetes/pki/etcd/ca.crt
    certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
    keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key

고가용성 - 내부 DB

또 하나의 방법은, 개별 Control Plane 노드에 etcd를 각자 구성하게 하는 것이다.
stacked etcd라고도 부르고, 비교적 더 일반적인 선택지다.

Control Plane와 etcd 한 쌍이 하나의 독립적인 DB가 되고, Control Plane 그룹이 하나의 분산 DB가 되는 것이다.
kubeadm의 HA 구성에서는 실제로 Raft 알고리즘을 통해 데이터를 분산하고 공유한다. Leader도 선출하고 그런다. 그래서 최소 쿼럼 충족을 위해 3개 이상의 노드가 필수적이다.

외부 etcd 방식에 비해 하드웨어 자원이 덜 필요하다는 장점이 있다. 마찬가지로 가용성 수준은 괜찮다.
하나의 노드가 뻗더라도 나머지 노드들로 새 Leader를 선출하든지 해서 안정성을 유지할 수 있다.

만약 노드를 control plain 노드로 등록하려면, join할때 전용 플래그를 넣으면 된다.
kubeadm 배포판의 경우에는 --control-plane 플래그를 넣으면, node로 참여함과 동시에 control plane으로 설정된다.

kubeadm join --control-plane ...

참조
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/