NGINX Gateway Fabric 릴리스 1.2.0 발표

Kubernetes Gateway API의 준수 구현인 NGINX Gateway Fabric에 대한 최신 소식을 공유하게 되어 기쁩니다. 최근 여러 가지 흥미로운 새로운 기능과 개선 사항이 포함된 버전 1.2.0으로 업데이트했습니다. 이 릴리스에서는 플랫폼의 기능을 향상하고 사용자의 요구 사항을 충족하는 데 중점을 두고 있습니다. F5 NGINX Plus 지원을 포함시키고 가장 요구되는 사용 사례도 포괄할 수 있도록 API 표면을 확장했습니다. 저희는 이러한 개선 사항을 통해 모든 사용자에게 더 나은 경험을 제공하고, 더욱 효율적으로 목표를 달성하는 데 도움이 될 것으로 믿습니다.

그림 1 : NGINX Gateway Fabric의 디자인 및 아키텍처 개요

NGINX Gateway Fabric 1.2.0 개요:

• NGINX Plus 지원 – NGINX Gateway Fabric은 이제 데이터 평면에 대해 NGINX Plus를 지원하여 가용성이 개선되고 자세한 측정항목과 실시간 관찰 대시보드가 제공됩니다.
• BackendTLSPolicy – TLS 검증을 통해 NGINX Gateway Fabric은 백엔드 애플리케이션의 신원을 확인하여 악성 애플리케이션에 의한 잠재적인 연결 하이재킹으로부터 보호합니다. 또한 TLS는 클러스터 내의 트래픽을 암호화하여 클라이언트와 백엔드 애플리케이션 간의 안전한 통신을 보장합니다.
• URLRewrite – NGINX Gateway Fabric은 이제 Route 객체에서 URL 다시 쓰기를 지원합니다. 이 기능을 사용하면 원래 요청 URL을 쉽게 수정하고 더 적합한 대상으로 리디렉션할 수 있습니다. 이렇게 하면 백엔드 애플리케이션의 API가 변경되더라도 클라이언트에 노출하는 API의 일관성을 유지할 수 있습니다.
• 제품 원격 측정 – 이제 NGINX Gateway Fabric에 제품 원격 측정 기능이 제공되므로 사용자 환경에서 제품을 사용하는 방법을 학습하여 인프라의 운영 효율성을 더욱 개선하는 데 도움을 줄 수 있습니다. 또한, 우리는 회의를 통해 이러한 통찰력을 커뮤니티와 정기적으로 공유할 계획입니다.

아래에서 새로운 기능을 자세히 살펴보겠습니다.

NGINX Gateway Fabric 1.2.0의 새로운 기능은 무엇입니까?

NGINX 플러스 지원

NGINX Plus를 지원하는 NGINX Gateway Fabric 버전 1.2.0이 출시되어 사용자에게 많은 새로운 이점을 제공합니다. 새로운 업그레이드를 통해 사용자는 추가 Prometheus 메트릭, 동적 업스트림 리로드, NGINX Plus 대시보드를 포함한 NGINX Plus의 고급 기능을 배포에 활용할 수 있습니다. 이 업그레이드를 통해 사용자 환경에 대해 NGINX로부터 직접 지원을 받을 수 있는 옵션도 제공됩니다.

추가 Prometheus 메트릭

