NGINX Korea

NGINX Ingress/Gateway Fabric 에서 구현가능한 기술 / 사용사례 소개 64

14

Ingress Controller 선택 가이드, 1부: 요구 사항 식별

관리자

2024-08-16

편집자 - 이 게시물은 10부작 시리즈의 일부입니다.

프로덕션 등급 Kubernetes로 복잡성 감소
고급 트래픽 관리를 사용하여 Kubernetes의 복원력을 개선하는 방법
Kubernetes에서 가시성을 개선하는 방법
트래픽 관리 도구를 사용하여 Kubernetes를 보호하는 6가지 방법
Ingress Controller 선택 가이드, 1부: 요구 사항 식별(이 게시물)
Ingress 컨트롤러 선택 가이드, 2부: 위험 및 미래 대비
Ingress 컨트롤러 선택 가이드, 3부: 오픈소스 대 기본 대 상업용
Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress 컨트롤러 옵션
서비스 메시를 선택하는 방법
동적 Kubernetes 클라우드 환경에서 NGINX Ingress 컨트롤러 성능 테스트

또한 전체 블로그 세트를 무료 전자책인 ' 테스트에서 프로덕션까지 Kubernetes 활용' 으로 다운로드할 수 있습니다 .

조직이 처음 Kubernetes를 실험하기 시작할 때, Ingress 컨트롤러 선택에 대해 깊은 고민을 하지 않는 경우가 많습니다.

모든 Ingress 컨트롤러가 비슷하다고 생각할 수 있으며, 대부분 기본 인그레스 컨트롤러를 사용하여 빠르게 배포를 진행하려 합니다.

테스트 환경이나 낮은 트래픽의 프로덕션 환경에서는 어떤 인그레스 컨트롤러를 사용해도 무방할 수 있지만,

규모가 커질수록 인그레스 컨트롤러의 선택이 중요해집니다.

인그레스 컨트롤러는 단순히 트래픽을 A 지점에서 B 지점으로 이동시키는 것 이상의 기능을 제공합니다.

고급 트래픽 관리부터 가시성, 내장 보안까지 Ingress 컨트롤러는 Kubernetes 스택에서 가장 강력한 도구 중 하나가 될 수 있습니다.

확장성이 좋지 않거나 복잡한 환경을 보호하지 못하는 Ingress 컨트롤러를 선택하면

Kubernetes를 테스트에서 프로덕션으로 전환하는 데 방해가 될 수 있습니다.

이 블로그 시리즈에서는 Ingress 컨트롤러의 기본 사항과 오늘과 미래에 필요한 기능과

보안을 제공하는 현명한 선택을 하는 방법에 대해 알려드리고자 합니다.

인그레스 컨트롤러란?

인그레스 컨트롤러는 Kubernetes 클러스터에 들어오는 Layer 4와 7 트래픽을 관리하는 전문 로드 밸런서입니다.

또한, 클러스터에서 나가는 트래픽을 관리할 수도 있습니다. NGINX에서 사용하는 용어는 다음과 같습니다:

Ingress Traffic: Kubernetes 클러스터로 들어오는 트래픽
Egress Traffic: Kubernetes 클러스터에서 나가는 트래픽
North-South Traffic: 클러스터의 출입 트래픽
East-West Traffic: 클러스터 내의 서비스 간 트래픽
Service Mesh: 서비스 간 트래픽을 라우팅하고 보호하는 도구

인그레스 컨트롤러가 필요한 이유는 무엇인가요?

기본적으로 Kubernetes 포드(컨테이너)에서 실행되는 애플리케이션은 외부 네트워크에서 액세스할 수 없고

Kubernetes 클러스터 내의 다른 포드에서만 액세스할 수 있습니다.

Kubernetes에는 Ingress 라는 HTTP 로드 밸런싱을 위한 기본 제공 구성 객체가 있는데 ,

이는 Kubernetes 클러스터 외부의 엔터티가 하나 이상의 Kubernetes 서비스로 표현되는 포드에 연결할 수 있는 방법을 정의합니다.

Kubernetes 서비스에 대한 외부 액세스를 제공해야 하는 경우 URI 경로, 백업 서비스 이름 및 기타 정보를 포함하여

연결 규칙을 정의하기 위해 Ingress 리소스를 만듭니다 . 그러나 Ingress 리소스 자체로는 아무것도 하지 않습니다.

Ingress 리소스에 정의된 규칙을 구현하려면 Ingress 컨트롤러 애플리케이션(Kubernetes API 사용)을 배포하고 구성해야 합니다.

인그레스 컨트롤러의 기능은 무엇인가요?

트래픽 수용 및 분배: 외부에서 들어오는 트래픽을 수용하고 수정하여 내부 포드에 분배합니다. 이는 기본 kube-proxy 트래픽 분배 모델을 대체하여, 애플리케이션 딜리버리 컨트롤러(ADC) 및 리버스 프록시와 같은 추가 제어 기능을 제공합니다.
포드 모니터링: 서비스의 개별 포드를 모니터링하여 지능적인 라우팅을 보장하고, 요청이 블랙홀에 빠지지 않도록 합니다.
Egress 규칙 구현: 상호 TLS(mTLS) 또는 특정 외부 서비스로의 아웃바운드 트래픽을 제한하는 규칙을 구현하여 보안을 강화합니다.

Ingress 컨트롤러를 선택할 때 기능 목록으로 시작하는 것에 이끌릴 수 있지만, 환상적인 기능을 갖추고 있지만 비즈니스 요구 사항을 충족하지 못하는 Ingress 컨트롤러를 얻게 될 수 있습니다. 대신 Ingress 컨트롤러가 팀과 앱에 얼마나 잘 작동하는 지에 대한 영향을 미치는 두 가지 요소, 즉 사용 사례(해결할 문제)와 리소스(어떻게 "지불"할 것인가)를 살펴보세요. 이 블로그의 나머지 부분에서는 이 두 가지 주제를 다루겠습니다.

Ingress Controller로 어떤 문제를 해결하고 싶으신가요?

Ingress 컨트롤러의 핵심 사용 사례는 트래픽 관리이므로 Ingress 컨트롤러가

다음과 같은 일반적인 사용 사례 중 하나 이상을 처리하도록 하려고 할 것입니다.

부하 분산(HTTP2, HTTP/HTTPS, SSL/TLS 종료, TCP/UDP, WebSocket, gRPC)
트래픽 제어(속도 제한, 회로 차단, 활성 상태 검사)
트래픽 분할(디버그 라우팅, A/B 테스트, 카나리아 배포, 블루-그린 배포)

하지만 "한 가지 기능만 하는 포니"에 만족할 이유는 없습니다. 대부분의 Ingress 컨트롤러는 트래픽을 관리하는 것 이상을 할 수 있습니다.
Ingress 컨트롤러를 사용하여 여러 문제를 해결하면 스택의 크기와 복잡성을 줄일 수 있을 뿐만 아니라
앱에서 비기능적 요구 사항을 Ingress 컨트롤러로 오프로드할 수도 있습니다.
리소스를 보다 효율적으로 사용하면서 Kubernetes 배포를 보다 안전하고 민첩하며 확장 가능하게 만드는 데
도움이 되는 네 가지 비전통적인 Ingress 컨트롤러 사용 사례를 살펴보겠습니다.

모니터링 및 가시성

Kubernetes 클러스터에 대한 가시성 부족은 프로덕션 환경에서 가장 큰 과제 중 하나이며, 문제 해결 및 복원력에 어려움을 줍니다. Ingress 컨트롤러는 Kubernetes 클러스터의 가장자리에서 작동하고 모든 트래픽에 영향을 미치므로 Kubernetes 클러스터 또는 플랫폼에서 느린 앱과 리소스 고갈이라는 두 가지 일반적인 문제를 해결(심지어 방지)하는 데 도움이 되는 데이터를 제공할 수 있는 위치에 있습니다. Ingress 컨트롤러가 가시성을 개선하려면 다음이 필요합니다.

실시간으로 측정 항목을 제공하여 "지금" 무슨 일이 일어나고 있는지 진단할 수 있습니다.
Prometheus 및 Grafana와 같은 인기 있는 가시성 도구에 메트릭을 내보내어 시간에 따른 값을 표시하여 트래픽 급증 및 기타 추세를 예측할 수 있습니다.

API 게이트웨이

Kubernetes에서 요청-응답 조작을 수행하려는 것이 아니라면 Ingress 컨트롤러가 API 게이트웨이 역할을 할 가능성이 매우 높습니다.

Ingress 컨트롤러는 기능 세트에 따라 TLS 종료, 클라이언트 인증, 속도 제한, 세분화된 액세스 제어, 레이어 4~7에서 요청 라우팅을 포함한 핵심 API 게이트웨이 기능을 제공할 수 있습니다.

인증 및 Single Sign‑On

Kubernetes 서비스에서 Ingress 컨트롤러로 로그인 자격 증명 인증을 오프로드하면 두 가지 문제를 해결할 수 있습니다.

OpenID Connect(OIDC)를 사용하여 SSO(Single Sign On)를 구현하여 사용자가 단일 자격 증명 세트로 여러 앱에 로그인할 수 있도록 합니다.
각 애플리케이션에 인증 기능을 내장할 필요성을 없애면 개발자가 앱의 비즈니스 로직에 집중할 수 있습니다.

웹 애플리케이션 방화벽 통합

Ingress 컨트롤러가 웹 애플리케이션 방화벽(WAF) 역할을 할 수 있다는 것이 아니라 WAF를 Ingress 컨트롤러와 통합할 수 있다는 것입니다. WAF는 Kubernetes 외부와 내부의 여러 위치에 배포할 수 있지만 대부분의 조직에서 가장 효율적이고 효과적인 위치는 Ingress 컨트롤러와 동일한 포드입니다. 이 사용 사례는 보안 정책이 SecOps 또는 DevSecOps의 지시를 받고 세분화된 서비스별 또는 URI별 접근 방식이 필요할 때 완벽합니다. 즉, Kubernetes API를 사용하여 정책을 정의하고 서비스와 연결할 수 있습니다. 또한 Ingress 컨트롤러의 역할 기반 액세스 제어(RBAC) 기능을 사용하면 SecOps가 리스너별로 정책을 시행하는 동안 DevOps 사용자는 Ingress 리소스별로 정책을 설정할 수 있습니다.

Ingress Controller의 리소스를 어떻게 확보할 예정인가요?

모든 Ingress 컨트롤러에는 비용이 듭니다. 무료이고 오픈 소스인 컨트롤러도 마찬가지입니다(아마도 "강아지처럼 무료"라는 표현을 들어보셨을 겁니다). 일부 비용은 예산의 항목으로 예측 가능한 달러 금액을 할당할 수 있는 반면, 다른 비용은 선택한 Ingress 컨트롤러의 결과(복잡성 증가, 휴대성 부족 등)를 처리하는 데 팀에서 얼마나 많은 시간을 할애해야 하는지에 따라 달라집니다. Ingress 컨트롤러를 위한 예산을 세울 때 고려해야 할 비용(시간과 비용 측면)을 살펴보겠습니다. 시간과 비용입니다.

시간 비용에 대한 예산 책정

인원 수에 대한 예산 책정은 고정 비용 항목에 대한 예산 책정보다 훨씬 더 어려울 수 있습니다. 특히 익숙하지 않은 공간에서 프로젝트에 리소스를 제공하려고 할 때 더욱 그렇습니다. 다음과 같은 질문을 해야 합니다.

Ingress 컨트롤러를 구성하고 관리할 사람은 누구입니까? 정규직(예: Platform Ops 팀원)의 일부입니까? 아니면 추가 책임(개발자)으로 맡습니까?
직원들이 정식 교육을 받을 시간을 낼 수 있나요? 아니면 도구가 직장에서 빠르고 쉽게 배울 수 있을 만큼 간단해야 하나요?
새로운 기능이 필요할 때마다 직원들이 그것을 만지작거리거나, 문제가 있을 때 문제 해결에 많은 시간을 할애할 준비가 되어 있습니까? 아니면 다른 비즈니스 가치를 제공해야 합니까?

Kubernetes 도구 소유권에 대한 참고 사항

업계에서 NetOps 팀의 도메인에서 도구와 소유권을 통합하는 추세를 관찰했습니다. 이는 스택을 단순화하고 보안을 개선하는 데 큰 도움이 될 수 있지만, 팀 목표에 따라 도구를 신중하게 복제하는 것을 옹호합니다 .

NetOps 팀이 경계 도구(예: 외부 로드 밸런서)를 관리하는 것은 더 광범위한 플랫폼에 집중하기 때문에 합리적이지만
DevOps 팀은 앱 코드에 가깝게 배포된 서비스를 가장 중요하게 여기며 NetOps 도구에서 얻는 것보다 더 많은 민첩성과 세밀한 제어가 필요합니다.
Ingress 컨트롤러를 포함한 Kubernetes 도구는 DevOps에서 선택할 때 성공할 가능성이 가장 높습니다.
그렇다고 개발자에게 도구 선택의 완전한 자유를 주어야 한다는 것은 아닙니다!
Kubernetes 내에서 도구를 엄격하게 표준화하는 것이 여전히 모범 사례입니다.

자본 비용 예산

조직이 처음 Kubernetes를 실험할 때는 도구나 지원에 많은 예산을 책정하지 않는 경우가 많습니다. 더 많은 "컨트롤러"가 필요한 Ingress 컨트롤러를 진정으로 지원할 인적 자원이 있다면 처음에는 아무런 금전적 예산도 괜찮지 않습니다. 하지만 Kubernetes 투자가 늘어나면 도구의 기능에 제한을 받거나 팀을 다른 우선순위에 전담하고 싶을 수 있습니다. 그때가 엔터프라이즈 기능과 지원이 포함된 사용하기 쉽고 안정적인 도구에 비용을 지불하는 쪽으로 규모가 기울어지는 때입니다.

Ingress 컨트롤러에 대한 비용을 지불할 준비가 되면 라이선스 모델이 중요하다는 점을 알아두십시오. Kubernetes 외부의 기존 가격 책정 모델을 기준으로 Ingress 컨트롤러의 가격은 종종 "인스턴스당" 또는 "Ingress 프록시당"입니다. Kubernetes에서 여전히 이것이 의미가 있는 사용 사례가 있지만, "클러스터당" 기준으로 Ingress 컨트롤러를 라이선스하는 것은 "프록시 수"가 아닌 애플리케이션 테넌시에 따라 비용을 지불한다는 것을 의미합니다.

다양한 시나리오에 대한 권장 사항은 다음과 같습니다.

쿠버네티스를 처음 사용하시나요? 클러스터당 라이선스를 선택하세요.
쿠버네티스에 대한 경험이 없다면 필요한 Ingress 컨트롤러 인스턴스 수를 정확하게 예측하기가 매우 어렵습니다. 인스턴스 수를 선택해야 하는 경우 과소평가하여 목표를 달성하기 어려울 수 있고, 과대평가하여 쿠버네티스 프로젝트의 다른 부분에 더 잘 쓸 수 있는 돈을 낭비할 수 있습니다. "소규모 클러스터"에 대해 비교적 낮은 고정 가격을 협상하면 성공 가능성이 높아집니다.
쿠버네티스 확장? 클러스터별 라이선싱을 선택하세요.
쿠버네티스 리소스를 얼마나 자주 확장하고 축소해야 할지 예측하는 것은 거의 불가능합니다(버스팅 및 붕괴). 인스턴스별 가격 책정은 팀이 라이선싱 상한 내에 머물기 위해 임의의 임계값을 부과하도록 강요합니다. 클러스터별 라이선싱을 사용하면 개별 Ingress 컨테이너를 추적할 필요가 없으며 공급업체(예: NGINX)에 따라 추가 비용 없이 버스팅이 포함될 수 있습니다.
고급 또는 정적 배포? 인스턴스별 라이선싱을 선택하세요.
Kubernetes에 정통하여 Ingress 컨트롤러를 어떻게 사용할지 정확히 알고 있고 클러스터당 소수의 Ingress 프록시를 사용할 계획이며 도구와 함께 제공되는 번들 서비스가 필요하지 않은 경우 인스턴스별 가격이 좋은 선택이 될 수 있습니다.

다음 단계: 위험 허용도 및 미래 보호

이제 요구 사항을 파악했으므로 다음 단계는 Ingress 컨트롤러가 도입할 수 있는 위험에 대한 허용 범위를 팀으로 결정하고 Kubernetes 배포를 확장함에 따라 Ingress 컨트롤러가 어떻게 확장되어야 하는지 파악하는 것입니다. 2부 에서 이러한 주제를 다룹니다 .

위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요

전문가에게 상담하기

13

NGINX, Opsani 및 Prometheus를 사용하여 클라우드에서 Kubernetes 비용을 70% 절감

관리자

2024-07-31

완벽한 폭풍"이라는 표현은 흔한 표현일 수 있지만, 클라우드 컴퓨팅 비용이 폭주하는 경우 유용한 표현입니다.

여러 요소가 서로 결합되어 완벽하게 됩니다.

작업 부하를 배포하는 사람은 작업 부하에 대한 비용을 지불하는 사람이 아닙니다.
필요에 따라 그리고 프로그래밍 방식으로 인프라를 사용하기 쉽습니다.
쉽게 접근할 수 있는 코드 저장소를 통해 다른 사람이 작성한 기존 코드에서 기능을 "빌려올" 수 있습니다.
CI/CD 파이프라인과 SRE 관행은 개발자가 코드를 빠르게 통합하고 배포하는 데 도움이 됩니다.

모든 것을 종합해 보면, 개발자는 일반적으로 새로운 앱에서 제공하는 목적에 맞게 간소화되거나

최적화되지 않은 기존 코드 블록을 활용하여 새로운 기능을 빠르게 배포하도록 인센티브를 받습니다.

출시 시간이 가장 중요하기 때문에 최적화는 뒤로 밀려납니다.

최적화되지 않은 코드가 성능을 저하시키는 경우, 더 강력한 인프라를 프로비저닝하는 것은 API 호출만 있으면 됩니다.

문제를 더 복잡하게 만드는 것은 코드를 작성하는 사람과 비용을 지불하는 사람 사이의 사고방식과 조직 구조의 분열입니다.

엔터프라이즈 클라우드 비용이 증가함에 따라 CFO는 진땀을 흘립니다.

그러나 클라우드 비용을 증가시킨 개발자는 신속한 제품 제공에 대한 보상을 받는 반면, 자신들이 만들어내도록 인센티브를 받은 하류 재정 문제에 대해서는 전혀 모릅니다.

문제를 해결하기 위해 F5 NGINX와 Opsani는 협력하여 F5 NGINX Ingress Controller 구독자에게 기존 배포에서 추가 이점을 제공하는 최적화 솔루션을 제공했습니다.

NGINX Ingress Controller는 Opsani Servo 컨테이너가 KubeNest 워크로드에 배포될 때 최적화된 솔루션이 되며, Prometheus를 활용하여 비율, 오류 및 기간(RED) 메트릭을 수집합니다.

Opsani는 머신 러닝으로 구동되는 자율 최적화 기능을 사용하여 인프라를 지속적으로 최적화하여 더 높은 성능과 더 낮은 비용을 위해 적절한 양의 리소스가 소비되도록 합니다.

클라우드 최적화를 사용하여 비용 절감

NGINX 사용자는 이미 클라우드 비용을 줄이는 가장 기본적인 방법을 알고 있습니다.

즉, 최소한의 대기 시간을 추가하면서도 번개처럼 빠른 성능을 제공하는 가벼운 도구를 사용하는 것입니다.

물론 Kubernetes의 세계에서는 간단하면서도 강력한 도구가 성공적인 배포의 전제 조건입니다.

이 블로그에서는 세 가지 도구를 활용하여 비용을 절감하고 동시에 성능을 개선하는 방법을 설명합니다.

NGINX Ingress Controller – F5 NGINX Plus 기반의 Ingress 컨트롤러로, 이벤트 핸들러나 구성의 재로드 없이

백엔드 엔드포인트의 변경 사항에 동적으로 조정되므로 다른 NGINX 기반 Ingress 컨트롤러보다 성능이 훨씬 뛰어납니다.

Opsani – CI/CD 파이프라인에 CO를 추가할 수 있는 고유한 COaaS(Continuous Optimization as a Service) 솔루션으로,

코드를 신속하게 제공하고 최저 비용으로 최적의 성능을 위해 코드를 최적화할 수 있습니다.

Prometheus – 모니터링 및 알림을 위한 인기 있는 오픈 소스 프로젝트.

NGINX Plus Prometheus 모듈을 사용하면 NGINX Plus를 기반으로 하는

NGINX Ingress Controller가 수백 개의 메트릭을 Prometheus 서버로 내보냅니다.

NGINX Plus 기반 버전의 NGINX Ingress Controller에 대한 가장 강력한 사용 사례 중 하나는

라이브 모니터링(NGINX Plus 대시보드를 통해) 및 과거 데이터(Prometheus를 통해)를 통해 Kubernetes에서 가시성을 개선하는 기능입니다.

또한 워크로드의 프런트엔드 역할에서 NGINX Ingress Controller는 비율, 오류 및 기간(RED) 메트릭을 수집하여(Prometheus를 통해)

Opsani에 제공할 수 있습니다.

