Study/CS

[Cilium Study] 5주차 - BGP와 ClusterMesh로 클러스터 경계 넘기

마늘김 2025. 8. 17. 08:04

 지난 4주차 스터디에서는 Cilium의 LB-IPAM과 L2 Announcement 기능을 통해 온프레미스 환경에서도 LoadBalancer 타입의 서비스를 외부에 노출하는 방법을 알아보았습니다. L2 통신을 통해 외부 트래픽을 클러스터로 인입시키는 편리한 방법이었죠. 하지만 L2 통신은 동일 네트워크 대역이라는 한계를 가집니다. 만약 우리 클러스터가 여러 네트워크 대역에 걸쳐 있거나, 외부 라우터와 더 지능적으로 경로를 교환해야 한다면 어떻게 해야 할까요?

이번 포스팅에서는 L3 라우팅 프로토콜의 표준인 BGP(Border Gateway Protocol) 를 Cilium과 연동하여 동적으로 라우팅 정보를 교환하는 방법을 알아보고, 한 걸음 더 나아가 여러 쿠버네티스 클러스터를 하나의 거대한 클러스터처럼 연결하는 ClusterMesh 기능까지 깊이 있게 다뤄보겠습니다.

1. Cilium BGP Control Plane: 동적 라우팅으로 똑똑하게 길 찾기

지난 시간에 다룬 L2 Announcement는 동일 L2 네트워크 안에서는 훌륭하게 동작하지만, 라우터를 거쳐야 하는 다른 네트워크 대역에서는 외부 IP를 노출할 수 없습니다. 또한, 노드가 추가되거나 Pod CIDR이 변경될 때마다 외부 라우터에 수동으로 Static Route를 추가하는 것은 대규모 환경에서는 거의 불가능에 가까운 운영 부담을 야기합니다.

Cilium BGP Control Plane은 바로 이 문제를 해결하기 위한 솔루션입니다. 이는 인터넷을 지탱하는 핵심 라우팅 프로토콜인 BGP를 쿠버네티스 클러스터에 통합한 기능입니다. 각 쿠버네티스 노드가 BGP 스피커(Speaker)가 되어, 자신이 담당하는 파드 IP 대역(Pod CIDR)과 LoadBalancer 서비스의 외부 IP(ExternalIP)를 외부 라우터에게 동적으로 "광고(Advertise)"합니다.

BGP 연동의 핵심 흐름

  1. BGP Peering: Cilium이 설치된 각 노드는 외부 라우터(실습에서는 FRR 사용)와 BGP Peer 관계를 맺습니다. 이는 각자의 라우팅 정보를 교환하기 위한 일종의 '친구 맺기' 과정으로, "우리 이제부터 서로 아는 길을 공유하자"고 약속하는 것과 같습니다.
  2. Route Advertisement (경로 광고): Peer 관계가 수립되면, 각 노드는 자신이 알고 있는 경로 정보, 즉 "172.20.1.0/24 대역으로 가려면 나에게 와!" 와 같은 Pod CIDR 정보를 외부 라우터에게 알려줍니다. LoadBalancer 서비스 IP 또한 동일한 방식으로 광고하여 외부에서 직접 접근할 수 있는 경로를 제공합니다.
  3. Dynamic Routing: 외부 라우터는 여러 노드로부터 BGP를 통해 경로 정보를 수신하고, 이를 자신의 라우팅 테이블에 자동으로 업데이트합니다. 이제 라우터는 클러스터 내부의 모든 파드 IP 대역으로 가는 최적의 경로를 동적으로 학습하게 되며, 노드가 추가되거나 파드가 다른 노드로 이동하더라도 이 정보는 자동으로 갱신됩니다.

이 모든 복잡한 과정이 Cilium의 CRD (CiliumBGPClusterConfig, CiliumBGPPeerConfig, CiliumBGPAdvertisement)를 통해 쿠버네티스 네이티브 방식으로 선언적으로 관리됩니다. 즉, 우리는 YAML 파일을 통해 "어떤 경로를, 어떤 조건으로 광고하겠다"고 정의만 하면, Cilium이 알아서 BGP 연동을 처리해줍니다. 더 이상 노드나 라우터에 하나하나 접속하여 명령어를 입력할 필요가 없는 것이죠.

ExternalTrafficPolicy와 ECMP

BGP를 사용하면 여러 노드가 동일한 서비스 IP(172.16.1.1/32)를 동시에 광고할 수 있습니다. 이때 라우터는 ECMP(Equal-Cost Multi-Path) 기능을 통해 들어온 트래픽을 여러 노드로 효과적으로 분산시킬 수 있습니다. 여기서 서비스의 externalTrafficPolicy 설정이 매우 중요해집니다.

  • externalTrafficPolicy: Cluster (기본값): 트래픽이 어떤 노드로 들어오든, 해당 서비스의 파드가 없는 노드라 할지라도 일단 받아서 클러스터 내부에서 실제 파드가 있는 노드로 한 번 더 전달합니다. 이 방식은 구현이 간단하지만, 클라이언트의 원본 IP가 소실(SNAT)되고 클러스터 내부에 불필요한 트래픽(Hairpinning)이 발생하는 단점이 있습니다.
  • externalTrafficPolicy: Local (권장): BGP 광고 단계에서부터 실제 서비스 파드가 실행 중인 노드만 해당 서비스 IP를 광고하도록 지능적으로 제어합니다. 트래픽은 처음부터 올바른 노드로만 전달되므로 불필요한 내부 홉이 사라집니다. 무엇보다 클라이언트의 원본 IP 주소(Source IP)가 백엔드 파드까지 그대로 보존되므로, 로깅이나 IP 기반 보안 정책 적용에 매우 중요합니다.

