Red Hat OCP 및 Kubernetes용 외부 로드 밸런서로 NGINX Plus 구성하기

NGINX | 2020년 7월 24일

컨테이너 오케스트레이션 분야에서 늘 접하게 되는 두 가지 이름이 있습니다. 바로 RedHat OpenShift Container Platform(OCP)과 Kubernetes입니다. 아시다시피 OpenShift는 Kubernetes를 기반으로 하며, 다른 많은 컨테이너 오케스트레이션 플랫폼도 마찬가지입니다. 외부 트래픽을 Kubernetes 또는 OpenShift 환경으로 라우팅하는 작업은 다음 두 가지 측면에서 늘 다소 까다로웠습니다:

Kubernetes 내부에 배포된 서비스를 외부에 노출합니다. 해결책은 NGINX Plus Ingress Controller와 같은 Ingress 컨트롤러를 사용하는 것입니다. 자세한 내용은 블로그 게시물 Red Hat OpenShift에서 NGINX Ingress Operator 시작하기에서 확인할 수 있습니다.
Kubernetes 노드 간 트래픽 부하 분산. 이 문제를 해결하기 위해 조직에서는 일반적으로 외부 하드웨어 또는 가상 로드 밸런서나 클라우드 네이티브 솔루션을 선택합니다. 하지만 NGINX Plus를 외부 로드 밸런서로 사용하여 성능을 개선하고 기술 투자를 간소화할 수도 있습니다.

이 블로그에서는 NGINX Plus를 사용하여 두 번째 문제를 간단하고 효율적으로 해결하는 동시에, 애플리케이션 개발 팀이 Kubernetes 내부의 Ingress 구성과 외부 로드 밸런서 구성을 모두 관리할 수 있도록 하는 방법을 중점적으로 설명합니다. 시작하는 데 도움이 되는 참조 아키텍처로 nginx-lb-operator 프로젝트를 GitHub에 만들었습니다. NGINX Load Balancer Operator(NGINX-LB-Operator)는 NGINX Controller용 Ansible 기반 Operator로, Red Hat Operator Framework와 SDK를 사용하여 만들었습니다. NGINX-LB-Operator는 NGINX Controller의 선언적 API를 구동하여 Kubernetes 클러스터 내에서 새 서비스가 추가되거나 Pod가 변경되거나 배포가 확장될 때 외부 NGINX Plus 로드 밸런서의 구성을 업데이트합니다.

NGINX-LB-Operator는 NGINX Plus 또는 NGINX Controller 지원 계약의 적용 대상이 아닙니다. 버그를 신고하거나 문제 해결 지원을 요청하려면 GitHub을 이용해 주세요.

Kubernetes 및 NGINX 기술 – 개요

NGINX-LB-Operator는 여러 Kubernetes 및 NGINX 기술을 기반으로 하므로, 모두가 같은 내용을 이해할 수 있도록 간단히 살펴보겠습니다. 이미 이러한 기술에 익숙하다면 NGINX 로드 밸런서 오퍼레이터로 바로 넘어가셔도 됩니다.

Kubernetes 컨트롤러 및 오퍼레이터

Kubernetes는 느슨하게 결합된 중앙 API를 중심으로 구축된 오케스트레이션 플랫폼입니다. 이 API는 리소스 정의 모음과 함께 해당 리소스를 모니터링하고 관리하는 컨트롤러(일반적으로 플랫폼 내에서 Pod로 실행됨)를 제공합니다. Kubernetes API는 확장 가능하며, 컨트롤러의 한 유형인 오퍼레이터를 사용하여 Kubernetes의 기능을 확장할 수 있습니다.

