Red Hat OCP 및 Kubernetes를 위한 외부 로드 밸런서로 NGINX Plus 구성

컨테이너 오케스트레이션의 세계에서 우리가 항상 접하는 두 가지 이름이 있습니다. RedHat OpenShift 컨테이너 플랫폼(OCP) 및 쿠버네티스. 아마 여러분도 알고 계시겠지만 OpenShift는 다른 많은 컨테이너 오케스트레이션 플랫폼과 마찬가지로 Kubernetes를 기반으로 사용합니다. 외부 트래픽을 Kubernetes 또는 OpenShift 환경으로 라우팅하는 것은 항상 두 가지 면에서 약간 어려웠습니다.

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

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

NGINX-LB-Operator는 NGINX Plus 또는 NGINX Controller 지원 계약에 포함되지 않습니다. GitHub 에서 버그를 보고하거나 문제 해결에 대한 지원을 요청할 수 있습니다.

Kubernetes 및 NGINX 기술 - 리뷰

NGINX-LB-Operator는 여러 가지 Kubernetes와 NGINX 기술을 사용하므로 모두가 동일한 내용을 이해할 수 있도록 간단히 살펴보겠습니다. 이미 잘 알고 계시다면 NGINX Load Balancer Operator 로 넘어가셔도 됩니다.

쿠버네티스 컨트롤러 및 운영자

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

• 컨트롤러 - 쿠버네티스 시스템의 핵심 부분. 그들은 특정 Kubernetes 리소스에 대한 "감시"를 생성하고 각 리소스가 변경될 때 원하는 상태에 도달하기 위해 필요한 단계를 수행합니다. 고객 대화에서 가장 일반적으로 논의되는 Kubernetes 컨트롤러는 "Ingress 컨트롤러"입니다.
• 연산자 - 사용자 정의 리소스 정의(CRD)를 정의하고 활용하여 애플리케이션과 해당 구성 요소를 관리하는 사용자 정의 컨트롤러입니다.

Kubernetes용 NGINX Ingress 컨트롤러

NGINX에는 두 가지 주요 Ingress 컨트롤러 옵션이 있는데, GitHub에서 이름이 너무 비슷해서 두 옵션을 구별하는 것이 약간 혼란스러울 수 있습니다. 이 주제에 대해서는 이전 블로그 에서 자세히 논의했지만 여기서는 간략하게 살펴보겠습니다.

• kubernetes/ingress-nginx – Kubernetes 오픈 소스 커뮤니티에서 지원 및 유지 관리하는 Ingress 컨트롤러입니다. 사용 편의성을 위해 이를 "커뮤니티의 Ingress 컨트롤러"라고 부릅니다. 놀랍지 않게도 NGINX 오픈 소스를 기반으로 합니다. 불행히도 성능을 저하시키는 경향이 있는 타사 Lua 모듈로 지원되는 추가 기능을 제공합니다.

• nginxinc/kubernetes-ingress – F5의 NGINX 팀이 유지 관리하는 Ingress 컨트롤러입니다. 두 가지 버전이 있습니다. 하나는 NGINX 오픈 소스(속도를 위해 구축)용이고, 다른 하나는 NGINX Plus(속도를 위해 구축되었지만 상업적으로 지원되고 추가 엔터프라이즈급 기능 제공)용입니다. 우리는 이것을 "NGINX(또는 우리의) Ingress 컨트롤러"라고 부릅니다.

  표준 Kubernetes Ingress 리소스를 사용하여 두 가지 Ingress 컨트롤러를 모두 관리할 수 있습니다. 또한 Ingress 사양에서 제공하는 제한된 기능을 확장하기 위해 Annotation 과 ConfigMaps를 지원하지만, 이런 방식으로 리소스를 확장하는 것은 이상적이지 않습니다.

  Ingress 컨트롤러의 릴리스 1.6.0 이상에는 더 나은 솔루션이 포함되었습니다. 즉, Kubernetes API를 확장하고 Kubernetes 네이티브 방식으로 추가 기능을 제공하는 VirtualServer 및 VirtualServerRoute 라는 사용자 정의 NGINX Ingress 리소스 입니다. 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)에 대한 제어 루프 기능을 수행하므로 Kubernetes 플랫폼의 도구(표준 Ingress 리소스 또는 NGINX Ingress 리소스)를 사용하여 관리해야 합니다.

외부 로드 밸런서

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

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