NGINX Plus를 데이터 플레인으로 사용하는 경우 일반적으로 NGINX 오픈 소스에서 얻는 지표와 함께 추가적인 고급 지표가 내보내집니다. 주요 내용으로는 http 요청, 스트림, 연결 등을 포함한 다양한 측정 항목이 있습니다. 전체 목록은 NGINX의 Prometheus 내보내기 프로그램에서 편리하게 확인할 수 있습니다. 하지만 이 내보내기 프로그램은 NGINX Gateway Fabric에 꼭 필요한 것은 아니라는 점에 유의하세요. Prometheus나 Prometheus 호환 스크래퍼를 설치하면 이러한 메트릭을 관찰 스택으로 스크래핑하고 아키텍처 내의 일관된 계층을 사용하여 대시보드와 알림을 구축할 수 있습니다. Prometheus 메트릭은 HTTP 포트 9113을 통해 NGINX Gateway Fabric에서 자동으로 사용할 수 있습니다. Pod 템플릿을 업데이트하여 기본 포트를 변경할 수도 있습니다. 간단한 설정을 원하시면 GitHub 페이지를 방문하여 Prometheus를 배포하고 구성하여 수집을 시작하는 방법에 대한 자세한 내용을 알아보세요. 또는, 설정을 건너뛰고 메트릭만 보고 싶은 경우 다음 섹션에서 설명하는 NGINX Plus 대시보드를 사용할 수 있습니다. 클러스터에 Prometheus를 설치한 후 백그라운드에서 포트 포워딩을 실행하여 대시보드에 액세스할 수 있습니다. kubectl -n monitoring port-forward svc/prometheus-server 9090:80

그림 2: NGINX Gateway Fabric 연결이 수락되었음을 보여주는 Prometheus Graph

위의 설정은 기본 NGINX 오픈 소스를 데이터 플레인으로 사용하는 경우에도 작동합니다! 하지만 NGINX Plus가 제공하는 추가적인 측정항목은 볼 수 없습니다. 클러스터의 크기와 범위가 커짐에 따라 NGINX Plus 메트릭이 용량 계획 문제, 인시던트, 심지어 백엔드 애플리케이션 오류까지 신속하게 해결하는 데 어떻게 도움이 될 수 있는지 살펴보는 것이 좋습니다.

동적 업스트림 리로드

NGINX Plus와 함께 설치되면 NGINX Gateway Fabric이 자동으로 활성화하는 동적 업스트림 리로드를 통해 NGINX Gateway Fabric이 NGINX를 다시 로드하지 않고도 NGINX 구성을 업데이트할 수 있습니다. 전통적으로 NGINX가 다시 로드되면 기존 연결은 이전 작업자 프로세스에 의해 처리되고 새로 구성된 작업자는 새 연결을 처리합니다. 모든 이전 연결이 완료되면 이전 작업자는 중지되고 NGINX는 새로 구성된 작업자만으로 작업을 계속 진행합니다. 이런 식으로 NGINX 오픈 소스에서도 구성 변경이 우아하게 처리됩니다. 그러나 NGINX에 부하가 많이 걸릴 때 기존 작업자와 새 작업자를 모두 유지하면 리소스 오버헤드가 발생하여 문제가 발생할 수 있습니다. 특히 NGINX Gateway Fabric을 최대한 간소하게 실행하려는 경우 더욱 그렇습니다. NGINX Plus의 동적 업스트림 다시 로드 기능은 구성 변경에 대한 API 엔드포인트를 제공하여 NGINX Gateway Fabric이 자동으로 해당 변경 사항을 사용함으로써 이러한 문제를 해결하고, 다시 로드 프로세스 중에 이전 및 새 작업자를 처리하기 위한 추가적인 리소스 오버헤드의 필요성을 줄입니다. NGINX Gateway Fabric을 더 자주 변경할수록 다시 로드하는 작업도 더 자주 발생합니다. 현재 NGF 설치에서 재로드가 얼마나 자주 또는 언제 발생하는지 궁금하다면 Prometheus 메트릭 nginx_gateway_fabric_nginx_reloads_total을 살펴보면 됩니다. 이 문제에 대해 더 자세하고 자세히 알아보려면 Nick Shadrin의 기사를 여기에서 확인하세요! 다음은 Prometheus 대시보드에서 NGINX Gateway Fabric을 두 번 배포한 환경의 메트릭 예입니다.

그림 3: NGINX Gateway Fabric이 총 재로드를 보여주는 Prometheus 그래프

NGINX 플러스 대시보드