컨트롤러 – Kubernetes 시스템의 핵심 구성 요소입니다. 특정 Kubernetes 리소스를 감시하는 “watch”를 생성하고, 각 리소스가 변경될 때 원하는 상태에 도달하도록 필요한 단계를 수행합니다. 고객과의 대화에서 가장 자주 언급되는 Kubernetes 컨트롤러는 “인그레스 컨트롤러”입니다.
오퍼레이터 – 사용자 정의 리소스 정의(CRD)를 정의하고 활용하여 애플리케이션과 해당 구성 요소를 관리하는 사용자 정의 컨트롤러입니다.

Kubernetes용 NGINX Ingress Controller

NGINX에는 두 가지 주요 Ingress 컨트롤러 옵션이 있으며, GitHub에서 이름이 매우 비슷해 서로 구분하기가 다소 어려울 수 있습니다. 이 주제는 이전 블로그 게시물에서 자세히 다루었지만, 여기서 간단히 살펴보겠습니다:

kubernetes/ingress-nginx – Kubernetes 오픈 소스 커뮤니티에서 지원하고 유지 관리하는 Ingress 컨트롤러입니다. 편의상 이를 ‘커뮤니티 Ingress 컨트롤러’라고 부릅니다. 예상할 수 있듯이 NGINX Open Source를 기반으로 합니다. 타사 Lua 모듈을 통해 활성화되는 추가 기능을 제공하지만, 안타깝게도 이러한 기능은 성능을 저하시키는 경향이 있습니다.
nginxinc/kubernetes-ingress – F5의 NGINX 팀에서 유지 관리하는 Ingress 컨트롤러입니다. 두 가지 버전이 있습니다. 하나는 NGINX Open Source용(속도에 중점을 두고 구축됨)이고, 다른 하나는 NGINX Plus용(역시 속도에 중점을 두고 구축되었지만 상용 지원과 추가 엔터프라이즈급 기능이 제공됨)입니다. 이를 “NGINX(또는 당사의) Ingress 컨트롤러”라고 부릅니다. 표준 Kubernetes Ingress 리소스를 사용하여 두 Ingress 컨트롤러를 모두 관리할 수 있습니다. 또한 어노테이션과 ConfigMap을 지원하여 Ingress 사양에서 제공하는 제한된 기능을 확장하지만, 이런 방식으로 리소스를 확장하는 것은 바람직하지 않습니다. 릴리스 1.6.0 이상 버전의 당사 Ingress 컨트롤러에는 더 나은 솔루션이 포함되어 있습니다. 바로 NGINX Ingress 리소스라는 사용자 지정 리소스입니다. 이 리소스는 VirtualServer 및 VirtualServerRoute로 불리며, Kubernetes API를 확장하고 Kubernetes 네이티브 방식으로 추가 기능을 제공합니다. NGINX Ingress 리소스는 더 많은 NGINX 기능을 제공하며, Ingress에서 고급 부하 분산 기능을 사용하고 블루-그린 및 카나리 릴리스와 회로 차단기 패턴 등을 구현할 수 있게 해 줍니다.

이 세 가지 Ingress 컨트롤러 옵션의 주요 차이점을 요약한 내용은 GitHub 저장소에서 확인하세요.

NGINX 컨트롤러

NGINX Controller는 여러 환경에서 NGINX Plus 인스턴스를 관리하고 성능 및 오류 상태에 관한 핵심 인사이트를 활용할 수 있도록 지원하는 클라우드 독립형 제어 영역입니다. 이 솔루션의 모듈은 애플리케이션 전송(부하 분산) 및 API 관리를 위한 중앙 집중식 구성 관리 기능을 제공합니다. NGINX Controller는 물리, 가상, 클라우드 등 다양한 환경에 배포된 NGINX Plus 인스턴스의 구성을 관리할 수 있습니다. 최종 일관성을 보장하는 선언형 API를 기반으로 구축되었으며, 앱과 해당 구성 요소를 앱 중심의 관점에서 보여 줍니다. CI/CD 파이프라인과 쉽게 연동하고, 인프라를 코드에서 추상화하여 개발자가 본연의 업무에 집중할 수 있도록 설계되었습니다.

