블로그 | NGINX

BGP를 사용하여 클러스터로 이동하시겠습니까?

NGINX-F5-수평-검정-유형-RGB의 일부
크리스 아커 썸네일
크리스 아커
2023년 2월 28일 게시

강력한 Kubernetes 환경을 만들고 관리하려면 네트워크 팀과 애플리케이션 팀 간의 원활한 협업이 필요합니다. 그러나 이들의 우선순위와 작업 스타일은 일반적으로 상당히 다르기 때문에 잠재적으로 심각한 결과를 초래할 수 있는 갈등으로 이어집니다. 앱 개발 속도가 느리거나 배포가 지연되거나 심지어 네트워크 다운타임이 발생할 수도 있습니다.

오늘날의 현대적 애플리케이션이 적절한 보안과 확장성을 갖추고 정해진 시간에 제공되려면 두 팀이 공통의 목표를 향해 성공적으로 노력해야만 합니다. 그러면 각 팀의 기술과 전문성을 활용하면서, 그들이 협력하도록 어떻게 도울 수 있을까요?

저희의 백서 ' Get Me to the Cluster' 에서는 네트워크팀과 애플리케이션팀이 충돌 없이 각자의 강점을 결합할 수 있도록 Kubernetes 서비스에 대한 외부 액세스를 활성화하는 솔루션을 자세히 설명합니다.

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

이 솔루션은 베어 메탈 또는 기존 Linux 가상 머신(VM)에서 실행되는 노드와 표준 2계층 스위치, 3계층 라우터를 통해 데이터 센터 내 통신을 위한 네트워킹을 제공하는 온프레미스에서 호스팅되는 Kubernetes 클러스터에 특히 적합합니다. 클라우드 호스팅된 Kubernetes 클러스터에는 적용되지 않습니다. 클라우드 공급업체는 해당 데이터 센터의 핵심 네트워킹이나 관리형 Kubernetes 환경의 네트워킹을 제어할 수 없기 때문입니다.

데이터 센터 내에서 호스팅되는 Kubernetes 클러스터의 다이어그램. 노드와 표준 2계층 스위치, 3계층 라우터가 데이터 센터의 통신을 위한 네트워킹을 제공합니다.

솔루션의 세부 사항을 살펴보기 전에 Kubernetes 클러스터에서 애플리케이션을 노출하는 다른 표준 방식이 온프레미스 배포에 작동하지 않는 이유를 살펴보겠습니다.

  • 서비스 – 동일한 앱을 실행하는 포드를 그룹화합니다. 이는 내부 Pod 간 통신에는 유용하지만, 클러스터 내부에서만 볼 수 있으므로 앱을 외부에 노출하는 데는 도움이 되지 않습니다.
  • NodePort – 클러스터의 모든 노드에서 특정 포트를 열고 해당 앱으로 트래픽을 전달합니다. 이렇게 하면 외부 사용자가 서비스에 액세스할 수 있지만 구성이 정적이고 잘 알려진 하위 포트 번호 대신 높은 번호의 TCP 포트를 사용하고 다른 앱과 포트 번호를 조정해야 하기 때문에 이상적이지 않습니다. 또한 여러 앱 간에 공통 TCP 포트를 공유할 수 없습니다.
  • LoadBalancer – 각 노드의 NodePort 정의를 사용하여 외부 세계에서 Kubernetes 노드로의 네트워크 경로를 생성합니다. 이 기능은 AWS, Google Cloud Platform, Microsoft Azure 및 대부분의 다른 클라우드 공급업체에서 쉽게 구성할 수 있는 기능으로 지원되며, 서비스에 필요한 공용 IP 주소와 일치하는 DNS A 레코드를 제공하므로 클라우드 호스팅 Kubernetes에 적합합니다. 불행히도 온프레미스 클러스터에는 이에 상응하는 것이 없습니다.

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

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

솔루션의 또 다른 핵심 구성 요소가 3계층 라우팅 프로토콜인 BGP( Border Gateway Protocol )라는 사실에 놀라실 수도 있습니다. 하지만 좋은 솔루션은 반드시 복잡할 필요는 없습니다!

Get Me to the Cluster 에 설명된 솔루션은 실제로 4가지 구성 요소로 구성되어 있습니다.

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

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

솔루션 구성 요소가 통신하는 데 사용하는 프로토콜을 나타내는 솔루션 아키텍처를 설명하는 다이어그램

백서를 무료로 다운로드하세요

잘 정의된 구성 요소를 사용하여 솔루션을 구현하기 위해 협력함으로써 네트워크 및 애플리케이션 팀은 최적의 성능과 안정성을 쉽게 제공할 수 있습니다.

당사의 솔루션은 최신 네트워킹 도구, 프로토콜 및 기존 아키텍처를 사용합니다. 비용이 저렴하고 구현, 관리, 지원이 쉽도록 설계되어 팀 간의 연결과 소통이 용이해집니다.

코드가 실행되는 모습을 보고 솔루션을 배포하는 방법을 단계별로 알아보려면 Get Me to the Cluster를 무료로 다운로드하세요 .

F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›

"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."