Opsani는 머신 러닝을 사용하여 메트릭을 현재 배포된 인프라와 상관시키고

NGINX Ingress Controller, 앱 또는 기술 스택 전체를 최적화하는 변경 사항을 권장합니다.

NGINX Ingress Controller에 대해 설정된 대기 시간 및 성능 임계값에 대해 경고하도록 Opsani를 구성할 수도 있습니다.

숫자 살펴보기 – 최적화 테스트 결과

Opsani와 Prometheus를 사용하여 NGINX Plus 기반 NGINX Ingress Controller를 배포하여

기대할 수 있는 결과의 예를 살펴보겠습니다.

스크린샷에 표시된 대로 Opsani 요약 페이지는 시간 경과에 따른 트래픽 볼륨(초당 요청 수 또는 RPS)을 보고하고

기준 설정과 비교하여 최적화의 이점을 강조합니다.

여기서는 시간당 인스턴스 비용이 70% 절감되고 P50 응답 시간이 5% 향상되었습니다.

우리는 이러한 결과가 가장 잘 알려진 Ingress 컨트롤러 중 하나,

즉 Kubernetes 커뮤니티가 GitHub kubernetes/ingress-nginx repo에서

유지 관리하는 NGINX 오픈 소스 기반 Ingress 컨트롤러와 비교했을 때 어떨지 궁금했습니다.

(기존 NGINX 규칙 에 따라 이 블로그의 나머지 부분에서는 "커뮤니티 Ingress 컨트롤러"라고 부르겠습니다.

NGINX Plus 기반 버전의 NGINX Ingress Controller는 NGINX 엔지니어링 팀이

GitHub nginxinc/kubernetes-ingress repo에서 유지 관리하며,

NGINX 오픈 소스를 기반으로 하는 자매 NGINX Ingress Controller도 유지 관리합니다.)

우리는 세 가지 토폴로지에서 두 개의 Ingress 컨트롤러의 성능을 테스트했습니다.

토폴로지 1 – 표준 프로세스를 사용하여 배포된 커뮤니티 Ingress 컨트롤러 .

메트릭은 애플리케이션 포드의 사이드카 컨테이너에서 테스트 중

애플리케이션과 함께 Envoy 프록시를 인라인으로 추가하여 수집되었습니다.

토폴로지 2 – Helm을 사용하여 배포된 NGINX Plus 기반 NGINX Ingress Controller .

메트릭 수집이 최적화 성능 프로세스에 영향을 미치지 않도록 하기 위해 커뮤니티

Ingress Controller와 동일한 Envoy 배포 및 구성으로 메트릭을 수집했습니다.

토폴로지 3 – NGINX Plus 기반 NGINX Ingress Controller, Helm을 사용하여 배포.

메트릭은 Prometheus를 사용하여 수집되었습니다.

표는 테스트 결과를 요약한 것입니다. 보시다시피,

NGINX Ingress Controller는 커뮤니티 Ingress Controller보다

더 나은 비용 절감, CPU 최적화 및 메모리 최적화를 달성합니다.

이는 NGINX Ingress Controller의 더 효율적인 로드 밸런싱 덕분입니다.

P50 응답 시간에 대한 결과는 Prometheus가 Envoy 사이드카 메커니즘에 필요한 추가

홉을 제거하기 때문에 메트릭을 수집하는 이상적인 방법임을 나타냅니다.

Envoy는 Community Ingress 컨트롤러의 P50 응답 시간에 영향을 미치지 않지만

실제로 NGINX Ingress 컨트롤러로 대기 시간을 4% 악화시킵니다.

반면 Prometheus는 NGINX Ingress 컨트롤러로 P50 응답 시간을 5% 개선합니다.

토폴로지비용 절감 (%)P50 응답 시간(%)CPU 최적화(%)메모리 최적화(%)

1 – Envoy가 있는 커뮤니티 인그레스 컨트롤러	44	0	44	44
2 – Envoy를 갖춘 NGINX Ingress 컨트롤러	70	4	63	81
3 – Prometheus를 사용한 Ingress 컨트롤러	70	-5	63	81

테스트를 어떻게 진행했는지에 대한 자세한 내용은 부록을 참조하세요 .

Opsani가 NGINX Ingress Controller를 최적화하는 방법

Opsani는 동적 환경에서 로드 밸런싱이 제대로 이루어지지 않은 애플리케이션도 최적화할 수 있습니다.

또한 모든 유형의 메트릭 입력을 활용할 수 있지만,

네트워크 메트릭을 수집하는 기존 도구에서 입력이 제공되면

연결된 서비스의 최적화가 극적으로 향상됩니다.

이를 위해 간단한 배포 프로세스를 사용하여 Opsani를 NGINX Ingress Controller와 통합합니다.

NGINX가 Ingress 컨트롤러인 환경에서(오늘날 많은 애플리케이션에 적용됨)

NGINX Plus 기반 NGINX Ingress Controller를 사용하는 간단한 전환은 애플리케이션 기능에 영향을 미치지 않으면서

더 효율적인 로드 밸런싱 알고리즘을 제공합니다.

두 번째 이점은 NGINX Ingress Controller로 로드 밸런싱된 애플리케이션의 메트릭도 사용할 수 있다는 것입니다.

유일한 추가 요구 사항은 최적화 네임스페이스 아래에 애플리케이션이 있는 단일 Opsani 포드를 배포하는 것입니다.

NGINX Plus 기반 NGINX Ingress Controller용 Opsani 템플릿은 최적화에 필요한

애플리케이션별 메트릭을 캡처하기 위해 Ingress 서비스에서 메트릭 엔드포인트를 가리킵니다.

3~4개의 피크 기간의 메트릭을 처리함으로써 Opsani 엔진은 단 몇 시간 내에 최적의 최적화 수준에 도달합니다.

지금까지 30%에서 70%로 피크 로드 최적화를 달성했습니다.

Opsani 및 NGINX Ingress Controller 시작하기

NGINX Ingress Controller 와 Opsani 의 무료 평가판을 받아보신 후 ,

Prometheus와 함께 NGINX Ingress Controller와 Opsani에 대한

스크립트와 구성 파일이 있는 GitHub 저장소 로 이동하세요 .

부록: 테스트 방법론

필수 조건

NGINX Plus 기반 NGINX Ingress Controller는 컨테이너로 구축 되었습니다 .
쿠버네티스가 구성되었으며 레지스트리 액세스 비밀을 사용하여 안전한 개인 Docker 레지스트리 에 액세스할 수 있습니다 .
NGINX Plus 기반 NGINX Ingress Controller는 Helm을 통해 ingress 네임스페이스에 배포됩니다.
NGINX VirtualServer 리소스는 최적화할 서비스(일반적으로 기본적으로 프런트엔드 서비스)를 가리키도록 구성됩니다.
예를 보려면 GitHut repo의 frontend-virtualserver.yaml을 참조하세요.

토폴로지 및 구성

우리는 세 개의 Opsani 인스턴스를 만듭니다. 토폴로지 1과 2 의 경우,

우리는 모든 Opsani 계정에서 사용 가능한 표준 Opsani Dev 템플릿을 사용하고

NGINX Ingress Controller로 애플리케이션을 프런트엔드하고 애플리케이션 서비스를 가리킵니다.

Topology 3 의 경우 , 우리는 동일한 기본 템플릿을 사용하고

GitHub repo의 opsani-manifests-nginx-plus.yaml 에 정의된 ConfigMap으로 Servo 구성을 수정합니다 .

표준 템플릿과 마찬가지로, 우리는 ConfigMap의 다음 변수에 적절한 값을 대체합니다.

{{ NAMESPACE }} – 대상 리소스 네임스페이스
{{ DEPLOYMENT }} – 타겟 배포
{{ CONTAINER }} – 대상 애플리케이션 컨테이너 이름

또한, 애플리케이션 배포 시 노출되는 문서에 따라

OPSANI_ACCOUNT_NAME, OPSANI_APPLICATION_NAME, 를 설정합니다.

OPSANI_TOKEN

Opsani Dev용 기본 ServoX 에는 Prometheus 인스턴스가 포함되어 있지만,

대신 ClusterRole 구성의 필요성을 줄이기 위해 NGINX Ingress Controller와

동일한 네임스페이스에 Prometheus 인스턴스를 배포합니다.

또한 Servo 포드가 올바른 인스턴스를 찾아 쿼리할 수 있도록 서비스를 구성합니다.

이 아티팩트는 opsani-manifests-nginx-plus.yaml 에 포함되어 있습니다 .

Bank of Anthos 가 샘플 웹 애플리케이션으로 실행되고 Ingress가 검증되면

Ingress Prometheus 인스턴스를 시작합니다.

마지막으로 opsani -manifests-nginx-plus.yaml 파일을 적용하여 Opsani 최적화를 시작할 수 있습니다.

위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요

전문가에게 상담받기

라이브 채팅:Codey와 채팅하기

12

Okta 및 NGINX Ingress Controller를 사용하여 Kubernetes에 대한 OpenID Connect 인증 구현

관리자

2024-07-29

우리는 오늘날 랜섬웨어와 봇 기반 공격의 환경에서 앱과 API를 보호하는 것이 얼마나 중요한지에 대해 여러 번 글을 썼습니다 .

웹 애플리케이션 방화벽 (WAF)과 같은 메커니즘과 함께 사용자 ID를 인증하고 권한 부여에 대한 제어를 시행하는 것은

비즈니스 애플리케이션을 보호하는 중요한 방법입니다.

인증 및 권한 부여를 구현하는 가장 직접적인 방법은 애플리케이션 자체에 있습니다.

사용자 기반이 작고 앱에 자주 업데이트가 필요하지 않은 경우 이 방법이 효과적일 수 있지만,

규모가 커지면 빠른 유지가 불가능해집니다.

한 가지 예로, 사용자가 여러 앱 각각에 대해 다른 계정 이름과 비밀번호를 기억해야 하는 경우

로그인을 시도할 때 종종 실망스러운 "잘못된 사용자 이름 또는 비밀번호" 메시지가 표시되어

쉽게 추측할 수 있는 "abc123" 비밀번호와 같은 안전하지 않은 솔루션을 사용하게 됩니다.

그리고 우리는 모두 비밀번호 알림을 담은 Post‑it® 노트로 장식된 모니터를 본 적이 있을 것입니다!

Single sign‑on(SSO) 기술은 모든 개별 사용자 이름과 비밀번호를 제거하고 하나의 자격 증명 세트를 사용하여

이러한 문제를 부분적으로 해결할 수 있습니다. 사용자는 ID 공급자(IdP)를 통해 한 번만 로그인하여 많은 앱에 액세스할 수 있습니다.

하지만 개발자는 여전히 앱에 코드를 포함하여 SSO 시스템과 인터페이스해야 하며,

이는 특히 애플리케이션이 복잡해짐에 따라 매우 어려울 수 있습니다.

조직이 확장되고 급증하는 사용자 기반의 요구 사항을 충족해야 함에 따라

인증 및 권한 부여와 같이 앱의 기능에 특화되지 않은 요구 사항을 애플리케이션 계층에서 오프로드하는 것이 중요해집니다.

Kubernetes 에서 중앙화된 인증 및 권한 부여를 위한 이상적인 위치는 Ingress 컨트롤러로 ,

클러스터에 들어오는 모든 트래픽을 면밀히 조사하여 적절한 서비스로 라우팅할 수 있습니다.

이를 통해 개발자는 인증 논리를 빌드, 유지 관리 및 복제하는 부담에서 벗어나

네이티브 Kubernetes API를 사용하여 Ingress 계층에서 SSO 기술을 쉽게 활용할 수 있습니다.

이 블로그에서는 NGINX Plus 기반 NGINX Ingress Controller를 릴레이 당사자로 작동시키고,

Okta를 사전 구성된 ID 공급자(IdP)로 사용하여 OIDC 인증 코드 흐름을 지원하는

본격적인 SSO 솔루션을 구현하는 방법을 보여줍니다 .

참고: 이 기능은 NGINX 오픈 소스 기반 NGINX Ingress Controller와 함께 사용할 수 없습니다.

필수 조건

이 블로그에서는 Kubernetes 환경에서 운영 경험이 있다고 가정합니다. 또한 다음이 필요합니다.

Kubernetes 환경 – NGINX Ingress Controller는 vanilla Kubernetes뿐만 아니라

Amazon Elastic Kubernetes(EKS), bare metal, Google Kubernetes Engine(GKE), Microsoft Azure Kubernetes Service(AKS),

Rancher Kubernetes Engine, Red Hat OpenShift를 비롯한 수많은 Kubernetes 플랫폼에서 지원됩니다.

NGINX Plus 기반 NGINX Ingress Controller – NGINX Plus 기반 버전의 NGINX Ingress Controller 에 대한 유효한 라이선스가 있어야 합니다 .

무료 30일 평가판을 요청하여 오늘 라이선스로 시작할 수 있습니다 . 자세한 내용은 설명서를 참조하세요 .

Okta 개발자 계정 – Okta를 IdP로 구성하려면 개발자 계정에 가입하는 것으로 시작합니다.

대안으로 Okta 명령줄 인터페이스 (CLI)를 다운로드하고 okta register명령을 실행하여 새 계정에 가입합니다.

이 글을 쓰는 시점에서 Okta CLI는 베타 상태이며 프로덕션 용도로는 권장되지 않습니다.

IdP 사전 구성

클라우드 서비스는 사용자 신원을 검색하고 검증할 곳을 알아야 하며, 여기서 IdP가 필요합니다.

IdP는 디지털 신원을 안전하게 관리하고 저장하며 공격자가 사용자를 사칭하기 위해 신원을 훔칠 수 없도록 보장합니다.

이 섹션에서는 Okta CLI를 사용하여 Okta를 IdP로 미리 구성하여 Okta가 앱 통합 이라고 부르는 것을 만듭니다 .

1. okta loginOkta 개발자 계정으로 Okta CLI를 인증하는 명령을 실행합니다 . 프롬프트에 Okta 도메인과 API 토큰을 입력합니다.

$ okta login Okta Org URL: https://your-okta-domain
Okta API token: your-api-token

2. 앱 통합을 만듭니다. :

$ okta apps create --app-name=mywebapp --redirect-uri=http[s]://ingress-controller-hostname/_codexch

where

--app-name애플리케이션 이름을 정의합니다(여기서는 mywebapp )
--redirect-uri로그인이 리디렉션되는 URI를 정의합니다(여기서는 ingress-controller-hostname /_codexch )

3. 프롬프트에 따라 애플리케이션 유형을 지정합니다. 먼저 1 (웹 애플리케이션을 나타냄)을 지정하고 그 다음

5 (나열된 것 이외의 프레임워크를 나타냄)를 지정합니다.

Type of Application 
(The Okta CLI only supports a subset of application types and properties):
> 1: Web 
> 2: Single Page App 
> 3: Native App (mobile) 
> 4: Service (Machine-to-Machine) 
Enter your choice [Web]: 1
Type of Application 
> 1: Okta Spring Boot Starter 
> 2: Spring Boot 
> 3: JHipster 
> 4: Quarkus 
> 5: Other Enter your choice [Other]: 5
Configuring a new OIDC Application, almost done: 
Created OIDC application, client-id: 0oa1mi...OrfQAg5d7

NGINX Ingress 컨트롤러 구성

NGINX Ingress Controller의 NGINX Plus 기반 버전을 사용자를 인증하는 릴레이 당사자로 구성합니다 .

클라이언트 자격 증명 비밀 정의

보안상의 이유로 OIDC 정책 개체에 클라이언트 비밀을 하드코딩하는 것은 지원되지 않습니다.

대신 클라이언트 비밀의 base64 인코딩된 값을 포함하는 데이터로 Kubernetes 비밀을 만듭니다.

그런 다음 비밀을 포함하는 YAML 파일을 적용합니다(여기서는 client-secret.yaml ).

$ kubectl apply –f client-secret.yaml

인증 엔드포인트 가져오기

OAuth 2.0 및 OpenID Connect API를 사용하여 Okta가 인증 서버에 노출하는 엔드포인트에 대한 정보를 가져옵니다.

로컬 머신에서 다음 명령을 실행하여 Okta 엔드포인트에 대한 정보를 출력합니다.

샘플 출력에 표시된 대로 authorization_endpoint, token_endpoint, 의 값을 기록해 두십시오.

다음 섹션 에서 이를 사용합니다 .jwks_uri

$ curl -i https://your-okta-domain/.well-known/openid-configuration
{   
 "authorization_endpoint": "https://your-okta-domain/oauth2/v1/authorize",    
...    
"jwks_uri": "https://your-okta-domain/oauth2/v1/keys",    
...    
"token_endpoint": "https://your-okta-domain/oauth2/v1/token", 
... 
}

NGINX Ingress OIDC 정책 정의

OIDC 기반 인증에 대한 지원이 NGINX Ingress Controller 1.10.0에 추가되었습니다.

자세한 내용은 블로그에서 OpenID Connect와 NGINX Ingress Controller를 사용한 간편하고 견고한 Single Sign‑On을 읽어보세요.

NGINX Ingress Controller의 OIDC 인증 구현은 NGINX Ingress Controller에서

OIDC 정책을 정의하는 PolicyKubernetes 사용자 정의 리소스 인 객체를 사용합니다.

1. 이전 섹션에서 얻은 정보를 Policy 객체의 authEndpoint, tokenEndpoint, jwksURI 필드 에 삽입합니다

apiVersion: k8s.nginx.org/v1 kind: Policy metadata:
name: oidc-policy 
spec:  
  oidc:    
 clientID: client-id    
 clientSecret: oidc-secret    
 authEndpoint: https://your-okta-domain/oauth2/v1/authorize    
 tokenEndpoint: https://your-okta-domain/oauth2/v1/token    
 jwksURI: https://your-okta-domain/oauth2/v1/keys

2. 정책을 적용합니다(여기서는 oidc.yaml 에 정의되어 있음 ):

$ kubectl apply -f oidc.yaml

3. (선택 사항) 정책의 유효성을 확인하세요.

$ kubectl get policy 
NAME        STATE  AGE 
oidc-policy Valid  2m

VirtualServer 객체 정의

VirtualServer와 VirtualServerRoute는 Kubernetes 클러스터의 백엔드 애플리케이션으로 들어오는

트래픽을 라우팅하기 위한 규칙을 프로비저닝하는 NGINX Ingress 리소스 입니다.

OIDC 정책이 적용되려면 VirtualServer 또는 VirtualServerRoute 리소스에서 참조되어야 합니다.

1. / 경로 접두사 아래에 OIDC 정책을 참조하면 접두사와 일치하는 경로를 요청하는 사용자가 요청이 서비스로 프록시되기 전에 인증됩니다 app-server-payload.

apiVersion: k8s.nginx.org/v1 
  kind: VirtualServer 
  metadata:  
   name: app-ingress 
  spec:  
   host: unit-demo.linkpc.net  
   upstreams:  
   - name: app-server-payload    
   service: app-server-svc    
   port: 80 
   routes:  
   - path: /    
     policies:    
     - name: oidc-policy    
     action:      
       proxy:         
      upstream: app-server-payload

2. VirtualServer 리소스를 적용합니다(여기서는 app-virtual-server.yaml 에 정의됨 ):

$ kubectl apply -f app-virtual-server.yaml

3. (선택 사항) 리소스의 유효성을 확인합니다.

$ kubectl get vs
 NAME         STATE           HOST          IP   PORTS  AGE 
 app-ingress  Valid   unit-demo.linkpc.net               2m

환경 테스트

OIDC Okta 통합이 제대로 작동하는지 테스트하려면 브라우저의 주소창에 NGINX Ingress Controller의 호스트 이름을 입력합니다.

Okta 로그인 포털로 리디렉션되며, 여기서 Okta 개발자 계정의 자격 증명을 입력하여 백엔드 애플리케이션에 액세스할 수 있습니다.

성공적으로 인증되면 업스트림 서비스에 액세스할 수 있습니다 app-server-payload.

애플리케이션에 사용자 추가

대부분의 경우, 조직의 여러 사용자가 앱에 액세스해야 합니다.

Okta 관리 콘솔의 디렉토리 카테고리 아래 People 페이지에서 각 사용자를 추가합니다.

여러 앱에 대한 SSO 통합 생성

우리는 Okta를 IdP로, NGINX Ingress Controller를 릴레이 당사자로 하여 SSO를 구성함으로써 하나의 애플리케이션에서 인증 프로세스를 오프로드했습니다.

실제로는 사용자가 단일 자격 증명 세트를 사용하여 여러 애플리케이션에 액세스할 수 있도록 하려고 할 것입니다.

또한 사용자가 액세스할 수 있는 애플리케이션을 다양하게 변경할 수 있는 유연성이 필요할 수도 있습니다. 위 섹션의 지침을 반복하여 이를 수행할 수 있습니다.

다른 애플리케이션을 Okta와 통합하기 위한 IdP 사전 구성
다른 OIDC 정책을 정의하기 위한 NGINX Ingress OIDC 정책 정의
추가 정책을 참조하기 위한 VirtualServer 개체 정의

다음 다이어그램에 나와 있는 예에서는 unit-demo.marketing.net 과 unit-demo.engineering.net 이라는 두 개의 하위 도메인이 있으며 ,