2. Kind: 내 PC 안에 작은 데이터센터 만들기

ClusterMesh와 같이 여러 쿠버네티스 클러스터를 연동하는 복잡한 시나리오를 실습하려면, 실제로 여러 개의 클러스터가 필요합니다. 이때 매우 유용한 도구가 바로 Kind(Kubernetes in Docker) 입니다.

Kind는 이름 그대로 도커 컨테이너를 하나의 쿠버네티스 '노드'로 사용하여, 내 로컬 PC에서 가볍고 빠르게 멀티 노드, 멀티 클러스터 환경을 구축할 수 있게 해줍니다. 가상 머신을 여러 개 띄우는 것보다 훨씬 자원을 적게 사용하면서도 실제와 거의 동일한 클러스터 환경을 제공합니다. 또한, 모든 클러스터 구성을 YAML 파일 하나로 선언적으로 관리할 수 있어, 동일한 테스트 환경을 반복적으로 생성하고 파괴해야 하는 CI/CD 파이프라인에 통합하기에도 매우 용이합니다.

3. ClusterMesh: 클러스터의 경계를 허물다

애플리케이션의 규모가 커지면 고가용성(High Availability) 확보, 지역별 지연 시간 감소, 기능별 클러스터 분리 등의 이유로 여러 개의 쿠버네티스 클러스터를 운영하게 됩니다. 하지만 이렇게 분리된 클러스터들은 기본적으로 서로를 인식하지 못하는 별개의 섬과 같습니다.

Cilium ClusterMesh는 이 섬들을 다리로 연결하여, 여러 개의 클러스터를 마치 하나의 거대한 클러스터처럼 동작하게 만드는 강력한 기능입니다. 마치 바다로 단절된 여러 개의 섬(클러스터)들을 거대한 다리(ClusterMesh)로 연결하여, 주민들(파드)이 자유롭게 오가고, 각 섬의 특산물(서비스)을 함께 나눌 수 있는 하나의 대도시권으로 만드는 것과 같습니다.

ClusterMesh의 마법

ClusterMesh가 활성화되면 다음과 같은 놀라운 일들이 가능해집니다.

  • Global Service Discovery: cluster-west에 있는 파드가 cluster-east에 있는 서비스를 별도의 설정 없이 my-service.default.svc.cluster.local이라는 익숙한 이름으로 바로 찾아 접속할 수 있습니다. Cilium이 클러스터 간 서비스 정보를 동기화하고 DNS 요청을 가로채 다른 클러스터의 서비스 IP로 응답해주기 때문에, 개발자 입장에서는 서비스가 어느 클러스터에 있는지 전혀 신경 쓸 필요가 없습니다.
  • Cross-Cluster Pod-to-Pod Communication: 클러스터 간에 파드 IP 대역에 대한 라우팅이 자동으로 설정되어, 서로 다른 클러스터에 있는 파드들이 마치 같은 클러스터에 있는 것처럼 직접 통신할 수 있습니다. 이 클러스터 간의 모든 통신은 상호 TLS(mTLS)를 통해 암호화되므로, 민감한 데이터가 클러스터 경계를 넘나들더라도 안전하게 보호됩니다.
  • Shared Services & High Availability: 여러 클러스터에 동일한 서비스를 배포하고 이를 하나의 Global Service로 묶어, 한쪽 클러스터에 장애가 발생하더라도 다른 클러스터의 서비스로 트래픽이 자동으로 Failover 되도록 구성하여 높은 수준의 가용성을 확보할 수 있습니다.

이 모든 복잡한 과정이 cilium clustermesh CLI 명령 몇 줄로 간단하게 처리됩니다. 클러스터 간 인증서를 교환하고, 서로의 API 서버 정보를 등록하면, Cilium 에이전트들이 알아서 필요한 설정들을 구성하여 클러스터들을 안전하게 연결합니다.

결론

이번 스터디를 통해 우리는 단일 클러스터의 경계를 넘어 외부 네트워크, 그리고 다른 클러스터와 소통하는 고급 네트워킹 기술을 살펴보았습니다. BGP Control Plane은 온프레미스 환경에서도 동적 라우팅을 통해 대규모 클러스터의 외부 연결을 자동화하고 최적화하는 길을 열어주었고, ClusterMesh는 물리적으로 분리된 클러스터들을 논리적으로 하나의 네트워크로 묶어줌으로써 진정한 의미의 멀티 클러스터 아키텍처를 구현할 수 있게 했습니다.

Cilium과 함께라면, 복잡하고 거대해지는 인프라 환경 속에서도 네트워킹을 단순하고, 선언적이며, 안전하게 관리할 수 있다는 확신을 다시 한번 얻게 됩니다.

 추가로, 예전에 가이드를 작성하였던 Cilium + BGP 관련 링크도 함께 남겨봅니다.

 

On-Premise 환경에서 Kubernetes LoadBalancer 구현

CSP에서 제공하는 Kubernetes 서비스는 클라우드 인프라에 잘 통합되어 있어 있습니다. 그래서 간단한 명령어나 웹 UI를 통해 쉽게 클러스터를 생성할 수 있고 사용할 수 있습니다. 특히 Load Balancer

tech-recipe.tistory.com

 

 

Cilium BGP와 ECMP

이전 포스팅에서 이어집니다. 'On-Premise 환경에서 Kubernetes LoadBalancer 구현'을 읽고 오시길 권장드립니다. On-Premise 환경에서 Kubernetes LoadBalancer 구현CSP에서 제공하는 Kubernetes 서비스는 클라우드 인

tech-recipe.tistory.com