Kubernetes의 경우, NGINX Controller는 프런트엔드에 역방향 프록시 또는 API 게이트웨이로 배포된 NGINX Plus 인스턴스를 관리할 수 있습니다. 하지만 NGINX Controller가 NGINX Plus Ingress Controller 자체를 관리하는 것은 적절하지 않습니다. Ingress Controller는 Kubernetes의 핵심 리소스인 Ingress에 대한 제어 루프 기능을 수행하므로, 표준 Ingress 리소스 또는 NGINX Ingress 리소스와 같은 Kubernetes 플랫폼의 도구를 사용하여 관리해야 합니다.

외부 로드 밸런서

Kubernetes용 NGINX Plus Ingress Controller는 Kubernetes 내부의 서비스를 외부에 노출하는 훌륭한 방법이지만, Kubernetes 노드나 클러스터로 유입되는 트래픽을 관리하려면 외부 로드 밸런싱 계층이 필요한 경우가 많습니다. 퍼블릭 클라우드에서 실행하는 경우 외부 로드 밸런서로 NGINX Plus, F5 BIG-IP LTM Virtual Edition 또는 클라우드 네이티브 솔루션을 사용할 수 있습니다. 온프레미스나 프라이빗 클라우드에 배포하는 경우 NGINX Plus 또는 BIG-IP LTM(물리적 또는 가상) 어플라이언스를 사용할 수 있습니다. 다른 로드 밸런서도 있다고 들었지만, 저는 믿지 않습니다 😉 .

외부 로드 밸런서를 관리할 때는 NGINX Controller를 사용하여 외부 NGINX Plus 인스턴스를 직접 관리할 수 있습니다. NGINX Controller의 선언형 API는 CI/CD 파이프라인과 연동할 수 있도록 설계되었으며, 이를 사용해 애플리케이션의 각 구성 요소를 배포할 수 있습니다. 하지만 Ingress 계층이 확장 가능하거나, 동적으로 할당되는 Kubernetes NodePort를 사용하거나, OpenShift Route가 변경될 수 있다면 어떻게 해야 할까요?

이러한 경우에는 외부 로드 밸런서 구성을 Kubernetes 상태와 통합하고 Kubernetes Operator를 통해 NGINX Controller API를 구동하는 것이 좋습니다. 이 다이어그램은 외부 로드 밸런서를 관리하는 이러한 Operator(NGINX-LB-Operator)가 포함된 배포 예시를 보여 주며, NGINX Plus Ingress Controller와 NGINX Controller의 차이점을 강조합니다.

여기서:

Ingress 리소스(파란색 상자) – 표준 Ingress 리소스와 NGINX VirtualServer 리소스가 프로젝트 네임스페이스에 정의되어 있습니다.
파란색 화살표 – Ingress 리소스는 Kubernetes API에 생성되며, 다른 네임스페이스에서 실행 중인 NGINX Plus Ingress Controller가 이를 감지합니다.
사용자 정의 리소스(녹색 상자) – NGINX-LB-Operator와 함께 설치된 CRD의 인스턴스인 사용자 정의 리소스는 프로젝트의 네임스페이스에 정의되며, 동일한 네임스페이스에서 실행되는 NGINX-LB-Operator가 이를 사용합니다.
녹색 화살표 – 리소스는 API에서 생성된 후 NGINX-LB-Operator에 의해 처리됩니다. 동일한 Pod에서 실행되는 로컬 NGINX Plus 인스턴스를 구성하는 Ingress Controller와 달리, NGINX-LB-Operator는 NGINX Controller에 API 호출을 수행합니다.
주황색 화살표 – NGINX Controller는 외부 NGINX Plus 인스턴스가 NGINX Plus Ingress Controller로 부하를 분산하도록 구성합니다.