이는 NGINX Ingress Controller의 외부 IP 주소로 확인됩니다.

NGINX Ingress Controller는 하위 도메인을 기반으로 마케팅 앱이나 엔지니어링 앱으로 요청을 라우팅합니다.

사용자에게 액세스 권한을 부여하려면 Okta GUI의 Assignments 탭에서 사용자를 각 적절한 애플리케이션과 연결합니다.

그런 다음 Okta는 인증된 사용자에게 해당 애플리케이션에 액세스할 수 있는 단기 세션 쿠키를 부여합니다.

Topology diagram of multiple app integrations for single sign-on with NGINX Ingress Controller and Okta as the IdP

결론

NGINX Ingress Controller를 릴레이 당사자로, Okta를 IdP로 사용하여 Kubernetes에서 OIDC 기반 SSO를 구현하면 개발자의 인증 및 권한 부여를 오프로드하여

앱에서 비즈니스 로직을 최적화하는 데 집중할 수 있습니다.

위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요

전문가에게 상담하기

11

동일한 아키텍처에서 BIG-IP 및 NGINX Ingress Controller 배포

관리자

2024-07-23

이전 블로그 시리즈인 Kubernetes 내 애플리케이션 서비스 배포에서 우리는 많은 고객이 디지털 전환(DT) 여정을 거치는 동안

발견한 패턴을 논의했습니다. 대부분의 여정은 앱(일반적으로 모놀리스)을 만들고 배포하는 기존 모델에서 시작하여

두 기능에 대한 책임을 사일로화된 개발 및 운영 팀 간에 분할합니다.

조직이 보다 현대적인 모델로 이동함에 따라 마이크로서비스 기반 앱을 만들고 DevOps 관행을 사용하여 배포하는데,

이는 기존 사일로 조직 간의 구분을 모호하게 합니다.

DevOps 팀과 애플리케이션 소유자가 애플리케이션이 배포, 관리 및 제공되는 방식을 보다 직접적으로 제어하고 있지만,

사일로 벽을 한꺼번에 무너뜨리는 것은 실용적이지 않은 경우가 많습니다.

또한 그럴 필요성도 없습니다. 대신 논리적인 책임 분할이 여전히 적용된다는 것을 관찰했습니다.

네트워크 및 보안 팀은 기업 인프라의 전반적인 보안, 성능 및 가용성에 지속적으로 집중합니다.

그들은 일반적으로 해당 인프라의 "프런트 도어"에 배치되는 글로벌 서비스를 가장 중요하게 여깁니다.

이러한 팀은 글로벌 서버 로드 밸런싱(GSLB), DNS 해결 및 로드 밸런싱, 정교한 트래픽 셰이핑과 같은 사용 사례에 F5 BIG-IP를 사용합니다.

BIG‑IQ 및 NGINX Controller[현재 F5 NGINX Management Suite]는 NetOps 팀에 가장 적합한 형태로 메트릭과 알림을 제공하고,

SecOps 팀의 경우 SecOps가 조직의 자산을 보호하고 업계 규정을 준수하는 데 필요한 보안에 대한 가시성과 제어를 제공합니다.

운영팀(Ops에 중점을 둔 DevOps)은 관련 사업 라인에서 요구하는 대로 개별 애플리케이션을 만들고 관리합니다.

이들은 자동화 및 CI/CD 파이프라인과 같은 서비스를 가장 중요하게 생각하며,

이를 통해 업데이트된 기능에 대해 더 빠르게 반복할 수 있습니다.

이러한 서비스는 일반적으로 앱에 "더 가깝게" 배포됩니다(예: Kubernetes 환경 내부).

이러한 팀은 Kubernetes 클러스터를 포함한 여러 환경에서 호스팅되는

분산 마이크로서비스 기반 애플리케이션의 부하 분산 및 트래픽 셰이핑을 위해

NGINX Plus, NGINX App Protect, NGINX Ingress Controller, NGINX Service Mesh와 같은 NGINX 제품을 사용합니다.

사용 사례로는 TLS 종료, 호스트 기반 라우팅, URI 재작성, JWT 인증, 세션 지속성, 속도 제한, 상태 검사,

보안(통합 WAF로 NGINX App Protect 사용) 등이 있습니다.

Kubernetes 환경에서의 NetOps 및 DevOps

NetOps와 DevOps 팀의 서로 다른 우려 사항은 Kubernetes 환경에서 수행하는 역할과 이를 충족하는 데 사용하는 도구에 반영됩니다.

지나치게 단순화할 위험을 무릅쓰고 말하자면 NetOps 팀은 주로 Kubernetes 클러스터 외부의 인프라 및 네트워킹 기능에 관심이 있고

DevOps 팀은 클러스터 내부의 해당 기능에 관심이 있다고 말할 수 있습니다.

트래픽을 Kubernetes 클러스터로 유도하기 위해

NetOps 팀은 BIG‑IP를 이미 익숙한 오버레이 네트워킹 기술의 기능과 범위를 지원하는 외부 로드 밸런서로 사용할 수 있습니다.

그러나 BIG‑IP만으로는 Kubernetes 클러스터 내부의 파드 세트에 대한 변경 사항(예: 파드 수 또는 IP 주소 변경)을 추적할 방법이 없습니다.

이러한 제약 조건을 해결하기 위해 F5 Container Ingress Services(CIS)가 클러스터 내부에 운영자로 배포됩니다.

CIS는 포드 세트에 대한 변경 사항을 감시하고 BIG‑IP 시스템의 로드 밸런싱 풀에 있는 주소를 자동으로 수정합니다.

또한 새로운 Ingress, Route 및 사용자 지정 리소스가 생성되었는지 확인하고 BIG‑IP 구성을 적절히 업데이트합니다.

BIG‑IP와 CIS를 조합하여 트래픽을 애플리케이션 파드로 직접적으로 로드밸런싱 할 수 있지만 실제로 NGINX Ingress Controller는 많은 수의 서비스를 나타내는 파드 및 워크로드에 대한 동적 애플리케이션 변경 사항을 발견하고 이를 따라잡는 데 이상적인 솔루션입니다.

예를 들어, 수요 수준 변화에 맞춰 애플리케이션 파드를 수평 확장하는 경우에 유용합니다.

NGINX Ingress Controller를 배포하는 또 다른 장점은 애플리케이션 로드 밸런싱 제어를애플리케이션 자체를 담당하는 DevOps 팀으로 전환한다는 것입니다.

고성능 제어 평면과 DevOps 중심 설계로 인해 여러 네임스페이스의 Kubernetes 서비스에서 인플레이스 재구성 및 롤링 업데이트와 같은 빠르게 변화하는 DevOps 사용 사례를 지원하는 데 특히 강력합니다.

NGINX Ingress Controller는 네이티브 Kubernetes API를 사용하여 확장되는 포드를 검색합니다.

BIG-IP와 NGINX Ingress Controller가 함께 작동하는 방식

아시다시피 BIG‑IP와 NGINX Ingress Controller는 원래 두 개의 별도 회사(각각 F5와 NGINX)에서 설계되었습니다.

F5가 NGINX를 인수한 이후, 고객들은 두 도구 간의 상호 운용성을 개선하면 인프라 관리가 간소화될 것이라고 말했습니다.

이에 대응하여 IngressLink라고 하는 새로운 Kubernetes 리소스를 개발했습니다.

IngressLink 리소스는 Kubernetes CustomResourceDefinition(CRD)을 사용하여 NGINX Ingress Controller와 BIG-IP를 "연결"하는 간단한 향상 기능입니다.

간단히 말해서, CIS가 NGINX Ingress Controller 파드 세트가 변경될 때마다 BIG-IP에 "알릴" 수 있도록 합니다.

이 정보를 통해 BIG-IP는 해당 로드 밸런싱 정책을 민첩하게 전환하여 일치시킬 수 있습니다.

Kubernetes 클러스터에 대한 부하 분산을 위해 BIG‑IP가 배포되고 NGINX Ingress Controller가 유입-유출 트래픽을 처리하면 트래픽 흐름은 다음과 같습니다.

BIG‑IP는 외부 트래픽을 NGINX Ingress Controller 인스턴스로 전송합니다.
NGINX Ingress Controller는 클러스터 내의 적절한 서비스에 트래픽을 분산합니다.
NGINX Ingress Controller는 매우 효율적이기 때문에 안정적인 인스턴스 세트는 애플리케이션 파드 세트에 대한 빈번하고 큰 변경 사항을 처리할 수 있습니다.

하지만 NGINX Ingress Controller가 수평적으로 확장 또는 축소해야 하는 경우(트래픽 급증 및 감소를 처리하기 위해),

CIS는 BIG‑IP에 변경 사항을 알리고(IngressLink 리소스를 통해), BIG‑IP가 변경 사항에 빠르게 적응할 수 있도록 합니다.

시작하기

위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요

전문가에게 상담하기

10

API Gateway vs. Ingress Controller vs. Service Mesh 의 선택 가이드

관리자

2024-07-17

2021년 동안 제공한 Ingress 컨트롤러 및 서비스 메시에 대한 거의 모든 웨비나에서 "이 도구는 API 게이트웨이와 어떻게 다릅니까?"

또는 "Kubernetes에서 API 게이트웨이와 Ingress 컨트롤러(또는 서비스 메시)가 모두 필요한가요?"와 같은 다양한 질문을 들었습니다.

위의 두 질문과 같이 혼란을 줄 수 있는 부분에 대한 답변은 아래와 같습니다.

Ingress 컨트롤러와 서비스 메시는 다양한 API 게이트웨이 사용 사례를 충족할 수 있습니다.
일부 공급업체는 API 게이트웨이 도구를 Ingress 컨트롤러나 서비스 메시를 사용하는 것에 대한 대안으로 포지셔닝하거나
세 가지 기능을 모두 하나의 도구로 통합합니다.

이 블로그에서는 이러한 도구가 어떻게 다른지, 그리고 Kubernetes 특정 API 게이트웨이 사용 사례에 어떤 도구를 사용해야 하는지 다룹니다.

데모를 포함하여 더 자세히 알아보려면 웨비나 Kubernetes를 위한 API 게이트웨이 사용 사례를 시청하세요.

정의

API 게이트웨이, Ingress 컨트롤러, 서비스 메시는 본질적으로 각각 프록시 유형으로서,

사용자 환경 내부와 주변 환경으로 트래픽을 유도하도록 설계되었습니다.

API 게이트웨이란?

API 게이트웨이는 클라이언트의 API 요청을 적절한 서비스로 라우팅합니다.

하지만 이 간단한 정의에 대한 큰 오해는 API 게이트웨이가 고유한 기술이라는 생각입니다.

하지만, 그렇지 않으며, 오히려 "API 게이트웨이"는 다양한 유형의 프록시 (가장 일반적으로 ADC 또는 로드 밸런서 및 역방향 프록시,

그리고 점점 더 Ingress 컨트롤러 또는 서비스 메시)를 통해 구현할 수 있는 일련의 사용 사례를 설명합니다.

업계에서는 API 게이트웨이 역할을 하는 도구에 "필수" 기능이 무엇인지에 대한 합의가 많지 않습니다.

일반적으로 다음과 같은 기능을 통해 알려줍니다.(사용 사례별로 그룹화):

회복성 사용 사례

A/B 테스트, 카나리아 배포 및 블루-그린 배포
프로토콜 변환(예: JSON과 XML 간)
속도 제한
서비스 발견

교통 관리 사용 사례

방법 기반 라우팅 및 매칭
요청/응답 헤더 및 본문 조작
7계층에서의 요청 라우팅

보안 사용 사례

API 스키마 적용
클라이언트 인증 및 권한 부여
사용자 정의 응답
세분화된 액세스 제어
TLS 종료

이러한 사용 사례의 거의 대부분이 Kubernetes에서 일반적으로 사용됩니다. 프로토콜 변환과 요청/응답 헤더 및 본문 조작은 일반적으로 Kubernetes 및 마이크로서비스 환경에 적합하지 않은 레거시 API에 연결되어 있기 때문에 덜 일반적입니다.

블로그의 'API 게이트웨이로 NGINX 배포, 1부'에서 API 게이트웨이 사용 사례에 대해 자세히 알아보세요.

인그레스 컨트롤러란?

Ingress 컨트롤러(Kubernetes Ingress Controller, 줄여서 KIC라고도 함)는 트래픽을 Kubernetes로, 서비스로, 다시 내보내는(ingress‑egress 또는 north‑south 트래픽이라고 함) 특수화된 Layer 4 및 Layer 7 프록시입니다. 트래픽 관리 외에도 Ingress 컨트롤러는 가시성 및 문제 해결, 보안 및 ID, 그리고 가장 진보된 API 게이트웨이 사용 사례를 제외한 모든 용도로 사용할 수 있습니다.

블로그의 'Ingress 컨트롤러 선택 가이드, 1부: 요구 사항 식별'에서

기본적인 트래픽 관리 이상의 용도로 Ingress 컨트롤러를 사용하는 방법에 대해 자세히 알아보세요.

서비스 메시란?

서비스 메시는 Kubernetes 서비스 간에 흐르는 트래픽(서비스 간 또는 동서 트래픽이라고 함)을 처리하며 일반적으로 종단 간 암호화(E2EE)를 달성하는 데 사용됩니다. 서비스 메시 채택은 작지만 더 많은 조직이 고급 배포를 시작하거나 E2EE에 대한 요구 사항이 있기 때문에 증가하고 있습니다. 서비스 메시는 앱에 매우 가까운 분산(경량) API 게이트웨이로 사용할 수 있으며, 서비스 메시 사이드카를 통해 데이터 플레인 수준에서 가능합니다.

블로그의 서비스 메시 선택 방법에서 서비스 메시에 대해 자세히 알아보고 언제 서비스 메시를 사용할 준비가 되는지 알아보세요.

Kubernetes 환경을 위한 Kubernetes 네이티브 도구 사용

NGINX Sprint 2.0에서 Kubernetes와 애플리케이션 네트워킹의 미래에 대한 Mark Church의 기조연설에서 들었듯이

"API 게이트웨이, 로드 밸런서, 서비스 메시는 서로 점점 더 비슷해 보이고 유사한 기능을 제공할 것입니다."

우리는 이 진술에 전적으로 동의하며, 어디에서(그리고 어떻게) 사용할지에 따라 작업에 적합한 도구를 선택하는 것이 전부라고 덧붙입니다.

결국, 마체테(넓은 칼)와 버터 나이프는 모두 자르는 데 사용되지만, 아마도 아침에 토스트를 먹을 때, 마체테를 사용하지는 않을 것입니다.

즉, 특정 문제를 해결하기 위해서는 그 문제에 맞는 적절한 도구나 접근 방식을 선택해야 합니다.

그렇다면 어떤 도구가 자신에게 적합한지 어떻게 결정할까요? 간단하게 설명드리겠습니다.

Kubernetes 내에서 API 게이트웨이 기능이 필요한 경우

일반적으로 YAML과 같은 기본 Kubernetes 구성 도구를 사용하여 구성할 수 있는 도구를 선택하는 것이 가장 좋습니다.

일반적으로 Ingress 컨트롤러 또는 서비스 메시입니다.

하지만 "내 API 게이트웨이 도구는 Ingress 컨트롤러(또는 서비스 메시)보다 훨씬 더 많은 기능이 있지만 놓치고 있지 않나요?"

라는 이야기를 들을 수 있습니다.

그러나, 더 많은 기능이 더 나은 도구와 같지는 않습니다.

특히 도구 복잡성이 치명적일 수 있는 Kubernetes 내에서는 더욱 그렇습니다.

참고: Kubernetes‑native(Knative와 다름)는 Kubernetes를 위해 설계 및 빌드된 도구를 말합니다.

일반적으로 Kubernetes CLI와 함께 작동하고 Helm을 사용하여 설치할 수 있으며 Kubernetes 기능과 통합됩니다.

대부분의 Kubernetes 사용자는 Kubernetes 네이티브 방식으로 구성할 수 있는 도구를 선호하는데,

이는 개발 또는 GitOps 경험에 대한 변경을 피하기 때문입니다. YAML 친화적 도구는 세 가지 주요 이점을 제공합니다.

YAML은 Kubernetes 팀에 익숙한 언어이므로 API 게이트웨이 기능을 위해 기존 Kubernetes 도구를 사용하는 경우 학습 곡선이 작거나 존재하지 않습니다. 이를 통해 팀은 가끔만 사용할 수 있는 새 도구를 구성하는 방법을 배울 필요 없이 기존 기술 세트 내에서 작업할 수 있습니다.
다른 Kubernetes 도구와 같은 방식으로 YAML 친화적인 도구를 자동화할 수 있습니다. 워크플로에 깔끔하게 들어맞는 것은 팀에서 인기가 있을 것입니다. 즉, 사용할 가능성이 높아집니다.
Ingress 컨트롤러, 서비스 메시 또는 둘 다를 사용하여 Kubernetes 트래픽 관리 도구 스택을 축소할 수 있습니다. 결국 모든 추가 홉이 중요하고 불필요한 지연이나 단일 장애 지점을 추가할 이유가 없습니다. 그리고 물론 Kubernetes 내에 배포된 기술 수를 줄이는 것도 예산과 전반적인 보안에 좋습니다.

North-South API 게이트웨이 사용 사례: Ingress 컨트롤러 사용

Ingress 컨트롤러는 많은 API 게이트웨이 사용 사례를 활성화할 수 있는 잠재력을 가지고 있습니다.

정의에 설명된 것 외에도 조직은 다음을 구현할 수 있는 Ingress 컨트롤러를 가장 중요하게 생각합니다.

인증 및 권한 부여 오프로드
권한 기반 라우팅
7계층 라우팅 및 매칭(HTTP, HTTP/S, 헤더, 쿠키, 메서드)
프로토콜 호환성(HTTP, HTTP/2, WebSocket, gRPC)
속도 제한

샘플 시나리오: 메서드 수준 라우팅

Ingress 컨트롤러를 사용하여 API 요청에서 POST 메서드를 거부하고 메서드 수준 매칭 및 라우팅을 구현하려고 합니다.

일부 공격자는 API 정의를 준수하지 않는 요청 유형을 보내 API의 취약점을 찾습니다.

예를 들어, GET 요청만 허용하도록 정의된 API에 POST 요청을 보냅니다.

웹 애플리케이션 방화벽(WAF)은 이런 종류의 공격을 감지할 수 없습니다.

공격에 대한 요청 문자열과 본문만 검사하기 때문에 Ingress 계층에서 API 게이트웨이를 사용하여 잘못된 요청을 차단하는 것이 가장 좋습니다.

NGINX Ingress Controller가 GET 요청만 허용하는 API에 대한 POST 요청을 거부하는 방법 수준 라우팅을 위한 토폴로지를 보여주는 다이어그램

예를 들어, 새로운 API /coffee/{coffee-store}/brand가 클러스터에 추가되었다고 가정해 보겠습니다.

첫 번째 단계는 NGINX Ingress Controller를 사용하여 API를 노출하는 것입니다. 간단히 API를 upstreams 필드에 추가하면 됩니다.

이렇게 하면 원치 않는 POST 트래픽으로부터 새 API를 보호할 수 있습니다.

routes:  - path: apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
  name: cafe
spec:
  host: cafe.example.com
  tls:
    secret: cafe-secret
  upstreams:
  -name: tea
    service: tea-svc
    port: 80
  -name: coffee
    service: coffee-svc 
    port: 80

메서드 수준 매칭을 활성화하려면 routes 필드에 /coffee/{coffee-store}/brand 경로를 추가하고

$request_method 변수를 사용하여 GET 및 POST 요청을 구분하는 두 가지 조건을 추가합니다.

HTTP GET 메서드를 사용하는 모든 트래픽은 자동으로 coffee service로 전달됩니다.

POST 메서드를 사용하는 트래픽은 "거부되었습니다!"라는 메시지가 있는 오류 페이지로 이동합니다.

이렇게 하면 원치 않는 POST 트래픽으로부터 새 API를 보호할 수 있습니다.

routes:  - path: /coffee/{coffee-store}/brand
    matches:
    - conditions:
      - variable: $request_method
        value: POST
        action:
          return:
            code: 403
            type: text/plain
            body: "You are rejected!"
    - conditions:
      - variable: $request_method
        value: GET
        action:
          pass: coffee
  - path: /tea
    action:
      pass:tea

오류 페이지와 함께 메서드 수준 라우팅 및 매칭을 사용하는 방법에 대한 자세한 내용은 NGINX Ingress Controller 문서를 확인하세요.

API 게이트웨이 기능을 위해 Ingress 컨트롤러를 사용하는 보안 관련 예는

블로그에서 Okta 및 NGINX Ingress Controller를 사용하여 Kubernetes에 대한 OpenID Connect 인증 구현을 읽어보세요.

동서 API 게이트웨이 사용 사례: 서비스 메시 사용

서비스 메시는 대부분의 API 게이트웨이 사용 사례에 필수적이지 않거나 처음에는 도움이 되지 않습니다. 대부분의 작업은 Ingress 계층에서 수행할 수 있고 수행해야 하기 때문입니다. 하지만 아키텍처의 복잡성이 증가함에 따라 서비스 메시를 사용하여 가치를 얻을 가능성이 더 큽니다. 가장 유용하다고 생각되는 사용 사례는 A/B 테스트, 카나리아 배포, 블루-그린 배포와 같은 E2EE 및 트래픽 분할과 관련이 있습니다.