이전에 언급했듯이 Prometheus 설치나 관찰 스택 없이 NGINX Plus 메트릭을 빠르게 볼 방법을 찾고 있다면 NGINX Plus 대시보드를 통해 성능 메트릭을 실시간으로 모니터링하여 인시던트를 해결하고 리소스 용량을 살펴보는 데 사용할 수 있습니다. 대시보드에서는 NGINX Plus가 제공하는 모든 지표에 대한 다양한 보기가 제공되며 내부 포트에서 쉽게 접근할 수 있습니다. 대시보드 기능이 어떤지 직접 확인해보려면 demo.nginx.com 에서 대시보드 데모 사이트를 확인하세요. NGINX Gateway Fabric 설치에서 NGINX Plus 대시보드에 액세스하려면 포트 포워딩을 통해 로컬 머신의 포트 8765로 연결을 전달합니다. kubectl port-forward -n nginx-gateway 8765:8765 다음으로, 원하는 브라우저를 열고 주소창에 http://localhost:8765/dashboard.html을 입력합니다.

그림 4: NGINX Plus 대시보드 개요

백엔드TLSPolicy

이 릴리스에서는 BackendTLSPolicy 에 대한 대망의 지원이 추가되었습니다. BackendTLSPolicy는 NGINX Gateway Fabric과 애플리케이션 간에 암호화된 TLS 통신을 도입하여 통신 채널의 보안을 크게 강화합니다. 다음은 신뢰할 수 있는 인증 기관(CA)에 대해 서버 인증서를 검증할 때 TLS 암호 및 프로토콜과 같은 설정을 지정하여 정책을 적용하는 방법을 보여주는 예입니다. BackendTLSPolicy를 사용하면 사용자는 NGF와 백엔드 간의 트래픽을 보호할 수 있습니다. 또한 최소 TLS 버전과 암호화 제품군을 설정할 수 있습니다. 이렇게 하면 악성 애플리케이션이 연결을 하이재킹하는 것을 방지하고 클러스터 내의 트래픽을 암호화할 수 있습니다. 백엔드 TLS 종료를 구성하려면 먼저 사용하려는 CA 인증으로 ConfigMap을 만듭니다. 내부 Kubernetes 인증서 관리에 대한 도움이 필요하면 이 가이드를 확인하세요.

친절한: ConfigMap
apiVersion: v1
메타데이터:
이름: 백엔드-인증서
데이터:
ca.crt: 
< -----인증서 시작-----
-----인증서 끝-----
>

다음으로, 보안 앱 서비스를 타겟으로 하고 이전 단계에서 만든 ConfigMap을 참조하는 BackendTLSPolicy를 만듭니다.

api 버전: gateway.networking.k8s.io/v1alpha2
종류: BackendTLSPolicy
메타데이터:
이름: backend-tls
스펙:
targetRef:
그룹: ''
종류: 서비스
이름: secure-app
네임스페이스: default
tls:
caCertRefs:
- 이름: backend-cert
그룹: ''
종류: ConfigMap
호스트 이름: secure-app.example.com

URL 다시 쓰기

URLRewrite 필터를 사용하면 들어오는 요청의 원래 URL을 수정하여 성능에 전혀 영향을 주지 않고 다른 URL로 리디렉션할 수 있습니다. 이 기능은 백엔드 애플리케이션이 노출된 API를 변경하지만 기존 클라이언트에 대한 이전 버전과의 호환성을 유지하려는 경우에 특히 유용합니다. 또한 이 기능을 사용하면 다양한 API URL을 사용하여 요청을 다른 애플리케이션으로 리디렉션하는 동안 클라이언트에게 일관된 API URL을 노출하여 클라이언트의 편의성과 성능을 위해 여러 다른 API의 기능을 결합한 "경험" API를 제공할 수 있습니다. 시작하려면 NGINX 게이트웨이 패브릭에 대한 게이트웨이를 만들어 보겠습니다. 이를 통해 HTTP 리스너를 정의하고 최적의 성능을 위해 포트 80을 구성할 수 있습니다.