이런 경우에는 외부 로드 밸런서 구성을 Kubernetes 상태와 병합하고 Kubernetes Operator를 통해 NGINX Controller API를 구동하는 것이 좋습니다. 이 다이어그램은 외부 로드 밸런서를 관리하기 위한 연산자( 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에서는 NGINX Controller용 인증 컬렉션을 포함해 다양한 제품에 대한 Ansible 컬렉션을 이미 게시했습니다. 따라서 외부 NGINX Plus 인스턴스를 관리하고 NGINX Controller와 인터페이스하는 Operator를 구축하는 것은 매우 간단합니다.

Operator SDK를 사용하여 네임스페이스 또는 클러스터 범위로 배포할 수 있고 소수의 사용자 정의 리소스를 감시하는 NGINX Load Balancer Operator인 NGINX-LB-Operator를 만들었습니다. 사용자 정의 리소스는 NGINX Controller 객체(인증서, 게이트웨이, 애플리케이션 및 구성 요소)에 직접 매핑되므로 Kubernetes에서 NGINX Controller의 애플리케이션 중심 모델을 직접 나타냅니다. Kubernetes에 구성된 사용자 정의 리소스는 NGINX-LB-Operator 에 의해 수집되며, 이후 NGINX Controller에 동등한 리소스를 생성합니다.

NGINX-LB-Operator를 사용하면 NGINX Controller의 선언적 API를 사용하여 외부 NGINX Plus 인스턴스의 구성을 관리할 수 있습니다. NGINX Controller가 외부 인스턴스를 관리하기 때문에 모니터링 및 알림의 추가 이점과 NGINX Controller가 제공하는 심층적인 애플리케이션 통찰력을 얻을 수 있습니다.

이 다이어그램은 다음 사항을 보여줍니다.

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

자세한 배포 지침과 샘플 애플리케이션은 GitHub 에서 제공됩니다. 롤 플레이를 좋아하지 않거나 TL;DR 버전을 보려고 왔다면 지금 당장 그곳으로 가세요.

샘플 배포

그럼 롤플레잉을 해볼까요. 내가 수잔이 되고, 너는 데이브가 되면 돼.

데이브는 당신이 가장 좋아하는 상상 속 대기업에서 사업을 운영합니다. 아이들과 함께 일하고 최신 동향을 파악하는 등의 작업을 수행하므로 모든 애플리케이션과 마이크로서비스를 OpenShift에 배포하고 Ingress의 경우 Kubernetes용 NGINX Plus Ingress Controller를 사용합니다. 모든 애플리케이션은 OpenShift 프로젝트(네임스페이스)로 배포되고 NGINX Plus Ingress Controller는 자체 Ingress 네임스페이스에서 실행됩니다.

여러분은 기본 Ingress 사양에서 사용할 수 있는 기능에 만족하지 못했고, ConfigMaps와 Annotation이 조금 어색하다고 생각했습니다. NGINX Plus Ingress Controller가 자체 CRD를 지원할 것이라고 발표했을 때 여러분이 기뻐했던 이유가 바로 이겁니다. 오늘날 애플리케이션 개발자는 VirtualServer 및 VirtualServerRoutes 리소스를 사용하여 NGINX Plus Ingress Controller에 대한 애플리케이션 배포를 관리하고 OpenShift 내에서 내부 라우팅 및 오류 처리를 구성합니다.

때로는 NGINX Plus Ingress Controller에서도 사용할 수 있는 TransportServer 사용자 정의 리소스 덕분에 HTTP가 아닌 서비스를 노출할 수도 있습니다. 개발자는 자신의 프로젝트 네임스페이스에서 사용자 정의 리소스를 정의할 수 있으며, 이후 NGINX Plus Ingress Controller가 이를 수집하여 즉시 적용합니다. 정말 멋진 기능이지만, OpenShift 클러스터의 가장자리에 있는 외부 네트워크 로드 밸런서를 똑같이 쉽게 관리할 수 있었으면 좋겠습니다. Ingress 레이어를 확장해야 할 때마다 항상 허리가 아프게 됩니다.

토요일 밤이고 당신은 디스코에 있어야 할 텐데, 어제 당신은 다시 Ingress 층을 올라야 했고 지금은 허리 아랫부분에 통증이 있습니다. 핑! 연기 구름 속에서 요정 대모 수잔이 나타납니다.

"안녕, 데이브" 그녀가 말한다.

"누구세요? "내 페르시아 카펫에 무슨 짓을 한 거야?"라고 당신은 대답합니다.

수잔은 당신의 태도를 무시한 채 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 컨트롤러는 외부 NGINX Plus 로드 밸런서에서 메트릭을 수집하여 사용자가 이미 즐기고 있는 애플리케이션 중심 관점에서 이를 표시합니다. 다음에 NGINX Plus Ingress 계층을 확장하면 NGINX-LB-Operator가 자동으로 NGINX Controller와 외부 NGINX Plus 로드 밸런서를 업데이트합니다. 허리 통증은 더 이상 없습니다!

결론

쿠버네티스는 컨테이너화된 애플리케이션을 관리하기 위해 구축된 플랫폼입니다. NGINX Controller는 애플리케이션 부하 분산을 고려하고 관리하기 위한 애플리케이션 중심 모델을 제공합니다. NGINX-LB-Operator는 두 가지를 결합하며 기본 인프라에 대해 걱정할 필요 없이 전체 스택을 종단 간에 관리할 수 있게 해줍니다. NGINX-LB-Operator에 대한 자세한 기술 정보와 전체 샘플을 살펴보려면 GitHub 로 이동하세요.

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

• NGINX Controller 무료 체험판을 요청하세요
• 귀하의 사용 사례에 대해 논의 하려면 저희에게 연락하세요.
• OpenShift용 NGINX Ingress Operator 가져오기
• 강사가 진행하는 코스 에 등록하세요