샘플 시나리오: Canary 배포

HTTP/S 기준에 따른 조건부 라우팅을 사용하여 서비스 간에 카나리아 배포를 설정하려고 합니다.

장점은 프로덕션 트래픽에 영향을 주지 않고 새로운 기능이나 버전 등의 API 변경 사항을 점진적으로 출시할 수 있다는 것입니다.

현재 NGINX Ingress Controller는 NGINX Service Mesh에서 관리하는 두 서비스인 Coffee.frontdoor.svc와 Tea.frontdoor.svc 간의 트래픽을 라우팅합니다. 이러한 서비스는 NGINX Ingress Controller에서 트래픽을 수신하여 Tea.cream1.svc를 포함한 적절한 앱 기능으로 라우팅합니다. Tea.cream1.svc를 리팩토링하여 새 버전인 Tea.cream2.svc를 호출하기로 결정했습니다. 베타 테스터가 새 기능에 대한 피드백을 제공하기를 원하므로 베타 테스터의 고유한 세션 쿠키를 기반으로 카나리아 트래픽 분할을 구성하여 일반 사용자가 Tea.cream1.svc만 경험하도록 합니다.

NGINX Service Mesh를 사용한 Canary 배포를 위한 토폴로지를 보여주는 다이어그램

NGINX Service Mesh를 사용하여 Tea.frontdoor.svc가 프런트하는 모든 서비스(Tea.cream1.svc 및 Tea.cream2.svc 포함) 간에

트래픽 분할을 만드는 것으로 시작합니다.

조건부 라우팅을 활성화하려면 HTTPRouteGroup 리소스(tea-hrg라는 이름)를 만들고 트래픽 분할과 연결합니다.

그 결과 베타 사용자의 요청(세션 쿠키가 version=beta로 설정된 요청)만 Tea.frontdoor.svc에서 Tea.cream2.svc로 라우팅됩니다.

일반 사용자는 Tea.frontdoor.svc 뒤의 버전 1 서비스만 계속 경험합니다.

apiVersion: split.smi-spec.io/v1alpha3kind: TrafficSplit
metadata:
  name: tea-svc
spec:
  service: tea.1
  backends:
  - service: tea.1
    weight: 0
  - service: tea.2
    weight: 100
  matches:
  - kind: HTTPRouteGroup
    name: tea-hrg

apiVersion: specs.smi-spec.io/v1alpha3
kind: HTTPRouteGroup
metadata:
  name: tea-hrg
  namespace: default
spec:
  matches:
  - name: beta-session-cookie
    headers:
    - cookie: "version=beta"

이 예에서는 0-100 분할로 카나리아 배포를 시작합니다. 즉, 모든 베타 테스터가 Tea.cream2.svc를 경험하게 되지만 물론 베타 테스트 전략에 맞는 비율로 시작할 수도 있습니다. 베타 테스트가 완료되면 간단한 카나리아 배포(쿠키 라우팅 없음)를 사용하여 Tea.cream2.svc의 복원력을 테스트할 수 있습니다.

NGINX Service Mesh를 사용한 트래픽 분할에 대한 자세한 내용은 문서를 확인하세요. 위의 트래픽 분할 구성은 루트 서비스가 백엔드 서비스로 나열되어 있으므로 자체 참조입니다. 이 구성은 현재 Service Mesh Interface 사양(smi-spec)에서 지원되지 않지만, 사양은 현재 알파 상태이며 변경될 수 있습니다.

Kubernetes 앱에 API Gateway 도구를 사용하는 시기(및 방법)

Kubernetes의 대부분 API 게이트웨이 사용 사례는 Ingress 컨트롤러나 서비스 메시로 처리할 수 있지만(처리해야 함) NGINX Plus와 같은 API 게이트웨이 도구가 적합한 몇몇 특수 상황도 있습니다.

비즈니스 요구 사항

여러 팀이나 프로젝트가 Ingress 컨트롤러 세트를 공유하거나 Ingress 컨트롤러를 환경별로 특화할 수 있지만, 기존 Ingress 컨트롤러를 활용하는 대신 Kubernetes 내부에 전용 API 게이트웨이를 배포하기로 선택할 수 있는 이유가 있습니다. Kubernetes 내부에서 Ingress 컨트롤러와 API 게이트웨이를 모두 사용하면 조직이 비즈니스 요구 사항을 달성할 수 있는 유연성을 제공할 수 있습니다. 일부 시나리오는 다음과 같습니다.

귀하의 API 게이트웨이 팀은 쿠버네티스에 익숙하지 않고 YAML을 사용하지 않습니다. 예를 들어, NGINX 구성에 익숙하다면 쿠버네티스에서 NGINX Plus를 API 게이트웨이로 배포하면 마찰이 완화되고 학습 곡선이 줄어듭니다.
플랫폼 운영팀에서는 Ingress 컨트롤러를 앱 트래픽 관리에만 전담하는 것을 선호합니다.
클러스터의 서비스 중 하나에만 적용되는 API 게이트웨이 사용 사례가 있습니다. Ingress 컨트롤러를 사용하여 모든 남북 트래픽에 정책을 적용하는 대신 API 게이트웨이를 배포하여 필요한 곳에만 정책을 적용할 수 있습니다.

API를 Kubernetes 환경으로 마이그레이션

기존 API를 Kubernetes 환경으로 마이그레이션할 때 Kubernetes 외부에 배포된 API 게이트웨이 도구에 해당 API를 게시할 수 있습니다.

이 시나리오에서 API 트래픽은 일반적으로 외부 로드 밸런서(클러스터 간 로드 밸런싱용)를 거쳐

라우팅된 다음 API 게이트웨이로 구성되도록 구성된 로드 밸런서로 라우팅되고

마지막으로 Kubernetes 클러스터 내의 Ingress 컨트롤러로 라우팅됩니다.

Kubernetes에서 SOAP API 지원

대부분의 최신 API는 REST를 사용하여 만들어지지만

(일부는 RESTful 또는 gRPC 서비스와 API가 Kubernetes 플랫폼을 최대한 활용할 수 있기 때문)

재구성되지 않은 SOAP API가 있을 수 있습니다.

SOAP API는 마이크로서비스에 최적화되지 않았기 때문에 Kubernetes에 권장되지 않지만

재구성될 때까지 Kubernetes에 SOAP API를 배포해야 할 수 있습니다.

API는 REST 기반 API 클라이언트와 통신해야 할 가능성이 높으며, 이 경우 SOAP 및 REST 프로토콜 간에 변환할 방법이 필요합니다.

Ingress 컨트롤러로 이 기능을 수행할 수 있지만 리소스를 매우 많이 사용하므로 권장하지 않습니다.

대신 API 게이트웨이 도구를 Pod별 또는 서비스별 프록시로 배포하여 SOAP와 REST 간에 변환하는 것이 좋습니다.

Kubernetes 내부 및 외부의 API 트래픽 관리

비교적 소수의 고객이 Kubernetes 환경 내부와 외부에 걸친 API를 관리하는 데 관심이 있습니다.

API 관리 전략이 Kubernetes 네이티브 도구를 선택하는 것보다 더 높은 우선순위인 경우,

Kubernetes에 배포된 "Kubernetes 친화적" API 게이트웨이(API 관리 솔루션과 통합 가능)가 올바른 선택일 수 있습니다.

참고: Kubernetes 네이티브 도구와 달리 Kubernetes 친화적 도구(때로는 Kubernetes 조정 도구라고도 함)는

Kubernetes용으로 설계되지 않았으며 Kubernetes 구성을 사용하여 관리할 수 없습니다.

그러나 민첩하고 가벼워서 상당한 지연 시간을 추가하거나 광범위한 해결 방법을 요구하지 않고 Kubernetes에서 수행할 수 있습니다.

NGINX 시작하기

NGINX는 세 가지 유형의 배포 시나리오 모두에 대한 옵션을 제공합니다.

Kubernetes 네이티브 도구:

NGINX Ingress Controller – Kubernetes용 NGINX Plus 기반 Ingress 컨트롤러로, 고급 트래픽 제어 및 셰이핑, 모니터링 및 가시성, 인증 및 단일 로그인(SSO)을 처리합니다.
NGINX 서비스 메시 – NGINX Plus를 엔터프라이즈 사이드카로 제공하는 가볍고 턴키 방식의 개발자 친화적인 서비스 메시입니다.

NGINX App Protect WAF 및 DoS가 포함된 NGINX Ingress Controller의 무료 30일 체험판을 요청하고, 항상 무료인 NGINX Service Mesh를 다운로드하여 시작하세요.

Kubernetes 환경 내부 또는 외부에서 Kubernetes 친화적인 API 게이트웨이의 경우:

NGINX Plus – 고가용성, 활성 상태 검사, DNS 시스템 검색, 세션 지속성 및 RESTful API와 같은 엔터프라이즈급 기능을 갖춘 올인원 로드 밸런서, 역방향 프록시, 웹 서버 및 API 게이트웨이. 전체 API 라이프사이클 솔루션을 위해 NGINX Controller[현재 F5 NGINX Management Suite]와 통합됩니다.

위 내용과 같이 NGINX Ingress Controller 및 NGINX App Protect WAF, DoS 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요

전문가에게 상담받기

9

OpenTelemetry를 최신 앱 참조 아키텍처에 통합하기 – 진행 보고서

관리자

2024-07-12

작년 가을 Sprint 2.0에서 NGINX 모던 앱 레퍼런스 아키텍처 프로젝트 NGINX Modern Apps Reference Architecture(MARA) 를 소개했을 때 , 우리는 그것이 일부 아키텍처와 같은 "장난감"이 아니라 "Kubernetes 환경에서 실행되는 실제 운영 애플리케이션에 배포할 준비가 된 견고하고 테스트된" 솔루션이라는 점을 강조했습니다. 이러한 프로젝트의 경우 관찰 툴링은 절대적으로 필요합니다. MARA 팀의 모든 구성원은 상태와 성능에 대한 통찰력이 부족하여 애플리케이션 개발과 제공이 무산되는 일을 직접 경험했습니다.

그렇기에 우리는 MARA가 프로덕션 환경에서 디버깅 및 추적을 위한 계측을 포함해야 한다는 데 즉시 합의했습니다.

MARA의 또 다른 주요 원칙은 오픈 소스 솔루션을 선호한다는 점입니다. 이번 포스트에서는 다기능 오픈 소스 관찰 도구를 찾는 과정에서OpenTelemetry 를 선택하게 된 이유와 Python, Java 및 NGINX로 구축된 마이크로서비스 애플리케이션과 OpenTelemetry를 통합하기 위해 사용한 절충점, 설계 결정, 기술 및 기법들을 자세히 설명합니다. 이러한 경험담을 통해 여러분이 잠재적인 함정을 피하고 OpenTelemetry 도입을 가속화하는 데 도움이 되길 바랍니다. 이 포스트는 시기 적절한 진행 보고서이므로, 여기서 논의하는 기술들은 1년 내에 성숙할 것으로 예상합니다. 게다가 일부 프로젝트의 현재 단점을 지적하기는 하지만, 진행 중인 모든 오픈 소스 작업에 대단히 감사드리며 그 발전을 지켜보는 것이 매우 기대가 됩니다.

우리의 애플리케이션

관찰 솔루션과 통합할 애플리케이션으로 Google의 Bank of Anthos 샘플 앱을 포크한 Bank of Sirius를 선택했습니다. 이 웹 애플리케이션은 코드 기반 인프라를 통해 배포될 수 있는 마이크로서비스 아키텍처를 가지고 있습니다. 이 웹 애플리케이션은 성능과 신뢰성 측면에서 개선될 여지가 많지만, 브라운필드 애플리케이션으로 간주할 만큼 충분히 성숙했습니다. 따라서 이 애플리케이션은 OpenTelemetry를 통합하는데 좋은 예가 된다고 생각합니다. 이론적으로 분산 추적은 애플리케이션 아키텍처의 단점에 대한 귀중한 통찰력을 제공하기 때문입니다 .

다이어그램에서 볼 수 있듯이, 애플리케이션을 지원하는 서비스는 비교적 간단합니다.

이미지는 Google 에서 제공

OpenTelemetry 선택 과정

OpenTelemetry를 선택하게 된 과정은 꽤 복잡했고 여러 단계가 있었습니다.

기능 요구사항 목록 작성

사용 가능한 오픈소스 관측 도구를 평가하기 전에, 우리는 관측에서 중요하게 생각하는 요소들을 식별했습니다. 과거 경험을 바탕으로 다음 목록을 작성했습니다.

- 로깅 - 애플리케이션에서 생성된 뉴라인으로 구분된 메세지 세트; Bank of Sirius 앱은 Bunyan 형식 으로 로그를 구조화합니다.

- 분산 추적 – 애플리케이션 내의 각 구성 요소에 대한 타이밍과 메타데이터 , APM 벤더들이 제공하는 것과 유사합니다.

- 메트릭 – 일정 기간 동안 수집된 측정값으로 시간 시계열 데이터로 그래프화 한 것입니다.

- 예외/오류 집계 및 알림 – 가장 흔한 예외와 오류의 집합을 검색 가능하게 하여 애플리케이션 오류가 무엇인지 파악합니다.

- 상태 확인 – 애플리케이션 내에서 서비스가 올바르게 기능하고 있는지 확인하기 위해 주기적으로 서비스에 전송되는 프로브입니다.

- 런타임 상태 조사 - 관리자에게만 표시되는 API 세트로 – 애플리케이션의 런타임 상태에 대한 정보를 반환합니다.

- 힙/코어 덤프 - 서비스 런타임 상태의 포괄적인 스냅샷. 서비스가 충돌할 때 또는 요청 시 이러한 덤프를 얼마나 쉽게 얻을 수 있는지가 중요합니다.

도구 기능 비교

물론, 우리는 단일 오픈소스 도구나 접근 방식에 이 모든 기능이 포함될 것이라고 기대하지 않았지만, 적어도 사용 가능한 도구를 비교할 수 있는 기틀을 마련했습니다. 우리는 각 도구의 설명서를 참조하여 우리의 위시 목록에 있는 7가지 기능 중 어떤 기능을 지원하는지 알아냈습니다. 표는 이 결과를 요약한 것입니다.

이 표를 만드는 것은 갑작스러운 깨달음이었습니다. 다양한 도구들은 그들의 기능과 목적이 너무 달라서 우리는 그들을 모두 같은 범주에 포함시킬 수 없었습니다 – 마치 사과를 토스터기와 비교하는 것 같았습니다! 이 표를 작성하면서 각 도구가 얼마나 다양한 기능과 목적을 가지고 있는지 깨달았습니다.

예를 들어, ELK (Elasticsearch-Logstash-Kibana, plus Filebeat)와 Zipkin은 근본적으로 다른 기능을 수행하므로 이 둘을 비교하려는 시도 자체가 더 혼란스러울 뿐입니다. 불행히도, "목표의 확장"은 상황을 더욱 복잡하게 만듭니다. 이는 사용자 요청에 대한 응답으로, 도구의 주요 목적과는 다소 무관한 기능이 추가되어 다른 도구와의 중복을 초래하기 때문입니다. 표면적으로는 ELK가 로그 저장 및 시각화를 수행하는 반면, Zipkin은 분산 추적을 수행합니다. 그러나 Elastic 제품 포트폴리오를 조금 더 깊이 들여다보면, 분산 추적을 지원하고 Jaeger와의 호환성까지 제공하는 Elastic APM을 빠르게 발견할 수 있습니다.

목표의 확장 문제를 넘어, 많은 도구들이 서로 통합될 수 있어 다양한 조합의 수집기, 집계기, 대시보드 등을 만들 수 있습니다. 일부 기술들은 서로 호환되지만, 일부는 그렇지 않습니다.

확장 기능으로 제공

정성적 조사 수행

이 비교표만으로는 충분한 정보를 제공하지 못했기 때문에, 각 프로젝트의 목표, 원칙, 미래 방향에 대한 정성적 조사가 필요했습니다. 프로젝트의 가치가 우리의 가치와 유사할수록 시간이 지나도 호환성을 유지할 가능성이 더 높다는 추론이 있었기 때문입니다. 프로젝트 페이지를 방문했을 때, 우리는 OpenCensus 페이지에서 즉시 주목할 점을 발견했습니다.

OpenCensus와 OpenTracing이 OpenTelemetry로 통합되면서, 이는 OpenCensus와 OpenTracing의 다음 주요 버전으로 사용됩니다. OpenTelemetry는 기존 OpenCensus 통합과의 역호환성을 제공하며, 우리는 향후 2년간 기존 OpenCensus 라이브러리에 보안 패치를 계속 제공할 예정입니다. 이는 중요한 데이터 포인트였으며, OpenTelemetry가 앞으로도 탄탄한 커뮤니티 지원을 받을 것이라고 판단하여 선택했습니다. OpenTelemetry Collector는 벤더 중립적인 구현을 제공하여 여러 오픈 소스 및 상업적 백엔드에 텔레메트리 데이터를 보낼 수 있도록 합니다. 이를 통해 다양한 수집 및 계측 방법을 백엔드와 혼합하여 사용할 수 있습니다.

그리고 OpenTelemetry Collector 에 대해서도 알아보았습니다 .

OpenTelemetry Collector는 원격 측정 데이터를 수신, 처리 및 내보내는 방법에 대한 공급업체에 독립적인 구현을 제공합니다. 또한 오픈 소스 원격 측정 데이터 형식(예: Jaeger, Prometheus 등)을 지원하기 위해 여러 에이전트/수집기를 실행, 운영 및 유지 관리할 필요성을 제거하여 여러 오픈 소스 또는 상용 백엔드로 전송합니다.

OpenTelemetry Collector는 다양한 관찰 수집 및 계측 방법을 다양한 백엔드와 혼합하고 일치시킬 수 있는 집계기 역할을 합니다. 기본적으로, 우리 애플리케이션은 Zipkin으로 추적을 수집하고 Prometheus 에서 메트릭을 수집 한 다음, 이를 구성 가능한 백엔드로 보내고 Grafana 로 시각화 할 수 있습니다. 이 디자인의 여러 다른 순열이 가능하므로, 어떤 기술이 사용 사례에 적합한지 확인하기 위해 다양한 접근 방식을 시도할 수 있습니다.

OpenTelemetry 통합 추진

OpenTelemetry Collector의 아키텍처는 각 호스트에 하나의 인스턴스를 실행하여 여러 애플리케이션에서 데이터를 수집하고 저장 백엔드로 전송할 수 있도록 합니다. 우리는 자바와 파이썬 서비스에서 OpenTelemetry 자바 라이브러리와 Micrometer를 사용하여 메트릭을 수집하고, OpenTelemetry Collector를 사용하여 데이터를 처리합니다.

결론적으로, OpenTelemetry Collector는 다양한 관측 기술을 사용할 수 있게 해줍니다. 우리는 OpenTelemetry 프로젝트가 아직 초기 단계임에도 불구하고 이를 사용하여 오픈 소스 통합을 통해 기술 환경을 이해하려고 합니다.

로깅 구현

로깅은 간단해 보이지만, 데이터 저장소 결정, 데이터 전송 방법, 데이터 인덱싱 및 보관 기간 결정 등의 복잡한 문제를 포함합니다. 우리는 다른 옵션을 계속 조사하는 동안 단기적으로 로깅에 ELK를 사용하기로 결정했습니다.

Elasticsearch 툴링을 기본으로 사용하여 배포를 수집, 조정, 마스터 및 데이터 노드로 분할할 수 있었습니다. 배포를 더 쉽게 하기 위해 Bitnami 차트를 사용했습니다. 데이터를 전송하기 위해 Kubernetes DaemonSet의 일부로 Filebeat를 배포했습니다. Kibana를 배포하고 미리 로드된 인덱스, 검색, 시각화 및 대시보드를 활용하여 검색 기능을 추가했습니다.

이 솔루션이 작동했지만 기본 구성이 리소스를 많이 소모하여 K3S 나 Microk8s 와 같이 리소스가 작은 환경에서 실행하기 어렵다는 것이 꽤 분명해졌습니다. 각 구성 요소에 대한 복제본 수를 조정하는 기능을 추가하면 이 문제가 해결되었지만 리소스 고갈이나 과도한 양의 데이터로 인해 오류가 발생할 수 있습니다.

이러한 문제에도 불구하고, 우리는 이를 다양한 구성으로 로깅 시스템을 벤치마킹하고 Grafana Loki 및 Graylog와 같은 다른 옵션을 조사할 기회로 보고 있습니다. 가벼운 로깅 솔루션은 일부 사용자에게 필요하고 더 많은 리소스를 필요로 하는 도구에서 얻을 수 있는 전체 기능 세트를 제공하지 않는다는 것을 알게 될 수도 있습니다. MARA의 모듈식 특성을 감안할 때, 사용자에게 더 많은 선택권을 제공하기 위해 이러한 옵션에 대한 추가 모듈을 구축할 가능성이 높습니다.

분산 추적 구현