이 토폴로지에서 사용자 지정 리소스에는 외부 로드 밸런서의 원하는 상태가 포함되며, 업스트림(워크로드 그룹)은 NGINX Plus Ingress Controller로 설정됩니다. NGINX-LB-Operator는 Ingress Pod에 대한 정보를 수집하고 이를 원하는 상태와 병합한 후 NGINX Controller API로 전송합니다.

NGINX 로드 밸런서 오퍼레이터

Kubernetes용 Operator를 작성하는 일은 처음에는 벅찬 작업처럼 보일 수 있지만, Red Hat과 Kubernetes 오픈 소스 커뮤니티에서 Operator Framework를 유지 관리하고 있어 비교적 쉽게 작업할 수 있습니다. Operator SDK를 사용하면 누구나 Go, Ansible 또는 Helm으로 Kubernetes Operator를 만들 수 있습니다. F5는 이미 여러 제품을 위한 Ansible 컬렉션을 게시하고 있으며, 여기에는 NGINX Controller 인증 컬렉션도 포함됩니다. 따라서 외부 NGINX Plus 인스턴스를 관리하고 NGINX Controller와 연동하는 Operator를 구축하는 일은 매우 간단합니다.

저는 Operator SDK를 사용하여 NGINX 로드 밸런서 오퍼레이터인 NGINX-LB-Operator를 만들었습니다. 이 오퍼레이터는 네임스페이스 또는 클러스터 범위로 배포할 수 있으며 몇 가지 사용자 정의 리소스를 감시합니다. 사용자 정의 리소스는 NGINX Controller 객체(Certificate, Gateway, Application, Component)에 직접 매핑되므로 NGINX Controller의 애플리케이션 중심 모델을 Kubernetes에서 그대로 구현합니다. Kubernetes에 구성된 사용자 정의 리소스는 NGINX-LB-Operator에서 감지되며, 이후 NGINX Controller에 이에 상응하는 리소스가 생성됩니다.

NGINX-LB-Operator를 사용하면 NGINX Controller의 선언적 API를 통해 외부 NGINX Plus 인스턴스의 구성을 관리할 수 있습니다. NGINX Controller가 외부 인스턴스를 관리하므로 모니터링 및 알림 기능과 더불어 NGINX Controller가 제공하는 심층적인 애플리케이션 인사이트도 활용할 수 있습니다.

이 다이어그램은 다음을 보여줍니다:

프로젝트 네임스페이스에서 사용자 정의 리소스를 생성하면 Kubernetes API로 전송됩니다.
NGINX-LB-Operator는 새로 구성된 리소스를 감지하고, Ingress 네임스페이스의 Ingress 컨트롤러에서 구성 요소의 원하는 상태와 배포 정보를 수집합니다.
사용자가 정의한 구성과 Ingress 컨트롤러의 현재 상태를 병합한 구성이 NGINX Controller로 전송됩니다.
구성이 요청된 NGINX Plus 인스턴스에 전달되고 NGINX Controller가 새 애플리케이션의 메트릭 수집을 시작합니다.

자세한 배포 지침과 샘플 애플리케이션은 GitHub에서 확인할 수 있습니다. 역할극이 마음에 들지 않거나 요약본만 보러 오셨다면 지금 바로 해당 페이지로 이동하세요.

샘플 배포

그럼 역할극을 해보죠. 저는 Susan을 맡고, 여러분은 Dave를 맡으시면 됩니다.

Dave 역할을 맡은 여러분은 마음에 드는 가상의 대기업에서 한 사업 부문을 운영합니다. 최신 트렌드에 밝고 업계 동향도 훤히 꿰고 있기 때문에 모든 애플리케이션과 마이크로서비스를 OpenShift에 배포하고, Ingress에는 Kubernetes용 NGINX Plus Ingress Controller를 사용합니다. 모든 애플리케이션은 OpenShift 프로젝트(네임스페이스)로 배포되며, NGINX Plus Ingress Controller는 자체 Ingress 네임스페이스에서 실행됩니다.

