멀티 클러스터
멀티 클러스터 (Cluster Mesh)
Cluster Mesh는 Cilium 네트워킹을 여러 Kubernetes 클러스터에 걸쳐 확장해 주는 기능이에요. 장애 격리·확장성·지리적 분산 같은 이유로 멀티 클러스터를 도입했을 때 겪는 서비스 디스커버리와 정책 문제를 해결해 줍니다. 이 글에서는 Cluster Mesh의 소개와 아키텍처, 보안 고려 사항을 알아볼게요.
본문
멀티 클러스터 Kubernetes 설정은 장애 격리, 확장성, 지리적 분산 같은 이유로 자주 채택됩니다. 이 접근 방식은 네트워킹 복잡성을 초래할 수 있어요. 이런 멀티 클러스터 설정에서 전통적인 네트워킹 모델은 서비스 디스커버리, 네트워크 세그멘테이션, 정책 적용, 그리고 클러스터 간 로드 밸런싱에 어려움을 겪습니다. Cluster Mesh는 Cilium 네트워킹을 여러 Kubernetes 클러스터에 걸쳐 확장해 이러한 과제를 해결하며 다음을 제공합니다:
- 플랫 IP 주소 공간 안에서 클러스터 간 Pod-to-pod 연결
- 클러스터를 인식하는 네트워크 정책 적용
- 크로스 클러스터 서비스 디스커버리 및 로드 밸런싱
- 로컬 또는 원격 백엔드를 선호하도록 하는 서비스 어피니티 컨트롤
Cluster Mesh를 설정하는 방법은 Cluster Mesh 설정하기를 참고하세요.
아키텍처
Cluster Mesh는 clustermesh-apiserver Pod가 호스팅하는 클러스터별 컨트롤 플레인을 중심으로 구축됩니다. 이 Pod들은 로컬 클러스터 상태를 원격 클러스터에 노출하고, 원격 클러스터 상태를 로컬 클러스터에 동기화해요.
Cilium 에이전트는 로컬 Kubernetes API 서버 상태와 원격 Cluster Mesh 상태를 유사한 방식으로 사용해 로컬 데이터패스를 프로그래밍합니다. Pod-to-pod 트래픽은 클러스터 경계를 넘어서도 노드 간에 직접 전달되며, 추가 프록시나 게이트웨이가 필요하지 않아요.
다음 다이어그램은 주요 Cluster Mesh 구성 요소와 두 클러스터가 상태를 교환하는 방법을 보여 줍니다.
clustermesh-apiserver Pod는 보통 다음 컨테이너를 포함합니다:
etcd: 로컬 클러스터 상태를 mTLS를 통해 원격 클러스터에 노출하는데, 보통 LoadBalancer 또는 NodePort 서비스를 통해 노출합니다. 이 임베디드 etcd는 단일 인스턴스이고 시작 시 kube-apiserver에서 전체 상태가 다시 구축되므로 영구 스토리지가 필요하지 않아 운영하기 간단해요.apiserver: 로컬 Cilium 및 Kubernetes 상태를 로컬 etcd 인스턴스에 동기화합니다.kvstoremesh: 다른 클러스터의 원격 클러스터 상태를 로컬 클러스터에 동기화합니다.
Cluster Mesh는 클러스터 간 상태를 교환하기 위해 kvstore 모드의 몇 가지 개념을 재사용합니다. Cilium이 이미 kvstore 모드로 실행 중이면, Cluster Mesh는 추가 임베디드 etcd 인스턴스를 배포하는 대신 기존 kvstore etcd 인스턴스를 확장해요.
보안
Cluster Mesh에 연결된 모든 클러스터는 단일 트러스트 도메인을 형성합니다.
Cilium은 원격 클러스터에서 받은 정보에 대해 다양한 정합성 검사를 수행하지만, 이 검사들은 손상된 클러스터의 Cilium 컨트롤 플레인이 다른 클러스터에 악의적인 정보를 전파하는 것을 완전히 막을 수는 없어요.
서로 신뢰하고 동등한 보안 태세를 가진 클러스터만 연결하세요.