Java와 Python 서비스에서 OpenTelemetry 라이브러리를 사용하여 분산 추적을 구현하고, NGINX에서도 OpenTelemetry 모듈을 사용하여 통합했습니다. 첫째, 우리는 어떤 계측도 애플리케이션 자체의 서비스 품질에 부정적인 영향을 미치지 않는지 확인하고 싶었습니다. OpenTelemetry Collector의 아키텍처는 호스트당 하나의 인스턴스를 실행할 수 있기 때문에 이런 면에서 매력적이었습니다. 각 수집기는 호스트에서 실행 중인 모든 애플리케이션(컨테이너화 또는 기타)의 클라이언트와 에이전트에서 데이터를 수신합니다. 수집기는 데이터를 집계하고 잠재적으로 압축한 다음 스토리지 백엔드로 전송하는데, 이는 이상적이었습니다.

다음으로, 우리는 애플리케이션에서 사용하는 다양한 프로그래밍 언어와 프레임워크에서 OpenTelemetry에 대한 지원을 평가했습니다. 여기서는 상황이 조금 더 까다로워졌습니다. 두 가지 프로그래밍 언어와 관련 프레임워크만 사용했음에도 불구하고 복잡성 수준이 놀라울 정도로 높았습니다.

Language Framework Number of Services

Java	Spring Boot	3
Python	Flask	3

언어 수준의 추적을 추가하기 위해 처음에는 OpenTelemetry의 자동 계측 에이전트를 사용해 보았지만, 출력이 혼란스럽고 이해하기 어려웠습니다. 자동 계측 라이브러리가 성숙해지면 개선될 것이라 확신하지만, 현재로서는 OpenTelemetry 에이전트를 배제하고 코드에 직접 추적 기능을 통합하기로 했습니다.

코드에 직접 추적을 구현하기 전에, 먼저 OpenTelemetry Collector를 로컬에서 실행 중인 Jaeger 인스턴스에 연결하여 모든 추적 데이터를 출력하도록 설정했습니다. 이렇게 하면 추적 데이터를 시각적으로 확인하면서 OpenTelemetry를 완전히 통합하는 방법을 파악할 수 있어 매우 유용했습니다. 예를 들어, HTTP 클라이언트 라이브러리가 종속 서비스 호출 시 추적 데이터를 포함하지 않는 것을 발견하면, 즉시 해당 문제를 수정 목록에 추가했습니다. Jaeger는 단일 추적 내의 모든 다양한 스팬을 보기 좋게 시각화해 줍니다.

Python을 위한 분산 추적

Python 코드에 추적을 추가하는 것은 비교적 간단했습니다. 모든 서비스에서 참조하는 두 개의 Python 소스 파일을 추가하고, 해당 requirements.txt 파일을 업데이트하여 관련 opentelemetry-instrumentation-*종속성을 포함했습니다. 즉, 모든 Python 서비스에 동일한 추적 구성을 사용할 수 있고, 로그 메시지에 각 요청의 추적 ID를 포함하고 종속 서비스에 대한 요청에 추적 ID를 임베드할 수 있었습니다.

Java용 분산 추적

다음으로, 우리는 Java 서비스에 주의를 돌렸습니다. OpenTelemetry Java 라이브러리를 그린필드 프로젝트에서 직접 사용하는 것은 비교적 간단합니다. 필요한 라이브러리를 임포트하고 추적 API를 직접 사용하기만 하면 됩니다. 하지만 우리처럼 Spring을 사용하는 경우, 추가로 결정해야 할 사항이 있습니다.

Spring은 이미 분산 추적 API인 Spring Cloud Sleuth를 가지고 있습니다. 이는 설명서에 설명된 대로 다음을 수행하는 기본 분산 추적 구현에 대한 인터페이스를 제공합니다.

Slf4J MDC에 추적 및 스팬 ID를 추가하므로 로그 집계기에서 지정된 추적 또는 스팬에서 모든 로그를 추출할 수 있습니다.
Spring 애플리케이션의 일반적인 유입 및 유출 지점(서블릿 필터, REST 템플릿, 예약된 작업, 메시지 채널, Feign 클라이언트)을 도구화합니다.
사용 가능한 경우 spring-cloud-sleuth-zipkin, Zipkin 호환 추적을 HTTP를 통해 생성 및 보고합니다. 기본적으로 로컬 호스트(포트 9411)의 Zipkin 수집기 서비스로 전송합니다. spring.zipkin.baseUrl을 사용하여 서비스의 위치를 구성할 수 있습니다.
API를 사용하면 @Scheduled 주석이 달린 작업에 추적을 추가할 수도 있습니다.

즉, Spring Cloud Sleuth만 사용하면 HTTP 서비스 엔드포인트 수준에서 추적을 바로 받을 수 있어서 좋은 이점입니다. 저희 프로젝트는 이미 Spring을 사용하고 있으므로 모든 것을 해당 프레임워크 내에서 유지하고 제공된 기능을 활용하기로 했습니다. 하지만 Maven으로 모든 것을 연결하면서 몇 가지 문제를 발견했습니다.

Spring Cloud Sleuth Autoconfigure 모듈은 아직 마일스톤 릴리스 단계에 있습니다.
Spring Cloud Sleuth Autoconfigure 모듈은 오래된 알파 버전의 opentelemetry-instrumentation-api에 의존합니다. 현재 이 라이브러리의 최신 비알파 1.x 릴리스는 없습니다.
Spring Cloud Sleuth가 마일스톤 릴리스에 대한 종속성 참조를 코딩하는 방식 때문에 프로젝트는 Spring Snapshot 저장소에서 부모 프로젝트 객체 모델(POM)을 가져와야 합니다.

이로 인해 Maven 프로젝트 정의가 조금 더 복잡해졌습니다. Maven이 Spring 저장소와 Maven Central에서 모두 가져와야 했기 때문입니다. 이는 Spring Cloud에서 OpenTelemetry 지원이 얼마나 초기 단계인지를 명확히 보여주는 지표였습니다. 그럼에도 불구하고 우리는 계속해서 나아가 Spring Cloud Sleuth와 OpenTelemetry를 사용하여 분산 추적을 구성하는 공통 원격 측정 모듈을 만들었고, 여기에는 다양한 원격 측정 관련 도우미 함수와 확장 기능이 포함되었습니다.

공통 원격 측정 모듈에서 Spring Cloud Sleuth와 OpenTelemetry 라이브러리가 제공하는 추적 기능을 확장하여 다음을 제공합니다.

프로젝트의 추적 및 확장 기능을 설정하고 추가 추적 리소스 속성을 로드하는 Spring 지원 Autoconfiguration 클래스입니다.
NoOp 인터페이스 구현을 통해 모든 Spring Cloud Sleuth 인터페이스에 NoOp 인스턴스를 주입하여 시작 시 추적을 비활성화할 수 있습니다.
추적 이름을 정규화하기 위한 추적 명명 인터셉터입니다.
slf4j 및 Spring Cloud Sleuth 추적을 통해 오류를 출력하는 오류 처리기입니다.
서비스 버전, 서비스 인스턴스 ID, 머신 ID, Pod 이름, 컨테이너 ID, 컨테이너 이름, 네임스페이스 이름을 포함하여 각 방출된 추적에 추가 정보를 인코딩하는 추적 속성의 향상된 구현입니다.
Hibernate에서 발행한 SQL 문 앞에 있는 주석에 추적 ID를 주입하는 추적 문 검사기. 이는 SQLCommenter로 할 수 있지만 아직 마이그레이션하지 않았습니다.

또한, 서비스 간에 HTTP 호출을 할 때 더 많은 메트릭과 사용자 정의 기능을 원했기 때문에 Apache HTTP 클라이언트가 지원하는 Spring 호환 HTTP 클라이언트를 구현했습니다. 이 구현에서 추적 및 스팬 식별자는 종속 서비스가 호출될 때 헤더로 전달되어 추적 출력에 포함될 수 있습니다. 게다가 이 구현은 OpenTelemetry에서 집계하는 HTTP 연결 풀 메트릭을 제공합니다.

전반적으로 Spring Cloud Sleuth와 OpenTelemetry로 추적을 연결하는 것은 힘들었지만, 그만한 가치가 있었다고 믿습니다. 이 프로젝트와 이 게시물이 이 길을 가고자 하는 다른 사람들에게 길을 밝히는 데 도움이 되기를 바랍니다.

NGINX를 위한 분산 추적

요청의 전체 수명 주기 동안 모든 서비스를 연결하는 추적을 얻으려면 OpenTelemetry를 NGINX에 통합해야 했습니다. 이 목적을 위해 OpenTelemetry NGINX 모듈(아직 베타 상태)을 사용했습니다. 모든 버전의 NGINX에서 작동하는 모듈의 작동하는 바이너리를 얻는 것이 어려울 수 있다는 것을 예상하고 지원되지 않는 NGINX 모듈을 통합하는 컨테이너 이미지의 GitHub 저장소를 만들었습니다. 매일 밤 빌드를 실행하고 쉽게 가져올 수 있는 Docker 이미지를 통해 모듈 바이너리를 배포합니다. 우리는 아직 이 프로세스를 MARA 프로젝트의 NGINX Ingress Controller 빌드 프로세스에 통합하지 않았지만, 곧 통합할 계획입니다.

메트릭 수집 구현

추적 OpenTelemetry 통합을 완료한 후, 다음으로 메트릭에 집중했습니다. Python 기반 애플리케이션에 대한 기존 메트릭이 없었고, 지금은 추가하는 것을 미루기로 했습니다. Java 애플리케이션의 경우, Google Cloud의 Stackdriver와 함께 Micrometer를 사용하는 원래 Bank of Anthos 소스 코드는 메트릭을 지원합니다. 그러나 Bank of Anthos를 포크한 후 Bank of Sirius에서 해당 코드를 제거했는데, 메트릭 백엔드를 구성할 수 없었기 때문입니다. 그럼에도 불구하고 메트릭 후크가 이미 존재했다는 사실은 적절한 메트릭 통합이 필요하다는 것을 말해주었습니다.

구성 가능하고 실용적인 솔루션을 찾기 위해 먼저 OpenTelemetry Java 라이브러리와 Micrometer 내의 메트릭 지원을 살펴보았습니다. 기술 간 비교를 검색한 결과, OpenTelemetry 메트릭이 작성 당시 알파 단계에 있었음에도 불구하고 JVM에서 메트릭 API로 사용된 OpenTelemetry의 단점이 여러 결과에서 나열되었습니다. Micrometer는 JVM을 위한 성숙한 메트릭 파사드 계층으로, 자체 메트릭 구현이 아닌 구성 가능한 메트릭 구현을 제공하는 공통 API 래퍼를 제공한다는 점에서 slf4j와 유사합니다. 흥미롭게도, Spring의 기본 메트릭 API입니다.

이 시점에서 우리는 다음과 같은 사실을 고려했습니다.

OpenTelemetry Collector는 Prometheus, StatsD 및 기본 OpenTelemetry Protocol(OTLP)을 포함한 거의 모든 소스에서 메트릭을 사용할 수 있습니다.
Micrometer는 Prometheus 및 StatsD를 포함한 다양한 메트릭 백엔드도 지원합니다.
JVM용 OpenTelemetry Metrics SDK는 OTLP를 통한 메트릭 전송을 지원합니다.

몇 가지 실험을 거친 후, 우리는 가장 실용적인 접근 방식은 Prometheus 백킹 구현과 함께 Micrometer façade를 사용하고 OpenTelemetry Collector를 구성하여 Prometheus API를 사용하여 애플리케이션에서 메트릭을 가져오는 것이라고 결정했습니다. 우리는 수많은 문서에서 OpenTelemetry에서 누락된 메트릭 유형이 문제를 일으킬 수 있다는 것을 알고 있었지만, 우리의 사용 사례에는 그러한 유형이 필요하지 않았기 때문에 타협이 가능했습니다.

우리는 OpenTelemetry Collector에 대해 흥미로운 사실 하나를 발견했습니다. OTLP를 통해 추적을 수신하고 Prometheus API를 통해 메트릭을 수신하도록 구성했지만 OTLP 또는 다른 지원 프로토콜을 사용하여 두 유형의 데이터를 모두 외부 데이터 수신기로 보내도록 구성할 수 있습니다. 이를 통해 LightStep으로 애플리케이션을 쉽게 시도할 수 있었습니다.

전반적으로 Java로 메트릭을 코딩하는 것은 Micrometer API에 맞게 작성했기 때문에 꽤 간단했습니다. Micrometer API에는 수많은 예제와 튜토리얼이 있습니다. 아마도 메트릭과 추적 모두에서 가장 어려웠던 것은 pom.xml 파일에 Maven 종속성 그래프를 telemetry-common에 적절하게 넣는 것이었습니다.

오류 집계 구현

OpenTelemetry 프로젝트는 자체 임무에 오류 집계를 포함하지 않으며 Sentry나 Honeybadger.io와 같은 솔루션만큼 우아한 오류 태그 구현을 제공하지 않습니다. 그럼에도 불구하고 다른 도구를 추가하는 대신 단기적으로 오류 집계에 OpenTelemetry를 사용하기로 결정했습니다. Jaeger와 같은 도구를 사용하면 error=true 오류 조건이 있는 모든 추적을 찾을 수 있습니다. 이를 통해 적어도 일반적으로 무엇이 잘못되는지 알 수 있었고. 나중에 Sentry 통합을 추가하는 것을 고려할 수 있습니다.

Health Checks 및 런타임 내성 구현

애플리케이션의 맥락에서, 상태 점검은 Kubernetes가 서비스가 정상인지 또는 시작 단계를 완료했는지 알 수 있도록 합니다. 서비스가 정상적이지 않은 경우 Kubernetes는 인스턴스를 종료하거나 다시 시작하도록 구성할 수 있습니다. 애플리케이션에서 OpenTelemetry 상태 점검을 사용하지 않기로 결정한 이유는 설명서가 충분하지 않기 때문입니다.

대신, JVM 서비스의 경우 Spring Boot Actuator라는 Spring 프로젝트를 사용하는데, 이는 헬스체크 엔드포인트뿐만 아니라 런타임 인트로스펙션 및 힙 덤프 엔드포인트도 제공합니다. Python 서비스의 경우, Spring Boot Actuator 기능의 하위 집합을 제공하는 Flask Management Endpoints 모듈을 사용합니다. 현재는 사용자 정의 가능한 애플리케이션 정보와 헬스체크만 제공합니다.

Spring Boot Actuator는 JVM과 Spring에 연결하여 내성, 모니터링 및 상태 점검 엔드포인트를 제공합니다. 또한 엔드포인트에서 제공하는 기본 데이터에 사용자 정의 정보를 추가하기 위한 프레임워크를 제공합니다. 엔드포인트는 캐시 상태, 런타임 환경, 데이터베이스 마이그레이션, 상태 점검, 사용자 정의 가능한 애플리케이션 정보, 메트릭, 주기적 작업, HTTP 세션 상태 및 스레드 덤프와 같은 사항에 대한 런타임 내성을 제공합니다.

Spring Boot Actuator에서 구현한 Health-check 엔드포인트는 모듈식 구성을 가지고 있어서 서비스의 상태를 liveness 또는 readiness로 분류된 여러 개별 검사로 구성할 수 있습니다. 모든 검사 모듈을 표시하는 전체 상태 검사는 다음과 같습니다.

정보적 엔드포인트는 JSON 문서에서 단일 상위 수준 JSON 객체와 일련의 계층적 키와 값으로 정의됩니다. 일반적으로 문서는 서비스 이름과 버전, 아키텍처, 호스트 이름, OS 정보, 프로세스 ID, 실행 파일 이름, 머신 ID 또는 고유 서비스 ID와 같은 호스트에 대한 세부 정보를 지정합니다.

힙 및 코어 덤프 구현

위시리스트와 비교하는 도구 기능의 표에서 어떤 도구도 런타임 내성이나 힙/코어 덤프를 지원하지 않는다는 것을 기억하실 수 있을 것입니다. 그러나 기본 프레임워크인 Spring은 둘 다 지원하지만 관찰 기능을 애플리케이션에 연결하는 데 약간의 작업이 필요했습니다. 이전 섹션에서 자세히 설명했듯이 런타임 내성의 경우 Spring Boot Actuator와 함께 Python 모듈을 사용합니다.

마찬가지로, 힙 덤프의 경우 Spring Boot Actuator에서 제공하는 스레드 덤프 엔드포인트를 사용하여 원하는 기능의 하위 집합을 달성합니다. 필요에 따라 코어 덤프를 얻을 수 없고 이상적으로 세분된 수준의 JVM 힙 덤프를 얻을 수 없지만, 약간의 추가 노력으로 원하는 기능 중 일부를 얻을 수 있습니다. Python 서비스의 코어 덤프는 불행히도 상당한 추가 작업이 필요하며, 이는 나중으로 연기되었습니다.

요약

많은 시행착오 끝에 우리는 MARA에서 관찰을 위해 다음 기술을 사용하기로 결정했습니다 (이하 OTel은 OpenTelemetry를 뜻합니다).

로깅 (모든 컨테이너에 대해): Filebeat → Elasticsearch / Kibana
분산 추적
- Java: Spring Cloud Sleuth → OTel용 Spring Cloud Sleuth 내보내기 도구 → OTel Collector → Jaeger, Lightstep, Splunk 등과 같은 플러그형 내보내기 도구
- Python: OTel Python 라이브러리 → OTel Collector → 플러그형 스토어
- NGINX 및 NGINX Plus (NGINX Ingress Controller는 아직 지원되지 않음): NGINX OTel 모듈 → OTel Collector → 플러그형 내보내기 도구
메트릭 수집
- Java: Spring을 통한 Micrometer → Prometheus exporter → OTel Collector
- Python: 아직 구현되지 않음
- Python WSGI: GUnicorn StatsD → Prometheus (StatsD/ServiceMonitor를 통해)
- NGINX: Prometheus 엔드포인트 → Prometheus (ServiceMonitor를 통해)
오류 집계: OTel 분산 추적 → 플러그형 내보내기 도구 → 표시된 추적을 찾기 위한 내보내기 검색 기능
헬스체크
- Java: Spring Boot Actuator → Kubernetes
- Python: Flask 관리 엔드포인트 모듈 → Kubernetes
런타임 내성
- Java: Spring Boot Actuator
- Python: Flask 관리 엔드포인트 모듈
힙/코어 덤프
- Java: 스레드 덤프에 대한 Spring Boot Actuator 지원
- Python: 아직 지원되지 않음

이 구현은 시간적 스냅샷입니다. 개발이 계속됨에 따라 확실히 변화하고 진화할 것입니다. 곧 광범위한 부하 테스트를 통해 애플리케이션을 실행할 것입니다. 추가로 기능을 추가할 것을 예상합니다.

위 내용과 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요

전문가에게 상담받기

8

트래픽 관리 도구를 사용하여 Kubernetes를 보호하는 6가지 방법

관리자

2024-07-12

편집자 - 이 게시물은 10부작 시리즈의 일부입니다.

프로덕션 등급 Kubernetes로 복잡성 감소
고급 트래픽 관리를 사용하여 Kubernetes의 복원력을 개선하는 방법
Kubernetes에서 가시성을 개선하는 방법
트래픽 관리 도구를 사용하여 Kubernetes를 보호하는 6가지 방법(이 게시물)
Ingress Controller 선택 가이드, 1부: 요구 사항 식별
Ingress 컨트롤러 선택 가이드, 2부: 위험 및 미래 대비
Ingress 컨트롤러 선택 가이드, 3부: 오픈소스 대 기본 대 상업용
Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress 컨트롤러 옵션
서비스 메시를 선택하는 방법
동적 Kubernetes 클라우드 환경에서 NGINX Ingress 컨트롤러 성능 테스트

또한 전체 블로그 세트를 무료 전자책인 ' 테스트에서 프로덕션까지 Kubernetes 활용' 으로 다운로드할 수 있습니다 .

속도 저하 없이 클라우드 네이티브 앱 보안 에서 논의한 대로, 우리는 클라우드 네이티브 앱을 기존 앱보다 보안하기 어렵게 만드는 세 가지 요소를 관찰했습니다 .

클라우드 기반 앱 제공으로 인해 도구가 확산되고 일관되지 않은 엔터프라이즈급 서비스가 제공됩니다.
클라우드 기반 앱 제공 비용은 예측 불가능하고 높을 수 있습니다.
SecOps 팀은 클라우드 기반 앱을 보호하는 데 어려움을 겪고 있으며 DevOps와 의견이 맞지 않습니다.

세 가지 요인 모두 보안에 동등하게 영향을 미칠 수 있지만,

세 번째 요인은 가장 "인간적"이기 때문에 해결하기 가장 어려운 문제가 될 수 있습니다.

SecOps가 클라우드 네이티브 앱을 보호할 수 없거나 보호할 권한이 없는 경우,

일부 결과는 명백하지만(취약성과 침해) 민첩성 저하와 디지털 변환 중단을 포함하여 다른 결과는 숨겨져 있습니다.

숨겨진 비용을 더 자세히 살펴보겠습니다.

조직은 민첩성과 비용 절감의 약속 때문에 Kubernetes를 선택합니다.

그러나 Kubernetes 환경에서 보안 사고가 발생하면 대부분의 조직은 Kubernetes 배포를 프로덕션에서 철회합니다.