기본 Ingress 사양에서 제공하는 기능에 만족한 적이 없었고, ConfigMap과 Annotation은 다소 불편하다고 늘 생각했습니다. 그래서 NGINX가 NGINX Plus Ingress Controller에서 자체 CRD 지원을 시작한다고 발표했을 때 매우 기뻤습니다. 현재 애플리케이션 개발자들은 VirtualServer 및 VirtualServerRoutes 리소스를 사용하여 NGINX Plus Ingress Controller에 애플리케이션을 배포하고 OpenShift 내에서 내부 라우팅과 오류 처리를 구성합니다.

때로는 비 HTTP 서비스까지 노출할 수 있는데, 이는 모두 TransportServer 사용자 정의 리소스 덕분입니다. 이 리소스는 NGINX Plus Ingress Controller에서도 사용할 수 있습니다. 개발자는 자신의 프로젝트 네임스페이스에 사용자 정의 리소스를 정의할 수 있으며, 그러면 NGINX Plus Ingress Controller가 이를 감지해 즉시 적용합니다. 정말 훌륭하지만, OpenShift 클러스터 경계의 외부 네트워크 로드 밸런서도 이처럼 손쉽게 관리할 수 있으면 좋겠다는 생각이 듭니다. Ingress 계층을 확장해야 할 때마다 요통이 도지곤 합니다.

토요일 밤이면 디스코장에 가 있어야 하지만, 어제 Ingress 계층을 또 확장하느라 지금은 허리가 아픕니다. 짠! 연기 구름 속에서 요정 대모 수전이 나타납니다.

“안녕, 데이브.” 그녀가 말합니다.

“당신 누구야? 내 페르시아 카펫을 이 꼴로 만들어 놓다니,” 당신이 대답합니다.

당신의 태도는 아랑곳하지 않고, Susan은 이제 GitHub에서 사용할 수 있는 NGINX-LB-Operator에 관해 계속 설명합니다. OpenShift의 에지에 NGINX Plus 클러스터를 배치하고 NGINX Controller를 통해 애플리케이션 중심의 관점에서 이를 관리하면, NGINX Plus 로드 밸런서의 구성 방식을 정의하는 사용자 지정 리소스를 생성할 수 있다고 설명합니다.

NGINX-LB-Operator는 이러한 리소스를 모니터링하고 이를 사용하여 애플리케이션 중심의 구성을 NGINX Controller로 전송합니다. 그러면 NGINX Controller가 필요한 NGINX Plus 구성을 생성하여 외부 NGINX Plus 로드 밸런서에 배포합니다.

최종 사용자는 애플리케이션에 즉시 액세스할 수 있으며, 외부 NGINX Plus 로드 밸런서를 수정해야 하는 변경 사항은 사용자가 직접 제어할 수 있습니다!

NGINX Controller는 외부 NGINX Plus 로드 밸런서에서 메트릭을 수집하여, 기존에 사용하던 것과 동일한 애플리케이션 중심 관점에서 보여 줍니다. 또한 다음에 NGINX Plus Ingress 계층을 확장하거나 축소하면 NGINX-LB-Operator가 NGINX Controller와 외부 NGINX Plus 로드 밸런서를 자동으로 업데이트합니다. 이제 더 이상 번거롭게 작업할 필요가 없습니다!

결론

Kubernetes는 컨테이너화된 애플리케이션을 관리하기 위해 구축된 플랫폼입니다. NGINX Controller는 애플리케이션 부하 분산을 이해하고 관리할 수 있는 애플리케이션 중심 모델을 제공합니다. NGINX-LB-Operator는 이 둘을 결합하여 전체 스택을 엔드 투 엔드로 관리할 수 있게 해주므로 기반 인프라에 대해 걱정할 필요가 없습니다. NGINX-LB-Operator에 대한 자세한 기술 정보와 전체 샘플 안내는 GitHub에서 확인하세요.

당사의 솔루션에 대해 자세히 알아보세요: