BGP로 클러스터에 연결한다고?

NGINX | 2023년 2월 28일

강력한 Kubernetes 환경을 구축하고 관리하려면 네트워크 팀과 애플리케이션 팀 간의 원활한 협업이 필요합니다. 하지만 두 팀은 우선순위와 업무 방식이 대체로 크게 달라 갈등이 발생할 수 있으며, 이는 애플리케이션 개발 지연, 배포 지연, 심지어 네트워크 중단과 같은 심각한 결과로 이어질 수 있습니다.

공동의 목표를 향해 나아가는 두 팀이 모두 성공해야만 오늘날의 최신 애플리케이션을 적절한 보안과 확장성을 갖춰 제때 제공할 수 있습니다. 그렇다면 각 팀이 긴밀하게 협력하도록 지원하면서 각 팀의 역량과 전문성을 어떻게 활용할 수 있을까요?

당사의 백서 「클러스터로 안내해 주세요」에서는 네트워크 팀과 애플리케이션 팀이 충돌 없이 각자의 강점을 결합할 수 있도록 Kubernetes 서비스에 대한 외부 액세스를 지원하는 솔루션을 자세히 설명합니다.

Kubernetes 클러스터에서 앱을 외부에 노출하는 방법

이 솔루션은 특히 온프레미스에서 호스팅되는 Kubernetes 클러스터를 위한 것으로, 노드는 베어 메탈 또는 기존 Linux 가상 머신(VM)에서 실행되고 표준 레이어 2 스위치와 레이어 3 라우터가 데이터 센터 내 통신을 위한 네트워크를 제공합니다. 클라우드 공급자는 자사 데이터 센터의 핵심 네트워크나 관리형 Kubernetes 환경의 네트워크를 사용자가 제어하도록 허용하지 않으므로, 이 솔루션은 클라우드에서 호스팅되는 Kubernetes 클러스터에는 적용되지 않습니다.

온프레미스에서 호스팅되는 Kubernetes 클러스터의 다이어그램. 데이터 센터 내 통신을 위한 네트워크는 노드와 표준 레이어 2 스위치 및 레이어 3 라우터로 구성되어 있습니다.

솔루션의 구체적인 내용을 살펴보기에 앞서, Kubernetes 클러스터에서 애플리케이션을 외부에 노출하는 다른 표준 방식이 온프레미스 배포에 적합하지 않은 이유를 알아보겠습니다.

서비스 – 동일한 앱을 실행하는 Pod를 하나로 묶습니다. 내부 Pod 간 통신에는 매우 유용하지만 클러스터 내부에서만 표시되므로 앱을 외부에 노출하는 데는 도움이 되지 않습니다.
NodePort – 클러스터의 모든 노드에서 특정 포트를 열고 트래픽을 해당 앱으로 전달합니다. 외부 사용자가 서비스에 액세스할 수 있게 해 주지만, 구성이 정적이고 잘 알려진 낮은 포트 번호 대신 높은 번호의 TCP 포트를 사용해야 하며 다른 앱과 포트 번호를 조율해야 하므로 이상적인 방식은 아닙니다. 또한 여러 앱이 공통 TCP 포트를 공유할 수도 없습니다.
LoadBalancer – 각 노드의 NodePort 정의를 사용하여 외부에서 Kubernetes 노드로 연결되는 네트워크 경로를 생성합니다. AWS, Google Cloud Platform, Microsoft Azure를 비롯한 대부분의 클라우드 제공업체에서 손쉽게 구성할 수 있고 안정적으로 작동하며 필요한 공용 IP 주소와 이에 대응하는 DNS A 레코드를 서비스에 제공하는 기능으로 지원하므로, 클라우드에서 호스팅되는 Kubernetes에 매우 적합합니다. 하지만 온프레미스 클러스터에는 이에 상응하는 기능이 없습니다.

온프레미스 Kubernetes 클러스터에 대한 외부 사용자 액세스 활성화

그러면 Kubernetes Ingress 객체가 남습니다. 이 객체는 클러스터 외부 사용자에서 클러스터 내부의 Pod로 흐르는 트래픽(남북 트래픽)을 위해 특별히 설계되었습니다. Ingress는 클러스터에 외부 HTTP/HTTPS 진입점, 즉 외부 사용자가 여러 서비스에 액세스할 수 있는 단일 IP 주소 또는 DNS 이름을 생성합니다. 바로 우리에게 필요한 기능입니다! Ingress 객체는 Ingress 컨트롤러로 구현되며, 이 솔루션에서는 엔터프라이즈급 F5 NGINX Ingress Controller를 사용합니다. 이 컨트롤러는 NGINX Plus를 기반으로 합니다.

이 솔루션의 또 다른 핵심 구성 요소가 경계 경로 프로토콜 (BGP)이라는 레이어 3 라우팅 프로토콜이라는 점이 의외일 수 있습니다. 하지만 훌륭한 솔루션이 반드시 복잡할 필요는 없습니다!

「클러스터로 연결하기」에서 설명한 솔루션은 실제로 네 가지 구성 요소로 이루어져 있습니다:

iBGP 네트워크 – 내부 BGP(iBGP)는 데이터 센터의 자율 시스템(AS) 내에서 라우팅 정보를 교환하는 데 사용되며, 네트워크의 안정성과 확장성을 보장하는 데 도움이 됩니다. 대부분의 데이터 센터에는 이미 iBGP가 구축되어 있으며 네트워크 팀에서 이를 지원하고 있습니다.
Project Calico CNI 네트워킹 – Project Calico는 온프레미스 데이터 센터의 환경을 유연하게 연결하는 동시에 트래픽 흐름을 세밀하게 제어할 수 있는 오픈 소스 네트워킹 솔루션입니다. Kubernetes 클러스터의 네트워킹에는 BGP가 활성화된 Project Calico의 CNI 플러그인을 사용합니다. 이를 통해 Pod에 할당되는 IP 주소 풀을 제어할 수 있어 네트워킹 문제를 신속하게 파악하는 데 도움이 됩니다.
NGINX Plus 기반 NGINX Ingress Controller – NGINX Ingress Controller를 사용하면 Pod의 서비스 엔드포인트 IP 주소를 모니터링하고, 트래픽 처리를 중단하지 않고도 업스트림 서비스 목록을 자동으로 재구성할 수 있습니다. 또한 애플리케이션 팀은 능동 상태 확인, mTLS, JWT 기반 인증을 비롯한 NGINX Plus의 다양한 엔터프라이즈급 레이어 7 HTTP 기능을 활용할 수 있습니다.
에지의 리버스 프록시로서의 NGINX Plus – NGINX Plus는 Kubernetes 클러스터의 에지에서 리버스 프록시로 작동하며, 데이터 센터의 스위치 및 라우터와 Kubernetes 클러스터의 내부 네트워크 사이에 경로를 제공합니다. 이는 Kubernetes LoadBalancer 객체를 대체하는 역할을 하며 BGP에 Quagga를 사용합니다.

이 다이어그램은 솔루션 아키텍처와 솔루션 구성 요소가 통신에 사용하는 프로토콜을 보여 주며, 요청 처리 중 데이터가 교환되는 순서를 나타내는 것은 아닙니다.