[k8s] 다중 영역에서의 클러스터

#Kubernetes

쿠버네티스는 기본적으로 단일 네트워크 메시 내에서 사용하는 것을 전제로 만들어진 도구다.
보안적으로도 그렇고, 성능이나 네트워크 안정성 측면 모두에서 그렇다.

하지만 때로는 물리적 수준에서 영역을 구분해서 장애를 격리하거나, 혹은 정말 멀리 떨어진 리전들을 단일 클러스터처럼 관리하고 싶을 수도 있다. 그럴때 접근할만한 방향과 관점들을 정리해본다.

논리 영역 분리

엄밀하게 영역을 분리하지 않고, 단순히 가용성 확보를 위해 논리적인 관점에서만 영역을 분리하고 싶을 수도 있다.
예를 들어, A 영역의 장비와 B 영역의 장비 그룹을 정의한 다음에, 특정 영역에만 서버를 띄우거나, 각 영역에 1개씩 복제해서 띄운다거나 하는 것이다.

이렇게 하는 것은 그다지 어렵지 않다.

노드마다 영역을 뜻하는 레이블을 붙이고, nodeSelector나 node Affinity를 사용하면 되기 때문이다.
그러면 쿠버가 원하는 영역의 node에만 배포하도록 할 수 있다.

여기서부터는 매우 까다로워지기 시작한다.
경우에 따라서는 별도의 근거리 네트워크 망에 존재하는 장비들(이를테면 동일 리전의 다른 AZ)이나 아예 멀리 떨어진 리전들 간에 존재하는 장비들을 하나의 클러스터처럼 관리하고 싶을 수도 있다.

쿠버네티스는 이런 사용사례를 위한 기능을 직접적으로 제공하진 않고 그닥 권장하지도 않으나, 이런 요구사항이 생길 경우도 분명히 존재는 한다.

여기서 가장 큰 쟁점은 네트워크 지연과 손실이다. 동일 리전(근거리) 내에서의 연결이라면 해볼만한데, 아예 국가나 대륙이 다른 경우에는 속도가 매우 느려지기 때문이다. 사실 하려면 다 할 수는 있다.

보통 근거리 네트워크로 연결될 수 있는 경우에는 Zone(가용영역) 등으로 느슨하게 분리하되 단일 클러스터로 엮고, 국가나 대륙간의 장거리 네트워크 관계를 가진다면 아예 별도 클러스터로 분리하는 것이 일반적인 패턴이 된다.

근거리 네트워크를 단일 클러스터로 묶을 경우에는 여러가지 선택지가 존재할 수 있다.

VPN을 사용해서 개별 망들을 오버레이할 수도 있고(예: Tailscale), CNI 수준에서 L3 라우팅을 뚫어서 통신하도록 할 수도 있다. 전자가 좀 더 쉬운 방식이고, 후자가 좀 번거롭지만 정석에 가까운 방법이다.

하지만 위에서 언급했듯, 네트워크 길이가 매우 길어진다면 단일 클러스터로 구성하는 것은 썩 좋은 방법이 아니다.
그래서 보통은 서울과 이탈리아의 서버가 있다면 각각의 리전 클러스터를 독립적으로 구축하는 것을 권장한다.

이 상황에서 다른 영역 간의 상호작용이 필요하다면, 제어 서버를 별도로 두고서, 각각의 리전 클러스터에 API를 날려서 통제할 수 있다. 이게 가장 깔끔하고 정석적인 패턴 중 하나다.

이러라고 쿠버네티스 서버가 API Server로 되어있는 것이기도 하다.
이러면 딱 원하는 지점과 상황에만 제한적으로 장거리 통신을 하게 되니, 여러가지 변수들을 미연에 차단하고 운영능력을 더 긍정적인 방향으로 끌고나갈 수 있다.