api 버전: gateway.networking.k8s.io/v1
종류: 게이트웨이
메타데이터:
이름: cafe
스펙:
gatewayClassName: nginx
리스너:
- 이름: http
포트: 80
프로토콜: HTTP

HTTPRoute 리소스를 만들고 요청 필터를 구성하여 /coffee에 대한 모든 요청을 /beans로 다시 작성해 보겠습니다. 백엔드가 처리할 /latte 접두사를 포함하도록 다시 작성된 /latte 엔드포인트를 제공할 수도 있습니다("/latte/126"은 "/126"이 됩니다).

api 버전: gateway.networking.k8s.io/v1
종류: HTTPRoute
메타데이터:
이름: 커피
스펙:
parentRefs:
- 이름: 카페
sectionName: http
호스트 이름:
- "cafe.example.com"
규칙:
- 일치:
- 경로:
유형: PathPrefix
값: /커피
필터:
- 유형: URLRewrite
urlRewrite:
경로:
유형: ReplaceFullPath
replaceFullPath: /beans
backendRefs:
- 이름: 커피
포트: 80
- 일치:
- 경로:
유형: PathPrefix
값: /latte
필터:
- 유형: URLRewrite
urlRewrite:
경로:
유형: ReplacePrefixMatch
replacePrefixMatch: /
backendRefs:
- 이름: 커피
포트: 80

HTTP 재작성 기능은 클라이언트 측 엔드포인트와 백엔드와의 매핑 방식 간의 유연성을 보장하는 데 도움이 됩니다. 또한 한 URL에서 다른 URL로 트래픽을 리디렉션할 수 있어 특히 콘텐츠를 새로운 웹사이트나 API 트래픽으로 마이그레이션할 때 유용합니다. NGINX Gateway Fabric은 경로 기반 재작성을 지원하지만 현재 경로 기반 리디렉션은 지원하지 않습니다. 알려주세요 이 기능이 귀하의 환경에 필요한 경우.

제품 원격 측정

우리는 1.2 릴리스의 일부로 피드백을 수동적으로 수집하는 메커니즘으로 제품 원격 측정을 포함하기로 결정했습니다. 이 기능은 사용자 환경에서 다양한 측정 항목을 수집하여 24시간마다 데이터 수집 플랫폼으로 전송합니다. 개인 식별 정보(PII)는 수집되지 않으며, 수집되는 항목의 전체 목록은 여기에서 확인할 수 있습니다. 당사는 원격 측정 기능에 대한 완전한 투명성을 제공하기 위해 노력하고 있습니다. 수집하는 모든 필드를 문서화하고, 사용자는 코드를 통해 수집한 데이터의 유효성을 검사할 수 있지만, 이를 완전히 비활성화할 수도 있습니다. 저희는 커뮤니티 회의 에서 수집한 통계에 기반한 흥미로운 관찰 결과를 커뮤니티와 정기적으로 검토할 계획이니, 꼭 참석해 주시기 바랍니다!

리소스

NGINX Gateway Fabric 1.2.0의 전체 변경 사항은 릴리스 노트를 참조하세요. NGINX Plus와 함께 Kubernetes용 NGINX Gateway Fabric을 사용해 보려면 오늘 무료 30일 평가판을 시작하거나 당사에 문의하여 사용 사례에 대해 논의하세요 . 참여하고 싶거나, 앞으로 어떤 일이 일어날지 확인하고 싶거나, NGINX Gateway Fabric의 소스 코드를 보고 싶다면 GitHub 의 저장소를 확인하세요! 우리는 매주 월요일 오전 9시 태평양 표준시/오후 5시 그리니치 표준시에 2주에 한 번씩 커뮤니티 회의를 갖습니다. 회의 링크, 업데이트, 의제 및 메모는 NGINX Gateway Fabric 회의 일정 에서 확인할 수 있습니다. 링크는 항상 GitHub readme에서도 제공됩니다.