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 Gateway Fabric 버전 1.2.0이 NGINX Plus를 지원하여 출시되어 사용자에게 많은 새로운 이점을 제공합니다. 새로운 업그레이드를 통해 사용자는 이제 추가 Prometheus 메트릭, 동적 업스트림 재로드 및 NGINX Plus 대시보드를 포함하여 배포에서 NGINX Plus의 고급 기능을 활용할 수 있습니다. 이 업그레이드를 통해 환경에 대한 NGINX에서 직접 지원을 받을 수 있는 옵션도 제공됩니다.
추가 Prometheus 메트릭
NGINX Plus를 데이터 플레인으로 사용하는 동안 NGINX Open Source에서 일반적으로 얻는 메트릭과 함께 추가적인 고급 메트릭이 내보내집니다. 몇 가지 주요 내용으로는 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 그래프
위의 설정은 기본 NGINX Open Source를 데이터 플레인으로 사용하는 경우에도 작동합니다! 그러나 NGINX Plus가 제공하는 추가 메트릭은 볼 수 없습니다. 클러스터의 크기와 범위가 커짐에 따라 NGINX Plus 메트릭이 용량 계획 문제, 인시던트, 심지어 백엔드 애플리케이션 오류를 신속하게 해결하는 데 어떻게 도움이 될 수 있는지 살펴보는 것이 좋습니다.
동적 업스트림 리로드
NGINX Plus와 함께 설치 시 NGINX Gateway Fabric에서 자동으로 활성화되는 동적 업스트림 다시 로드를 통해 NGINX Gateway Fabric은 NGINX 다시 로드 없이 NGINX 구성을 업데이트할 수 있습니다. 전통적으로 NGINX 다시 로드가 발생하면 기존 연결은 이전 작업자 프로세스에서 처리하는 반면 새로 구성된 작업자는 새 연결을 처리합니다. 모든 이전 연결이 완료되면 이전 작업자가 중지되고 NGINX는 새로 구성된 작업자만 사용하여 계속 진행합니다. 이런 방식으로 NGINX 오픈 소스에서도 구성 변경이 우아하게 처리됩니다. 그러나 NGINX에 부하가 많이 걸리는 경우 이전 작업자와 새 작업자를 모두 유지하면 리소스 오버헤드가 생성되어 특히 NGINX Gateway Fabric을 최대한 간소하게 실행하려는 경우 문제가 발생할 수 있습니다. NGINX Plus에서 제공하는 동적 업스트림 다시 로드는 NGINX Gateway Fabric에서 자동으로 사용할 구성 변경에 대한 API 엔드포인트를 제공하여 다시 로드 프로세스 중에 이전 작업자와 새 작업자를 처리하기 위한 추가 리소스 오버헤드의 필요성을 줄임으로써 이 문제를 우회합니다. 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 인증서 관리에 대한 도움말은 이 가이드를 확인하세요 .
URLRewrite 필터를 사용하면 들어오는 요청의 원래 URL을 수정하여 성능에 전혀 영향을 미치지 않고 다른 URL로 리디렉션할 수 있습니다. 이 기능은 백엔드 애플리케이션이 노출된 API를 변경하지만 기존 클라이언트에 대한 이전 버전과의 호환성을 유지하려는 경우에 특히 유용합니다. 또한 이 기능을 사용하여 클라이언트에 일관된 API URL을 노출하는 동시에 다른 API URL을 사용하여 요청을 다른 애플리케이션으로 리디렉션하여 클라이언트의 편의성과 성능을 위해 여러 다른 API의 기능을 결합한 "경험" API를 제공할 수 있습니다. 시작하려면 NGINX 게이트웨이 패브릭에 대한 게이트웨이를 만들어 보겠습니다. 이를 통해 HTTP 리스너를 정의하고 최적의 성능을 위해 포트 80을 구성할 수 있습니다.
HTTPRoute 리소스를 만들고 요청 필터를 구성하여 /coffee에 대한 모든 요청을 /beans로 다시 작성해 보겠습니다. 백엔드가 처리할 /latte 접두사를 포함하도록 다시 작성된 /latte 엔드포인트를 제공할 수도 있습니다("/latte/126"이 "/126"이 됨).
HTTP 재작성 기능은 클라이언트 측의 엔드포인트와 백엔드와 매핑되는 방식 간의 유연성을 보장하는 데 도움이 됩니다. 또한 한 URL에서 다른 URL로 트래픽을 리디렉션할 수 있어 특히 콘텐츠를 새 웹사이트나 API 트래픽으로 마이그레이션할 때 유용합니다. NGINX Gateway Fabric은 경로 기반 재작성을 지원하지만 현재는 경로 기반 리디렉션을 지원하지 않습니다. 이 기능이 환경에 필요한지 알려주세요 .
제품 원격 측정 (Telemetry)
우리는 1.2 릴리스의 일부로 수동적으로 피드백을 수집하는 메커니즘으로 제품 원격 측정을 포함하기로 결정했습니다. 이 기능은 환경에서 다양한 메트릭을 수집하여 24시간마다 데이터 수집 플랫폼으로 전송합니다. PII는 수집되지 않으며 수집되는 전체 목록은 여기 에서 확인할 수 있습니다 . 우리는 원격 측정 기능에 대한 완전한 투명성을 제공하기 위해 최선을 다하고 있습니다. 수집하는 모든 필드를 문서화하고 코드로 수집하는 내용을 검증할 수 있지만, 항상 완전히 비활성화할 수 있는 옵션이 있습니다. 커뮤니티 회의 에서 커뮤니티와 함께 수집한 통계를 기반으로 흥미로운 관찰 결과를 정기적으로 검토할 계획 이므로 꼭 들러주세요!
자원
NGINX Gateway Fabric 1.2.0의 전체 변경 사항은 릴리스 노트를 참조하세요 . NGINX Plus로 Kubernetes용 NGINX Gateway Fabric을 사용해 보려면 오늘 무료 30일 평가판을 시작하거나 저희에게 연락하여 사용 사례에 대해 논의하세요 . 참여하고 싶거나, 앞으로 나올 내용을 보고 싶거나, NGINX Gateway Fabric의 소스 코드를 보고 싶다면 GitHub 에서 저희 리포지토리를 확인하세요 ! 월요일 오전 9시 태평양/오후 5시 GMT에 2주마다 커뮤니티 회의가 있습니다. 회의 링크, 업데이트, 일정 및 메모는 NGINX Gateway Fabric 회의 일정 에 있습니다 . 링크는 항상 GitHub readme에서도 사용할 수 있습니다.
위 내용과 같이 NGINX Gateway Fabric 을 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
쿠버네티스에서 인공 지능(AI) 및 머신 러닝(ML) 워크로드를 실행하는 주요 이점 중 하나는 Ingress Controller를 통해 들어오는 모든 요청에 대한 중앙 제어 지점을 갖는 것입니다. 로드 밸런서 및 API 게이트웨이 역할을 하는 다재다능한 모듈로, 쿠버네티스 환경에서 AI/ML 애플리케이션을 보호하기 위한 견고한 기반을 제공합니다.
통합 도구인 Ingress Controller는 보안 및 성능 측정을 적용하고, 활동을 모니터링하고, 규정 준수를 의무화하는 데 편리한 터치포인트입니다. 더 구체적으로, Kubernetes 환경에서 Ingress Controller에서 AI/ML 애플리케이션을 보호하면 이 블로그에서 살펴보는 몇 가지 전략적 이점이 있습니다.
중앙 집중식 보안 및 규정 준수 제어
Ingress Controller는 Kubernetes 클러스터에 대한 게이트웨이 역할을 하므로 MLOps 및 플랫폼 엔지니어링 팀이 보안 정책을 시행하기 위한 중앙 집중식 지점을 구현할 수 있습니다. 이를 통해 포드별 또는 서비스별로 보안 설정을 구성하는 복잡성이 줄어듭니다. Ingress 수준에서 보안 제어를 중앙 집중화하면 규정 준수 프로세스가 간소화되고 규정 준수 상태를 관리하고 모니터링하기가 더 쉬워집니다.
통합 인증 및 권한 부여
Ingress Controller는 모든 AI/ML 애플리케이션에 대한 액세스에 대한 인증 및 승인을 구현하고 시행하는 논리적인 위치이기도 합니다. 강력한 인증 기관 관리를 추가함으로써 Ingress Controller는 Kubernetes를 위한 제로 트러스트(ZT) 아키텍처를 구축하는 핵심이기도 합니다. ZT는 매우 귀중한 독점 데이터에서 실행되는 민감한 AI 애플리케이션의 지속적인 보안 및 규정 준수를 보장하는 데 필수적입니다.
속도 제한 및 액세스 제어
Ingress Controller는 속도 제한을 시행하여 DDoS 공격이나 과도한 API 호출과 같은 남용으로부터 애플리케이션을 보호하기에 이상적인 곳으로, 이는 공개 AI/ML API에 필수적입니다. 모델 도난 및 데이터 유출과 같은 새로운 AI 위협이 증가함에 따라 속도 제한 및 액세스 제어를 시행하는 것이 무차별 대입 공격으로부터 보호하는 데 더욱 중요해지고 있습니다. 또한 적대자가 비즈니스 로직을 남용하거나 가드레일을 탈옥하여 데이터를 추출하고 학습을 모델링하거나 정보에 가중치를 두는 것을 방지하는 데 도움이 됩니다.
웹 애플리케이션 방화벽(WAF) 통합
많은 Ingress Controller는 노출된 애플리케이션과 서비스를 보호하기 위한 기본 요소인 WAF와의 통합을 지원합니다. WAF는 OWASP 10과 같은 일반적인 웹 취약성과 공격에 대한 추가 보안 계층을 제공합니다. 더욱 중요한 점은 적절하게 조정하면 WAF가 AI/ML 애플리케이션을 겨냥한 보다 집중적인 공격으로부터 보호한다는 것입니다. 지연 시간과 성능이 중요한 AI/ML 앱의 주요 고려 사항은 WAF로 인해 발생할 수 있는 잠재적인 오버헤드입니다. 또한 AI/ML 앱에서 효과적이려면 WAF를 모니터링 및 관찰 대시보드와 알림 구조를 위해 Ingress Controller에 긴밀하게 통합해야 합니다. WAF와 Ingress Controller가 공통 데이터 플레인을 공유할 수 있다면 이상적입니다.
결론: AI/ML 아키텍처 계획 초기에 Ingress Controller 포함
Ingress Controller는 AI/ML 앱을 위한 Kubernetes 애플리케이션 배포에서 매우 중요한 위치를 차지하기 때문에 AI/ML 애플리케이션을 설계하는 과정에서 해당 기능을 포함하는 것이 가장 좋습니다. 이를 통해 기능 중복을 완화하고 AI/ML 애플리케이션 요구 사항에 따라 확장 및 성장할 Ingress Controller에 대한 더 나은 결정을 내릴 수 있습니다. MLOps 팀의 경우 Ingress Controller는 보안을 최우선 순위로 두고 많은 중요한 플랫폼 및 운영 기능에 대한 중앙 제어 지점이 됩니다.
NGINX 시작하기
NGINX는 사용자의 요구 사항을 충족하고 Kubernetes 플랫폼의 보안, 확장성, 관찰성을 향상시키는 데 필요한 포괄적인 도구와 빌딩 블록 세트를 제공합니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
AI 및 머신 러닝(AI/ML) 워크로드는 기업의 운영 및 혁신 방식에 혁명을 일으키고 있습니다. 컨테이너 오케스트레이션 및 관리의 사실상 표준인 Kubernetes 는 하이브리드, 멀티 클라우드 환경에서 확장 가능한 대규모 언어 모델(LLM) 워크로드 및 추론 모델을 구동하기 위한 선택 플랫폼입니다.
Kubernetes에서 Ingress 컨트롤러는 컨테이너화된 애플리케이션을 제공하고 보호하는 데 중요한 역할을 합니다. Kubernetes 클러스터의 가장자리에 배포되어 사용자와 애플리케이션 간의 통신을 처리하는 중심점 역할을 합니다.
이 블로그에서는 Ingress 컨트롤러와 Kubernetes용 F5 NGINX Connectivity Stack이 AI/ML 워크로드에 대한 모델 제공, 실험, 모니터링 및 보안을 단순화하고 효율화하는 데 어떻게 도움이 될 수 있는지 살펴보겠습니다 .
대규모 프로덕션에서 AI/ML 모델 배포
대규모로 AI/ML 모델을 배포할 때 즉시 사용 가능한 Kubernetes 기능과 성능은 다음과 같은 데 도움이 될 수 있습니다.
AI/ML 애플리케이션 릴리스 수명 주기를 가속화하고 단순화합니다.
다양한 환경에서 AI/ML 워크로드 이동성을 지원합니다.
컴퓨팅 리소스 활용의 효율성과 경제성을 개선합니다.
확장성을 제공하고 프로덕션 준비 상태를 달성합니다.
비즈니스 SLA를 충족하도록 환경을 최적화합니다.
동시에 조직은 대규모 프로덕션에서 AI/ML 모델을 제공하고, 실험하고, 모니터링하고, 보호하는 데 어려움을 겪을 수 있습니다.
복잡성이 증가하고 도구가 확산되면서 조직이 온프레미스, 클라우드 및 엣지에서 Kubernetes 환경을 구성, 운영, 관리, 자동화하고 문제를 해결하기가 어려워졌습니다.
Pod 오류 및 재시작, 자동 크기 조정, 매우 높은 요청률 등의 동적 이벤트로 인한 연결 시간 초과 및 오류로 인해 사용자 경험이 저하됩니다 .
집계된 보고와 세부적이고 실시간이며 과거 기록된 지표가 부족하여 복잡한 Kubernetes 환경에서 성능 저하, 가동 중지 시간, 문제 해결 속도가 느리고 어렵습니다.
기존 보안 모델은 느슨하게 결합된 분산 애플리케이션을 보호하도록 설계되지 않았기 때문에 하이브리드, 멀티 클라우드 Kubernetes 환경에서 사이버보안 위협에 노출될 위험이 큽니다 .
F5 NGINX Ingress Controller 와 같은 엔터프라이즈급 Ingress 컨트롤러는 이러한 과제를 해결하는 데 도움이 될 수 있습니다. Ingress 컨트롤러, 로드 밸런서, API 게이트웨이 기능을 결합한 하나의 도구를 활용하면 Kubernetes를 어디에서 실행하든 규모에 맞게 더 나은 가동 시간, 보호 및 가시성을 달성할 수 있습니다. 또한 복잡성과 운영 비용을 줄여줍니다.
NGINX Ingress Controller는 LLM 애플리케이션에 대한 OWASP Top 10 사이버 위협을 완화하고 DoS 공격으로부터 AI/ML 워크로드를 방어하는 데 도움이 되는 F5의 업계 선도적인 Layer 7 앱 보호 기술 과 긴밀하게 통합될 수도 있습니다 .
AI/ML 워크로드를 위한 Ingress 컨트롤러의 이점
Ingress 컨트롤러는 다음 기능을 통해 프로덕션에서 AI/ML 워크로드의 배포 및 실행을 간소화하고 효율화할 수 있습니다.
모델 제공 – Kubernetes 기본 부하 분산, 자동 확장, 속도 제한 및 동적 재구성 기능을 사용하여 중단 없이 앱을 제공합니다.
모델 실험 – 블루-그린 및 카나리아 배포와 A/B 테스트를 구현하여 다운타임 없이 새로운 버전과 업그레이드를 출시합니다.
모델 모니터링 – 앱 상태와 성능에 대한 더 나은 통찰력을 얻기 위해 모델 메트릭을 수집, 표현 및 분석합니다.
모델 보안 – 앱을 사이버보안 위협으로부터 보호하기 위해 사용자 ID, 인증, 권한 부여, 역할 기반 액세스 제어 및 암호화 기능을 구성합니다.
Kubernetes용 NGINX Connectivity Stack에는 NGINX Ingress Controller 와 F5 NGINX App Protect가 포함되어 AI/ML 애플리케이션을 실행하는 Kubernetes 클러스터와 온프레미스 및 클라우드에서 사용자 간에 빠르고 안정적이며 안전한 통신을 제공합니다. 모든 Kubernetes 환경에서 모델 제공, 실험, 모니터링 및 보안을 간소화하고 간소화하여 클라우드 공급자와 사전 패키징된 Kubernetes 오퍼링의 기능을 향상시키고 규모에 따라 더 높은 수준의 보호, 가용성 및 관찰성을 제공합니다.
Kubernetes를 위한 NGINX Connectivity Stack 시작하기
NGINX는 사용자의 요구 사항을 충족하고 Kubernetes 플랫폼의 보안, 확장성 및 가시성을 향상시키는 데 필요한 포괄적인 도구와 빌딩 블록 세트를 제공합니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
당신은 현대적 Platform Ops 또는 DevOps 엔지니어입니다. 당신은 오픈 소스(그리고 아마도 일부 상업용) 도구 라이브러리를 사용하여 개발팀을 위한 새로운 앱과 컨테이너를 테스트, 배포 및 관리합니다. 당신은 개발, 테스트, 스테이징 및 프로덕션 환경에서 이러한 컨테이너와 포드를 실행하기 위해 Kubernetes를 선택했습니다. 당신은 마이크로서비스의 아키텍처와 개념을 받아들였고, 대부분 잘 작동합니다. 그러나 이 여정에서 몇 가지 속도 범프에 부딪혔습니다.
예를 들어, 새로운 클러스터, 서비스 및 애플리케이션을 빌드하고 출시할 때 트래픽을 끊지 않고 이러한 새로운 리소스를 프로덕션에 쉽게 통합하거나 마이그레이션하려면 어떻게 해야 할까요? 기존 네트워킹 어플라이언스는 DNS 레코드, 로드 밸런서, 방화벽 및 프록시에 대한 구성 변경을 구현할 때 다시 로드하거나 재부팅해야 합니다. 이러한 조정은 DNS, 로드 밸런서 및 방화벽 규칙을 업데이트하는 데 "서비스 중단" 또는 "유지 관리 창"이 필요하기 때문에 다운타임을 발생시키지 않고는 재구성할 수 없습니다. 대부분의 경우, 두려운 서비스 티켓을 제출하고 다른 팀이 승인하고 변경을 수행할 때까지 기다려야 합니다.
유지 관리 창은 팀을 도랑에 빠뜨리고, 애플리케이션 제공을 멈추고, "트래픽을 관리하는 더 나은 방법이 있어야 한다!"고 선언하게 만들 수 있습니다. 따라서 빠른 차선으로 돌아갈 수 있는 솔루션을 살펴보겠습니다.
액티브-액티브 멀티 클러스터 로드 밸런싱
여러 개의 Kubernetes 클러스터가 있는 경우 두 클러스터로 동시에 트래픽을 라우팅하는 것이 이상적입니다. 더 나은 옵션은 A/B, 카나리아 또는 블루-그린 트래픽 분할을 수행하고 트래픽의 작은 비율을 테스트로 보내는 것입니다. 이를 위해 NGINX Plus를 ngx_http_split_clients_module.
HTTP Split Clients 모듈은 NGINX Open Source에서 작성되었으며 요청 비율을 키에 따라 분산할 수 있습니다. 이 사용 사례에서 클러스터는 NGINX의 "업스트림"입니다. 따라서 클라이언트 요청이 도착하면 트래픽이 두 클러스터로 분할됩니다. 클라이언트 요청을 결정하는 데 사용되는 키는 사용 가능한 NGINX 클라이언트입니다 $variable. 즉, 모든 요청에 대해 이를 제어하려면 $request_idNGINX에서 모든 수신 요청에 할당한 고유 번호인 변수를 사용합니다.
분할 비율을 구성하려면 각 클러스터에 할당할 백분율을 결정합니다. 이 예에서 K8s Cluster1을 프로덕션용 "대형 클러스터"로 사용하고 Cluster2를 사전 프로덕션 테스트용 "소형 클러스터"로 사용합니다. 스테이징용 소규모 클러스터가 있는 경우 90:10 비율을 사용하고 소규모 클러스터에서 트래픽의 10%를 테스트하여 대규모 클러스터에 새 변경 사항을 롤아웃하기 전에 모든 것이 제대로 작동하는지 확인할 수 있습니다. 너무 위험해 보이면 비율을 95:5로 변경할 수 있습니다. 사실, 0~100% 사이에서 원하는 비율을 선택할 수 있습니다.
대부분의 실시간 프로덕션 트래픽의 경우 두 클러스터가 동일한 크기인 50:50 비율을 원할 것입니다. 하지만 클러스터 크기나 기타 세부 정보에 따라 다른 비율을 쉽게 제공할 수 있습니다. 비율을 0:100(또는 100:0)으로 쉽게 설정하고 다운타임 없이 전체 클러스터를 업그레이드, 패치, 수리 또는 교체할 수 있습니다. NGINX split_clients가 라이브 클러스터로 요청을 라우팅하는 동안 다른 클러스터에서 문제를 해결합니다.
# Nginx Multi Cluster Load Balancing
# HTTP Split Clients Configuration for Cluster1:Cluster2 ratios
# Provide 100, 99, 50, 1, 0% ratios (add/change as needed)
# Based on
# https://www.nginx.com/blog/dynamic-a-b-testing-with-nginx-plus/
# Chris Akker – Jan 2024
#
split_clients $request_id $split100 {
* cluster1-cafe; # All traffic to cluster1
}
split_clients $request_id $split99 {
99% cluster1-cafe; # 99% cluster1, 1% cluster2
* cluster2-cafe;
}
split_clients $request_id $split50 {
50% cluster1-cafe; # 50% cluster1, 50% cluster2
* cluster2-cafe;
}
split_clients $request_id $split1 {
1.0% cluster1-cafe; # 1% to cluster1, 99% to cluster2
* cluster2-cafe;
}
split_clients $request_id $split0 {
* cluster2-cafe; # All traffic to cluster2
}
# Choose which cluster upstream based on the ratio
map $split_level $upstream {
100 $split100;
99 $split99;
50 $split50;
1.0 $split1;
0 $split0;
default $split50;
}
위의 구성을 추가하거나 편집하여 필요한 비율(예: 90:10, 80:20, 60:40 등)에 맞게 조정할 수 있습니다.
참고: NGINX에는 스트림 컨텍스트에서 TCP 연결을 위한 것도 있는데 Split Clients module, 이는 HTTP가 아닌 트래픽에 사용할 수 있습니다. 이는 HTTP 요청 대신 새로운 TCP 연결을 기준으로 트래픽을 분할합니다.
NGINX Plus 키-값 저장소
사용할 수 있는 다음 기능은 NGINX Plus 키-값 저장소 입니다 . 이것은 다양한 데이터 저장 사용 사례에 사용할 수 있는 NGINX 공유 메모리 영역의 키-값 개체입니다. 여기서는 위 섹션에서 언급한 분할 비율 값을 저장하는 데 사용합니다. NGINX Plus를 사용하면 NGINX를 다시 로드하지 않고도 모든 키-값 레코드를 변경할 수 있습니다. 이를 통해 API 호출로 이 분할 값을 변경하여 동적 분할 함수를 만들 수 있습니다.
우리의 예를 기준으로 보면 다음과 같습니다.
{“cafe.example.com”:90}
이 KeyVal 레코드는 다음과 같이 읽힙니다. 키는 "cafe.example.com" 호스트 이름이고 값은 분할 비율에 대해 "90"입니다.
NGINX 구성 파일에 분할 비율을 하드 코딩하는 대신 키-값 메모리를 사용할 수 있습니다. 이렇게 하면 NGINX에서 정적 분할 값을 변경하는 데 필요한 NGINX 재로드가 제거됩니다.
이 예에서 NGINX는 분할 비율에 90:10을 사용하도록 구성되어 있으며, 큰 Cluster1은 90%를 차지하고 작은 Cluster2는 나머지 10%를 차지합니다. 이는 키-값 레코드이므로 구성을 다시 로드하지 않고도 NGINX Plus API를 사용하여 이 비율을 동적으로 변경할 수 있습니다 ! 분할 클라이언트 모듈은 변경하자마자 바로 다음 요청에서 이 새로운 비율 값을 사용합니다.
KV 레코드를 생성하려면 50/50 비율로 시작하세요.
NGINX Plus에 API 명령을 보내어 KeyValue 저장소에 새 레코드를 추가합니다.
curl -iX POST -d '{"cafe.example.com":50}' http://nginxlb:9000/api/8/http/keyvals/split
KV 레코드를 변경하고 90/10 비율로 변경합니다.
HTTP PATCH 메서드를 사용하여 메모리에서 KeyVal 레코드를 업데이트하여 KeyVal 분할 비율을 90으로 변경합니다.
다음으로, 사전 프로덕션 테스트 팀은 새로운 애플리케이션 코드가 준비되었는지 확인하고, 이를 대규모 Cluster1 에 배포하고 비율을 100%로 변경합니다. 그러면 모든 트래픽이 Cluster1 로 즉시 전송되고 트래픽 중단, 서비스 중단, 유지 관리 기간, 재부팅, 다시 로드 또는 많은 티켓 없이 새로운 애플리케이션이 "라이브" 상태가 됩니다. 선택한 시점에 이 분할 비율을 변경하려면 API 호출이 한 번만 필요합니다.
물론, 90%에서 100%로 쉽게 이동할 수 있다는 것은 비율을 100:0에서 50:50(또는 0:100)으로 쉽게 변경할 수 있다는 것을 의미합니다. 따라서 핫 백업 클러스터를 보유하거나 새로운 리소스로 클러스터를 수평적으로 확장할 수 있습니다. 풀 스로틀로 최신 소프트웨어, 하드웨어 및 소프트웨어 패치로 완전히 새로운 클러스터를 구축하여 단 하나의 연결도 끊지 않고 일정 기간 동안 애플리케이션을 배포하고 트래픽을 마이그레이션할 수도 있습니다!
사용 사례
동적 키-값 저장소 와 함께 HTTP 분할 클라이언트 모듈을 사용하면 다음과 같은 사용 사례를 제공할 수 있습니다.
액티브-액티브 로드 밸런싱 – 여러 클러스터에 대한 로드 밸런싱을 위해.
액티브-패시브 로드 밸런싱 – 기본, 백업, DR 클러스터 및 애플리케이션에 대한 로드 밸런싱을 위해 사용됩니다.
A/B, 블루-그린 및 카나리아 테스트 – 새로운 Kubernetes 애플리케이션과 함께 사용됩니다.
수평적 클러스터 확장 – 준비가 되면 더 많은 클러스터 리소스를 추가하고 비율을 변경합니다.
히트리스 클러스터 업그레이드 – 한 클러스터를 사용하는 동안 다른 클러스터를 업그레이드, 패치 또는 복구할 수 있는 기능입니다.
즉각적인 장애 조치 - 한 클러스터에 심각한 문제가 있는 경우 비율을 변경하여 다른 클러스터를 사용할 수 있습니다.
구성 예제
키-값 구성의 예는 다음과 같습니다.
# Define Key Value store, backup state file, timeout, and enable sync
keyval_zone zone=split:1m state=/var/lib/nginx/state/split.keyval timeout=365d sync;
keyval $host $split_level zone=split;
그리고 이것은 cafe.example.com 애플리케이션 구성의 예입니다:
# Define server and location blocks for cafe.example.com, with TLS
server {
listen 443 ssl;
server_name cafe.example.com;
status_zone https://cafe.example.com;
ssl_certificate /etc/ssl/nginx/cafe.example.com.crt;
ssl_certificate_key /etc/ssl/nginx/cafe.example.com.key;
location / {
status_zone /;
proxy_set_header Host $host;
proxy_http_version 1.1;
proxy_set_header "Connection" "";
proxy_pass https://$upstream; # traffic split to upstream blocks
}
# Define 2 upstream blocks – one for each cluster
# Servers managed dynamically by NLK, state file backup
# Cluster1 upstreams
upstream cluster1-cafe {
zone cluster1-cafe 256k;
least_time last_byte;
keepalive 16;
#servers managed by NLK Controller
state /var/lib/nginx/state/cluster1-cafe.state;
}
# Cluster2 upstreams
upstream cluster2-cafe {
zone cluster2-cafe 256k;
least_time last_byte;
keepalive 16;
#servers managed by NLK Controller
state /var/lib/nginx/state/cluster2-cafe.state;
}
업스트림 서버 IP:포트는 Kubernetes용 NGINX 로드밸런서 에서 관리합니다 . 이 새로운 컨트롤러는 NGINX Plus API를 사용하여 NGINX Plus를 동적으로 구성합니다. 자세한 내용은 다음 섹션 에 나와 있습니다 .
인기 있는 모니터링 및 시각화 도구 인 Grafana를 사용하여 시간에 따른 HTTP 분할 트래픽을 살펴보겠습니다 . NGINX Prometheus Exporter ( njs 기반 )를 사용하여 모든 NGINX Plus 메트릭을 내보내고, 이를 Grafana에서 수집하여 그래프로 표시합니다. Prometheus와 Grafana를 구성하는 방법에 대한 자세한 내용은 여기에서 확인할 수 있습니다 .
그래프에는 4개의 업스트림 서버가 있습니다. Cluster1 에 2개, Cluster2 에 2개 입니다 . HTTP 로드 생성 도구를 사용하여 HTTP 요청을 생성하고 NGINX Plus로 보냅니다.
아래 세 개의 그래프에서 그래프 시작부분의 분할 비율은 50:50임을 알 수 있습니다.
그러면 12:56:30에서는 비율이 10:90으로 바뀐다.
그러면 13:00:00에 90:10으로 변경됩니다.
Prometheus와 Grafana의 작동 구성은 Kubernetes용 NGINX Loadbalancer GitHub 저장소 에서 찾을 수 있습니다 .
동적 HTTP 업스트림: Kubernetes용 NGINX 로드밸런서
NGINX Plus API와 Kubernetes 컨트롤러용 NGINX Loadbalancer를 사용하여 정적 NGINX Upstream 구성을 동적 클러스터 업스트림으로 변경할 수 있습니다 . 이 무료 프로젝트는 NGINX Ingress Controller를 감시 하고 TCP/HTTP 로드 밸런싱을 위해 구성된 외부 NGINX Plus 인스턴스를 자동으로 업데이트하는 Kubernetes 컨트롤러 입니다 . 설계가 매우 간단하고 설치 및 작동이 간단합니다. 이 솔루션을 사용하면 Kubernetes 환경에서 TCP/HTTP 로드 밸런싱을 구현하여 새 앱과 서비스를 즉시 감지하고 트래픽에 사용할 수 있습니다. 다시 로드할 필요가 없습니다.
Architecture & Flow
Kubernetes용 NGINX 로드밸런서는 Kubernetes 클러스터 내부에 있습니다. Kubernetes에 등록되어 NGINX Ingress Controller( ) 서비스를 감시합니다 . Ingress 컨트롤러가 변경되면 Kubernetes용 NGINX 로드밸런서는 Worker Ips와 NodePort TCP 포트 번호를 수집한 다음 NGINX Plus API를nginx-ingress 통해 IP:ports를 NGINX Plus로 전송합니다 .
NGINX 업스트림 서버는 재로드가 필요 없이 업데이트되고, NGINX Plus는 트래픽을 올바른 업스트림 서버와 Kubernetes NodePorts로 로드 밸런싱합니다. 추가 NGINX Plus 인스턴스를 추가하여 고가용성을 달성할 수 있습니다 .
Kubernetes용 NGINX 로드밸런서의 작동 스냅샷
아래 스크린샷에는 Kubernetes용 NGINX Loadbalancer가 배포되어 작업을 수행하는 모습을 보여주는 두 개의 창이 있습니다.
서비스LoadBalancer 유형 –nginx-ingress
외부 IP – NGINX Plus 서버에 연결
포트 - NodePort는 NGINX 업스트림 서버와 일치하는 443:30158에 매핑됩니다(NGINX Plus 실시간 대시보드 에 표시됨 )
로그 - Kubernetes용 NGINX 로드밸런서가 NGINX Plus로 데이터를 성공적으로 전송하고 있음을 나타냄
참고 : 이 예에서 Kubernetes 워커 노드는 10.1.1.8 및 10.1.1.10입니다.
NGINX Plus 보안 기능 추가
쿠버네티스에서 실행되는 애플리케이션이 점점 더 개방형 인터넷에 노출됨에 따라 보안이 필요해지고 있습니다. 다행히도 NGINX Plus에는 계층화된 심층 방어 아키텍처를 만드는 데 사용할 수 있는 엔터프라이즈급 보안 기능이 있습니다.
클러스터 앞에 NGINX Plus가 있고 split_clients기능을 수행한다면, 그 존재감을 활용하고 유익한 보안 기능을 추가하는 건 어떨까요? 보안을 강화하는 데 사용할 수 있는 NGINX Plus 기능 몇 가지와 이를 구성, 테스트, 배포하는 데 사용할 수 있는 다른 문서에 대한 링크와 참조가 있습니다.
IP 차단/허용 목록 – 소스 IP 주소에 따라 액세스를 제어합니다. NGINX Docs의 IP 주소 동적 거부 목록 페이지 에서 Plus API를 사용하여 동적 IP 차단/허용 목록에 NGINX Plus 키-값 저장소를 사용하는 방법에 대한 구성 가이드를 찾을 수 있습니다 .
속도 제한 - 애플리케이션, API 엔드포인트 및 미디어 다운로드에 대한 TCP 연결 수, HTTP 요청 및 대역폭 사용량을 제어합니다. NGINX를 사용한 속도 제한에 대한 자세한 내용은 NGINX Docs의 Limiting Access to Proxied HTTP Resources 와 블로그 게시물 Rate Limiting with NGINX and NGINX Plus 및 Dynamic Bandwidth Limits Using the NGINX Plus Key-Value Store를 참조하세요 .
GeoIP2 동적 모듈 - 소스 IP 주소에 따라 위치 메타데이터를 수집합니다. NGINX Docs의 지리적 위치에 따른 액세스 제한 페이지 에서 이에 대해 자세히 알아보세요 .
JWT 및 OpenID Connect(OIDC) 모듈 – 업계 표준 프로토콜로 사용자 액세스를 제어합니다. 이에 대한 자세한 내용은 NGINX Docs의 Setting up JWT Authentication 페이지에서 확인할 수 있습니다.
NGINX App Protect – 기존 및 진화하는 위협으로부터 보호하는 가볍고 지연 시간이 짧은 웹 애플리케이션 방화벽 입니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
Kubernetes에서 인공 지능(AI) 및 머신 러닝(ML) 모델 학습 및 추론을 실행할 때 동적 확장 및 축소가 중요한 요소가 됩니다. 데이터를 수집하기 위해 고대역폭 스토리지와 네트워킹이 필요할 뿐만 아니라 AI 모델 학습에는 대부분 GPU 또는 기타 특수 프로세서에서 나오는 상당한(그리고 값비싼) 컴퓨팅도 필요합니다. 사전 학습된 모델을 활용하더라도 프로덕션에서 모델 제공 및 미세 조정과 같은 작업은 여전히 대부분의 엔터프라이즈 워크로드보다 컴퓨팅 집약적입니다.
클라우드 네이티브 쿠버네티스는 빠른 확장성을 위해 설계되었습니다. 또한 하이브리드, 멀티 클라우드 환경에서 동적 워크로드에 대한 민첩성과 비용 효율적인 리소스 사용을 제공하도록 설계되었습니다.
이 블로그에서는 Kubernetes에서 AI/ML 워크로드를 확장하는 가장 일반적인 세 가지 방법을 다룹니다. 이를 통해 다양한 환경에서 동적 확장에 대한 최적의 성능, 비용 절감 및 적응성을 얻을 수 있습니다.
Kubernetes에서 AI/ML 워크로드를 위한 3가지 확장 모달리티
Kubernetes가 작업 부하를 확장하는 세 가지 일반적인 방법은 수평적 Pod 자동 확장기(HPA), 수직적 Pod 자동 확장기(VPA), 클러스터 자동 확장기입니다.
세 가지 방법을 자세히 살펴보면 다음과 같습니다.
HPA – 애플리케이션에 인스턴스나 Pod 복제본을 추가하는 것과 동일하여 확장성, 용량, 처리량을 더 높여줍니다.
VPA – 더 높은 컴퓨팅 및 메모리로 더 높은 용량을 제공하기 위해 포드 크기를 조정하는 것과 같습니다.
클러스터 자동 확장기 – 포드의 현재 리소스 수요에 따라 Kubernetes 클러스터의 노드 수를 자동으로 늘리거나 줄입니다.
각 모달리티는 모델 학습 및 추론에 있어서 각자의 이점을 가지고 있으며, 아래 사용 사례를 통해 이를 알아볼 수 있습니다.
HPA 사용 사례
많은 경우 분산형 AI 모델 학습 및 추론 워크로드는 수평적으로 확장할 수 있습니다(즉, 학습 프로세스 또는 요청 처리를 가속화하기 위해 더 많은 포드를 추가). 이를 통해 워크로드는 HPA의 이점을 얻을 수 있으며, CPU 및 메모리 사용과 같은 메트릭 또는 워크로드와 관련된 사용자 지정 및 외부 메트릭을 기반으로 포드 수를 확장할 수 있습니다. 워크로드가 시간에 따라 달라지는 시나리오에서 HPA는 최적의 리소스 활용을 보장하기 위해 포드 수를 동적으로 조정할 수 있습니다.
쿠버네티스에서 AI 워크로드를 수평적으로 확장하는 또 다른 측면은 로드 밸런싱입니다. 최적의 성능과 적시에 요청을 처리하려면 들어오는 요청을 여러 인스턴스 또는 포드에 분산해야 합니다. 이것이 HPA와 함께 사용할 수 있는 이상적인 도구 중 하나가 Ingress 컨트롤러 인 이유입니다 .
VPA 사용 사례
AI 모델 학습 작업은 종종 리소스 집약적이어서 상당한 CPU, GPU 및 메모리 리소스가 필요합니다. VPA는 이러한 리소스 할당을 동적으로 조정할 수 있습니다. 이를 통해 각 포드가 학습 워크로드를 효율적으로 처리할 수 있는 충분한 리소스를 확보하고 할당된 모든 포드가 계산을 수행할 수 있는 충분한 컴퓨팅 용량을 확보할 수 있습니다. 또한 메모리 요구 사항은 대규모 모델을 학습하는 동안 상당히 변동될 수 있습니다. VPA는 필요에 따라 메모리 할당을 늘려 메모리 부족 오류를 방지하는 데 도움이 될 수 있습니다.
기술적으로 HPA와 VPA를 함께 사용하는 것은 가능하지만, 서로 다른 방식(즉, 수평 대 수직)으로 동일한 작업 부하를 확장하려고 할 수 있으므로 충돌을 피하기 위해 신중하게 구성해야 합니다. 각 자동 확장기의 경계를 명확하게 정의하여 서로 충돌하지 않고 보완하도록 하는 것이 중요합니다. 새로운 접근 방식은 두 가지를 서로 다른 범위로 사용하는 것입니다. 예를 들어, HPA는 작업 부하에 따라 여러 포드에 걸쳐 확장하고 VPA는 HPA에서 설정한 제한 내에서 각 포드의 리소스 할당을 미세 조정하는 데 사용합니다.
클러스터 자동 확장기 사용 사례
클러스터 오토스케일러는 AI/ML 워크로드의 수요를 충족하기 위해 클러스터 전체에서 사용 가능한 컴퓨팅, 스토리지 및 네트워킹 인프라 리소스의 전체 풀을 동적으로 조정하는 데 도움이 될 수 있습니다. 현재 수요에 따라 클러스터의 노드 수를 조정함으로써 조직은 거시 수준에서 로드 밸런싱을 수행할 수 있습니다. 이는 AI/ML 워크로드가 예측할 수 없이 상당한 컴퓨팅 리소스를 요구할 수 있으므로 최적의 성능을 보장하는 데 필요합니다.
HPA, VPA 및 클러스터 자동 확장기에는 각각 역할이 있습니다.
요약하자면 Kubernetes 자동 확장이 작동하고 AI 워크로드에 도움이 되는 세 가지 방법은 다음과 같습니다.
HPA는 다양한 요청 속도를 처리해야 하는 엔드포인트에 서비스를 제공하는 AI 모델을 확장합니다.
VPA는 AI/ML 워크로드에 대한 리소스 할당을 최적화하고 과도한 프로비저닝 없이 효율적인 처리를 위해 각 Pod에 충분한 리소스가 확보되도록 보장합니다.
클러스터 자동 스케일러는 리소스 집약적 AI 작업을 수용할 수 있도록 클러스터에 노드를 추가하거나 컴퓨팅 수요가 낮으면 노드를 제거합니다.
HPA, VPA 및 Cluster Autoscaler는 Kubernetes에서 AI/ML 워크로드를 관리하는 데 있어 서로를 보완합니다. Cluster Autoscaler는 워크로드 수요를 충족할 수 있는 충분한 노드가 있는지 확인하고, HPA는 여러 포드에 워크로드를 효율적으로 분산하며, VPA는 이러한 포드의 리소스 할당을 최적화합니다. 함께 Kubernetes 환경에서 AI/ML 애플리케이션을 위한 포괄적인 확장 및 리소스 관리 솔루션을 제공합니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
2023년 10월 25일, 미국 국립표준기술원(NIST)은 Kubernetes용 NGINX Ingress Controller에 영향을 미치는 3개의 CVE를 보고했습니다 .
CVE-2022-4886 – ingress-nginx 경로 정리는 directive를 통해 우회될 수 있음 log_format.
CVE-2023-5043 – ingress-nginx 주석 주입으로 인해 임의의 명령 실행이 발생합니다.
CVE-2023-5044 – nginx.ingress.kubernetes.io/permanent-redirect 주석을 통해 코드 주입이 발생합니다.
해당 보고서와 후속 출판물(긴급 : Kubernetes용 NGINX Ingress 컨트롤러에서 새로운 보안 결함 발견 )은 어떤 NGINX Ingress 컨트롤러가 실제로 영향을 받는지, 그리고 이러한 CVE에 설명된 취약점을 해결하는 데 누가 관여해야 하는지에 대한 혼란(및 여러 지원 문의)을 야기했습니다.
혼란은 완전히 이해할 수 있습니다. NGINX 기반 Ingress 컨트롤러가 두 개 이상 있다는 것을 알고 계셨나요? 시작으로, "NGINX Ingress Controller"라는 완전히 다른 두 프로젝트가 있습니다.
커뮤니티 프로젝트 – GitHub의 kubernetes/ingress-nginx 리포지토리에서 발견된 이 Ingress 컨트롤러는 NGINX 오픈 소스 데이터 플레인을 기반으로 하지만 Kubernetes 커뮤니티에서 개발 및 유지 관리하고 있으며 문서는 GitHub에 호스팅됩니다 .
NGINX 프로젝트 – GitHub의 nginxinc/kubernetes -ingress repo 에서 찾을 수 있는 NGINX Ingress Controller는 F5 NGINX에서 개발 및 유지 관리하며 docs.nginx.com에 문서가 있습니다 . 이 공식 NGINX 프로젝트는 두 가지 버전으로 제공됩니다.
NGINX 오픈 소스 기반(무료 및 오픈 소스 옵션)
NGINX Plus 기반(상업용 옵션)
NGINX를 기반으로 하는 다른 Ingress 컨트롤러도 있는데, Kong이 있습니다. 다행히도, 이름은 쉽게 구별할 수 있습니다. 어떤 것을 사용하는지 잘 모르겠다면 실행 중인 Ingress 컨트롤러의 컨테이너 이미지를 확인한 다음 Docker 이미지 이름을 위에 나열된 리포와 비교하세요.
위에 설명된 취약점(CVE-2022-4886, CVE-2023-5043 및 CVE-2023-5044)은 커뮤니티 프로젝트 ( kubernetes/ingress-nginx )에만 적용됩니다. NGINX Ingress Controller( nginxinc/kubernetes-ingress , 오픈소스 및 상업용)에 대한 NGINX 프로젝트는 이러한 CVE의 영향을 받지 않습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
당신은 현대적 앱 개발자입니다. 오픈 소스와 아마도 일부 상용 도구 모음을 사용하여 새로운 앱과 컨테이너를 작성, 테스트, 배포 및 관리합니다. 개발, 테스트, 스테이징 및 프로덕션 환경에서 이러한 컨테이너와 포드를 실행하기 위해 Kubernetes를 선택했습니다. 마이크로서비스의 아키텍처와 개념, Cloud Native Computing Foundation 및 기타 현대적 산업 표준을 도입했습니다.
이 여정에서 여러분은 쿠버네티스가 실제로 강력하다는 것을 알게 되었습니다. 하지만 여러분은 쿠버네티스가 얼마나 어렵고, 유연하지 않으며, 좌절스러울 수 있는지에 놀랐을 것입니다. 라우터, 방화벽, 로드 밸런서 및 기타 네트워크 장치에 대한 변경 사항과 업데이트를 구현하고 조정하는 것은 압도적일 수 있습니다. 특히 자체 데이터 센터에서는 더욱 그렇습니다! 개발자를 눈물 흘리게 만들기에 충분합니다.
이러한 과제를 어떻게 처리하는지는 Kubernetes를 어디서 어떻게 실행하는지(관리형 서비스 또는 온프레미스)와 많은 관련이 있습니다. 이 문서에서는 배포 선택이 사용 편의성에 영향을 미치는 주요 영역인 TCP 로드 밸런싱을 다룹니다.
관리형 Kubernetes를 사용한 TCP 부하 분산(일명 Easy Option)
Kubernetes용 퍼블릭 클라우드 공급자와 같은 관리형 서비스를 사용하면 지루한 네트워킹 작업의 대부분이 처리됩니다. 단 하나의 명령( kubectl apply -f loadbalancer.yaml) 으로 서비스 유형 LoadBalancer는 퍼블릭 IP, DNS 레코드 및 TCP 로드 밸런서를 제공합니다. 예를 들어, NGINX Ingress Controller가 포함된 포드에 트래픽을 분산하도록 Amazon Elastic Load Balancer를 구성하고 이 명령을 사용하면 백엔드가 변경될 때 걱정할 필요가 없습니다. 너무 쉽기 때문에 당연하게 여기실 겁니다!
온프레미스 Kubernetes를 사용한 TCP 부하 분산(일명 하드 옵션)
온프레미스 클러스터의 경우 완전히 다른 시나리오입니다. 귀하 또는 네트워킹 피어가 네트워킹 부분을 제공해야 합니다. "왜 사용자를 내 Kubernetes 앱으로 유도하는 것이 이렇게 어려울까?"라고 궁금해할 수 있습니다. 답은 간단하지만 약간 충격적입니다. 클러스터의 정문인 서비스 유형 LoadBalancer는 실제로 존재하지 않습니다.
클러스터 외부에 앱과 서비스를 노출하려면 네트워크 팀에서 티켓, 승인, 절차, 심지어 보안 검토까지 필요할 수 있습니다. 이 모든 것이 장비를 재구성하기 전에 필요합니다. 아니면 모든 것을 직접 해야 할 수도 있는데, 그러면 애플리케이션 제공 속도가 엄청나게 느려질 수 있습니다. 더 나쁜 것은 Kubernetes 서비스를 변경하지 않는 것입니다. NodePort 가 변경되면 트래픽이 차단될 수 있기 때문입니다! 그리고 사용자들이 500 오류를 얼마나 좋아하는지 우리 모두 알고 있습니다. 상사는 아마 더 싫어할 것입니다.
온프레미스 TCP 로드 밸런싱을 위한 더 나은 솔루션: Kubernetes용 NGINX 로드 밸런서
새로운 프로젝트인 Kubernetes용 NGINX 로드밸런서를 사용하면 "하드 옵션"을 "쉬운 옵션"으로 바꿀 수 있습니다 . 이 무료 프로젝트는 NGINX Ingress Controller를 감시하고 로드 밸런싱을 위해 구성된 외부 NGINX Plus 인스턴스를 자동으로 업데이트하는 Kubernetes 컨트롤러 입니다 . 매우 간단한 설계로 설치 및 작동이 간편합니다. 이 솔루션을 사용하면 온프레미스 환경에서 TCP 로드 밸런싱을 구현하여 새로운 앱과 서비스를 즉시 감지하고 트래픽에 사용할 수 있습니다. 직접 작업할 필요가 없습니다.
Architecture와 Flow
Kubernetes용 NGINX 로드밸런서는 Kubernetes 클러스터 내부에 있습니다. Kubernetes에 등록되어 nginx-ingress 서비스(NGINX Ingress Controller)를 감시합니다. 백엔드가 변경되면 Kubernetes용 NGINX 로드밸런서는 Worker IP와 NodePort TCP 포트 번호를 수집한 다음 NGINX Plus API를 통해 IP:ports를 NGINX Plus로 전송합니다 . NGINX 업스트림 서버는 로 업데이트되고 NGINX Plus는 트래픽을 올바른 업스트림 서버와 Kubernetes NodePorts로 로드밸런싱합니다. 추가 NGINX Plus 인스턴스를 추가하여 고가용성을no reload required 달성할 수 있습니다 .
Kubernetes용 NGINX 로드밸런서의 작동 스냅샷
아래 스크린샷에는 Kubernetes용 NGINX Loadbalancer가 배포되어 작업을 수행하는 모습을 보여주는 두 개의 창이 있습니다.
서비스 유형 – LoadBalancer(용 nginx-ingress)
외부 IP – NGINX Plus 서버에 연결
포트 - NodePort는 NGINX 업스트림 서버와 일치하는 443:30158에 매핑됩니다(NGINX Plus 실시간 대시보드 에 표시됨 )
로그 - Kubernetes용 NGINX 로드밸런서가 NGINX Plus로 데이터를 성공적으로 전송하고 있음을 나타냄
참고 : 이 예에서 Kubernetes 워커 노드는 10.1.1.8 및 10.1.1.10입니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
이러한 말은 대부분의 다른 산업보다 의료 기술 분야의 회사에 더 해당됩니다. 그들의 경우 "심각한 결과"에는 문자 그대로 사망이 포함될 수 있습니다. 우리는 최근에 의료 기록 보관을 펜과 종이에서 언제 어디서나 액세스할 수 있는 안전한 디지털 데이터로 전환하려는 회사의 기술 스택을 분석할 기회를 가졌습니다. 이러한 데이터는 환자 정보에서 치료 지침, 생물학적 마커, 의료 분석, 과거 기록 및 의료 팀 간에 공유되는 모든 것에 이르기까지 다양합니다.
처음부터 이 회사는 겉보기에 간단한 질문인 "케어 종사자가 실시간으로 데이터를 쉽게 기록하도록 어떻게 도울 수 있을까?"를 해결하고자 했습니다. 그러나 회사가 성장함에 따라 확장하고 데이터를 지속적으로 사용할 수 있게 해야 하는 필요성으로 인해 이 과제를 해결하는 것이 점점 더 복잡해졌습니다. 여기서는 이 회사의 기술 여정이 어떻게 Kubernetes 와 NGINX Ingress Controller를 도입하게 되었는지 설명합니다 .
기술 스택을 한눈에 보기
OS – 리눅스
컨테이너 오케스트레이션 – Microsoft Azure Kubernetes Service
네트워킹 – Kubernetes , NGINX Plus 기반 NGINX Ingress Controller
소프트웨어 개발 언어/프레임워크 – .Net
모니터링, 관찰성 및 경고 – Prometheus
모니터링 대시보드 – Grafana
로깅 – Grafana Loki
데이터베이스 – Azure SQL 서비스
애플리케이션 서버 - Azure App Service , .Net
메시징 및 스트리밍 – Azure Event Hubs
캐싱 – Redis
보안 – NGINX 앱 보호
위치 및 인프라 – 2개의 가용성 영역, 2개의 Kubernetes 클러스터, 15~20개의 노드, 60~100개의 포드
DevOps – Azure DevOps 서비스
NGINX가 해당 아키텍처에서 어떻게 적용되는지 살펴보겠습니다.
종이의 문제
정기적으로 환자 상태와 치료 정보를 수집하는 것은 의료 종사자의 핵심 임무입니다. 전통적으로 그들은 환자 정보를 종이에 기록했거나, 최근에는 노트북이나 태블릿에 기록했습니다. 몇 가지 심각한 단점이 있습니다.
의료 종사자는 하루에 수십 명의 환자와 상호 작용할 수 있으므로 치료를 제공하는 동안 자세한 메모를 작성하는 것은 일반적으로 실용적이지 않습니다. 결과적으로 근로자는 교대 근무가 끝날 때 메모를 작성하게 됩니다. 그 시점에서 정신적, 신체적 피로로 인해 일반적인 의견만 기록하고 싶어집니다.
근로자는 또한 환자 행동에 대한 세부 사항에 대한 기억에 의존해야 합니다. 부정확한 내용은 시간이 지남에 따라 정확하고 일관되게 문서화되면 더 큰 건강 문제의 진단을 용이하게 하는 패턴을 가릴 수 있습니다.
종이 기록은 단일 부서 내의 부서 간에 쉽게 공유할 수 없으며, EMT, 응급실 직원, 보험 회사와 같은 다른 기관과는 더더욱 그렇습니다. 노트북이나 태블릿이 중앙 데이터 저장소나 클라우드에 연결되지 않은 경우 상황은 크게 나아지지 않습니다.
이러한 과제를 해결하기 위해 회사는 환자 정보에 액세스하고 약물 분배와 같은 일반적인 이벤트를 기록하기 위한 단축키를 제공하는 간소화된 데이터 기록 시스템을 만들었습니다. 이러한 액세스 및 사용의 용이성 덕분에 환자 상호작용을 발생하는 대로 실시간으로 기록할 수 있습니다.
모든 데이터는 회사에서 관리하는 클라우드 시스템에 저장되며, 앱은 다른 전자 의료 기록 시스템과 통합되어 거주자 행동에 대한 포괄적인 종단적 관점을 제공합니다. 이를 통해 간병인은 더 나은 치료 연속성을 제공하고, 안전한 과거 기록을 생성하며, 다른 의료 소프트웨어 시스템과 쉽게 공유할 수 있습니다.
의사와 다른 전문가도 환자를 입원시키거나 다른 방식으로 환자와 교류할 때 이 플랫폼을 사용합니다. 환자와 함께 모든 시설로 이동하는 선호도와 개인적 필요 사항의 기록이 있습니다. 이를 사용하여 환자가 새로운 환경에서 편안함을 느끼도록 도울 수 있으며, 이는 회복 시간과 같은 결과를 개선합니다.
회사가 환자 데이터를 얼마나 오랫동안 보관해야 하는지에 대한 엄격한 법적 요구 사항이 있습니다. 이 회사의 개발자는 일반 클라우드 애플리케이션보다 훨씬 더 나은 가동 시간 SLA로 매우 높은 가용성을 제공하는 소프트웨어를 구축했습니다. 환자의 파일이 로드되지 않아서 구급차를 기다리게 하는 것은 선택 사항이 아닙니다.
차고에서 클라우드로, 그리고 쿠버네티스로의 여행
많은 스타트업과 마찬가지로 이 회사는 공동 창업자의 집에 있는 서버에서 최초의 개념 증명 애플리케이션을 실행하여 처음에 비용을 절감했습니다. 이 아이디어가 타당하다는 것이 분명해지자 회사는 데이터 센터에서 하드웨어를 관리하는 대신 인프라를 클라우드로 옮겼습니다. Microsoft 매장인 그들은 Azure를 선택했습니다. 초기 아키텍처는 Microsoft의 IIS 웹 서버를 실행하는 관리형 애플리케이션 제공 서비스인 Azure App Service의 기존 가상 머신(VM)에서 애플리케이션을 실행했습니다. 데이터 저장 및 검색을 위해 이 회사는 VM에서 실행되는 Microsoft의 SQL Server를 관리형 애플리케이션으로 사용하기로 했습니다.
클라우드에서 수년간 운영한 후, 회사는 빠르게 성장하고 확장의 어려움을 겪었습니다. 회사는 무한히 확장해야 했고, VM을 사용하면 수직이 느리고 비용이 많이 들기 때문에 수평이 아닌 수평으로 확장해야 했습니다. 이러한 요구 사항으로 인해 컨테이너화와 Kubernetes가 가능한 솔루션으로 자연스럽게 이어졌습니다. 컨테이너화를 지지하는 또 다른 요점은 회사 개발자가 중단 위험 없이 애플리케이션과 인프라에 대한 업데이트를 자주 제공해야 한다는 것입니다. 환자 기록이 여러 시간대에 걸쳐 지속적으로 추가되면서 고객이 결함으로 인해 즉시 영향을 받을 위험 없이 프로덕션에 변경 사항을 푸시할 자연스러운 다운타임이 없습니다.
회사의 논리적인 시작점은 Microsoft의 관리형 Kubernetes 오퍼링인 Azure Kubernetes Services(AKS)였습니다. 팀은 Kubernetes 모범 사례를 조사하고 AKS의 노드와 포드에서 실행되는 트래픽과 애플리케이션을 효과적으로 관리하기 위해 Kubernetes 클러스터 앞에서 실행되는 Ingress 컨트롤러가 필요 하다는 것을 깨달았습니다.
Traffic 경로는 유연하면서도 정확해야 합니다.
팀은 AKS의 기본 Ingress 컨트롤러를 테스트했지만, 트래픽 라우팅 기능이 회사 고객에게 필요한 방식으로 업데이트를 제공할 수 없다는 것을 발견했습니다. 환자 케어에 관해서는 모호함이나 상충되는 정보에 대한 여지가 없습니다. 예를 들어, 한 케어 종사자가 주황색 플래그를 보고 다른 케어 종사자가 같은 이벤트에 대해 빨간색 플래그를 보는 것은 용납할 수 없습니다. 따라서 주어진 조직의 모든 사용자는 동일한 버전의 앱을 사용해야 합니다. 이는 업그레이드와 관련하여 큰 과제입니다. 고객을 새 버전으로 전환할 자연스러운 시기가 없으므로 회사는 서버 및 네트워크 수준에서 규칙을 사용하여 다른 고객을 다른 앱 버전으로 라우팅할 방법이 필요했습니다.
이를 달성하기 위해 이 회사는 조직의 모든 사용자에게 동일한 백엔드 플랫폼을 실행하고 조직 내 인프라 계층에서 세분화된 다중 테넌시를 제공하지 않습니다. Kubernetes를 사용하면 자세한 트래픽 규칙과 함께 브라우저의 가상 네트워크 경로 및 쿠키를 사용하여 트래픽을 분할할 수 있습니다. 그러나 이 회사의 기술 팀은 AKS의 기본 Ingress 컨트롤러는 필요에 따라 고객 조직 또는 개별 사용자 수준에서 작동하는 규칙이 아닌 백분율 기준으로만 트래픽을 분할할 수 있다는 것을 발견했습니다.
기본 구성에서 NGINX Open Source를 기반으로 하는 NGINX Ingress Controller는 동일한 제한이 있으므로 회사는 세분화된 트래픽 제어를 지원하는 엔터프라이즈급 제품인 NGINX Plus를 기반으로 하는 보다 고급 NGINX Ingress Controller로 전환하기로 결정했습니다. 높은 수준의 유연성과 제어를 기반으로 Microsoft와 Kubernetes 커뮤니티의 NGINX Ingress Controller에서 권장 사항을 찾은 것은 선택을 확고히 하는 데 도움이 되었습니다. 이 구성은 포드 관리(클래식 트래픽 관리와 대조적으로)에 대한 회사의 요구 사항을 더 잘 지원하여 포드가 적절한 영역에서 실행되고 트래픽이 해당 서비스로 라우팅되도록 합니다. 때로는 트래픽이 내부적으로 라우팅되지만 대부분의 사용 사례에서는 관찰 가능성을 위해 NGINX Ingress Controller를 통해 다시 라우팅됩니다.
Here Be Dragons: 모니터링, 관찰성 및 애플리케이션 성능
NGINX Ingress Controller를 사용하면 기술팀이 개발자와 최종 사용자 경험을 완벽하게 제어할 수 있습니다. 사용자가 로그인하여 세션을 설정하면 즉시 새 버전으로 라우팅되거나 이전 버전으로 되돌릴 수 있습니다. 패치는 조직의 모든 사용자에게 동시에 거의 즉시 푸시될 수 있습니다. 소프트웨어는 클라우드 플랫폼 전반의 네트워킹에 대한 DNS 전파나 업데이트에 의존하지 않습니다.
NGINX Ingress Controller는 또한 회사의 세부적이고 지속적인 모니터링 요구 사항을 충족합니다. 애플리케이션 성능은 의료 분야에서 매우 중요합니다. 지연이나 가동 중지 시간은 특히 생사의 상황에서 성공적인 임상 치료를 방해할 수 있습니다. Kubernetes로 이전한 후, 고객들은 회사에서 알아차리지 못한 가동 중지 시간을 보고하기 시작했습니다. 회사는 곧 문제의 근원을 발견했습니다. Azure App Service는 샘플링된 데이터에 의존합니다. 샘플링은 평균 및 광범위한 추세에는 적합하지만 거부된 요청 및 누락된 리소스와 같은 사항은 완전히 놓칩니다. 또한 간병인이 체크인하고 환자 데이터를 기록할 때 일반적으로 30분마다 발생하는 사용량 급증도 표시하지 않습니다. 회사는 지연, 오류 소스, 잘못된 요청 및 사용할 수 없는 서비스에 대한 불완전한 그림만 얻었습니다.
문제는 거기서 끝나지 않았습니다. 기본적으로 Azure App Service는 저장된 데이터를 한 달 동안만 보존합니다. 많은 국가의 법률에서 요구하는 수십 년보다 훨씬 짧습니다. 더 오래 보존하기 위해 필요에 따라 데이터 저장소를 확장하는 것은 엄청나게 비쌌습니다. 게다가 Azure 솔루션은 Kubernetes 네트워킹 스택 내부를 볼 수 없습니다. NGINX Ingress Controller는 4계층과 7계층 트래픽을 처리할 때 인프라와 애플리케이션 매개변수를 모두 모니터링할 수 있습니다.
성능 모니터링 및 관찰성을 위해 이 회사는 Grafana 시각화 엔진 및 대시보드에 연결된 Prometheus 시계열 데이터베이스를 선택했습니다. Prometheus와 Grafana와의 통합은 NGINX 데이터 및 제어 평면에 미리 구워져 있으며, 기술 팀은 모든 트래픽을 Prometheus 및 Grafana 서버를 통해 전달하기 위해 작은 구성 변경만 하면 되었습니다. 이 정보는 또한 Grafana Loki 로깅 데이터베이스로 라우팅되어 로그를 분석하기 쉬워졌고 소프트웨어 팀이 시간이 지남에 따라 데이터를 더 잘 제어할 수 있게 되었습니다.
이 구성은 또한 문제 해결 및 버그 수정을 위해 매우 빈번하고 방대한 양의 데이터 샘플링이 필요한 사고에 대비하여 미래를 보호합니다. 대부분의 대형 클라우드 회사에서 제공하는 애플리케이션 모니터링 시스템으로는 이러한 유형의 사고를 해결하는 데 비용이 많이 들 수 있지만 이 사용 사례에서 Prometheus, Grafana 및 Loki의 비용과 오버헤드는 최소입니다. 세 가지 모두 안정적인 오픈 소스 제품으로 일반적으로 초기 튜닝 후 패치만 하면 됩니다.
Routing 유지: 고가용성 및 보안에 집중
이 회사는 항상 가장 민감한 데이터 유형 중 하나를 보호하기 위한 보안과 필요할 때마다 앱을 사용할 수 있도록 하는 고가용성 에 중점을 두었습니다 . Kubernetes로 전환하면서 두 가지 용량을 모두 확장하기 위해 몇 가지 변경을 했습니다.
가장 높은 가용성을 위해 기술 팀은 단일 장애 지점 없이 완전한 중복성을 위해 액티브-액티브, 멀티 존, 멀티 지오 분산 인프라 설계를 구축합니다. 팀은 두 개의 다른 지리적 지역에 듀얼 쿠버네티스 클러스터가 있는 N+2 액티브-액티브 인프라를 유지 관리합니다. 각 지리적 지역 내에서 소프트웨어는 여러 데이터 센터에 걸쳐 다운타임 위험을 줄이고 인프라의 모든 계층에서 장애가 발생할 경우 적용 범위를 제공합니다. 친화성 및 반친화성 규칙은 사용자와 트래픽을 즉시 가동 중인 포드로 다시 라우팅하여 서비스 중단을 방지할 수 있습니다.
보안을 위해 팀은 잘못된 요청과 악의적인 행위자로부터 보호하기 위해 웹 애플리케이션 방화벽 (WAF)을 배포합니다. OWASP Top 10 에 대한 보호 는 대부분 WAF에서 제공하는 기본 사항입니다. 앱을 만들 때 팀은 기본 Azure WAF와 ModSecurity를 포함한 여러 WAF를 조사했습니다. 결국 팀은 인라인 WAF와 분산 서비스 거부 (DDoS) 보호 기능이 있는 NGINX App Protect를 선택했습니다.
NGINX App Protect의 큰 장점은 NGINX Ingress Controller와 함께 배치되어 중복 지점을 제거하고 지연 시간을 줄이는 것입니다. 다른 WAF는 Kubernetes 환경 외부에 배치해야 하므로 지연 시간과 비용이 증가합니다. 아주 사소한 지연(요청당 1밀리초 추가)도 시간이 지남에 따라 빠르게 누적됩니다.
서프라이즈 사이드 퀘스트: 개발자를 위한 다운타임 없음
대부분의 애플리케이션 및 네트워킹 인프라에 대해 AKS로의 전환을 완료한 이 회사는 개발자 경험(DevEx)에서도 상당한 개선을 이루었습니다. 이제 개발자는 고객이 문제를 알아차리기 전에 거의 항상 문제를 발견합니다. 전환 이후 오류에 대한 지원 전화의 양이 약 80% 감소했습니다!
회사의 보안 및 애플리케이션 성능 팀은 자세한 Grafana 대시보드와 통합 알림을 갖추고 있어 여러 시스템을 확인하거나 다른 프로세스에서 오는 경고 텍스트 및 호출에 대한 트리거를 구현할 필요가 없습니다. 개발 및 DevOps 팀은 이제 코드 및 인프라 업데이트를 매일 또는 하루에 여러 번 제공하고 매우 세부적인 청록색 패턴을 사용할 수 있습니다. 이전에는 일주일에 한두 번 업데이트를 제공하고 사용량이 적은 시간대에 시간을 내야 했으며 이는 스트레스가 많은 제안이었습니다. 이제 코드는 준비되면 제공되고 개발자는 애플리케이션 동작을 관찰하여 영향을 직접 모니터링할 수 있습니다.
결과는 전반적으로 긍정적입니다. 소프트웨어 개발 속도가 빨라지고, 개발자의 사기가 향상되고, 생명이 더 많이 구해졌습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
저희는 2023년 1월에 NGINX Ingress Controller 의 버전 3.0을 출시했으며, 여기에는 중요한 새로운 기능과 향상된 기능이 다수 포함되었습니다. 여러분께 특히 가치 있다고 생각되는 새로운 기능 중 하나는 NGINX Ingress Controller의 NGINX Plus 에디션에서 제공되는 Deep Service Insight입니다.
Deep Service Insight는 로드 밸런서와 같은 라우팅 결정 시스템이 하나 이상의 Kubernetes 클러스터 앞에 있을 때 최적의 기능을 방해하는 제한 사항을 해결합니다. 즉, 시스템은 Ingress 컨트롤러 뒤의 클러스터에서 실행되는 개별 서비스의 상태에 대한 정보에 액세스할 수 없습니다. 이를 통해 트래픽을 정상적인 서비스가 있는 클러스터로만 라우팅하지 못하게 되어 사용자를 중단 및 오류(예: 404) 에 노출시킬 가능성이 있습니다 500.
Deep Service Insight는 NGINX Ingress Controller에서 수집한 백엔드 서비스 포드의 상태를 전용 엔드포인트에 노출하여 시스템에서 액세스하고 더 나은 라우팅 결정을 내리는 데 활용할 수 있도록 함으로써 이러한 문제를 해결합니다.
이 게시물에서는 Deep Service Insight가 해결하는 문제를 자세히 살펴보고, 몇 가지 일반적인 사용 사례에서 이 기능이 어떻게 작동하는지 설명하고, 이를 구성하는 방법을 보여드리겠습니다.
왜 Deep Service Insight가 필요한가요?
표준 Kubernetes 라이브니스, 준비성 및 시작 프로브는 클러스터에서 실행되는 백엔드 서비스에 대한 정보를 제공하지만 스택 전체에 걸쳐 더 나은 라우팅 결정을 내리는 데 필요한 통찰력을 제공하기에는 충분하지 않습니다. Kubernetes 배포가 복잡해지고 중단 없는 가동 시간에 대한 비즈니스 요구 사항이 더 시급해짐에 따라 올바른 정보가 부족하면 문제가 더 커집니다.
Kubernetes 환경을 확장할 때 가동 시간을 개선하기 위한 일반적인 접근 방식은 클러스터 앞에 로드 밸런서, DNS 관리자 및 기타 자동화된 결정 시스템을 배포하는 것입니다. 그러나 Ingress 컨트롤러의 작동 방식 때문에 Kubernetes 클러스터 앞에 있는 로드 밸런서는 일반적으로 클러스터에서 Ingress 컨트롤러 뒤에 있는 서비스에 대한 상태 정보에 액세스할 수 없습니다. Ingress 컨트롤러 포드 자체가 정상이고 트래픽을 수용하는지 여부만 확인할 수 있습니다.
반면 NGINX Ingress Controller는 서비스 상태에 대한 정보를 가지고 있습니다. 이미 HTTP , TCP , UDP 및 gRPC 서비스에 대한 주기적 수동 상태 검사를 보내고, 요청 응답성을 모니터링하고, 성공적인 응답 코드 및 기타 메트릭을 추적하여 클러스터의 업스트림 포드 상태를 모니터링합니다. 이 정보를 사용하여 일관되고 예측 가능한 사용자 경험을 제공하기 위해 서비스의 포드에 트래픽을 분산하는 방법을 결정합니다. 일반적으로 NGINX Ingress Controller는 백그라운드에서 이 모든 마법을 조용히 수행하고 있으며, 후드 아래에서 무슨 일이 일어나고 있는지 두 번 생각하지 않을 수도 있습니다. Deep Service Insight는 이 귀중한 정보를 "표면화"하여 스택의 다른 계층에서 보다 효과적으로 사용할 수 있도록 합니다.
심층적 서비스 통찰력은 어떻게 작동하나요?
Deep Service Insight는 NGINX VirtualServer 및 TransportServer 사용자 지정 리소스(각각 HTTP 및 TCP/UDP용)를 사용하여 배포하는 서비스에 사용할 수 있습니다. Deep Service Insight는 NGINX Plus API를 사용하여 Deep Service Insight에 고유한 전용 엔드포인트에서 백엔드 서비스의 개별 포드에 대한 NGINX Ingress Controller의 뷰를 공유합니다.
VirtualServer의 경우 – <IP_주소> : <포트> /probe/ <호스트 이름>
TransportServer의 경우 – <IP_주소> : <포트> /probe/ts/ <서비스_이름 >
어디
<IP_address>는 NGINX Ingress Controller에 속합니다.
<port> 는 Deep Service Insight 포트 번호(기본값 9114)입니다.
<hostname>spec.host 은 VirtualServer 리소스 필드에 정의된 서비스의 도메인 이름입니다.
<service_name>spec.upstreams.service 은 TransportServer 리소스의 필드에 정의된 서비스의 이름입니다.
출력에는 두 가지 유형의 정보가 포함됩니다.
호스트 이름 또는 서비스 이름에 대한 HTTP 상태 코드:
200 OK – 적어도 하나의 포드가 건강합니다.
418 I’m a teapot – 건강한 포드가 없습니다
404 Not Found – 지정된 호스트 이름 또는 서비스 이름과 일치하는 포드가 없습니다.
활성 상태 검사를 구성하여 NGINX Ingress Controller가 포드가 정상인지 판단하는 데 사용하는 기준을 추가로 사용자 지정할 수 있습니다. 상태 검사가 전송되는 경로와 포트, 포드가 비정상으로 간주되기 위해 지정된 기간 내에 발생해야 하는 실패 검사 수, 예상 상태 코드, 연결 또는 응답 수신 시간 초과 등을 구성할 수 있습니다. VirtualServer 또는 TransportServerUpstream.Healthcheck 리소스 에 필드를 포함합니다 .
심층적인 서비스 통찰력을 위한 샘플 사용 사례
Deep Service Insight가 특히 가치 있는 사용 사례 중 하나는 로드 밸런서가 고가용성을 위해 두 클러스터에서 실행되는 서비스로 트래픽을 라우팅하는 경우입니다. 각 클러스터 내에서 NGINX Ingress Controller는 위에서 설명한 대로 업스트림 포드의 상태를 추적합니다. Deep Service Insight를 활성화하면 정상 및 비정상 업스트림 포드의 수에 대한 정보도 전용 엔드포인트에 노출됩니다. 라우팅 결정 시스템은 엔드포인트에 액세스하여 해당 정보를 사용하여 애플리케이션 트래픽을 비정상 포드에서 정상 포드로 전환할 수 있습니다.
이 다이어그램은 이 시나리오에서 Deep Service Insight가 작동하는 방식을 보여줍니다.
고가용성 시나리오에서 클러스터에 대한 유지 관리를 수행할 때 Deep Service Insight를 활용할 수도 있습니다. 유지 관리를 수행하는 클러스터에서 서비스에 대한 포드 수를 0으로 줄이기만 하면 됩니다. 건강한 포드가 없는 경우 Deep Service Insight 엔드포인트에 자동으로 표시되고 라우팅 결정 시스템은 해당 정보를 사용하여 다른 클러스터의 건강한 포드로 트래픽을 전송합니다. NGINX Ingress Controller나 시스템에서 구성을 변경하지 않고도 효과적으로 자동 장애 조치를 받을 수 있으며, 고객은 서비스 중단을 경험하지 않습니다.
심층적인 서비스 통찰력 활성화
Deep Service Insight를 활성화하려면 -enable-service-insightKubernetes 매니페스트에 명령줄 인수를 포함하거나 Helm을 사용하는 경우 serviceInsight.create매개변수를 로 설정합니다 true.
사용자 환경에 맞게 엔드포인트를 조정하기 위해 포함할 수 있는 두 가지 선택적 인수가 있습니다.
-service-insight-listen-port <port> – Deep Service Insight 포트 번호를 기본값인 9114에서 변경합니다( <port>1024–65535 범위의 정수). Helm과 동등한 것이 매개 serviceInsight.port변수입니다.
-service-insight-tls-string <secret> – Deep Service Insight 엔드포인트의 TLS 종료를 위한 Kubernetes 비밀(TLS 인증서 및 키)( <secret>형식이 있는 문자열 <namespace>/<secret_name>). Helm과 동등한 것이 serviceInsight.secret매개변수입니다.
예: 카페 애플리케이션에 대한 심층적 서비스 통찰력 활성화
Deep Service Insight가 실제로 어떻게 활용되는지 확인하려면 NGINX Ingress Controller 설명서에서 예로 자주 사용되는 Cafe 애플리케이션 에서 이를 활성화하면 됩니다 .
NGINX 사용자 정의 리소스를 지원하고 Deep Service Insight를 활성화하는 NGINX Ingress Controller의 NGINX Plus 버전을 설치합니다.
Helm을 사용하는 경우 serviceInsight.create매개변수를 .으로 설정합니다 true.
Kubernetes 매니페스트 (Deployment 또는 DaemonSet) 를 사용하는 경우 -enable-service-insight매니페스트 파일에 인수를 포함합니다.
NGINX Ingress Controller가 실행 중인지 확인하세요.
$ kubectl get pods -n nginx-ingressNAME READY ...
ingress-plus-nginx-ingress-6db8dc5c6d-cb5hp 1/1 ...
... STATUS RESTARTS AGE
... Running 0 9d
README 의 지침에 따라 Cafe 애플리케이션을 배포합니다 .
NGINX VirtualServer 사용자 정의 리소스가 Cafe 애플리케이션에 배포되었는지 확인합니다(IP 주소는 읽기 쉽도록 생략).
$ kubectl get vs NAME STATE HOST IP PORTS AGE
cafe Valid cafe.example.com ... [80,443] 7h1m
cafe.example.com 에서 실행되는 Cafe 서비스에 대해 세 개의 업스트림 포드가 있는지 확인하세요 .
$ kubectl get pods NAME READY STATUS RESTARTS AGE
coffee-87cf76b96-5b85h 1/1 Running 0 7h39m
coffee-87cf76b96-lqjrp 1/1 Running 0 7h39m
tea-55bc9d5586-9z26v 1/1 Running 0 111m
오늘날 기업에서 비용과 위험의 균형을 맞추는 것이 가장 중요합니다. 하지만 충분한 가시성이 없다면 리소스가 효과적으로 또는 일관되게 사용되고 있는지 알 수 없습니다.
쿠버네티스는 종종 일시적이고 가변적인 양의 클러스터 리소스를 소모하는 컨테이너화된 워크로드의 복잡한 배포를 가능하게 합니다. 이는 클라우드 환경이 쿠버네티스에 매우 적합한 이유입니다. 쿠버네티스는 피크 부하를 예상하여 과도하게 프로비저닝할 필요 없이 사용한 만큼만 비용을 지불하는 가격 모델을 제공하기 때문입니다. 물론 클라우드 공급업체는 이러한 편의성에 대해 프리미엄을 청구합니다. 비용 없이 퍼블릭 클라우드의 동적 로드 밸런싱을 잠금 해제할 수 있다면 어떨까요? 그리고 온프레미스 및 퍼블릭 클라우드 배포에 동일한 솔루션을 사용할 수 있다면 어떨까요?
이제 가능합니다. Kubecost와 NGINX는 Kubernetes 사용자가 수많은 배포에서 복잡성과 비용을 줄이는 데 도움을 줍니다. 이러한 솔루션을 함께 사용하면 최적의 성능과 해당 성능 및 관련 비용에 대한 궁극적인 가시성을 얻을 수 있습니다.
Kubecost의 통찰력을 통해 성능과 보안을 높이는 동시에 Kubernetes 배포 비용을 획기적으로 줄일 수 있습니다. Kubecost로 달성할 수 있는 것의 예는 다음과 같습니다.
다른 지역의 스토리지 버킷으로 포드가 상당한 유출 트래픽을 생성하는 잘못된 구성을 식별합니다.
비용을 절감하고 성능을 개선하기 위해 멀티 클러스터 Kubernetes 환경에서 로드 밸런서와 Ingress 컨트롤러 툴링을 통합합니다.
컨테이너의 성능을 파악하여 위험 없이 비용을 절감할 수 있도록 컨테이너 크기를 올바르게 조정하세요.
NGINX는 당신에게 필요한 성능을 제공합니다
NGINX Ingress Controller는 가장 널리 사용되는 Ingress 기술 중 하나로, 지금까지 Docker Hub에서 10억 회 이상 풀을 달성했으며 , 프로덕션 환경에서 실행되는 고성능, 확장 가능 및 보안을 갖춘 최신 앱의 대명사입니다.
NGINX Ingress Controller는 Kubernetes 환경에서 NGINX Open Source 또는 NGINX Plus 인스턴스와 함께 실행됩니다. 표준 Kubernetes Ingress 리소스 와 NGINX 사용자 지정 리소스를 모니터링하여 Ingress 로드 밸런싱이 필요한 서비스에 대한 요청을 발견합니다. 그런 다음 NGINX Ingress Controller는 NGINX 또는 NGINX Plus를 자동으로 구성하여 이러한 서비스로 트래픽을 라우팅하고 로드 밸런싱합니다.
NGINX Ingress Controller는 API 게이트웨이, 로드 밸런서 및 Ingress 컨트롤러 기능을 결합하는 범용 도구로 사용하여 운영을 간소화하고 비용과 복잡성을 줄일 수 있습니다.
Kubecost가 네트워크 운영의 실제 비용을 공개합니다.
Kubecost는 Kubernetes 사용자에게 클러스터에서 각 컨테이너를 실행하는 데 드는 비용에 대한 가시성을 제공합니다. 여기에는 각 노드의 명백한 CPU, 메모리 및 스토리지 비용이 포함됩니다. 그러나 Kubecost는 이러한 기본 사항을 넘어 클라우드 공급자의 데이터 이탈 시 일반적으로 발생하는 포드당 네트워크 전송 비용을 공개합니다.
Kubecost가 올바른 작업 부하에 비용을 얼마나 정확하게 할당하는지를 결정하는 두 가지 구성 옵션이 있습니다.
첫 번째 옵션은 통합 클라우드 청구 입니다 . Kubecost는 트래픽을 처리한 노드와 관련된 네트워크 전송 비용을 포함하여 클라우드 공급자로부터 청구 데이터를 가져옵니다. Kubecost는 이 비용을 컨테이너 트래픽의 공유에 따라 해당 노드의 포드에 분배합니다.
보고된 총 네트워크 비용은 정확하지만 이 방법은 이상적이지 않습니다. 많은 포드의 경우 유일하게 중요한 트래픽은 자체 존(따라서 무료) 내에 있지만 Kubecost는 이러한 워크로드에 대한 네트워크 비용을 보여줍니다.
두 번째 옵션인 네트워크 비용 구성은 모든 트래픽의 소스와 목적지를 살펴봄으로써 클라우드 청구 통합의 이러한 한계를 해결합니다. Kubecost Allocations 대시보드는 네임스페이스, 레이블, 서비스와 같은 Kubernetes 개념과 팀, 제품, 프로젝트, 부서, 환경과 같은 조직 부문을 포함한 여러 범주에 걸친 지출 비율을 표시합니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
Kubernetes Gateway API의 준수 구현인 NGINX Gateway Fabric에 대한 최신 소식을 공유하게 되어 기쁩니다. 최근 여러 가지 흥미로운 새로운 기능과 개선 사항이 포함된 1.2.0 버전으로 업데이트했습니다. 이 릴리스는 플랫폼의 기능을 향상하고 사용자의 요구 사항을 충족하는 데 중점을 두고 있습니다. F5 NGINX Plus 지원을 포함하고 가장 수요가 많은 사용 사례를 포괄하도록 API 표면을 확장했습니다. 이러한 개선 사항이 모든 사용자에게 더 나은 경험을 제공하고 사용자가 목표를 보다 효율적으로 달성하는 데 도움이 될 것이라고 믿습니다.
그림 1: NGINX Gateway Fabric의 설계 및 아키텍처 개요
NGINX Gateway Fabric 1.2.0 개요:
아래에서 새로운 기능을 자세히 살펴보겠습니다.
NGINX Gateway Fabric 1.2.0의 새로운 기능은 무엇입니까?
NGINX 플러스 지원
NGINX Gateway Fabric 버전 1.2.0이 NGINX Plus를 지원하여 출시되어 사용자에게 많은 새로운 이점을 제공합니다. 새로운 업그레이드를 통해 사용자는 이제 추가 Prometheus 메트릭, 동적 업스트림 재로드 및 NGINX Plus 대시보드를 포함하여 배포에서 NGINX Plus의 고급 기능을 활용할 수 있습니다. 이 업그레이드를 통해 환경에 대한 NGINX에서 직접 지원을 받을 수 있는 옵션도 제공됩니다.
추가 Prometheus 메트릭
NGINX Plus를 데이터 플레인으로 사용하는 동안 NGINX Open Source에서 일반적으로 얻는 메트릭과 함께 추가적인 고급 메트릭이 내보내집니다. 몇 가지 주요 내용으로는 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 그래프
위의 설정은 기본 NGINX Open Source를 데이터 플레인으로 사용하는 경우에도 작동합니다! 그러나 NGINX Plus가 제공하는 추가 메트릭은 볼 수 없습니다. 클러스터의 크기와 범위가 커짐에 따라 NGINX Plus 메트릭이 용량 계획 문제, 인시던트, 심지어 백엔드 애플리케이션 오류를 신속하게 해결하는 데 어떻게 도움이 될 수 있는지 살펴보는 것이 좋습니다.
동적 업스트림 리로드
NGINX Plus와 함께 설치 시 NGINX Gateway Fabric에서 자동으로 활성화되는 동적 업스트림 다시 로드를 통해 NGINX Gateway Fabric은 NGINX 다시 로드 없이 NGINX 구성을 업데이트할 수 있습니다. 전통적으로 NGINX 다시 로드가 발생하면 기존 연결은 이전 작업자 프로세스에서 처리하는 반면 새로 구성된 작업자는 새 연결을 처리합니다. 모든 이전 연결이 완료되면 이전 작업자가 중지되고 NGINX는 새로 구성된 작업자만 사용하여 계속 진행합니다. 이런 방식으로 NGINX 오픈 소스에서도 구성 변경이 우아하게 처리됩니다. 그러나 NGINX에 부하가 많이 걸리는 경우 이전 작업자와 새 작업자를 모두 유지하면 리소스 오버헤드가 생성되어 특히 NGINX Gateway Fabric을 최대한 간소하게 실행하려는 경우 문제가 발생할 수 있습니다. NGINX Plus에서 제공하는 동적 업스트림 다시 로드는 NGINX Gateway Fabric에서 자동으로 사용할 구성 변경에 대한 API 엔드포인트를 제공하여 다시 로드 프로세스 중에 이전 작업자와 새 작업자를 처리하기 위한 추가 리소스 오버헤드의 필요성을 줄임으로써 이 문제를 우회합니다. 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 인증서 관리에 대한 도움말은 이 가이드를 확인하세요 .
kind: ConfigMap apiVersion: v1 metadata: name: backend-cert data: ca.crt: < -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- >secure-app다음으로, 서비스를 타겟으로 하고 이전 단계에서 만든 ConfigMap을 참조하는 BackendTLSPolicy를 만듭니다 .
apiVersion: gateway.networking.k8s.io/v1alpha2 kind: BackendTLSPolicy metadata: name: backend-tls spec: targetRef: group: '' kind: Service name: secure-app namespace: default tls: caCertRefs: - name: backend-cert group: '' kind: ConfigMap hostname: secure-app.example.comURL 다시 쓰기
URLRewrite 필터를 사용하면 들어오는 요청의 원래 URL을 수정하여 성능에 전혀 영향을 미치지 않고 다른 URL로 리디렉션할 수 있습니다. 이 기능은 백엔드 애플리케이션이 노출된 API를 변경하지만 기존 클라이언트에 대한 이전 버전과의 호환성을 유지하려는 경우에 특히 유용합니다. 또한 이 기능을 사용하여 클라이언트에 일관된 API URL을 노출하는 동시에 다른 API URL을 사용하여 요청을 다른 애플리케이션으로 리디렉션하여 클라이언트의 편의성과 성능을 위해 여러 다른 API의 기능을 결합한 "경험" API를 제공할 수 있습니다. 시작하려면 NGINX 게이트웨이 패브릭에 대한 게이트웨이를 만들어 보겠습니다. 이를 통해 HTTP 리스너를 정의하고 최적의 성능을 위해 포트 80을 구성할 수 있습니다.
apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: cafe spec: gatewayClassName: nginx listeners: - name: http port: 80 protocol: HTTPHTTPRoute 리소스를 만들고 요청 필터를 구성하여 /coffee에 대한 모든 요청을 /beans로 다시 작성해 보겠습니다. 백엔드가 처리할 /latte 접두사를 포함하도록 다시 작성된 /latte 엔드포인트를 제공할 수도 있습니다("/latte/126"이 "/126"이 됨).
apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: coffee spec: parentRefs: - name: cafe sectionName: http hostnames: - "cafe.example.com" rules: - matches: - path: type: PathPrefix value: /coffee filters: - type: URLRewrite urlRewrite: path: type: ReplaceFullPath replaceFullPath: /beans backendRefs: - name: coffee port: 80 - matches: - path: type: PathPrefix value: /latte filters: - type: URLRewrite urlRewrite: path: type: ReplacePrefixMatch replacePrefixMatch: / backendRefs: - name: coffee port: 80HTTP 재작성 기능은 클라이언트 측의 엔드포인트와 백엔드와 매핑되는 방식 간의 유연성을 보장하는 데 도움이 됩니다. 또한 한 URL에서 다른 URL로 트래픽을 리디렉션할 수 있어 특히 콘텐츠를 새 웹사이트나 API 트래픽으로 마이그레이션할 때 유용합니다. NGINX Gateway Fabric은 경로 기반 재작성을 지원하지만 현재는 경로 기반 리디렉션을 지원하지 않습니다. 이 기능이 환경에 필요한지 알려주세요 .
제품 원격 측정 (Telemetry)
우리는 1.2 릴리스의 일부로 수동적으로 피드백을 수집하는 메커니즘으로 제품 원격 측정을 포함하기로 결정했습니다. 이 기능은 환경에서 다양한 메트릭을 수집하여 24시간마다 데이터 수집 플랫폼으로 전송합니다. PII는 수집되지 않으며 수집되는 전체 목록은 여기 에서 확인할 수 있습니다 . 우리는 원격 측정 기능에 대한 완전한 투명성을 제공하기 위해 최선을 다하고 있습니다. 수집하는 모든 필드를 문서화하고 코드로 수집하는 내용을 검증할 수 있지만, 항상 완전히 비활성화할 수 있는 옵션이 있습니다. 커뮤니티 회의 에서 커뮤니티와 함께 수집한 통계를 기반으로 흥미로운 관찰 결과를 정기적으로 검토할 계획 이므로 꼭 들러주세요!
자원
NGINX Gateway Fabric 1.2.0의 전체 변경 사항은 릴리스 노트를 참조하세요 . NGINX Plus로 Kubernetes용 NGINX Gateway Fabric을 사용해 보려면 오늘 무료 30일 평가판을 시작하거나 저희에게 연락하여 사용 사례에 대해 논의하세요 . 참여하고 싶거나, 앞으로 나올 내용을 보고 싶거나, NGINX Gateway Fabric의 소스 코드를 보고 싶다면 GitHub 에서 저희 리포지토리를 확인하세요 ! 월요일 오전 9시 태평양/오후 5시 GMT에 2주마다 커뮤니티 회의가 있습니다. 회의 링크, 업데이트, 일정 및 메모는 NGINX Gateway Fabric 회의 일정 에 있습니다 . 링크는 항상 GitHub readme에서도 사용할 수 있습니다.
위 내용과 같이 NGINX Gateway Fabric 을 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
쿠버네티스에서 인공 지능(AI) 및 머신 러닝(ML) 워크로드를 실행하는 주요 이점 중 하나는 Ingress Controller를 통해 들어오는 모든 요청에 대한 중앙 제어 지점을 갖는 것입니다. 로드 밸런서 및 API 게이트웨이 역할을 하는 다재다능한 모듈로, 쿠버네티스 환경에서 AI/ML 애플리케이션을 보호하기 위한 견고한 기반을 제공합니다.
통합 도구인 Ingress Controller는 보안 및 성능 측정을 적용하고, 활동을 모니터링하고, 규정 준수를 의무화하는 데 편리한 터치포인트입니다. 더 구체적으로, Kubernetes 환경에서 Ingress Controller에서 AI/ML 애플리케이션을 보호하면 이 블로그에서 살펴보는 몇 가지 전략적 이점이 있습니다.
중앙 집중식 보안 및 규정 준수 제어
Ingress Controller는 Kubernetes 클러스터에 대한 게이트웨이 역할을 하므로 MLOps 및 플랫폼 엔지니어링 팀이 보안 정책을 시행하기 위한 중앙 집중식 지점을 구현할 수 있습니다. 이를 통해 포드별 또는 서비스별로 보안 설정을 구성하는 복잡성이 줄어듭니다. Ingress 수준에서 보안 제어를 중앙 집중화하면 규정 준수 프로세스가 간소화되고 규정 준수 상태를 관리하고 모니터링하기가 더 쉬워집니다.
통합 인증 및 권한 부여
Ingress Controller는 모든 AI/ML 애플리케이션에 대한 액세스에 대한 인증 및 승인을 구현하고 시행하는 논리적인 위치이기도 합니다. 강력한 인증 기관 관리를 추가함으로써 Ingress Controller는 Kubernetes를 위한 제로 트러스트(ZT) 아키텍처를 구축하는 핵심이기도 합니다. ZT는 매우 귀중한 독점 데이터에서 실행되는 민감한 AI 애플리케이션의 지속적인 보안 및 규정 준수를 보장하는 데 필수적입니다.
속도 제한 및 액세스 제어
Ingress Controller는 속도 제한을 시행하여 DDoS 공격이나 과도한 API 호출과 같은 남용으로부터 애플리케이션을 보호하기에 이상적인 곳으로, 이는 공개 AI/ML API에 필수적입니다. 모델 도난 및 데이터 유출과 같은 새로운 AI 위협이 증가함에 따라 속도 제한 및 액세스 제어를 시행하는 것이 무차별 대입 공격으로부터 보호하는 데 더욱 중요해지고 있습니다. 또한 적대자가 비즈니스 로직을 남용하거나 가드레일을 탈옥하여 데이터를 추출하고 학습을 모델링하거나 정보에 가중치를 두는 것을 방지하는 데 도움이 됩니다.
웹 애플리케이션 방화벽(WAF) 통합
많은 Ingress Controller는 노출된 애플리케이션과 서비스를 보호하기 위한 기본 요소인 WAF와의 통합을 지원합니다. WAF는 OWASP 10과 같은 일반적인 웹 취약성과 공격에 대한 추가 보안 계층을 제공합니다. 더욱 중요한 점은 적절하게 조정하면 WAF가 AI/ML 애플리케이션을 겨냥한 보다 집중적인 공격으로부터 보호한다는 것입니다. 지연 시간과 성능이 중요한 AI/ML 앱의 주요 고려 사항은 WAF로 인해 발생할 수 있는 잠재적인 오버헤드입니다. 또한 AI/ML 앱에서 효과적이려면 WAF를 모니터링 및 관찰 대시보드와 알림 구조를 위해 Ingress Controller에 긴밀하게 통합해야 합니다. WAF와 Ingress Controller가 공통 데이터 플레인을 공유할 수 있다면 이상적입니다.
결론: AI/ML 아키텍처 계획 초기에 Ingress Controller 포함
Ingress Controller는 AI/ML 앱을 위한 Kubernetes 애플리케이션 배포에서 매우 중요한 위치를 차지하기 때문에 AI/ML 애플리케이션을 설계하는 과정에서 해당 기능을 포함하는 것이 가장 좋습니다. 이를 통해 기능 중복을 완화하고 AI/ML 애플리케이션 요구 사항에 따라 확장 및 성장할 Ingress Controller에 대한 더 나은 결정을 내릴 수 있습니다. MLOps 팀의 경우 Ingress Controller는 보안을 최우선 순위로 두고 많은 중요한 플랫폼 및 운영 기능에 대한 중앙 제어 지점이 됩니다.
NGINX 시작하기
NGINX는 사용자의 요구 사항을 충족하고 Kubernetes 플랫폼의 보안, 확장성, 관찰성을 향상시키는 데 필요한 포괄적인 도구와 빌딩 블록 세트를 제공합니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
AI 및 머신 러닝(AI/ML) 워크로드는 기업의 운영 및 혁신 방식에 혁명을 일으키고 있습니다. 컨테이너 오케스트레이션 및 관리의 사실상 표준인 Kubernetes 는 하이브리드, 멀티 클라우드 환경에서 확장 가능한 대규모 언어 모델(LLM) 워크로드 및 추론 모델을 구동하기 위한 선택 플랫폼입니다.
Kubernetes에서 Ingress 컨트롤러는 컨테이너화된 애플리케이션을 제공하고 보호하는 데 중요한 역할을 합니다. Kubernetes 클러스터의 가장자리에 배포되어 사용자와 애플리케이션 간의 통신을 처리하는 중심점 역할을 합니다.
이 블로그에서는 Ingress 컨트롤러와 Kubernetes용 F5 NGINX Connectivity Stack이 AI/ML 워크로드에 대한 모델 제공, 실험, 모니터링 및 보안을 단순화하고 효율화하는 데 어떻게 도움이 될 수 있는지 살펴보겠습니다 .
대규모 프로덕션에서 AI/ML 모델 배포
대규모로 AI/ML 모델을 배포할 때 즉시 사용 가능한 Kubernetes 기능과 성능은 다음과 같은 데 도움이 될 수 있습니다.
동시에 조직은 대규모 프로덕션에서 AI/ML 모델을 제공하고, 실험하고, 모니터링하고, 보호하는 데 어려움을 겪을 수 있습니다.
F5 NGINX Ingress Controller 와 같은 엔터프라이즈급 Ingress 컨트롤러는 이러한 과제를 해결하는 데 도움이 될 수 있습니다. Ingress 컨트롤러, 로드 밸런서, API 게이트웨이 기능을 결합한 하나의 도구를 활용하면 Kubernetes를 어디에서 실행하든 규모에 맞게 더 나은 가동 시간, 보호 및 가시성을 달성할 수 있습니다. 또한 복잡성과 운영 비용을 줄여줍니다.
NGINX Ingress Controller는 LLM 애플리케이션에 대한 OWASP Top 10 사이버 위협을 완화하고 DoS 공격으로부터 AI/ML 워크로드를 방어하는 데 도움이 되는 F5의 업계 선도적인 Layer 7 앱 보호 기술 과 긴밀하게 통합될 수도 있습니다 .
AI/ML 워크로드를 위한 Ingress 컨트롤러의 이점
Ingress 컨트롤러는 다음 기능을 통해 프로덕션에서 AI/ML 워크로드의 배포 및 실행을 간소화하고 효율화할 수 있습니다.
Kubernetes용 NGINX Connectivity Stack에는 NGINX Ingress Controller 와 F5 NGINX App Protect가 포함되어 AI/ML 애플리케이션을 실행하는 Kubernetes 클러스터와 온프레미스 및 클라우드에서 사용자 간에 빠르고 안정적이며 안전한 통신을 제공합니다. 모든 Kubernetes 환경에서 모델 제공, 실험, 모니터링 및 보안을 간소화하고 간소화하여 클라우드 공급자와 사전 패키징된 Kubernetes 오퍼링의 기능을 향상시키고 규모에 따라 더 높은 수준의 보호, 가용성 및 관찰성을 제공합니다.
Kubernetes를 위한 NGINX Connectivity Stack 시작하기
NGINX는 사용자의 요구 사항을 충족하고 Kubernetes 플랫폼의 보안, 확장성 및 가시성을 향상시키는 데 필요한 포괄적인 도구와 빌딩 블록 세트를 제공합니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
당신은 현대적 Platform Ops 또는 DevOps 엔지니어입니다. 당신은 오픈 소스(그리고 아마도 일부 상업용) 도구 라이브러리를 사용하여 개발팀을 위한 새로운 앱과 컨테이너를 테스트, 배포 및 관리합니다. 당신은 개발, 테스트, 스테이징 및 프로덕션 환경에서 이러한 컨테이너와 포드를 실행하기 위해 Kubernetes를 선택했습니다. 당신은 마이크로서비스의 아키텍처와 개념을 받아들였고, 대부분 잘 작동합니다. 그러나 이 여정에서 몇 가지 속도 범프에 부딪혔습니다.
예를 들어, 새로운 클러스터, 서비스 및 애플리케이션을 빌드하고 출시할 때 트래픽을 끊지 않고 이러한 새로운 리소스를 프로덕션에 쉽게 통합하거나 마이그레이션하려면 어떻게 해야 할까요? 기존 네트워킹 어플라이언스는 DNS 레코드, 로드 밸런서, 방화벽 및 프록시에 대한 구성 변경을 구현할 때 다시 로드하거나 재부팅해야 합니다. 이러한 조정은 DNS, 로드 밸런서 및 방화벽 규칙을 업데이트하는 데 "서비스 중단" 또는 "유지 관리 창"이 필요하기 때문에 다운타임을 발생시키지 않고는 재구성할 수 없습니다. 대부분의 경우, 두려운 서비스 티켓을 제출하고 다른 팀이 승인하고 변경을 수행할 때까지 기다려야 합니다.
유지 관리 창은 팀을 도랑에 빠뜨리고, 애플리케이션 제공을 멈추고, "트래픽을 관리하는 더 나은 방법이 있어야 한다!"고 선언하게 만들 수 있습니다. 따라서 빠른 차선으로 돌아갈 수 있는 솔루션을 살펴보겠습니다.
액티브-액티브 멀티 클러스터 로드 밸런싱
여러 개의 Kubernetes 클러스터가 있는 경우 두 클러스터로 동시에 트래픽을 라우팅하는 것이 이상적입니다. 더 나은 옵션은 A/B, 카나리아 또는 블루-그린 트래픽 분할을 수행하고 트래픽의 작은 비율을 테스트로 보내는 것입니다. 이를 위해 NGINX Plus를 ngx_http_split_clients_module.
HTTP Split Clients 모듈은 NGINX Open Source에서 작성되었으며 요청 비율을 키에 따라 분산할 수 있습니다. 이 사용 사례에서 클러스터는 NGINX의 "업스트림"입니다. 따라서 클라이언트 요청이 도착하면 트래픽이 두 클러스터로 분할됩니다. 클라이언트 요청을 결정하는 데 사용되는 키는 사용 가능한 NGINX 클라이언트입니다 $variable. 즉, 모든 요청에 대해 이를 제어하려면 $request_idNGINX에서 모든 수신 요청에 할당한 고유 번호인 변수를 사용합니다.
분할 비율을 구성하려면 각 클러스터에 할당할 백분율을 결정합니다. 이 예에서 K8s Cluster1을 프로덕션용 "대형 클러스터"로 사용하고 Cluster2를 사전 프로덕션 테스트용 "소형 클러스터"로 사용합니다. 스테이징용 소규모 클러스터가 있는 경우 90:10 비율을 사용하고 소규모 클러스터에서 트래픽의 10%를 테스트하여 대규모 클러스터에 새 변경 사항을 롤아웃하기 전에 모든 것이 제대로 작동하는지 확인할 수 있습니다. 너무 위험해 보이면 비율을 95:5로 변경할 수 있습니다. 사실, 0~100% 사이에서 원하는 비율을 선택할 수 있습니다.
대부분의 실시간 프로덕션 트래픽의 경우 두 클러스터가 동일한 크기인 50:50 비율을 원할 것입니다. 하지만 클러스터 크기나 기타 세부 정보에 따라 다른 비율을 쉽게 제공할 수 있습니다. 비율을 0:100(또는 100:0)으로 쉽게 설정하고 다운타임 없이 전체 클러스터를 업그레이드, 패치, 수리 또는 교체할 수 있습니다. NGINX split_clients가 라이브 클러스터로 요청을 라우팅하는 동안 다른 클러스터에서 문제를 해결합니다.
# Nginx Multi Cluster Load Balancing # HTTP Split Clients Configuration for Cluster1:Cluster2 ratios # Provide 100, 99, 50, 1, 0% ratios (add/change as needed) # Based on # https://www.nginx.com/blog/dynamic-a-b-testing-with-nginx-plus/ # Chris Akker – Jan 2024 # split_clients $request_id $split100 { * cluster1-cafe; # All traffic to cluster1 } split_clients $request_id $split99 { 99% cluster1-cafe; # 99% cluster1, 1% cluster2 * cluster2-cafe; } split_clients $request_id $split50 { 50% cluster1-cafe; # 50% cluster1, 50% cluster2 * cluster2-cafe; } split_clients $request_id $split1 { 1.0% cluster1-cafe; # 1% to cluster1, 99% to cluster2 * cluster2-cafe; } split_clients $request_id $split0 { * cluster2-cafe; # All traffic to cluster2 } # Choose which cluster upstream based on the ratio map $split_level $upstream { 100 $split100; 99 $split99; 50 $split50; 1.0 $split1; 0 $split0; default $split50; }위의 구성을 추가하거나 편집하여 필요한 비율(예: 90:10, 80:20, 60:40 등)에 맞게 조정할 수 있습니다.
참고: NGINX에는 스트림 컨텍스트에서 TCP 연결을 위한 것도 있는데 Split Clients module, 이는 HTTP가 아닌 트래픽에 사용할 수 있습니다. 이는 HTTP 요청 대신 새로운 TCP 연결을 기준으로 트래픽을 분할합니다.
NGINX Plus 키-값 저장소
사용할 수 있는 다음 기능은 NGINX Plus 키-값 저장소 입니다 . 이것은 다양한 데이터 저장 사용 사례에 사용할 수 있는 NGINX 공유 메모리 영역의 키-값 개체입니다. 여기서는 위 섹션에서 언급한 분할 비율 값을 저장하는 데 사용합니다. NGINX Plus를 사용하면 NGINX를 다시 로드하지 않고도 모든 키-값 레코드를 변경할 수 있습니다. 이를 통해 API 호출로 이 분할 값을 변경하여 동적 분할 함수를 만들 수 있습니다.
우리의 예를 기준으로 보면 다음과 같습니다.
{“cafe.example.com”:90}
이 KeyVal 레코드는 다음과 같이 읽힙니다.
키는 "cafe.example.com" 호스트 이름이고
값은 분할 비율에 대해 "90"입니다.
NGINX 구성 파일에 분할 비율을 하드 코딩하는 대신 키-값 메모리를 사용할 수 있습니다. 이렇게 하면 NGINX에서 정적 분할 값을 변경하는 데 필요한 NGINX 재로드가 제거됩니다.
이 예에서 NGINX는 분할 비율에 90:10을 사용하도록 구성되어 있으며, 큰 Cluster1은 90%를 차지하고 작은 Cluster2는 나머지 10%를 차지합니다. 이는 키-값 레코드이므로 구성을 다시 로드하지 않고도 NGINX Plus API를 사용하여 이 비율을 동적으로 변경할 수 있습니다 ! 분할 클라이언트 모듈은 변경하자마자 바로 다음 요청에서 이 새로운 비율 값을 사용합니다.
KV 레코드를 생성하려면 50/50 비율로 시작하세요.
NGINX Plus에 API 명령을 보내어 KeyValue 저장소에 새 레코드를 추가합니다.
curl -iX POST -d '{"cafe.example.com":50}' http://nginxlb:9000/api/8/http/keyvals/split
KV 레코드를 변경하고 90/10 비율로 변경합니다.
HTTP PATCH 메서드를 사용하여 메모리에서 KeyVal 레코드를 업데이트하여 KeyVal 분할 비율을 90으로 변경합니다.
curl -iX PATCH -d '{"cafe.example.com":90}' http://nginxlb:9000/api/8/http/keyvals/split
다음으로, 사전 프로덕션 테스트 팀은 새로운 애플리케이션 코드가 준비되었는지 확인하고, 이를 대규모 Cluster1 에 배포하고 비율을 100%로 변경합니다. 그러면 모든 트래픽이 Cluster1 로 즉시 전송되고 트래픽 중단, 서비스 중단, 유지 관리 기간, 재부팅, 다시 로드 또는 많은 티켓 없이 새로운 애플리케이션이 "라이브" 상태가 됩니다. 선택한 시점에 이 분할 비율을 변경하려면 API 호출이 한 번만 필요합니다.
물론, 90%에서 100%로 쉽게 이동할 수 있다는 것은 비율을 100:0에서 50:50(또는 0:100)으로 쉽게 변경할 수 있다는 것을 의미합니다. 따라서 핫 백업 클러스터를 보유하거나 새로운 리소스로 클러스터를 수평적으로 확장할 수 있습니다. 풀 스로틀로 최신 소프트웨어, 하드웨어 및 소프트웨어 패치로 완전히 새로운 클러스터를 구축하여 단 하나의 연결도 끊지 않고 일정 기간 동안 애플리케이션을 배포하고 트래픽을 마이그레이션할 수도 있습니다!
사용 사례
동적 키-값 저장소 와 함께 HTTP 분할 클라이언트 모듈을 사용하면 다음과 같은 사용 사례를 제공할 수 있습니다.
구성 예제
키-값 구성의 예는 다음과 같습니다.
# Define Key Value store, backup state file, timeout, and enable sync keyval_zone zone=split:1m state=/var/lib/nginx/state/split.keyval timeout=365d sync; keyval $host $split_level zone=split;그리고 이것은 cafe.example.com 애플리케이션 구성의 예입니다:
# Define server and location blocks for cafe.example.com, with TLS server { listen 443 ssl; server_name cafe.example.com; status_zone https://cafe.example.com; ssl_certificate /etc/ssl/nginx/cafe.example.com.crt; ssl_certificate_key /etc/ssl/nginx/cafe.example.com.key; location / { status_zone /; proxy_set_header Host $host; proxy_http_version 1.1; proxy_set_header "Connection" ""; proxy_pass https://$upstream; # traffic split to upstream blocks } # Define 2 upstream blocks – one for each cluster # Servers managed dynamically by NLK, state file backup # Cluster1 upstreams upstream cluster1-cafe { zone cluster1-cafe 256k; least_time last_byte; keepalive 16; #servers managed by NLK Controller state /var/lib/nginx/state/cluster1-cafe.state; } # Cluster2 upstreams upstream cluster2-cafe { zone cluster2-cafe 256k; least_time last_byte; keepalive 16; #servers managed by NLK Controller state /var/lib/nginx/state/cluster2-cafe.state; }업스트림 서버 IP:포트는 Kubernetes용 NGINX 로드밸런서 에서 관리합니다 . 이 새로운 컨트롤러는 NGINX Plus API를 사용하여 NGINX Plus를 동적으로 구성합니다. 자세한 내용은 다음 섹션 에 나와 있습니다 .
인기 있는 모니터링 및 시각화 도구 인 Grafana를 사용하여 시간에 따른 HTTP 분할 트래픽을 살펴보겠습니다 . NGINX Prometheus Exporter ( njs 기반 )를 사용하여 모든 NGINX Plus 메트릭을 내보내고, 이를 Grafana에서 수집하여 그래프로 표시합니다. Prometheus와 Grafana를 구성하는 방법에 대한 자세한 내용은 여기에서 확인할 수 있습니다 .
그래프에는 4개의 업스트림 서버가 있습니다. Cluster1 에 2개, Cluster2 에 2개 입니다 . HTTP 로드 생성 도구를 사용하여 HTTP 요청을 생성하고 NGINX Plus로 보냅니다.
아래 세 개의 그래프에서 그래프 시작부분의 분할 비율은 50:50임을 알 수 있습니다.
그러면 12:56:30에서는 비율이 10:90으로 바뀐다.
그러면 13:00:00에 90:10으로 변경됩니다.
Prometheus와 Grafana의 작동 구성은 Kubernetes용 NGINX Loadbalancer GitHub 저장소 에서 찾을 수 있습니다 .
동적 HTTP 업스트림: Kubernetes용 NGINX 로드밸런서
NGINX Plus API와 Kubernetes 컨트롤러용 NGINX Loadbalancer를 사용하여 정적 NGINX Upstream 구성을 동적 클러스터 업스트림으로 변경할 수 있습니다 . 이 무료 프로젝트는 NGINX Ingress Controller를 감시 하고 TCP/HTTP 로드 밸런싱을 위해 구성된 외부 NGINX Plus 인스턴스를 자동으로 업데이트하는 Kubernetes 컨트롤러 입니다 . 설계가 매우 간단하고 설치 및 작동이 간단합니다. 이 솔루션을 사용하면 Kubernetes 환경에서 TCP/HTTP 로드 밸런싱을 구현하여 새 앱과 서비스를 즉시 감지하고 트래픽에 사용할 수 있습니다. 다시 로드할 필요가 없습니다.
Architecture & Flow
Kubernetes용 NGINX 로드밸런서는 Kubernetes 클러스터 내부에 있습니다. Kubernetes에 등록되어 NGINX Ingress Controller( ) 서비스를 감시합니다 . Ingress 컨트롤러가 변경되면 Kubernetes용 NGINX 로드밸런서는 Worker Ips와 NodePort TCP 포트 번호를 수집한 다음 NGINX Plus API를nginx-ingress 통해 IP:ports를 NGINX Plus로 전송합니다 .
NGINX 업스트림 서버는 재로드가 필요 없이 업데이트되고, NGINX Plus는 트래픽을 올바른 업스트림 서버와 Kubernetes NodePorts로 로드 밸런싱합니다. 추가 NGINX Plus 인스턴스를 추가하여 고가용성을 달성할 수 있습니다 .
Kubernetes용 NGINX 로드밸런서의 작동 스냅샷
아래 스크린샷에는 Kubernetes용 NGINX Loadbalancer가 배포되어 작업을 수행하는 모습을 보여주는 두 개의 창이 있습니다.
참고 : 이 예에서 Kubernetes 워커 노드는 10.1.1.8 및 10.1.1.10입니다.
NGINX Plus 보안 기능 추가
쿠버네티스에서 실행되는 애플리케이션이 점점 더 개방형 인터넷에 노출됨에 따라 보안이 필요해지고 있습니다. 다행히도 NGINX Plus에는 계층화된 심층 방어 아키텍처를 만드는 데 사용할 수 있는 엔터프라이즈급 보안 기능이 있습니다.
클러스터 앞에 NGINX Plus가 있고 split_clients기능을 수행한다면, 그 존재감을 활용하고 유익한 보안 기능을 추가하는 건 어떨까요? 보안을 강화하는 데 사용할 수 있는 NGINX Plus 기능 몇 가지와 이를 구성, 테스트, 배포하는 데 사용할 수 있는 다른 문서에 대한 링크와 참조가 있습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
Kubernetes에서 인공 지능(AI) 및 머신 러닝(ML) 모델 학습 및 추론을 실행할 때 동적 확장 및 축소가 중요한 요소가 됩니다. 데이터를 수집하기 위해 고대역폭 스토리지와 네트워킹이 필요할 뿐만 아니라 AI 모델 학습에는 대부분 GPU 또는 기타 특수 프로세서에서 나오는 상당한(그리고 값비싼) 컴퓨팅도 필요합니다. 사전 학습된 모델을 활용하더라도 프로덕션에서 모델 제공 및 미세 조정과 같은 작업은 여전히 대부분의 엔터프라이즈 워크로드보다 컴퓨팅 집약적입니다.
클라우드 네이티브 쿠버네티스는 빠른 확장성을 위해 설계되었습니다. 또한 하이브리드, 멀티 클라우드 환경에서 동적 워크로드에 대한 민첩성과 비용 효율적인 리소스 사용을 제공하도록 설계되었습니다.
이 블로그에서는 Kubernetes에서 AI/ML 워크로드를 확장하는 가장 일반적인 세 가지 방법을 다룹니다. 이를 통해 다양한 환경에서 동적 확장에 대한 최적의 성능, 비용 절감 및 적응성을 얻을 수 있습니다.
Kubernetes에서 AI/ML 워크로드를 위한 3가지 확장 모달리티
Kubernetes가 작업 부하를 확장하는 세 가지 일반적인 방법은 수평적 Pod 자동 확장기(HPA), 수직적 Pod 자동 확장기(VPA), 클러스터 자동 확장기입니다.
세 가지 방법을 자세히 살펴보면 다음과 같습니다.
각 모달리티는 모델 학습 및 추론에 있어서 각자의 이점을 가지고 있으며, 아래 사용 사례를 통해 이를 알아볼 수 있습니다.
HPA 사용 사례
많은 경우 분산형 AI 모델 학습 및 추론 워크로드는 수평적으로 확장할 수 있습니다(즉, 학습 프로세스 또는 요청 처리를 가속화하기 위해 더 많은 포드를 추가). 이를 통해 워크로드는 HPA의 이점을 얻을 수 있으며, CPU 및 메모리 사용과 같은 메트릭 또는 워크로드와 관련된 사용자 지정 및 외부 메트릭을 기반으로 포드 수를 확장할 수 있습니다. 워크로드가 시간에 따라 달라지는 시나리오에서 HPA는 최적의 리소스 활용을 보장하기 위해 포드 수를 동적으로 조정할 수 있습니다.
쿠버네티스에서 AI 워크로드를 수평적으로 확장하는 또 다른 측면은 로드 밸런싱입니다. 최적의 성능과 적시에 요청을 처리하려면 들어오는 요청을 여러 인스턴스 또는 포드에 분산해야 합니다. 이것이 HPA와 함께 사용할 수 있는 이상적인 도구 중 하나가 Ingress 컨트롤러 인 이유입니다 .
VPA 사용 사례
AI 모델 학습 작업은 종종 리소스 집약적이어서 상당한 CPU, GPU 및 메모리 리소스가 필요합니다. VPA는 이러한 리소스 할당을 동적으로 조정할 수 있습니다. 이를 통해 각 포드가 학습 워크로드를 효율적으로 처리할 수 있는 충분한 리소스를 확보하고 할당된 모든 포드가 계산을 수행할 수 있는 충분한 컴퓨팅 용량을 확보할 수 있습니다. 또한 메모리 요구 사항은 대규모 모델을 학습하는 동안 상당히 변동될 수 있습니다. VPA는 필요에 따라 메모리 할당을 늘려 메모리 부족 오류를 방지하는 데 도움이 될 수 있습니다.
기술적으로 HPA와 VPA를 함께 사용하는 것은 가능하지만, 서로 다른 방식(즉, 수평 대 수직)으로 동일한 작업 부하를 확장하려고 할 수 있으므로 충돌을 피하기 위해 신중하게 구성해야 합니다. 각 자동 확장기의 경계를 명확하게 정의하여 서로 충돌하지 않고 보완하도록 하는 것이 중요합니다. 새로운 접근 방식은 두 가지를 서로 다른 범위로 사용하는 것입니다. 예를 들어, HPA는 작업 부하에 따라 여러 포드에 걸쳐 확장하고 VPA는 HPA에서 설정한 제한 내에서 각 포드의 리소스 할당을 미세 조정하는 데 사용합니다.
클러스터 자동 확장기 사용 사례
클러스터 오토스케일러는 AI/ML 워크로드의 수요를 충족하기 위해 클러스터 전체에서 사용 가능한 컴퓨팅, 스토리지 및 네트워킹 인프라 리소스의 전체 풀을 동적으로 조정하는 데 도움이 될 수 있습니다. 현재 수요에 따라 클러스터의 노드 수를 조정함으로써 조직은 거시 수준에서 로드 밸런싱을 수행할 수 있습니다. 이는 AI/ML 워크로드가 예측할 수 없이 상당한 컴퓨팅 리소스를 요구할 수 있으므로 최적의 성능을 보장하는 데 필요합니다.
HPA, VPA 및 클러스터 자동 확장기에는 각각 역할이 있습니다.
요약하자면 Kubernetes 자동 확장이 작동하고 AI 워크로드에 도움이 되는 세 가지 방법은 다음과 같습니다.
HPA, VPA 및 Cluster Autoscaler는 Kubernetes에서 AI/ML 워크로드를 관리하는 데 있어 서로를 보완합니다. Cluster Autoscaler는 워크로드 수요를 충족할 수 있는 충분한 노드가 있는지 확인하고, HPA는 여러 포드에 워크로드를 효율적으로 분산하며, VPA는 이러한 포드의 리소스 할당을 최적화합니다. 함께 Kubernetes 환경에서 AI/ML 애플리케이션을 위한 포괄적인 확장 및 리소스 관리 솔루션을 제공합니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
2023년 10월 25일, 미국 국립표준기술원(NIST)은 Kubernetes용 NGINX Ingress Controller에 영향을 미치는 3개의 CVE를 보고했습니다 .
해당 보고서와 후속 출판물(긴급 : Kubernetes용 NGINX Ingress 컨트롤러에서 새로운 보안 결함 발견 )은 어떤 NGINX Ingress 컨트롤러가 실제로 영향을 받는지, 그리고 이러한 CVE에 설명된 취약점을 해결하는 데 누가 관여해야 하는지에 대한 혼란(및 여러 지원 문의)을 야기했습니다.
혼란은 완전히 이해할 수 있습니다. NGINX 기반 Ingress 컨트롤러가 두 개 이상 있다는 것을 알고 계셨나요? 시작으로, "NGINX Ingress Controller"라는 완전히 다른 두 프로젝트가 있습니다.
NGINX를 기반으로 하는 다른 Ingress 컨트롤러도 있는데, Kong이 있습니다. 다행히도, 이름은 쉽게 구별할 수 있습니다. 어떤 것을 사용하는지 잘 모르겠다면 실행 중인 Ingress 컨트롤러의 컨테이너 이미지를 확인한 다음 Docker 이미지 이름을 위에 나열된 리포와 비교하세요.
위에 설명된 취약점(CVE-2022-4886, CVE-2023-5043 및 CVE-2023-5044)은 커뮤니티 프로젝트 ( kubernetes/ingress-nginx )에만 적용됩니다. NGINX Ingress Controller( nginxinc/kubernetes-ingress , 오픈소스 및 상업용)에 대한 NGINX 프로젝트는 이러한 CVE의 영향을 받지 않습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
당신은 현대적 앱 개발자입니다. 오픈 소스와 아마도 일부 상용 도구 모음을 사용하여 새로운 앱과 컨테이너를 작성, 테스트, 배포 및 관리합니다. 개발, 테스트, 스테이징 및 프로덕션 환경에서 이러한 컨테이너와 포드를 실행하기 위해 Kubernetes를 선택했습니다. 마이크로서비스의 아키텍처와 개념, Cloud Native Computing Foundation 및 기타 현대적 산업 표준을 도입했습니다.
이 여정에서 여러분은 쿠버네티스가 실제로 강력하다는 것을 알게 되었습니다. 하지만 여러분은 쿠버네티스가 얼마나 어렵고, 유연하지 않으며, 좌절스러울 수 있는지에 놀랐을 것입니다. 라우터, 방화벽, 로드 밸런서 및 기타 네트워크 장치에 대한 변경 사항과 업데이트를 구현하고 조정하는 것은 압도적일 수 있습니다. 특히 자체 데이터 센터에서는 더욱 그렇습니다! 개발자를 눈물 흘리게 만들기에 충분합니다.
이러한 과제를 어떻게 처리하는지는 Kubernetes를 어디서 어떻게 실행하는지(관리형 서비스 또는 온프레미스)와 많은 관련이 있습니다. 이 문서에서는 배포 선택이 사용 편의성에 영향을 미치는 주요 영역인 TCP 로드 밸런싱을 다룹니다.
관리형 Kubernetes를 사용한 TCP 부하 분산(일명 Easy Option)
Kubernetes용 퍼블릭 클라우드 공급자와 같은 관리형 서비스를 사용하면 지루한 네트워킹 작업의 대부분이 처리됩니다. 단 하나의 명령( kubectl apply -f loadbalancer.yaml) 으로 서비스 유형 LoadBalancer는 퍼블릭 IP, DNS 레코드 및 TCP 로드 밸런서를 제공합니다. 예를 들어, NGINX Ingress Controller가 포함된 포드에 트래픽을 분산하도록 Amazon Elastic Load Balancer를 구성하고 이 명령을 사용하면 백엔드가 변경될 때 걱정할 필요가 없습니다. 너무 쉽기 때문에 당연하게 여기실 겁니다!
온프레미스 Kubernetes를 사용한 TCP 부하 분산(일명 하드 옵션)
온프레미스 클러스터의 경우 완전히 다른 시나리오입니다. 귀하 또는 네트워킹 피어가 네트워킹 부분을 제공해야 합니다. "왜 사용자를 내 Kubernetes 앱으로 유도하는 것이 이렇게 어려울까?"라고 궁금해할 수 있습니다. 답은 간단하지만 약간 충격적입니다. 클러스터의 정문인 서비스 유형 LoadBalancer는 실제로 존재하지 않습니다.
클러스터 외부에 앱과 서비스를 노출하려면 네트워크 팀에서 티켓, 승인, 절차, 심지어 보안 검토까지 필요할 수 있습니다. 이 모든 것이 장비를 재구성하기 전에 필요합니다. 아니면 모든 것을 직접 해야 할 수도 있는데, 그러면 애플리케이션 제공 속도가 엄청나게 느려질 수 있습니다. 더 나쁜 것은 Kubernetes 서비스를 변경하지 않는 것입니다. NodePort 가 변경되면 트래픽이 차단될 수 있기 때문입니다! 그리고 사용자들이 500 오류를 얼마나 좋아하는지 우리 모두 알고 있습니다. 상사는 아마 더 싫어할 것입니다.
온프레미스 TCP 로드 밸런싱을 위한 더 나은 솔루션: Kubernetes용 NGINX 로드 밸런서
새로운 프로젝트인 Kubernetes용 NGINX 로드밸런서를 사용하면 "하드 옵션"을 "쉬운 옵션"으로 바꿀 수 있습니다 . 이 무료 프로젝트는 NGINX Ingress Controller를 감시하고 로드 밸런싱을 위해 구성된 외부 NGINX Plus 인스턴스를 자동으로 업데이트하는 Kubernetes 컨트롤러 입니다 . 매우 간단한 설계로 설치 및 작동이 간편합니다. 이 솔루션을 사용하면 온프레미스 환경에서 TCP 로드 밸런싱을 구현하여 새로운 앱과 서비스를 즉시 감지하고 트래픽에 사용할 수 있습니다. 직접 작업할 필요가 없습니다.
Architecture와 Flow
Kubernetes용 NGINX 로드밸런서는 Kubernetes 클러스터 내부에 있습니다. Kubernetes에 등록되어 nginx-ingress 서비스(NGINX Ingress Controller)를 감시합니다. 백엔드가 변경되면 Kubernetes용 NGINX 로드밸런서는 Worker IP와 NodePort TCP 포트 번호를 수집한 다음 NGINX Plus API를 통해 IP:ports를 NGINX Plus로 전송합니다 . NGINX 업스트림 서버는 로 업데이트되고 NGINX Plus는 트래픽을 올바른 업스트림 서버와 Kubernetes NodePorts로 로드밸런싱합니다. 추가 NGINX Plus 인스턴스를 추가하여 고가용성을no reload required 달성할 수 있습니다 .
Kubernetes용 NGINX 로드밸런서의 작동 스냅샷
아래 스크린샷에는 Kubernetes용 NGINX Loadbalancer가 배포되어 작업을 수행하는 모습을 보여주는 두 개의 창이 있습니다.
참고 : 이 예에서 Kubernetes 워커 노드는 10.1.1.8 및 10.1.1.10입니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
가동 중지 시간은 심각한 결과를 초래할 수 있습니다.
이러한 말은 대부분의 다른 산업보다 의료 기술 분야의 회사에 더 해당됩니다. 그들의 경우 "심각한 결과"에는 문자 그대로 사망이 포함될 수 있습니다. 우리는 최근에 의료 기록 보관을 펜과 종이에서 언제 어디서나 액세스할 수 있는 안전한 디지털 데이터로 전환하려는 회사의 기술 스택을 분석할 기회를 가졌습니다. 이러한 데이터는 환자 정보에서 치료 지침, 생물학적 마커, 의료 분석, 과거 기록 및 의료 팀 간에 공유되는 모든 것에 이르기까지 다양합니다.
처음부터 이 회사는 겉보기에 간단한 질문인 "케어 종사자가 실시간으로 데이터를 쉽게 기록하도록 어떻게 도울 수 있을까?"를 해결하고자 했습니다. 그러나 회사가 성장함에 따라 확장하고 데이터를 지속적으로 사용할 수 있게 해야 하는 필요성으로 인해 이 과제를 해결하는 것이 점점 더 복잡해졌습니다. 여기서는 이 회사의 기술 여정이 어떻게 Kubernetes 와 NGINX Ingress Controller를 도입하게 되었는지 설명합니다 .
기술 스택을 한눈에 보기
NGINX가 해당 아키텍처에서 어떻게 적용되는지 살펴보겠습니다.
종이의 문제
정기적으로 환자 상태와 치료 정보를 수집하는 것은 의료 종사자의 핵심 임무입니다. 전통적으로 그들은 환자 정보를 종이에 기록했거나, 최근에는 노트북이나 태블릿에 기록했습니다. 몇 가지 심각한 단점이 있습니다.
이러한 과제를 해결하기 위해 회사는 환자 정보에 액세스하고 약물 분배와 같은 일반적인 이벤트를 기록하기 위한 단축키를 제공하는 간소화된 데이터 기록 시스템을 만들었습니다. 이러한 액세스 및 사용의 용이성 덕분에 환자 상호작용을 발생하는 대로 실시간으로 기록할 수 있습니다.
모든 데이터는 회사에서 관리하는 클라우드 시스템에 저장되며, 앱은 다른 전자 의료 기록 시스템과 통합되어 거주자 행동에 대한 포괄적인 종단적 관점을 제공합니다. 이를 통해 간병인은 더 나은 치료 연속성을 제공하고, 안전한 과거 기록을 생성하며, 다른 의료 소프트웨어 시스템과 쉽게 공유할 수 있습니다.
의사와 다른 전문가도 환자를 입원시키거나 다른 방식으로 환자와 교류할 때 이 플랫폼을 사용합니다. 환자와 함께 모든 시설로 이동하는 선호도와 개인적 필요 사항의 기록이 있습니다. 이를 사용하여 환자가 새로운 환경에서 편안함을 느끼도록 도울 수 있으며, 이는 회복 시간과 같은 결과를 개선합니다.
회사가 환자 데이터를 얼마나 오랫동안 보관해야 하는지에 대한 엄격한 법적 요구 사항이 있습니다. 이 회사의 개발자는 일반 클라우드 애플리케이션보다 훨씬 더 나은 가동 시간 SLA로 매우 높은 가용성을 제공하는 소프트웨어를 구축했습니다. 환자의 파일이 로드되지 않아서 구급차를 기다리게 하는 것은 선택 사항이 아닙니다.
차고에서 클라우드로, 그리고 쿠버네티스로의 여행
많은 스타트업과 마찬가지로 이 회사는 공동 창업자의 집에 있는 서버에서 최초의 개념 증명 애플리케이션을 실행하여 처음에 비용을 절감했습니다. 이 아이디어가 타당하다는 것이 분명해지자 회사는 데이터 센터에서 하드웨어를 관리하는 대신 인프라를 클라우드로 옮겼습니다. Microsoft 매장인 그들은 Azure를 선택했습니다. 초기 아키텍처는 Microsoft의 IIS 웹 서버를 실행하는 관리형 애플리케이션 제공 서비스인 Azure App Service의 기존 가상 머신(VM)에서 애플리케이션을 실행했습니다. 데이터 저장 및 검색을 위해 이 회사는 VM에서 실행되는 Microsoft의 SQL Server를 관리형 애플리케이션으로 사용하기로 했습니다.
클라우드에서 수년간 운영한 후, 회사는 빠르게 성장하고 확장의 어려움을 겪었습니다. 회사는 무한히 확장해야 했고, VM을 사용하면 수직이 느리고 비용이 많이 들기 때문에 수평이 아닌 수평으로 확장해야 했습니다. 이러한 요구 사항으로 인해 컨테이너화와 Kubernetes가 가능한 솔루션으로 자연스럽게 이어졌습니다. 컨테이너화를 지지하는 또 다른 요점은 회사 개발자가 중단 위험 없이 애플리케이션과 인프라에 대한 업데이트를 자주 제공해야 한다는 것입니다. 환자 기록이 여러 시간대에 걸쳐 지속적으로 추가되면서 고객이 결함으로 인해 즉시 영향을 받을 위험 없이 프로덕션에 변경 사항을 푸시할 자연스러운 다운타임이 없습니다.
회사의 논리적인 시작점은 Microsoft의 관리형 Kubernetes 오퍼링인 Azure Kubernetes Services(AKS)였습니다. 팀은 Kubernetes 모범 사례를 조사하고 AKS의 노드와 포드에서 실행되는 트래픽과 애플리케이션을 효과적으로 관리하기 위해 Kubernetes 클러스터 앞에서 실행되는 Ingress 컨트롤러가 필요 하다는 것을 깨달았습니다.
Traffic 경로는 유연하면서도 정확해야 합니다.
팀은 AKS의 기본 Ingress 컨트롤러를 테스트했지만, 트래픽 라우팅 기능이 회사 고객에게 필요한 방식으로 업데이트를 제공할 수 없다는 것을 발견했습니다. 환자 케어에 관해서는 모호함이나 상충되는 정보에 대한 여지가 없습니다. 예를 들어, 한 케어 종사자가 주황색 플래그를 보고 다른 케어 종사자가 같은 이벤트에 대해 빨간색 플래그를 보는 것은 용납할 수 없습니다. 따라서 주어진 조직의 모든 사용자는 동일한 버전의 앱을 사용해야 합니다. 이는 업그레이드와 관련하여 큰 과제입니다. 고객을 새 버전으로 전환할 자연스러운 시기가 없으므로 회사는 서버 및 네트워크 수준에서 규칙을 사용하여 다른 고객을 다른 앱 버전으로 라우팅할 방법이 필요했습니다.
이를 달성하기 위해 이 회사는 조직의 모든 사용자에게 동일한 백엔드 플랫폼을 실행하고 조직 내 인프라 계층에서 세분화된 다중 테넌시를 제공하지 않습니다. Kubernetes를 사용하면 자세한 트래픽 규칙과 함께 브라우저의 가상 네트워크 경로 및 쿠키를 사용하여 트래픽을 분할할 수 있습니다. 그러나 이 회사의 기술 팀은 AKS의 기본 Ingress 컨트롤러는 필요에 따라 고객 조직 또는 개별 사용자 수준에서 작동하는 규칙이 아닌 백분율 기준으로만 트래픽을 분할할 수 있다는 것을 발견했습니다.
기본 구성에서 NGINX Open Source를 기반으로 하는 NGINX Ingress Controller는 동일한 제한이 있으므로 회사는 세분화된 트래픽 제어를 지원하는 엔터프라이즈급 제품인 NGINX Plus를 기반으로 하는 보다 고급 NGINX Ingress Controller로 전환하기로 결정했습니다. 높은 수준의 유연성과 제어를 기반으로 Microsoft와 Kubernetes 커뮤니티의 NGINX Ingress Controller에서 권장 사항을 찾은 것은 선택을 확고히 하는 데 도움이 되었습니다. 이 구성은 포드 관리(클래식 트래픽 관리와 대조적으로)에 대한 회사의 요구 사항을 더 잘 지원하여 포드가 적절한 영역에서 실행되고 트래픽이 해당 서비스로 라우팅되도록 합니다. 때로는 트래픽이 내부적으로 라우팅되지만 대부분의 사용 사례에서는 관찰 가능성을 위해 NGINX Ingress Controller를 통해 다시 라우팅됩니다.
Here Be Dragons: 모니터링, 관찰성 및 애플리케이션 성능
NGINX Ingress Controller를 사용하면 기술팀이 개발자와 최종 사용자 경험을 완벽하게 제어할 수 있습니다. 사용자가 로그인하여 세션을 설정하면 즉시 새 버전으로 라우팅되거나 이전 버전으로 되돌릴 수 있습니다. 패치는 조직의 모든 사용자에게 동시에 거의 즉시 푸시될 수 있습니다. 소프트웨어는 클라우드 플랫폼 전반의 네트워킹에 대한 DNS 전파나 업데이트에 의존하지 않습니다.
NGINX Ingress Controller는 또한 회사의 세부적이고 지속적인 모니터링 요구 사항을 충족합니다. 애플리케이션 성능은 의료 분야에서 매우 중요합니다. 지연이나 가동 중지 시간은 특히 생사의 상황에서 성공적인 임상 치료를 방해할 수 있습니다. Kubernetes로 이전한 후, 고객들은 회사에서 알아차리지 못한 가동 중지 시간을 보고하기 시작했습니다. 회사는 곧 문제의 근원을 발견했습니다. Azure App Service는 샘플링된 데이터에 의존합니다. 샘플링은 평균 및 광범위한 추세에는 적합하지만 거부된 요청 및 누락된 리소스와 같은 사항은 완전히 놓칩니다. 또한 간병인이 체크인하고 환자 데이터를 기록할 때 일반적으로 30분마다 발생하는 사용량 급증도 표시하지 않습니다. 회사는 지연, 오류 소스, 잘못된 요청 및 사용할 수 없는 서비스에 대한 불완전한 그림만 얻었습니다.
문제는 거기서 끝나지 않았습니다. 기본적으로 Azure App Service는 저장된 데이터를 한 달 동안만 보존합니다. 많은 국가의 법률에서 요구하는 수십 년보다 훨씬 짧습니다. 더 오래 보존하기 위해 필요에 따라 데이터 저장소를 확장하는 것은 엄청나게 비쌌습니다. 게다가 Azure 솔루션은 Kubernetes 네트워킹 스택 내부를 볼 수 없습니다. NGINX Ingress Controller는 4계층과 7계층 트래픽을 처리할 때 인프라와 애플리케이션 매개변수를 모두 모니터링할 수 있습니다.
성능 모니터링 및 관찰성을 위해 이 회사는 Grafana 시각화 엔진 및 대시보드에 연결된 Prometheus 시계열 데이터베이스를 선택했습니다. Prometheus와 Grafana와의 통합은 NGINX 데이터 및 제어 평면에 미리 구워져 있으며, 기술 팀은 모든 트래픽을 Prometheus 및 Grafana 서버를 통해 전달하기 위해 작은 구성 변경만 하면 되었습니다. 이 정보는 또한 Grafana Loki 로깅 데이터베이스로 라우팅되어 로그를 분석하기 쉬워졌고 소프트웨어 팀이 시간이 지남에 따라 데이터를 더 잘 제어할 수 있게 되었습니다.
이 구성은 또한 문제 해결 및 버그 수정을 위해 매우 빈번하고 방대한 양의 데이터 샘플링이 필요한 사고에 대비하여 미래를 보호합니다. 대부분의 대형 클라우드 회사에서 제공하는 애플리케이션 모니터링 시스템으로는 이러한 유형의 사고를 해결하는 데 비용이 많이 들 수 있지만 이 사용 사례에서 Prometheus, Grafana 및 Loki의 비용과 오버헤드는 최소입니다. 세 가지 모두 안정적인 오픈 소스 제품으로 일반적으로 초기 튜닝 후 패치만 하면 됩니다.
Routing 유지: 고가용성 및 보안에 집중
이 회사는 항상 가장 민감한 데이터 유형 중 하나를 보호하기 위한 보안과 필요할 때마다 앱을 사용할 수 있도록 하는 고가용성 에 중점을 두었습니다 . Kubernetes로 전환하면서 두 가지 용량을 모두 확장하기 위해 몇 가지 변경을 했습니다.
가장 높은 가용성을 위해 기술 팀은 단일 장애 지점 없이 완전한 중복성을 위해 액티브-액티브, 멀티 존, 멀티 지오 분산 인프라 설계를 구축합니다. 팀은 두 개의 다른 지리적 지역에 듀얼 쿠버네티스 클러스터가 있는 N+2 액티브-액티브 인프라를 유지 관리합니다. 각 지리적 지역 내에서 소프트웨어는 여러 데이터 센터에 걸쳐 다운타임 위험을 줄이고 인프라의 모든 계층에서 장애가 발생할 경우 적용 범위를 제공합니다. 친화성 및 반친화성 규칙은 사용자와 트래픽을 즉시 가동 중인 포드로 다시 라우팅하여 서비스 중단을 방지할 수 있습니다.
보안을 위해 팀은 잘못된 요청과 악의적인 행위자로부터 보호하기 위해 웹 애플리케이션 방화벽 (WAF)을 배포합니다. OWASP Top 10 에 대한 보호 는 대부분 WAF에서 제공하는 기본 사항입니다. 앱을 만들 때 팀은 기본 Azure WAF와 ModSecurity를 포함한 여러 WAF를 조사했습니다. 결국 팀은 인라인 WAF와 분산 서비스 거부 (DDoS) 보호 기능이 있는 NGINX App Protect를 선택했습니다.
NGINX App Protect의 큰 장점은 NGINX Ingress Controller와 함께 배치되어 중복 지점을 제거하고 지연 시간을 줄이는 것입니다. 다른 WAF는 Kubernetes 환경 외부에 배치해야 하므로 지연 시간과 비용이 증가합니다. 아주 사소한 지연(요청당 1밀리초 추가)도 시간이 지남에 따라 빠르게 누적됩니다.
서프라이즈 사이드 퀘스트: 개발자를 위한 다운타임 없음
대부분의 애플리케이션 및 네트워킹 인프라에 대해 AKS로의 전환을 완료한 이 회사는 개발자 경험(DevEx)에서도 상당한 개선을 이루었습니다. 이제 개발자는 고객이 문제를 알아차리기 전에 거의 항상 문제를 발견합니다. 전환 이후 오류에 대한 지원 전화의 양이 약 80% 감소했습니다!
회사의 보안 및 애플리케이션 성능 팀은 자세한 Grafana 대시보드와 통합 알림을 갖추고 있어 여러 시스템을 확인하거나 다른 프로세스에서 오는 경고 텍스트 및 호출에 대한 트리거를 구현할 필요가 없습니다. 개발 및 DevOps 팀은 이제 코드 및 인프라 업데이트를 매일 또는 하루에 여러 번 제공하고 매우 세부적인 청록색 패턴을 사용할 수 있습니다. 이전에는 일주일에 한두 번 업데이트를 제공하고 사용량이 적은 시간대에 시간을 내야 했으며 이는 스트레스가 많은 제안이었습니다. 이제 코드는 준비되면 제공되고 개발자는 애플리케이션 동작을 관찰하여 영향을 직접 모니터링할 수 있습니다.
결과는 전반적으로 긍정적입니다. 소프트웨어 개발 속도가 빨라지고, 개발자의 사기가 향상되고, 생명이 더 많이 구해졌습니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
저희는 2023년 1월에 NGINX Ingress Controller 의 버전 3.0을 출시했으며, 여기에는 중요한 새로운 기능과 향상된 기능이 다수 포함되었습니다. 여러분께 특히 가치 있다고 생각되는 새로운 기능 중 하나는 NGINX Ingress Controller의 NGINX Plus 에디션에서 제공되는 Deep Service Insight입니다.
Deep Service Insight는 로드 밸런서와 같은 라우팅 결정 시스템이 하나 이상의 Kubernetes 클러스터 앞에 있을 때 최적의 기능을 방해하는 제한 사항을 해결합니다. 즉, 시스템은 Ingress 컨트롤러 뒤의 클러스터에서 실행되는 개별 서비스의 상태에 대한 정보에 액세스할 수 없습니다. 이를 통해 트래픽을 정상적인 서비스가 있는 클러스터로만 라우팅하지 못하게 되어 사용자를 중단 및 오류(예: 404) 에 노출시킬 가능성이 있습니다 500.
Deep Service Insight는 NGINX Ingress Controller에서 수집한 백엔드 서비스 포드의 상태를 전용 엔드포인트에 노출하여 시스템에서 액세스하고 더 나은 라우팅 결정을 내리는 데 활용할 수 있도록 함으로써 이러한 문제를 해결합니다.
이 게시물에서는 Deep Service Insight가 해결하는 문제를 자세히 살펴보고, 몇 가지 일반적인 사용 사례에서 이 기능이 어떻게 작동하는지 설명하고, 이를 구성하는 방법을 보여드리겠습니다.
왜 Deep Service Insight가 필요한가요?
표준 Kubernetes 라이브니스, 준비성 및 시작 프로브는 클러스터에서 실행되는 백엔드 서비스에 대한 정보를 제공하지만 스택 전체에 걸쳐 더 나은 라우팅 결정을 내리는 데 필요한 통찰력을 제공하기에는 충분하지 않습니다. Kubernetes 배포가 복잡해지고 중단 없는 가동 시간에 대한 비즈니스 요구 사항이 더 시급해짐에 따라 올바른 정보가 부족하면 문제가 더 커집니다.
Kubernetes 환경을 확장할 때 가동 시간을 개선하기 위한 일반적인 접근 방식은 클러스터 앞에 로드 밸런서, DNS 관리자 및 기타 자동화된 결정 시스템을 배포하는 것입니다. 그러나 Ingress 컨트롤러의 작동 방식 때문에 Kubernetes 클러스터 앞에 있는 로드 밸런서는 일반적으로 클러스터에서 Ingress 컨트롤러 뒤에 있는 서비스에 대한 상태 정보에 액세스할 수 없습니다. Ingress 컨트롤러 포드 자체가 정상이고 트래픽을 수용하는지 여부만 확인할 수 있습니다.
반면 NGINX Ingress Controller는 서비스 상태에 대한 정보를 가지고 있습니다. 이미 HTTP , TCP , UDP 및 gRPC 서비스에 대한 주기적 수동 상태 검사를 보내고, 요청 응답성을 모니터링하고, 성공적인 응답 코드 및 기타 메트릭을 추적하여 클러스터의 업스트림 포드 상태를 모니터링합니다. 이 정보를 사용하여 일관되고 예측 가능한 사용자 경험을 제공하기 위해 서비스의 포드에 트래픽을 분산하는 방법을 결정합니다. 일반적으로 NGINX Ingress Controller는 백그라운드에서 이 모든 마법을 조용히 수행하고 있으며, 후드 아래에서 무슨 일이 일어나고 있는지 두 번 생각하지 않을 수도 있습니다. Deep Service Insight는 이 귀중한 정보를 "표면화"하여 스택의 다른 계층에서 보다 효과적으로 사용할 수 있도록 합니다.
심층적 서비스 통찰력은 어떻게 작동하나요?
Deep Service Insight는 NGINX VirtualServer 및 TransportServer 사용자 지정 리소스(각각 HTTP 및 TCP/UDP용)를 사용하여 배포하는 서비스에 사용할 수 있습니다. Deep Service Insight는 NGINX Plus API를 사용하여 Deep Service Insight에 고유한 전용 엔드포인트에서 백엔드 서비스의 개별 포드에 대한 NGINX Ingress Controller의 뷰를 공유합니다.
어디
출력에는 두 가지 유형의 정보가 포함됩니다.
호스트 이름 또는 서비스 이름에 대한 HTTP 상태 코드:
지정된 호스트 이름 또는 서비스 이름에 대한 세 개의 카운터:
다음은 서비스의 세 개의 Pod가 모두 정상인 예입니다.
HTTP/1.1 200 OKContent-Type: application/json; charset=utf-8 Date: Day, DD Mon YYYY hh:mm:ss TZ Content-Length: 32 {"Total":3,"Up":3,"Unhealthy":0}자세한 내용은 NGINX Ingress Controller 설명서를 참조하세요 .
활성 상태 검사를 구성하여 NGINX Ingress Controller가 포드가 정상인지 판단하는 데 사용하는 기준을 추가로 사용자 지정할 수 있습니다. 상태 검사가 전송되는 경로와 포트, 포드가 비정상으로 간주되기 위해 지정된 기간 내에 발생해야 하는 실패 검사 수, 예상 상태 코드, 연결 또는 응답 수신 시간 초과 등을 구성할 수 있습니다. VirtualServer 또는 TransportServerUpstream.Healthcheck 리소스 에 필드를 포함합니다 .
심층적인 서비스 통찰력을 위한 샘플 사용 사례
Deep Service Insight가 특히 가치 있는 사용 사례 중 하나는 로드 밸런서가 고가용성을 위해 두 클러스터에서 실행되는 서비스로 트래픽을 라우팅하는 경우입니다. 각 클러스터 내에서 NGINX Ingress Controller는 위에서 설명한 대로 업스트림 포드의 상태를 추적합니다. Deep Service Insight를 활성화하면 정상 및 비정상 업스트림 포드의 수에 대한 정보도 전용 엔드포인트에 노출됩니다. 라우팅 결정 시스템은 엔드포인트에 액세스하여 해당 정보를 사용하여 애플리케이션 트래픽을 비정상 포드에서 정상 포드로 전환할 수 있습니다.
이 다이어그램은 이 시나리오에서 Deep Service Insight가 작동하는 방식을 보여줍니다.
고가용성 시나리오에서 클러스터에 대한 유지 관리를 수행할 때 Deep Service Insight를 활용할 수도 있습니다. 유지 관리를 수행하는 클러스터에서 서비스에 대한 포드 수를 0으로 줄이기만 하면 됩니다. 건강한 포드가 없는 경우 Deep Service Insight 엔드포인트에 자동으로 표시되고 라우팅 결정 시스템은 해당 정보를 사용하여 다른 클러스터의 건강한 포드로 트래픽을 전송합니다. NGINX Ingress Controller나 시스템에서 구성을 변경하지 않고도 효과적으로 자동 장애 조치를 받을 수 있으며, 고객은 서비스 중단을 경험하지 않습니다.
심층적인 서비스 통찰력 활성화
Deep Service Insight를 활성화하려면 -enable-service-insightKubernetes 매니페스트에 명령줄 인수를 포함하거나 Helm을 사용하는 경우 serviceInsight.create매개변수를 로 설정합니다 true.
사용자 환경에 맞게 엔드포인트를 조정하기 위해 포함할 수 있는 두 가지 선택적 인수가 있습니다.
예: 카페 애플리케이션에 대한 심층적 서비스 통찰력 활성화
Deep Service Insight가 실제로 어떻게 활용되는지 확인하려면 NGINX Ingress Controller 설명서에서 예로 자주 사용되는 Cafe 애플리케이션 에서 이를 활성화하면 됩니다 .
NGINX 사용자 정의 리소스를 지원하고 Deep Service Insight를 활성화하는 NGINX Ingress Controller의 NGINX Plus 버전을 설치합니다.
NGINX Ingress Controller가 실행 중인지 확인하세요.
$ kubectl get pods -n nginx-ingressNAME READY ... ingress-plus-nginx-ingress-6db8dc5c6d-cb5hp 1/1 ... ... STATUS RESTARTS AGE ... Running 0 9dNGINX VirtualServer 사용자 정의 리소스가 Cafe 애플리케이션에 배포되었는지 확인합니다(IP 주소는 읽기 쉽도록 생략).
$ kubectl get vs NAME STATE HOST IP PORTS AGE cafe Valid cafe.example.com ... [80,443] 7h1mcafe.example.com 에서 실행되는 Cafe 서비스에 대해 세 개의 업스트림 포드가 있는지 확인하세요 .
$ kubectl get pods NAME READY STATUS RESTARTS AGE coffee-87cf76b96-5b85h 1/1 Running 0 7h39m coffee-87cf76b96-lqjrp 1/1 Running 0 7h39m tea-55bc9d5586-9z26v 1/1 Running 0 111mDeep Service Insight 엔드포인트에 액세스하세요.
$ curl -i <NIC_IP_address>:9114/probe/cafe.example.com응답 코드 는 200 OK서비스가 트래픽을 허용할 준비가 되었음을 나타냅니다(적어도 하나의 포드가 정상임). 이 경우 세 개의 포드가 모두 Up 상태입니다.
HTTP/1.1 200 OK Content-Type: application/json; charset=utf-8 Date: Day, DD Mon YYYY hh:mm:ss TZ Content-Length: 32 {"Total":3,"Up":3,"Unhealthy":0}상태 418 I’m a teapot코드는 서비스를 사용할 수 없음(모든 Pod가 비정상적임)을 나타냅니다.
HTTP/1.1 418 I'm a teapotContent-Type: application/json; charset=utf-8 Date: Day, DD Mon YYYY hh:mm:ss TZ Content-Length: 32 {"Total":3,"Up":0,"Unhealthy":3}상태 코드 404 Not Found는 지정된 호스트 이름에서 실행 중인 서비스가 없음을 나타냅니다.
HTTP/1.1 404 Not FoundDate: Day, DD Mon YYYY hh:mm:ss TZ Content-Length: 0위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기
오늘날 기업에서 비용과 위험의 균형을 맞추는 것이 가장 중요합니다. 하지만 충분한 가시성이 없다면 리소스가 효과적으로 또는 일관되게 사용되고 있는지 알 수 없습니다.
쿠버네티스는 종종 일시적이고 가변적인 양의 클러스터 리소스를 소모하는 컨테이너화된 워크로드의 복잡한 배포를 가능하게 합니다. 이는 클라우드 환경이 쿠버네티스에 매우 적합한 이유입니다. 쿠버네티스는 피크 부하를 예상하여 과도하게 프로비저닝할 필요 없이 사용한 만큼만 비용을 지불하는 가격 모델을 제공하기 때문입니다. 물론 클라우드 공급업체는 이러한 편의성에 대해 프리미엄을 청구합니다. 비용 없이 퍼블릭 클라우드의 동적 로드 밸런싱을 잠금 해제할 수 있다면 어떨까요? 그리고 온프레미스 및 퍼블릭 클라우드 배포에 동일한 솔루션을 사용할 수 있다면 어떨까요?
이제 가능합니다. Kubecost와 NGINX는 Kubernetes 사용자가 수많은 배포에서 복잡성과 비용을 줄이는 데 도움을 줍니다. 이러한 솔루션을 함께 사용하면 최적의 성능과 해당 성능 및 관련 비용에 대한 궁극적인 가시성을 얻을 수 있습니다.
Kubecost의 통찰력을 통해 성능과 보안을 높이는 동시에 Kubernetes 배포 비용을 획기적으로 줄일 수 있습니다. Kubecost로 달성할 수 있는 것의 예는 다음과 같습니다.
NGINX는 당신에게 필요한 성능을 제공합니다
NGINX Ingress Controller는 가장 널리 사용되는 Ingress 기술 중 하나로, 지금까지 Docker Hub에서 10억 회 이상 풀을 달성했으며 , 프로덕션 환경에서 실행되는 고성능, 확장 가능 및 보안을 갖춘 최신 앱의 대명사입니다.
NGINX Ingress Controller는 Kubernetes 환경에서 NGINX Open Source 또는 NGINX Plus 인스턴스와 함께 실행됩니다. 표준 Kubernetes Ingress 리소스 와 NGINX 사용자 지정 리소스를 모니터링하여 Ingress 로드 밸런싱이 필요한 서비스에 대한 요청을 발견합니다. 그런 다음 NGINX Ingress Controller는 NGINX 또는 NGINX Plus를 자동으로 구성하여 이러한 서비스로 트래픽을 라우팅하고 로드 밸런싱합니다.
NGINX Ingress Controller는 API 게이트웨이, 로드 밸런서 및 Ingress 컨트롤러 기능을 결합하는 범용 도구로 사용하여 운영을 간소화하고 비용과 복잡성을 줄일 수 있습니다.
Kubecost가 네트워크 운영의 실제 비용을 공개합니다.
Kubecost는 Kubernetes 사용자에게 클러스터에서 각 컨테이너를 실행하는 데 드는 비용에 대한 가시성을 제공합니다. 여기에는 각 노드의 명백한 CPU, 메모리 및 스토리지 비용이 포함됩니다. 그러나 Kubecost는 이러한 기본 사항을 넘어 클라우드 공급자의 데이터 이탈 시 일반적으로 발생하는 포드당 네트워크 전송 비용을 공개합니다.
Kubecost가 올바른 작업 부하에 비용을 얼마나 정확하게 할당하는지를 결정하는 두 가지 구성 옵션이 있습니다.
첫 번째 옵션은 통합 클라우드 청구 입니다 . Kubecost는 트래픽을 처리한 노드와 관련된 네트워크 전송 비용을 포함하여 클라우드 공급자로부터 청구 데이터를 가져옵니다. Kubecost는 이 비용을 컨테이너 트래픽의 공유에 따라 해당 노드의 포드에 분배합니다.
보고된 총 네트워크 비용은 정확하지만 이 방법은 이상적이지 않습니다. 많은 포드의 경우 유일하게 중요한 트래픽은 자체 존(따라서 무료) 내에 있지만 Kubecost는 이러한 워크로드에 대한 네트워크 비용을 보여줍니다.
두 번째 옵션인 네트워크 비용 구성은 모든 트래픽의 소스와 목적지를 살펴봄으로써 클라우드 청구 통합의 이러한 한계를 해결합니다. Kubecost Allocations 대시보드는 네임스페이스, 레이블, 서비스와 같은 Kubernetes 개념과 팀, 제품, 프로젝트, 부서, 환경과 같은 조직 부문을 포함한 여러 범주에 걸친 지출 비율을 표시합니다.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기