이는 조직의 미래에 필수적인 디지털 변환 이니셔티브를 늦추고, 낭비되는 엔지니어링 노력과 비용은 말할 것도 없습니다.

논리적인 결론은 다음과 같습니다.

Kubernetes를 테스트에서 프로덕션으로 전환하려면

보안을 조직의 모든 사람이 소유한 전략적 구성 요소로 간주해야 합니다.

이 게시물에서는 Kubernetes 트래픽 관리 도구로 해결할 수 있는 6가지 보안 사용 사례를 다루며,

이를 통해 SecOps가 DevOps 및 NetOps와 협업하여 클라우드 네이티브 앱과 API를 더 잘 보호할 수 있습니다.

이러한 기술을 조합하여 고객에게 미치는 영향을 최소화하면서

앱과 API를 안전하게 유지하도록 설계된 포괄적인 보안 전략을 만드는 경우가 많습니다.

사이버 공격을 방지하기 위해 CVE를 신속하게 해결하세요
OWASP Top 10 및 서비스 거부 공격 차단
앱에서 인증 및 권한 부여 오프로드
가드레일을 사용하여 셀프 서비스 설정
종단간 암호화 구현
클라이언트가 신뢰할 수 있는 구현을 통해 강력한 암호를 사용하고 있는지 확인하십시오.

보안 및 ID 용어

본격적으로 사용 사례를 살펴보기에 앞서, 이 글 전체에서 접하게 될 보안 용어에 대해 간략하게 살펴보겠습니다.

인증 및 권한 부여

"올바른" 사용자 및 서비스만 백엔드 또는 애플리케이션 구성 요소에 액세스할 수 있도록 보장하는 데 필요한 기능:

인증 – 요청을 하는 클라이언트가 자신이 주장하는 사람인지 확인하기 위한 신원 검증 .

비밀번호나 JSON 웹 토큰(JWT)과 같은 ID 토큰을 통해 수행됩니다.

권한 부여 – 리소스 또는 기능에 대한 액세스 권한 검증.

세션 쿠키, 세션 ID, 그룹 ID 또는 토큰 콘텐츠와 같은 레이어 7 속성과 같은 액세스 토큰을 통해 수행됩니다.

Critical Vulnerabilities and Exposures(CVE)

"취약성으로 인해 악용될 수 있는 소프트웨어, 펌웨어, 하드웨어 또는

서비스 구성 요소의 공개된 결함 데이터베이스로, 영향을 받는 구성 요소에 대한

구성 요소의 기밀성, 무결성 또는 가용성에 부정적인 영향을 줍니다."

CVE는 도구를 관리하는 개발자, 침투 테스터, 사용자 또는 고객 또는 커뮤니티의 누군가(예: "버그 헌터")가 발견할 수 있습니다.

악의적인 행위자에게 이점을 주지 않도록 취약성이 공개되기 전에

소프트웨어 소유자에게 패치를 개발할 시간을 주는 것이 일반적인 관행입니다.

서비스 거부(DoS) 공격

나쁜 행위자가 사이트를 크래시시키는 것을 목표로 요청(TCP/UDP 또는 HTTP/HTTPS)으로

웹사이트를 범람시키는 공격입니다.

DoS 공격은 가용성에 영향을 미치기 때문에 주요 결과는 대상의 평판 손상입니다.
여러 소스가 동일한 네트워크 또는 서비스를 대상으로 하는 분산 서비스 거부(DDoS) 공격은
잠재적으로 대규모 공격자 네트워크로 인해 방어하기가 더 어렵습니다.
DoS 보호에는 공격을 적응적으로 식별하고 방지하는 도구가 필요합니다.
분산 서비스 거부(DDoS)란 무엇입니까? 에서 자세히 알아보세요.

엔드투엔드 암호화(E2EE)

사용자에서 앱으로, 그리고 다시 앱으로 데이터를 전달할 때 데이터를 완전히 암호화하는 관행입니다.

E2EE에는 SSL 인증서와 잠재적으로 mTLS가 필요합니다.
상호 TLS(mTLS) – 클라이언트와 호스트 모두에 대한 인증(SSL/TLS 인증서를 통해)을 요구하는 관행입니다.
mTLS를 사용하면 클라이언트와 호스트 간에 전달되는 데이터의 기밀성과 무결성도 보호됩니다.
mTLS는 동일한 클러스터의 두 서비스 간에 Kubernetes 포드 수준까지 구현할 수 있습니다.
SSL/TLS와 mTLS에 대한 훌륭한 소개는 F5 Labs에서 mTLS란 무엇인가?를 참조하세요.

Single Sign‑On(SSO) SSO 기술(SAML, OAuth, OIDC 포함)을 사용하면 인증 및 권한 부여를 보다 쉽게 관리할 수 있습니다.

간소화된 인증 – SSO를 사용하면 사용자가 서로 다른 리소스나 기능마다 고유한 ID 토큰을 가질 필요가 없습니다.
표준화된 권한 부여 – SSO를 사용하면 역할, 부서 및 근속 기간에 따라 사용자 액세스 권한을 설정할 수 있으므로

각 사용자에 대한 권한을 개별적으로 구성할 필요가 없습니다.

SSL(Secure Sockets Layer)/TLS(Transport Layer Security)

네트워크 컴퓨터 간에 인증되고 암호화된 링크를 설정하기 위한 프로토콜입니다.

SSL/TLS 인증서는 웹사이트의 신원을 인증하고 암호화된 연결을 설정합니다.

SSL 프로토콜은 1999년에 더 이상 사용되지 않고 TLS 프로토콜로 대체되었지만

이러한 관련 기술을 "SSL" 또는 "SSL/TLS"라고 부르는 것이 여전히 일반적입니다.

일관성을 위해 이 게시물의 나머지 부분에서는 SSL/TLS를 사용합니다.

웹 애플리케이션 방화벽(WAF)

앱과 API( OWASP Top 10 및 기타 고급 위협 포함)에 대한 정교한 공격을 탐지하고 차단하는 역방향 프록시 로, "안전한" 트래픽은 통과시킵니다.

WAF는 민감한 데이터를 훔치거나 시스템을 하이재킹하여 대상에 피해를 입히려는 공격으로부터 방어합니다.

일부 공급업체는 WAF와 DoS 보호를 동일한 도구에 통합하는 반면, 다른 공급업체는 별도의 WAF와 DoS 도구를 제공합니다.

제로 트러스트

높은 보안 기관에서 자주 사용되지만 모든 사람에게 적용되는 보안 개념으로, 모든 저장 및 전송 단계에서 데이터를 보호해야 합니다.

즉, 기관은 기본적으로 사용자나 기기를 "신뢰"하지 않기로 결정했지만 모든 트래픽을 철저히 검토해야 합니다.

제로 트러스트 아키텍처에는 일반적으로 인증, 권한 부여, mTLS가 결합되어 있으며 기관에서 E2EE를 구현할 가능성이 높습니다.

사례 활용: 사이버 공격을 피하기 위해 CVE를 신속하게 해결

솔루션 : 시기적절하고 사전 예방적인 패치 알림이 가능한 도구 사용

Ponemon Institute의 연구 에 따르면 , 2019년에 중요하거나 우선순위가 높은 취약점에 대한 패치가 릴리스된 후

조직에서 취약점을 악용하려는 공격을 목격하기까지 평균 "유예 기간"이 43일이었습니다.

F5 NGINX에서 우리는 그 기간이 그 후 몇 년 동안 상당히 좁아지는 것을 보았습니다( 2021년 Apple iOS 15의 경우 0일차 까지 ).

따라서 가능한 한 빨리 패치를 적용하는 것이 좋습니다.

하지만 CVE가 발표된 후 몇 주 또는 몇 달 동안 트래픽 관리 도구에 대한 패치를 사용할 수 없다면 어떻게 될까요?

커뮤니티 기여자(전담 엔지니어링 팀이 아닌)가 개발하고 유지 관리하는 도구는 CVE 발표보다

몇 주 또는 몇 달 늦게 적용될 가능성이 있어 조직이 43일 창 내에 패치를 적용할 가능성이 낮습니다.

한 사례에서 OpenResty는 NGINX 관련 보안 패치를 적용하는 데 4개월이 걸렸습니다.

이로 인해 OpenResty 기반 Ingress 컨트롤러를 사용하는 모든 사람이 최소 4개월 동안 취약해졌지만,

현실적으로는 오픈 소스 프로젝트에 의존하는 소프트웨어에 대한 패치가 제공되기까지 일반적으로 추가 지연이 발생합니다.

가장 빠른 CVE 패치를 받으려면 트래픽 관리 도구를 선택할 때 두 가지 특징을 살펴보세요.

전담 엔지니어링 팀

커뮤니티 자원봉사자가 아닌 엔지니어링 팀이 도구 개발을 관리하는 경우,

상태를 유지하고 가능한 한 빨리 패치 릴리스를 우선 순위로 지정할 수 있는

사람들의 그룹이 있다는 것을 알 수 있습니다.

통합된 코드 기반 – 외부 의존성 없이 (우리가 OpenResty와 논의한 것처럼) 패치는 한 번의 애자일 스프린트만 있으면 완료됩니다.

CVE 패치에 대한 자세한 내용은 NGINX Plus를 사용하여 빠르고 쉽게 보안 취약점 완화를 읽어보세요 .

사례: OWASP Top 10 및 DoS 공격 차단

솔루션: 유연하고 Kubernetes 친화적인 WAF 및 DoS 보호 배포

Kubernetes 앱에 적합한 WAF 및 DoS 보호 기능을 선택하는 것은 기능 외에도 두 가지 요소에 따라 달라집니다.

유연성 – Kubernetes 내부에 도구를 배포하는 것이 가장 좋은 시나리오가 있으므로 Kubernetes 내부 또는 외부에서 실행할 수 있는 인프라 독립적인 도구가 필요합니다. 모든 배포에 동일한 도구를 사용하면 정책을 재사용하고 SecOps 팀의 학습 곡선을 낮출 수 있습니다.
Footprint – 최고의 Kubernetes 도구는 작은 풋프린트를 가지고 있어 처리량, 초당 요청 수, 대기 시간에 미치는 영향을 최소화하면서 적절한 리소스 소비가 가능합니다. DevOps 팀은 보안 도구가 앱을 느리게 한다는 인식 때문에 보안 도구를 거부하는 경우가 많기 때문에

풋프린트가 작은 고성능 도구를 선택하면 채택 가능성이 높아질 수 있습니다.

WAF와 DoS 보호를 통합하는 도구가 더 효율적인 것처럼 보일 수 있지만

실제로는 CPU 사용(더 큰 풋프린트로 인해)과 유연성에 문제가 있을 것으로 예상됩니다.

둘 다 필요하지 않더라도 WAF와 DoS 보호를 함께 배포해야 합니다.

궁극적으로 두 가지 문제는 Kubernetes 배포의 총 소유 비용을 높이는 동시에

다른 필수 도구와 서비스에 대한 예산 문제를 발생시킬 수 있습니다.

조직에 적합한 보안 도구를 선택했으면 이제 해당 도구를 어디에 배포할지 결정해야 합니다.

Kubernetes 앱을 보호하기 위해 애플리케이션 서비스를 일반적으로 배포할 수 있는 네 가지 위치가 있습니다.

프런트 도어에서 ( F5 NGINX Plus 또는 F5 BIG‑IP 와 같은 외부 로드 밸런서 에서 )

여러 클러스터에 걸쳐 글로벌 정책을 적용할 수 있으므로 "대략적인" 글로벌 보호에 적합합니다.

엣지에서 ( F5 NGINX Ingress Controller 와 같은 Ingress 컨트롤러 에서 )

단일 클러스터에서 표준인 "세분화된" 보호를 제공하는 데 이상적입니다.

서비스에서 (NGINX Plus와 같은 경량 로드 밸런서에서)

클러스터 내에 고유한 정책에 대한 공유 요구 사항이 있는 소수의 서비스가 있는 경우 필요한 접근 방식이 될 수 있습니다.

포드에서 (애플리케이션의 일부로서)

정책이 앱에 특화되어 있는 경우 사용될 수 있는 매우 사용자 지정적인 접근 방식

그럼, 네 가지 옵션 중에서 어느 것이 가장 좋을까요? 글쎄요... 상황에 따라 다르죠

WAF를 배포할 위치

먼저, 보다 미묘한 선택인 경향이 있는 WAF 배포 옵션부터 살펴보겠습니다.

프런트 도어 및 엣지

조직에서 "심층 방어" 보안 전략을 선호하는 경우 글로벌 및 사용자 지정 보호의 효율적인 균형을 제공하기 위해

외부 로드 밸런서와 Ingress 컨트롤러 모두에 WAF를 배포하는 것이 좋습니다.

프런트 도어 또는 엣지

"심층 방어" 전략이 없는 경우 단일 위치가 허용되며 배포 위치는 소유권에 따라 달라집니다.

기존 NetOps 팀이 보안을 소유하는 경우 기존 프록시(외부 로드 밸런서)에서 관리하는 것이 더 편안할 수 있습니다.

그러나 Kubernetes에 익숙한(그리고 클러스터 구성 근처에 보안 구성을 두는 것을 선호하는)

DevSecOps 팀은 인그레스 수준에서 WAF를 배포하도록 선택할 수 있습니다.

서비스 또는 포드당

팀에 서비스 또는 앱에 대한 특정 요구 사항이 있는 경우, 단품으로 추가 WAF를 배포할 수 있습니다.

하지만 이러한 위치에는 비용이 더 많이 든다는 점을 알아두십시오.

개발 시간이 늘어나고 클라우드 예산이 더 많아지는 것 외에도,

이러한 선택은 "어느 WAF가 의도치 않게 트래픽을 차단하고 있는가?"를

판단하는 것과 같은 문제 해결 노력과 관련된 운영 비용도 증가시킬 수 있습니다.

DoS 보호를 배포할 위치

DoS 공격에 대한 보호는 프런트 도어나 Ingress 컨트롤러 중 한 곳 에서만 필요하므로 더 간단합니다 .

프런트 도어와 에지 모두에 WAF를 배포하는 경우 프런트 도어 WAF 앞에 DoS 보호를 배포하는 것이 가장 글로벌하므로 좋습니다.

이렇게 하면 WAF에 도달하기 전에 원치 않는 트래픽을 줄일 수 있으므로 컴퓨팅 리소스를 보다 효율적으로 사용할 수 있습니다.

각 배포 시나리오에 대한 자세한 내용은 Kubernetes에서 애플리케이션 서비스 배포, 2부를 참조하세요 .

용 례 : 앱에서 인증 및 권한 부여 오프로드

솔루션: 진입 지점에서 인증 및 권한 부여를 중앙화합니다.

앱과 서비스에 내장된 일반적인 비기능적 요구 사항은 인증 및 권한 부여입니다.

앱에 빈번한 업데이트가 필요하지 않은 경우 허용할 수 있는 관리 가능한 양의 복잡성을 추가합니다.

그러나 대규모로 더 빠른 릴리스 속도로 인해 앱에 인증 및 권한 부여를 통합하는 것은 불가능해집니다.

각 앱이 적절한 액세스 프로토콜을 유지하도록 하면 앱의 비즈니스 로직에서 주의를 돌릴 수 있거나

더 나쁜 경우 간과되어 정보 침해로 이어질 수 있습니다.

SSO 기술을 사용하면 별도의 사용자 이름과 비밀번호를 제거하고 하나의 자격 증명 세트를 사용하여

보안을 개선할 수 있지만 개발자는 여전히 앱에 코드를 포함하여 SSO 시스템과 인터페이스해야 합니다.

더 나은 방법이 있습니다. 인증 및 권한 부여를 Ingress 컨트롤러로 오프로드하세요.

Ingress 컨트롤러는 이미 클러스터에 들어오는 모든 트래픽을 면밀히 조사하고

적절한 서비스로 라우팅하기 때문에 중앙 인증 및 권한 부여에 효율적인 선택입니다.

이를 통해 개발자는 애플리케이션 코드에서 로직을 빌드, 유지 관리 및 복제하는 부담을 덜 수 있습니다.

대신 네이티브 Kubernetes API를 사용하여 Ingress 계층에서 SSO 기술을 빠르게 활용할 수 있습니다.

이 주제에 대한 자세한 내용은 Okta 및 NGINX Ingress Controller를 사용하여 Kubernetes에 대한 OpenID Connect 인증 구현을 참조하세요 .

용례 : 가드레일을 사용하여 셀프 서비스 설정

솔루션: 역할 기반 액세스 제어(RBAC) 구현

쿠버네티스는 RBAC를 사용하여 다양한 유형의 사용자에게 제공되는 리소스와 작업을 제어합니다.

이는 관리자 또는 슈퍼유저가 사용자 또는 사용자 그룹이 클러스터의 모든 쿠버네티스 객체 또는 특정 네임스페이스와

상호 작용하는 방법을 결정할 수 있으므로 귀중한 보안 조치입니다.

Kubernetes RBAC는 기본적으로 활성화되어 있지만 Kubernetes 트래픽 관리 도구도 RBAC를 활성화하고

조직의 보안 요구 사항에 맞출 수 있도록 주의해야 합니다.

RBAC가 있으면 사용자는 티켓이 충족될 때까지 기다리지 않고도 작업을 수행하는 데 필요한 기능에 대한 게이트 액세스 권한을 얻습니다.

그러나 RBAC가 구성되지 않으면 사용자는 필요하지 않거나 권한이 없는 권한을 얻을 수 있으며,

권한이 오용되면 취약성이 발생할 수 있습니다.

Ingress 컨트롤러는 RBAC로 구성될 때 수많은 사람과 팀에 서비스를 제공할 수 있는 도구의 대표적인 예입니다.

Ingress 컨트롤러가 단일 네임스페이스까지 세분화된 액세스 관리를 허용하는 경우

RBAC를 사용하여 멀티 테넌시를 통해 리소스를 효율적으로 사용할 수 있습니다.

예를 들어, 여러 팀이 다음과 같이 Ingress 컨트롤러를 사용할 수 있습니다.

NetOps 팀 – 애플리케이션의 외부 진입점(호스트 이름 및 TLS 인증서 등)을 구성하고 다양한 팀에 트래픽 제어 정책을 위임합니다.
DevOps 팀 A – TCP/UDP 부하 분산 및 라우팅 정책 제공
DevOps 팀 B – 과도한 요청으로부터 서비스를 보호하기 위해 속도 제한 정책 구성
ID 팀 – 엔드투엔드 암호화 전략 의 일부로 mTLS 정책을 구성하는 동안 인증 및 권한 부여 구성 요소를 관리합니다.
DevSecOps 팀 – WAF 정책 설정

NGINX Ingress Controller에서 RBAC를 활용하는 방법을 알아보려면 NGINX Ingress Controller를 사용한 고급 Kubernetes 배포를 시청하세요 .

전문가가 보안, 셀프 서비스 및 멀티 테넌시를 위해 RBAC와 리소스 할당을 활용하는 방법을 설명합니다.

용례: 종단 간 암호화 구현

해결책: 트래픽 관리 도구 사용

종단간 암호화(E2EE)는 민감하거나 개인 정보를 처리하는 조직에 점점 더 일반적인 요구 사항이 되고 있습니다.

금융 데이터이든 소셜 미디어 메시징이든 GDPR 및 HIPAA와 같은 규정과 결합된

소비자 개인 정보 보호 기대치가 이러한 유형의 보호에 대한 수요를 주도하고 있습니다.

E2EE를 달성하기 위한 첫 번째 단계는 SSL/TLS 트래픽을 허용하도록 백엔드 앱을 설계하거나

앱에서 SSL/TLS 관리를 오프로드하는 도구(보안 기능, 성능, 키 관리 등을 분리하는 데 선호되는 옵션)를 사용하는 것입니다.

그런 다음 환경의 복잡성에 따라 트래픽 관리 도구를 구성합니다.

가장 일반적인 시나리오: Ingress Controller를 사용하는 E2EE

엔드포인트가 하나뿐인 앱(단순 앱 또는 Kubernetes로 "리프트 앤 시프트"한 모놀리식 앱)이 있거나

서비스 간 통신 이 없는 경우 Ingress 컨트롤러를 사용하여 Kubernetes 내에서 E2EE를 구현할 수 있습니다.

1단계: Ingress 컨트롤러가 서비스 측 인증서나 mTLS 인증서를 사용하여 암호화된 SSL/TLS 연결만 허용하는지 확인합니다

(이상적으로는 수신 및 송신 트래픽 모두에 적용).

2단계: 앱으로 전송하기 전에 Ingress 컨트롤러가 트래픽을 복호화하고 다시 암호화해야 하는 일반적인 기본 설정을 처리합니다.

이는 여러 가지 방법으로 수행할 수 있습니다. 선택하는 방법은 Ingress 컨트롤러와 요구 사항에 따라 달라집니다.

Ingress 컨트롤러가 SSL/TLS 패스스루를 지원하는 경우 SSL/TLS 인증서나 키에 대한 액세스를 요구하거나

암호를 해독하지 않고도 서비스 이름 표시(SNI) 헤더를 기반으로 SSL/TLS로 암호화된 연결을 라우팅할 수 있습니다.

2. 또는 SSL/TLS 종료를 설정할 수 있습니다. 이 경우 Ingress 컨트롤러가 트래픽을 종료한 다음 백엔드나 업스트림으로 프록시합니다.

이때 일반 텍스트로 프록시하거나 mTLS 또는 서비스 측 SSL/TLS로 Kubernetes 서비스에 대한 트래픽을 다시 암호화합니다.

덜 일반적인 시나리오: Ingress Controller 및 서비스 메시를 사용하는 E2EE

클러스터 내에 서비스 간 통신이 있는 경우 , Ingress 컨트롤러를 통한 ingress-egress 트래픽과

서비스 메시 를 통한 서비스 간 트래픽의 두 가지 평면에서 E2EE를 구현해야 합니다 .

E2EE에서 서비스 메시의 역할은 특정 서비스만 서로 통신할 수 있도록 하고, 이를 안전한 방식으로 수행하도록 하는 것입니다.

E2EE를 위한 서비스 메시를 설정할 때는 두 가지 요소를 통해 제로 트러스트 환경을 활성화해야 합니다.

서비스 간 mTLS(인증서가 필요하도록 설정)와 서비스 간 트래픽 액세스 제어(어떤 서비스가 통신할 수 있는지 지정)입니다.

이상적으로는 Kubernetes 클러스터 전체에서 진정한 E2EE 보안을 위해

애플리케이션(서비스 메시와 ingress-egress 컨트롤러에서 관리) 간에도 mTLS를 구현합니다.

전송 중에 노출된 데이터를 암호화하는 방법에 대한 자세한 내용은 NGINX 서비스 메시의 mTLS 아키텍처를 참조하세요 .

용례 : 신뢰할 수 있는 구현을 통해 클라이언트가 강력한 암호를 사용하고 있는지 확인

해결책: 연방 정보 처리 표준(FIPS) 준수

소프트웨어 산업에서 FIPS는 일반적으로 암호화에 대한 출판물인 FIPS PUB 140-2 암호화 모듈에 대한 보안 요구 사항을 말하며,

이는 미국과 캐나다의 공동 노력입니다.

이는 두 나라의 연방 기관에서 민감한 정보를 보호하기 위해 수용하는 암호화 모듈의 테스트 및 인증을 표준화합니다.

하지만 북미 정부 기관과 일하지 않기 때문에 FIPS에 관심이 없는 경우에도

산업이나 지역에 관계없이 FIPS를 준수하는 것은 현명한 선택이 될 수 있습니다.

FIPS는 사실상 글로벌 암호화 기준이기 때문입니다.

FIPS를 준수하는 것은 어려울 필요는 없지만 운영 체제와 관련 트래픽 관리 도구가 모두 FIPS 모드에서 작동할 수 있어야 합니다.

FIPS 준수는 단순히 운영 체제를 FIPS 모드로 실행하기만 하면 달성된다는 일반적인 오해가 있습니다.

운영 체제가 FIPS 모드이더라도 Ingress 컨트롤러와 통신하는 클라이언트가 강력한 암호를 사용하지 않을 수 있습니다.

FIPS 모드에서 작동할 때 운영 체제와 Ingress 컨트롤러는 일반적인 SSL/TLS 암호의 하위 집합만 사용할 수 있습니다.

Kubernetes 배포를 위한 FIPS 설정은 4단계 프로세스입니다.

1단계: FIPS 모드에 대한 운영 체제 구성
2단계: 운영 체제와 OpenSSL이 FIPS 모드인지 확인
3단계: Ingress 컨트롤러 설치
4단계: FIPS 상태 확인을 수행하여 FIPS 140-2 준수 여부를 확인합니다.

아래 예에서 NGINX Plus에서 사용하는 운영 체제와 OpenSSL 구현 모두에 FIPS 모드가 활성화된 경우, NGINX Plus에서 주고받는 모든 최종 사용자 트래픽은 검증된 FIPS 지원 암호화 엔진을 사용하여 복호화되고 암호화됩니다.

NGINX Plus를 통한 FIPS 규정 준수 달성 에서 FIPS에 대해 자세히 알아보세요 .

NGINX로 쿠버네티스를 더욱 안전하게 만드세요

이러한 보안 방법 중 일부(또는 전부)를 구현할 준비가 되었다면 도구에 사용 사례를 지원하는 데 적합한 기능과 역량이 있는지 확인해야 합니다. NGINX는 프로덕션에 적합한 Kubernetes 트래픽 관리 도구 모음으로 도움을 줄 수 있습니다.

NGINX Ingress Controller

Kubernetes용 NGINX Plus 기반 Ingress 컨트롤러로, 고급 트래픽 제어 및 셰이핑, 모니터링 및 가시성,

인증 및 SSO를 처리하고 API 게이트웨이 역할을 합니다.

F5 NGINX App Protect

F5의 시장을 선도하는 보안 기술을 기반으로 구축된 최신 앱과 API에 대한 전체적인 보호로,

NGINX Ingress Controller 및 NGINX Plus와 통합됩니다.

배포 시나리오의 유연성과 최적의 리소스 활용을 위해 모듈식 접근 방식을 사용합니다.

NGINX App Protect WAF

PCI DDS 규정을 준수하면서 OWASP Top 10 이상을 보호하는 강력하고 가벼운 WAF입니다.

NGINX App Protect DoS

클라우드와 아키텍처 전반에서 일관되고 적응적인 보호를 통해 동작 기반 DoS를 감지하고 완화합니다.

F5 NGINX 서비스 메시

가볍고, 턴키 방식이며, 개발자 친화적인 서비스 메시로, 엔터프라이즈 사이드카로 NGINX Plus를 제공합니다.

위 내용과 같이 NGINX Ingress Controller 및 NGINX App Protect WAF, DoS 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요

전문가에게 상담하기

7

NGINX Ingress Controller Version 2.0: What You Need to Know

관리자

2024-07-12

10월에 F5 NGINX Ingress Controller 버전 2.0(nginxinc/kubernetes-ingress)을 출시하여

Kubernetes 1.22와 Ingress API 버전 1(networking.k8s.io/v1)에 대한 지원을 추가했습니다.

쿠버네티스 릴리스가 중요한 이유는 무엇입니까?
Ingress API는 무엇이고 networking.k8s.io/v1로 업그레이드하는 것이 왜 중요한가요?
NGINX Ingress Controller 2.0은 현재 고객에게 어떤 영향을 미치나요?

2022년 1월 11일에 열리는 "Kubernetes 버전 공격에 대한 전투 계획" 에 대한 답변을 준비하면서,

F5 NGINX Ingress Controller 버전 2.0 (nginxinc/kubernetes-ingress)의

출시와 관련된 세 가지 상호 연관된 질문에 대해 자세히 설명드리겠습니다.

쿠버네티스 릴리스가 중요한 이유는 무엇입니까?

이 질문에 대한 답은 간단하면서도 복잡합니다.

Kubernetes의 호환성 관리가 어려운 이유는 Kubernetes 운영자가 세 가지 범주의 버전 관리를 관리해야 하기 때문입니다.

Kubernetes 플랫폼 자체 - Kubernetes 팀은 새로운 릴리스가 나올 때마다 이전 버전을 유지 관리하는 것을 중단합니다. 이러한 버전을 계속 사용하면 위험 관리 전략에 문제가 되고 Kubernetes 팀의 도움을 더 이상 받을 수 없기 때문에 문제 해결이 더 어려워집니다. 현재 Kubernetes 프로젝트는 가장 최근의 세 가지 마이너 릴리스(1.20, 1.21 및 1.22)에 대한 릴리스 브랜치를 유지 관리합니다. Kubernetes 1.19 이상은 약 1년 동안 패치 지원을 받는 반면 1.18 이하 버전은 약 9개월 동안 패치 지원을 받았습니다. (1.18 이하의 기간이 더 짧은 이유는 Kubernetes가 현재 3회가 아닌 1년에 4회 릴리스했기 때문입니다.)

Kubernetes API – 새 API는 각 Kubernetes 릴리스에서 탄생하고 폐기된 API는 사용되지 않으며, API의 변경 사항은 해당 리소스와 도구에 영향을 미칩니다. Kubernetes 플랫폼을 업그레이드할 때 API도 업그레이드해야 할 수 있습니다.
Kubernetes에 배포한 도구 – Kubernetes 또는 해당 API에 대한 주요 변경 사항은 Ingress 컨트롤러와 같은 도구와 해당 리소스가 계속해서 제대로 작동하는지에 영향을 미칠 수 있습니다.

따라서 Kubernetes, Ingress API, NGINX Ingress Controller의 세 가지 타임라인을 추적해야 합니다. Kubernetes를 깨지 않으려면 Kubernetes 버전이 API 및 NGINX Ingress Controller와 호환되는 적절한 지점을 찾아야 합니다. 호환성을 확인하지 않고 세 가지 구성 요소 중 하나를 업그레이드하면 엄청난 결과가 초래될 수 있습니다. 세 가지 구성 요소가 모두 서로 호환되지 않으면 축하드립니다. 어플리케이션이 Break 되셨습니다.

Ingress API는 무엇이고 networking.k8s.io/v1은 왜 중요한가요?

Ingress API를 사용하면 Ingress 컨트롤러가 Kubernetes 앱을 안전하게 노출할 수 있습니다. networking.k8s.io/v1 API(일명 Ingress API v1)는 Kubernetes 1.19에서 도입되었습니다. 당시 Kubernetes는 v1beta1과 v1을 모두 지원했으며, 한 버전을 다른 버전으로 자동 표시했습니다.

API 버전의 이러한 "은밀한" 호환성은 운영상 이점이 있지만 계획 노력을 방해할 수 있습니다.

Kubernetes 1.22가 출시되면서 v1이 Ingress API의 유일한 버전이 되었습니다. 이는 Ingress API v1이 "the one"이 되면서 모든 베타 버전(extensions/v1beta1 및 networking.k8s.io/v1beta1)이 더 이상 사용되지 않기 때문에 중요합니다. 아직 Ingress API v1을 채택하지 않은 조직에게는 혼란스러운 일이지만 NGINX에서는 이러한 변경을 좋은 신호로 봅니다. 베타에서 Ingress API로의 승격은 성숙하고 완전히 구현된 API로의 전환을 의미합니다. 이제 이러한 변경이 중요한 이유는 무엇일까요? 이는 버전 관리와 관련이 있습니다. 기존 클러스터를 Kubernetes 1.22로 업그레이드했지만 v1beta1 Ingress 관련 리소스를 계속 사용한다고 가정해 보겠습니다. 축하합니다. Ingress 리소스가 손상되었습니다!

NGINX Ingress Controller 2.0은 현재 고객에게 어떤 영향을 미칩니까?

NGINX Ingress Controller는 Ingress API와 긴밀하게 결합되어 있기 때문에 v1의 출시는 제품으로서 우리에게 큰 영향을 미쳤으며, 고객으로서 여러분에게도 영향을 미쳤습니다. 그래서 NGINX Ingress Controller 버전 번호를 1.x에서 2.x로 올렸습니다. NGINX Ingress Controller 2.0을 재구성하여 Ingress API v1을 활용하고 Kubernetes 1.22와 완벽하게 호환되도록 했습니다.

NGINX Ingress Controller를 사용하는 경우 Kubernetes, Ingress 리소스 또는 NGINX Ingress Controller가 손상되는 것을 방지하기 위해 버전에 따라 즉시 몇 가지 작업을 수행해야 합니다.

Kubernetes 1.18 및 이전 버전:

NGINX Ingress Controller 1.12를 사용하여 사용 가능한 모든 기능 세트를 활용하세요. (NGINX Ingress Controller 2.0으로 업그레이드하는 경우 Kubernetes 1.19 이상으로 업그레이드해야 합니다.)
Kubernetes 1.18은 다음 Kubernetes 릴리스 이후에는 지원되지 않으므로, 향후 몇 개월 내에 Kubernetes(및 NGINX Ingress Controller)의 최신 버전으로 마이그레이션하기 위한 계획을 세우세요.

쿠버네티스 1.19–1.21:

NGINX Ingress Controller 2.0으로 업그레이드하세요.
아직 Ingress 관련 리소스를 networking.k8s.io/v1로 마이그레이션하지 않았다면(NGINX Ingress Controller 2.0 릴리스 노트 참조) 지금 계획을 만드세요. Kubernetes 1.19–1.21은 Ingress API의 모든 현재 버전(v1beta1s 및 v1 모두)을 지원하여 제자리에서 변환할 수 있는 기회를 제공합니다.
아직 수행하지 않았다면 즉시 Ingress 및 IngressClass 리소스를 networking.k8s.io/v1로 이동하세요.
- Ingress 리소스에서 더 이상 사용되지 않는 kubernetes.io/ingress.class 어노테이션을 사용하는 경우 ingressClassName 필드로 전환하는 것이 좋습니다.
- 업데이트를 계획하려면 설명서와 예제(networking.k8s.io/v1 및 Ingress 리소스의 ingressClassName 필드에서 사용 가능)를 활용하세요.

쿠버네티스 1.22:

이전 버전의 NGINX Ingress Controller는 Kubernetes 1.22와 호환되지 않으며 Ingress API v1을 지원하지 않으므로 NGINX Ingress Controller 2.0을 이미 실행 중인지 확인하세요.

NGINX Ingress Controller의 (그다지) 간략하지 않은 역사

NGINX Ingress Controller는 2016년 첫 출시 이후, 신생 도구에서 Kubernetes 네트워킹의 강력한 도구로 성장했습니다.

출시부터 현재까지의 진화를 살펴보겠습니다.

2016 (v0.5.0)

NGINX 엔지니어 Michael Pleshakov가 GitHub repo(nginxinc/kubernetes-ingress)에 첫 번째 항목을 게시하여 NGINX와 F5 NGINX Plus를 Kubernetes Ingress 컨트롤러(KIC)로 사용할 수 있게 했습니다.

NGINX Ingress Controller가 KubeCon EU 2016에서 처음으로 대중에 공개되었습니다. 녹화 영상을 확인해 보세요:

1일차, NGINX를 사용하여 Kubernetes용 고급 부하 분산 솔루션 만들기; KubeCon EU 2016.

2017(v1.0.0)

이 프로젝트는 NGINX Plus 기반 버전에서 JSON 웹 토큰(JWT)에 대한 주요 지원을 포함하여 프로덕션에 적합한 상태를 달성했습니다.

NGINX Conf 2017에서 Michael Pleshakov는 Kubernetes의 부하 분산 애플리케이션을 위한 Ingress 컨트롤러로 NGINX Plus를 사용하여 고급 부하 분산을 포함한 프로덕션 기능을 시연했습니다.

2018

NGINX Ingress Controller는 가시성, 사용 편의성 및 유연성 측면에서 큰 개선을 보였습니다.

5월(v1.2.0) – 이 프로젝트는 새로운 NGINX Plus API를 채택하고 nginx-ingress 이미지를 공식 NGINX Docker Hub로 옮깁니다. 이 버전은 gRPC, 패시브 헬스 체크, Helm 차트, Prometheus에 대한 지원을 처음으로 선보입니다.
8월(v1.3.0) – NGINX Plus 고객은 이제 Prometheus로 메트릭을 내보내고 활성 상태 검사를 활용할 수 있으며, 모두가 Helm 차트 개선, 병합 가능한 Ingress 리소스, 사용자 정의 템플릿의 더 쉬운 관리의 혜택을 누릴 수 있습니다(Kubernetes 릴리스 1.3.0용 NGINX Ingress Controller 발표 참조).
11월(v1.4.0) – TCP/UDP 지원이 추가되어 레이어 4 트래픽 관리가 가능해졌습니다. 기타 기능으로는 사용자 지정 주석의 더 쉬운 개발과 Two Choices 부하 분산 알고리즘을 통한 Random 지원이 있습니다(Kubernetes 릴리스 1.4.0용 NGINX Ingress Controller 발표 참조).

NGINX Conf 2018에서 Michael Pleshakov는 NGINX를 Kubernetes Ingress Controller로 사용하는 방법에 대한 주제로 무대에 올라 Helm을 사용하여 NGINX Ingress Controller를 배포하는 방법, HTTP 및 TCP/UDP 부하 분산을 구성하는 방법, Prometheus로 모니터링하는 방법, 문제를 해결하는 방법을 공유합니다.

2019

Kubernetes Ingress 리소스를 대체하는 표준 리소스를 선보이며, 이를 통해 고급 기능을 더 쉽고 안정적으로 실행할 수 있게 되었습니다.

5월(v1.5.0) – VirtualServer 및 VirtualServerRoute(VS/VSR) 리소스가 새로운 구성 방식으로 도입되었습니다. VS/VSR은 최초의 NGINX Ingress 리소스로, Ingress 로드 밸런싱 구현을 간소화하는 네이티브, 유형 안전 및 들여쓰기 구성 스타일을 제공합니다(Kubernetes 릴리스 1.5.0용 NGINX Ingress Controller 발표<.htmla> 참조).
12월(v1.6.0) – docs.nginx.com에 문서가 작성되었습니다. VS/VSR 리소스는 더 풍부한 로드 밸런싱 지원을 추가하고 프로덕션 준비 상태에 도달합니다. OpenTracing 지원은 더 나은 모니터링 및 디버깅 사용 사례를 위해 추가되었으며, 루트가 아닌 사용자로 실행할 수 있는 기능이 보안을 개선하기 위해 추가되었습니다(Announcing NGINX Ingress Controller for Kubernetes Release 1.6.0 참조).

차세대 NGINX Ingress Controller에서 Michael Pleshakov는 NGINX Conf 2019에 복귀하여 블루-그린 배포 및 A/B 테스트를 포함한 사용 사례에 대한 VS/VSR을 시연합니다.

2020

NGINX Ingress 리소스에 대한 수많은 개선 사항 외에도 올해의 주요 주제는 생태계 도구 및 NGINX 제품과의 통합입니다.

4월(v1.7.0) – OpenShift 4.x 환경에서 NGINX Ingress Controller를 배포하는 빠르고 쉽고 인증된 방법을 제공하기 위해 NGINX Ingress Operator를 출시합니다. NGINX Ingress 리소스는 추가 프로토콜, 회로 차단기, 향상된 검증 및 보고에 대한 지원으로 계속 성장하고 있습니다(Kubernetes 릴리스 1.7.0용 NGINX Ingress Controller 발표 참조).
7월(v1.8.0) – F5 NGINX App Protect WAF와 통합하여 고객은 Ingress 컨트롤러와 동일한 컨테이너에 가볍고 유연한 WAF를 배포할 수 있습니다. 스니펫이나 사용자 정의 템플릿을 통한 NGINX Ingress 리소스의 사용자 정의가 추가되었으며, URI 재작성 및 액세스 제어 목록을 포함한 기능이 보다 세부적인 제어를 제공합니다(Kubernetes 릴리스 1.8.0용 NGINX Ingress 컨트롤러 발표 참조).
10월(v1.9.0) – F5 NGINX Service Mesh와 통합하여 동일한 구성에서 남북 및 동서 트래픽을 관리할 수 있습니다. Grafana 대시보드가 추가되어 과거 데이터를 쉽게 시각화할 수 있습니다(NGINX Ingress Controller 릴리스 1.9.0 발표 참조).

NGINX 및 OpenShift를 사용한 보안 프로덕션 앱에서는 기술 마케팅 엔지니어인 Amir Rawdat가 NGINX Ingress Operator를 사용하는 방법, 교차 기능 프로비저닝을 위한 역할 기반 액세스 제어(RBAC) 활용, NGINX App Protect를 사용하여 컨테이너화된 앱을 보호하는 방법, JWT를 사용하여 클라이언트를 검증하는 방법을 보여줍니다.

2021

보안은 많은 IT 생테계 통합에 있어 주요 주제입니다.

2월(v1.10.0) – OpenID Connect(OIDC) 인증이 주요 추가 기능으로, 이를 통해 JWT 인증을 사용하여 강력한 Single Sign‑On(SSO) 옵션을 제공하기 쉽습니다(OpenID Connect 및 NGINX Ingress Controller를 사용한 간편하고 강력한 Single Sign‑On 참조)
3월(v1.11.0) – WAF 및 부하 분산 정책에 대한 주요 개선 사항은 상태 검사 및 상태 보고를 포함하여 추가적인 성능과 유연성을 제공합니다(NGINX Ingress Controller를 사용한 향상된 TCP/UDP 부하 분산 및 WAF 구성 참조).
7월(v1.12.0) – 이 릴리스의 주요 내용은 모두 배포의 용이성에 관한 것입니다. AWS Container Marketplace를 통한 구매 외에도 F5 Container Registry에서 사전 빌드된 이미지를 가져올 수 있습니다(NGINX Is Available in AWS Marketplace for Containers 참조)
10월(v2.0.3) – 기능 면에서 주요 이정표는 아니지만, 이 릴리스는 Kubernetes API와의 상호 운용성 및 Ingress 객체의 진화에 대한 이정표를 나타냅니다. 이 변경 사항은 NGINX Ingress Controller 2.0(및 이후 버전)이 Kubernetes 1.19 이상과 호환됨을 의미합니다. NGINX Ingress Controller 2.0은 Kubernetes 1.22 이상과 함께 배포할 수 있는 유일한 버전이기도 합니다.

NGINX Sprint 2.0 세션인 '엔드 투 엔드 암호화를 사용한 마이크로서비스 마스터링'에서 소프트웨어 엔지니어인 Aidan Carson은 NGINX Ingress Controller를 사용하여 에지를 보호하는 방법, NGINX Service Mesh를 사용하여 서비스 간에 안전한 액세스 제어를 설정하는 방법, 두 제품을 모두 사용하여 mTLS를 사용하여 송신 트래픽을 보호하는 방법을 시연합니다.

다음 단계: NGINX Ingress Controller를 시도하세요

앱에 오픈소스 Ingress 컨트롤러가 적합하다고 결정했다면 GitHub 저장소에서 NGINX 오픈소스 기반 NGINX Ingress 컨트롤러를 사용하여 빠르게 시작할 수 있습니다. 대규모 프로덕션 배포의 경우 NGINX Plus 기반의 상용 NGINX Ingress Controller를 사용해 보시기 바랍니다.

위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요

전문가에게 상담받기

6

Kubernetes Networking 101

관리자

2024-07-12

NodePort, LoadBalancer, Ingress 컨트롤러...

고객&커뮤니티와 Kubernetes를 프로덕션 수준으로 만드는 것에 대해 이야기할 때 가장 흔한 질문 중 하나는 Ingress 컨트롤러가 필요한가입니다.

이 질문에 대한 답은 간단한 예 또는 아니요가 아닌 경우가 많지만, 대신 파드로 트래픽을 유도하는 다양한 방법에 대한 교육이 포함됩니다.

이 블로그에서는 Kubernetes 네트워킹의 기본 사항을 다루므로 Ingress 컨트롤러가 필요한지 여부와 언제 필요한지에 대한 정보에 입각한 결정을 내릴 수 있습니다.

쿠버네티스는 외부 트래픽을 파드로 라우팅하는 데 여러 가지 가능한 접근 방식과 계층을 지원하지만, 모두 동등하게 만들어진 것은 아닙니다.

기본 모델은 kube-proxy인데, 이는 실제로 프록시가 아니며 트래픽 부하 분산, API 제어 또는 서비스 동작 모니터링을 위해 설계되지 않았습니다.

(*참고 : 파드 - 파드(Pod) 는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다.)

다행히도 외부 트래픽을 관리하는 다른 방법이 있지만 계속하기 전에 Kubernetes 구성 요소를 간단히 살펴보겠습니다.

쿠버네티스 배포는 물리적 머신이나 가상 머신인 노드로 구성됩니다.
노드가 모여 클러스터를 형성합니다.
각 클러스터는 Kubernetes의 네트워킹 및 인프라 수준에서 가장 낮은 공통 분모인 파드를 관리합니다.
하나 이상의 파드가 함께 서비스를 구성합니다. 각 파드 내부에는 하나 이상의 컨테이너가 들어 있습니다 (애플리케이션 크기에 따라 다름).

쿠버네티스는 서비스를 구성하는 파드를 감시하고 앱 요구 사항에 맞게 필요에 따라 확장합니다.

하지만 파드로 트래픽을 가져오는 방법은 무엇일까요?

여기서 두 가지 유형의 쿠버네티스 객체가 등장합니다.

서비스와 Ingress 컨트롤러입니다.

쿠버네티스 서비스란?

Kubernetes 문서에 따르면 서비스는 "Pod 세트에서 실행되는 앱을 노출하는 추상적인 방법"입니다.

서비스는 특정 노드에서의 위치가 중요하지 않도록 클러스터 또는 컨테이너 네트워크의 Pod를 연결합니다.

즉, 위치가 변경되거나 파괴되고 다시 시작될 때에도 외부 트래픽을 특정 Pod로 라우팅할 수 있습니다.

이런 방식으로 서비스는 매우 기본적인 역방향 프록시와 매우 유사하게 작동합니다.

Kubernetes로 외부 트래픽을 라우팅하는 데 관련된 여러 유형의 서비스와 서비스 객체 유형이 있습니다.

이들은 종종 서로 혼동되지만 사실 각각은 매우 다른 일을 하므로 기능, 용도 및 단점을 살펴볼 가치가 있습니다.

클러스터IP

ClusterIP는 클러스터 내의 다른 서비스가 액세스할 수 있는 Kubernetes 내의 서비스를 제공하는 기본 서비스입니다.

클러스터 외부에서는 액세스할 수 없습니다.

ClusterIP 서비스를 노출하는 유일한 방법은 kube-proxy와 같은 것을 사용하는 것이지만 이것이 의미가 있는 시나리오는 거의 없습니다.

제한된 예로는 노트북에서 서비스에 액세스하거나, 서비스를 디버깅하거나, 모니터링 및 메트릭을 살펴보는 것이 있습니다.

노드포트

NodePort 서비스는 클러스터의 모든 노드에서 특정 포트를 열고 해당 포트의 노드로 전송된 모든 트래픽을 해당 앱으로 전달합니다.

이는 앱으로 트래픽을 가져오는 매우 기본적인 방법이며 실제 트래픽 관리 사용 사례에는 많은 제한이 있습니다.

NodePort당 하나의 서비스만 가질 수 있으며 30000~32767 범위의 포트만 사용할 수 있습니다.

2768개의 포트가 많은 것처럼 들릴 수 있지만 대규모로 Kubernetes를 실행하는 조직은 빠르게 고갈될 것입니다.

또한 NodePort는 레이어 4 라우팅 규칙과 Linux iptables 유틸리티를 사용하여 레이어 7 라우팅을 제한합니다.

라우팅 제한 외에도 NodePort를 사용하는 데에는 세 가지 큰 단점이 있습니다.

다운스트림 클라이언트는 연결하기 위해 각 노드의 IP 주소를 알아야 합니다.

노드의 IP 주소나 가상 머신 호스트가 변경되면 문제가 됩니다.

NodePort는 트래픽을 여러 IP 주소로 프록시할 수 없습니다.
다이어그램에서 보듯이 NodePort는 Kubernetes 클러스터 내에서 로드 밸런싱을 제공하지 않으므로 트래픽은 서비스 전체에 무작위로 분산됩니다.

이는 서비스 과부하 및 포트 고갈로 이어질 수 있습니다.

로드 밸런서

LoadBalancer 서비스는 외부 트래픽을 허용하지만 해당 트래픽의 인터페이스로 외부 로드 밸런서를 필요로 합니다.

이는 외부 로드 밸런서가 실행 중인 파드에 매핑되도록 적절히 조정되고 재구성된 경우 레이어 7 라우팅(파드 IP 주소로)을 지원합니다.

LoadBalancer는 서비스를 외부에 노출하는 가장 인기 있는 방법 중 하나입니다.

클라우드 플랫폼에서 가장 자주 사용되며 소규모 정적 배포에 적합한 선택입니다.

관리형 Kubernetes 서비스를 사용하는 경우 클라우드 공급자가 선택한 로드 밸런서를 자동으로 받게 됩니다.

예를 들어 Google Cloud Platform에서 LoadBalancer 서비스 유형을 사용하여 네트워크 로드 밸런서를 시작할 수 있는

반면, AWS에서는 Application Load Balancer(ALB)가 기본값입니다.

노출하는 각 서비스는 모든 트래픽을 전달하는 자체 공용 IP 주소를 받지만 필터링이나 라우팅은 없으므로

거의 모든 유형의 트래픽(HTTP, TCP/UDP, WebSocket 등)을 보낼 수 있습니다.

또는 클라우드 공급자의 툴링을 사용하지 않으려는 경우(예: 더 큰 기능이나 플랫폼에 독립적인 툴이 필요한 경우)

F5 BIG-IP(외부 로드 밸런서) 및 F5 Container Ingress Services(LoadBalancer 용량으로 작동하는 운영자)와 같은 것으로 대체할 수 있습니다.

이 패턴에 대한 자세한 내용은 블로그의 동일한 아키텍처에서 BIG-IP 및 NGINX Ingress Controller 배포를 참조하세요.

LoadBalancer를 사용하여 앱을 노출하는 것은 앱 파드가 변화하는 수요 수준에 맞춰 확장해야 하는 동적 환경에서는 어렵습니다.

각 서비스가 자체 IP 주소를 받기 때문에 인기 있는 앱은 수백 개 또는 수천 개의 IP 주소를 관리해야 할 수 있습니다.

대부분의 경우 외부 로드 밸런서는 다음 다이어그램에 표시된 대로 NodePort를 통해 서비스에 연결합니다.

이렇게 하면 트래픽이 노드 전체에 고르게 분산되지만

서비스에 대한 로드 밸런싱은 여전히 불가능하므로 여전히 서비스 과부하와 포트 고갈이 발생합니다.

Kubernetes Ingress 컨트롤러란 무엇인가요?

Kubernetes 문서에 따르면 "컨트롤러는 클러스터 상태를 감시한 다음 필요한 경우 변경을 하거나 요청하는 제어 루프입니다.

각 컨트롤러는 현재 클러스터 상태를 원하는 상태에 더 가깝게 옮기려고 시도합니다."

컨트롤러는 Kubernetes에서 여러 작업의 상태를 관리하는 데 사용됩니다. 리소스를 적절히 할당하고,

영구 저장소를 지정하고, cron 작업을 관리합니다.

라우팅 컨텍스트에서 Ingress 컨트롤러는 NodePort와 LoadBalancer의 한계를 극복하는 방법입니다.

Ingress 컨트롤러는 특정 서비스에 레이블이 지정된 파드와의 외부 상호 작용을 구성하고 관리하는 데 사용됩니다.

Ingress 컨트롤러는 동적 레이어 7 라우팅을 일류 시민으로 처리하도록 설계되었습니다.

즉, Ingress 컨트롤러는 훨씬 더 세부적인 제어 및 관리의 수고로움이 덜 합니다.

Ingress 컨트롤러를 사용하면 Ingress 트래픽을 제어할 뿐만 아니라

서비스 수준 성능 메트릭을 제공하고 보안 정책의 일부로 사용할 수도 있습니다.

Ingress 컨트롤러는 TLS 종료, 여러 도메인 및 네임스페이스 처리는 물론

트래픽 로드 밸런싱과 같은 기존 외부 로드 밸런서의 많은 기능을 제공합니다.

Ingress 컨트롤러는 서비스 수준이 아닌 요청별로 트래픽을 로드 밸런싱할 수 있으며,

레이어 7 트래픽을 보다 유용하게 볼 수 있고 SLA를 시행하는 훨씬 더 나은 방법입니다.

그리고 또 다른 보너스가 있습니다.

Ingress 컨트롤러는 특정 파드에서 특정 외부 서비스로만 나가는 트래픽을 허용하는 egress 규칙을 시행하거나,

트래픽이 mTLS를 사용하여 상호 암호화되도록 할 수도 있습니다.

mTLS를 요구하는 것은 의료, 금융, 통신, 정부와 같은 산업에서 규제된 서비스를 제공하는 데 필수적이며,

종단 간 암호화(E2EE) 전략의 핵심 구성 요소입니다.

동일한 도구에서 나가는 트래픽을 제어하면 서비스에 대한 비즈니스 로직의 적용도 간소화됩니다.

Ingress와 Egress가 모두 동일한 제어 평면에 연결되어 있으면 적절한 리소스 규칙을 설정하는 것이 훨씬 쉽습니다.

다음 다이어그램은 Ingress 컨트롤러가 클라이언트의 복잡성을 줄이는 방법을 보여줍니다.

클라이언트는 더 이상 서비스의 IP 주소나 포트를 알 필요가 없습니다.

서비스 전체에 걸친 트래픽 분산이 보장됩니다.

일부 Ingress 컨트롤러는 더 많은 유연성과 제어를 위해 여러 로드 밸런싱 알고리즘을 지원합니다.

Ingress 컨트롤러를 사용하여 로드 밸런서 배포

동일한 아키텍처에서 BIG-IP 및 NGINX Ingress 컨트롤러 배포에서 논의했듯이

많은 조직에서 Ingress 컨트롤러(또는 대부분의 경우 여러 Ingress 컨트롤러 인스턴스)와

함께 외부 로드 밸런서를 배포하는 데 이점이 있는 사용 사례가 있습니다.

이는 조직에서 Kubernetes를 확장하거나 고도로 규정을 준수하는 환경에서 운영해야 할 때 특히 일반적입니다.

이러한 도구는 일반적으로 여러 팀에서 관리하고 다양한 목적으로 사용됩니다.

1. 로드 밸런서(또는 ADC)

소유자: NetOps(또는 SecOps) 팀

사용 사례: 클러스터 외부의 사용자에게 제공되는 서비스와 앱에 대한 유일한 공개 엔드포인트로서 Kubernetes 외부 보안을 용이하게 하고

상위 수준의 네트워크 관리를 제공하도록 설계된 보다 일반적인 어플라이언스로 사용됨.

2. 인그레스 컨트롤러

소유자: 플랫폼 운영 또는 DevOps 팀

사례: 북쪽에서 남쪽으로의 트래픽(HTTP2, HTTP/HTTPS, SSL/TLS 종료,

TCP/UDP, WebSocket, gRPC)의 세분화된 부하 분산, API 게이트웨이 기능, 중앙 집중식 보안 및 ID를 위한 Kubernetes 내부.

이 다이어그램은 여러 클러스터에 걸쳐 트래픽을 분산하는 로드 밸런서를 보여 주며,

클러스터에는 서비스에 균등하게 분산되도록 Ingress 컨트롤러가 있습니다.

위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요

전문가와 상담하기

5

Red Hat OpenShift 에서 NGINX Ingress Controller 성능 테스트

관리자

2024-07-12

Red Hat OpenShift Container Platform(OCP)은 가장 인기 있는 관리형 Kubernetes 플랫폼 중 하나이며,

경쟁사와 마찬가지로 OCP에는 사용자가 빠르게 시작할 수 있도록 돕는 기본 트래픽 관리 툴링이 포함되어 있습니다.

HAProxy를 기반으로 하는 OCP 라우터는 OCP 클러스터의 기본 진입점입니다.

HTTP 및 WebSocket 트래픽을 로드 밸런싱하고, 라우터와 애플리케이션 인스턴스 간의 TLS 종료 및 TLS를 지원하며,

Pass-Through Mode에서 TLS 연결을 로드 밸런싱할 수 있습니다.

고객들은 종종 "라우터를 무료로 사용할 수 있는데

OpenShift에서 NGINX Ingress Controller를 왜 사용해야 합니까?" 라고 묻습니다.

게스트 블로거인 GigaOm의 Max Mortillaro 는 OpenShift에서 Enterprise‑Grade Ingress Controller가 필요한 이유로

NGINX Ingress Controller를 사용하려는 몇 가지 정성적 이유를 공유합니다.

> 고급 트래픽 관리 / 사용 편의성 / JWT 검증 및 WAF 통합

하지만 이 질문에 정량적 관점에서 답하는 것도 중요합니다.

이것이 우리가 OCP 환경에서 라우터와 NGINX Plus 기반 NGINX Ingress Controller (nginxINC/Kubernetes-Ingress) 의

성능 테스트를 실시한 이유이며, 테스트 중에 업스트림(백엔드) 서버의 수를 늘리거나 줄이는

동적 배포 또한 실시한 이유입니다.

성능 테스트를 수행할 때 우리는 도구의 성능을 평가하기 위해 두 가지 요소를 살펴봅니다.

요인 1: 동적 배포에 대한 대기 시간 결과

동적 배포에서 최종 사용자 경험을 측정하는 데 가장 효과적인 지표는 대기 시간 백분위수 분포라는 것을 알게 되었습니다.

시스템에서 대기 시간을 더 많이 추가할수록 사용자 경험에 미치는 영향이 커집니다.

또한 사용자 경험에 대한 진정한 그림을 얻으려면 분포에서 상위 백분위수의

대기 시간을 포함해야 한다는 것을 알게 되었습니다.

자세한 설명은 블로그의 NGINX 및 HAProxy 의 클라우드에서 사용자 경험 테스트의 성능 결과 섹션을 참조하세요.

요인 2: 타임아웃 및 오류

테스트 중인 시스템이 동적 배포에서 지연을 유발하는 경우,

일반적으로 시스템이 동적 다시 로드를 처리하는 데 문제가 있거나 시간 초과 또는 오류가 발생하기 때문입니다.

성능 테스트 결과

흥미로운 부분으로 바로 들어가서 결과를 검토해 보겠습니다.

테스트 토폴로지와 방법 에 대한 세부 사항은 다음과 같습니다.

위에서 설명한 대로 성능을 평가할 때는 지연 시간과 시간 초과/오류라는 두 가지 요소를 고려합니다.

요인 1: 지연 백분위수 분포

다음 차트에서 알 수 있듯이 NGINX Ingress Controller는 테스트 내내

무시할 수 있는 지연 시간을 추가했으며, 99.999번째 백분위수에서 최대 700ms 미만에 도달했습니다.

반면, OCP 라우터는 상당히 낮은 백분위수에서 지연 시간을 추가했으며,

지연 시간은 기하급수적으로 증가하여 99.99번째 백분위수에서 25,000ms(25초)가 조금 넘는 지점에서 정점에 도달했습니다.

이는 클러스터 환경의 변경 사항이 자주 적용되는 동안 부하가 걸리면

라우터가 사용자 경험을 저하시킬 수 있음을 보여줍니다.

요인 2: 타임아웃 및 오류

위에서 관찰된 지연은 시간 초과 및 오류에 기인할 수 있습니다.

OCP 라우터는 260개의 연결 시간 초과와 85개의 읽기 소켓 오류를 생성한

반면 NGINX Ingress 컨트롤러는 아무것도 생성하지 않았습니다.

다른 성능 테스트에서 보았듯이(동적 Kubernetes 클라우드 환경에서 NGINX Ingress 컨트롤러 성능 테스트 참조),

라우터의 시간 초과 및 오류는 HAproxy가 동적 다시 로드를 처리하는 방식으로 인해 발생합니다.

NGINX Plus 기반 NGINX Ingress 컨트롤러는 엔드포인트가 변경될 때

NGINX Plus API를 사용하여 NGINX 구성을 동적으로 업데이트하기 때문에

시간 초과나 오류를 발생시키지 않습니다 .

테스트 설정 및 방법론

토폴로지 테스트

우리는 테스트 대상 시스템(SUT)으로서 NGINX Ingress Controller와 OpenShift Router에서 동일한 테스트를 실행했습니다.

SUT는 클라이언트에서 TLS 1.3 연결을 종료하고 클라이언트 요청을 별도의 연결을 통해 백엔드 배포로 전달했습니다.

클라이언트는 OpenShift 클러스터와 동일한 LAN에 위치한, CentOS 7을 실행하는 별도의 머신에 호스팅되었습니다.

SUT와 백엔드 배포는 VMware vSphere 6.7.0.45100에 호스팅된 OCP 클러스터에서 실행되었습니다.

TLS 암호화의 경우, 2048비트 키 크기와 완벽한 순방향 비밀성을 갖춘 RSA를 사용했습니다 .

백엔드 애플리케이션의 각 응답은 HTTP 상태 코드 와 함께 약 1KB 의 기본 서버 메타데이터로 구성되었습니다. 200 OK

테스트 방법론

클라이언트 배포

wrk2 (버전 4.0.0)를 사용하여 클라이언트 머신에서 다음 스크립트를 실행하고, 초당 1000개 요청(RPS, 옵션으로 설정)의 일정한 처리량으로 60초 동안(옵션으로 설정) 테스트 -d를-R 실행했습니다 .

./wrk -t 2 -c 50 -d 60s -R 1000 -L https://ingress-url:443/

사용된 SUT 소프트웨어

기본적으로 HAProxy 기반 라우터를 포함하는 OpenShift Platform 버전 4.8
NGINX Ingress 컨트롤러 버전 1.11.0 (NGINX Plus R22)

백엔드 배포

다음 스크립트를 사용하여 백엔드 복제본의 수를 주기적으로 늘리거나 줄이는 백엔드 애플리케이션의 동적 배포로 테스트 실행을 수행했습니다. 이는 동적 OpenShift 환경을 에뮬레이트하고 NGINX Ingress Controller 또는 OCP 라우터가 엔드포인트 변경에 얼마나 효과적으로 적응하는지 측정합니다.

while [ 1 -eq 1 ]
 do  oc scale deployment nginx-backend --replicas=4    
 sleep 10   
 oc scale deployment nginx-backend --replicas=2  
 sleep 10
done

결론

마이크로서비스 방법론을 채택하는 대부분의 회사는 그 어느 때보다 더 높은 빈도로 CI/CD 파이프라인을 통해 새로운 개발을 추진하고 있습니다.

이러한 이유로 최종 사용자 경험을 방해하지 않으면서

이러한 새로운 방법론의 역량과 성능에 따라 성장하는 데이터 플레인을 활용하는 것이 중요합니다.

최적의 최종 사용자 경험을 제공하려면 모든 상황에서 모든 클라이언트 연결에 대해 지속적으로 낮은 지연 시간을 제공해야 합니다.

성능 결과에 따르면, NGINX Ingress Controller는 개발을 반복하고 개선해야 할 필요성이 높은 컨테이너화된 환경에서

최적의 최종 사용자 경험을 제공합니다.

시작하려면 NGINX Ingress Controller의 무료 평가판을 다운로드하고 NGINX Ingress Operator를 사용하여 배포하는 방법을 알아보세요 .

위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요

전문가에게 상담받기