블로그 | NGINX

NGINX Ingress Controller의 심층적인 서비스 통찰력으로 더 나은 의사 결정 내리기

NGINX-F5-수평-검정-유형-RGB의 일부
아카쉬 아난타나라야난 썸네일
아카쉬 아난타나라야난
2023년 4월 6일 게시

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 , UDPgRPC 서비스에 대한 주기적 수동 상태 검사를 전송하고, 요청 응답성을 모니터링하고, 성공적인 응답 코드와 기타 메트릭을 추적하여 클러스터의 업스트림 포드 상태를 모니터링하고 있습니다. 이 정보를 사용하면 일관적이고 예측 가능한 사용자 경험을 제공하기 위해 서비스의 포드 전반에 트래픽을 분산하는 방법을 결정합니다. 일반적으로 NGINX Ingress Controller는 이 모든 마법 같은 일을 백그라운드에서 조용히 수행하고 있기 때문에, 무슨 일이 일어나고 있는지 전혀 생각해 보지도 못할 수도 있습니다. Deep Service Insight는 이러한 귀중한 정보를 "표면화"하여 스택의 다른 계층에서 보다 효과적으로 활용할 수 있도록 합니다.

심층적 서비스 통찰력은 어떻게 작동하나요?

Deep Service Insight는 NGINX VirtualServerTransportServer 사용자 정의 리소스(각각 HTTP 및 TCP/UDP용)를 사용하여 배포하는 서비스에 사용할 수 있습니다. Deep Service Insight는 NGINX Plus API를 사용하여 Deep Service Insight에만 있는 전용 엔드포인트에서 백엔드 서비스의 개별 Pod에 대한 NGINX Ingress Controller의 뷰를 공유합니다.

  • VirtualServer의 경우 – <IP 주소> :<포트> /조사/<호스트 이름>
  • TransportServer의 경우 – <IP 주소> :<포트> /프로브/ts/<서비스 이름>

어디

  • <IP 주소> NGINX Ingress Controller에 속함
  • <포트> Deep Service Insight 포트 번호입니다(기본값은 9114)
  • <호스트 이름> 는 서비스의 도메인 이름입니다. spec.host VirtualServer 리소스의 필드
  • <서비스 이름> 는 정의된 서비스의 이름입니다. 사양.업스트림.서비스 TransportServer 리소스의 필드

출력에는 두 가지 유형의 정보가 포함됩니다.

  1. 호스트 이름 또는 서비스 이름에 대한 HTTP 상태 코드:

    • 200 확인 – 적어도 하나의 포드가 정상입니다.
    • 418 나는 찻주전자 입니다 . 포드는 건강에 좋지 않습니다.
    • 404 찾을 수 없음 – 지정된 호스트 이름 또는 서비스 이름과 일치하는 포드가 없습니다.
  2. 지정된 호스트 이름 또는 서비스 이름에 대한 세 개의 카운터:

    • 서비스 인스턴스(포드)의
    • Up (건강) 상태의 포드 수
    • 건강하지 않은 상태의 포드 수

다음은 서비스의 세 개의 포드가 모두 정상인 예입니다.

HTTP/1.1 200 OKContent-Type: application/json; charset=utf-8 날짜:  , 일, 월, 년, 월, 일, 시, 분, 토 , 일 ,  , 일 ... 32 {"전체":3,"상승":3,"건강에 해롭다":0}

자세한 내용은 NGINX Ingress Controller 설명서를 참조하세요.

활성 상태 검사를 구성하여 NGINX Ingress Controller가 Pod가 정상인지 판단하는 데 사용하는 기준을 추가로 사용자 지정할 수 있습니다. 상태 검사를 보낼 경로와 포트, 포드가 비정상으로 간주되기 위해 지정된 기간 내에 발생해야 하는 검사 실패 횟수, 예상 상태 코드, 연결 또는 응답 수신에 대한 시간 초과 등을 구성할 수 있습니다. VirtualServer 또는 TransportServer 리소스에 Upstream.Healthcheck 필드를 포함합니다.

심층적인 서비스 통찰력을 위한 샘플 사용 사례

Deep Service Insight가 특히 가치 있는 사용 사례 중 하나는 로드 밸런서가 고가용성을 위해 두 클러스터에서 실행되는 서비스로 트래픽을 라우팅하는 경우입니다. 각 클러스터 내에서 NGINX Ingress Controller는 위에 설명된 대로 업스트림 Pod의 상태를 추적합니다. Deep Service Insight를 활성화하면 정상 및 비정상 업스트림 Pod의 수에 대한 정보도 전용 엔드포인트에 노출됩니다. 라우팅 결정 시스템은 엔드포인트에 액세스하고 해당 정보를 사용하여 애플리케이션 트래픽을 건강에 해로운 Pod에서 건강한 Pod로 전환할 수 있습니다.

이 다이어그램은 이 시나리오에서 Deep Service Insight가 작동하는 방식을 보여줍니다.

NGINX Ingress Controller가 전용 Deep Service Insight 엔드포인트에서 Kubernetes Pod 상태에 대한 정보를 제공하는 방식을 보여주는 다이어그램으로, 라우팅 결정 시스템이 이를 사용하여 Tea 서비스 Pod가 정상적이지 않은 클러스터에서 트래픽을 다른 곳으로 전환합니다.

고가용성 시나리오에서 클러스터에 대한 유지 관리를 수행할 때 Deep Service Insight를 활용할 수도 있습니다. 유지 관리를 수행하는 클러스터에서 서비스에 대한 포드 수를 0으로 줄이기만 하면 됩니다. 정상적인 포드가 없는 경우 Deep Service Insight 엔드포인트에 자동으로 표시되고 라우팅 결정 시스템은 해당 정보를 사용하여 다른 클러스터에 있는 정상적인 포드로 트래픽을 전송합니다. NGINX Ingress Controller나 시스템의 구성을 변경하지 않고도 효과적으로 자동 장애 조치를 구현할 수 있으며, 고객은 서비스 중단을 경험하지 않습니다.

심층적인 서비스 통찰력 활성화

Deep Service Insight를 활성화하려면 Kubernetes 매니페스트에 -enable-service-insight 명령줄 인수를 포함하거나 Helm을 사용하는 경우 serviceInsight.create 매개변수를 true 로 설정합니다.

사용자 환경에 맞게 엔드포인트를 조정하기 위해 포함할 수 있는 두 가지 선택적 인수가 있습니다.

  • -service-insight-listen-port <포트> – Deep Service Insight 포트 번호를 기본값인 9114에서 변경합니다( <포트> 는 1024–65535 범위의 정수입니다). Helm의 경우 serviceInsight.port 매개변수가 이에 해당합니다.
  • -서비스-인사이트-tls-문자열 <비밀> – Deep Service Insight 엔드포인트의 TLS 종료를 위한 Kubernetes 비밀(TLS 인증서 및 키)<비밀> 형식이 있는 문자열입니다. <네임스페이스>/<비밀_이름>). Helm의 경우 serviceInsight.secret 매개변수가 이에 해당합니다.

예: 카페 애플리케이션에 대한 심층적 서비스 통찰력 활성화

Deep Service Insight가 실제로 어떻게 활용되는지 확인하려면 NGINX Ingress Controller 설명서에서 예로 자주 사용되는 Cafe 애플리케이션 에서 이를 활성화하면 됩니다.

  1. NGINX 사용자 정의 리소스를 지원하고 Deep Service Insight를 활성화하는 NGINX Ingress Controller의 NGINX Plus 버전을 설치합니다.

    • Helm을 사용하는 경우 serviceInsight.create 매개변수를 true 로 설정합니다.
    • Kubernetes 매니페스트 (Deployment 또는 DaemonSet)를 사용하는 경우 매니페스트 파일에 -enable-service-insight 인수를 포함합니다.
  2. NGINX Ingress Controller가 실행 중인지 확인하세요.

    $ kubectl get pods -n nginx-ingress 이름 준비 ... ingress-plus-nginx-ingress-6db8dc5c6d-cb5hp 1/1 ... ...  상태가 다시 시작됩니다.  러닝 0 9d
  3. README 의 지침에 따라 Cafe 애플리케이션을 배포합니다.
  4. NGINX VirtualServer 사용자 정의 리소스가 Cafe 애플리케이션에 배포되었는지 확인합니다(IP 주소는 읽기 쉽도록 생략).

    $ kubectl get vs NAME STATE HOST IP PORTS AGE cafe 유효한 cafe.example.com ... [80,443] 7h1m
  5. cafe.example.com 에서 실행되는 Cafe 서비스에 대해 세 개의 업스트림 포드가 있는지 확인하세요.

    $ kubectl get pods 이름 준비 상태 재시작 나이 coffee-87cf76b96-5b85h 1/1 실행 중 0 7시간 39분 coffee-87cf76b96-lqjrp 1/1 실행 중 0 7시간 39분 tea-55bc9d5586-9z26v 1/1 실행 중 0 111분
  6. Deep Service Insight 엔드포인트에 액세스하세요.

    $ 컬 -i <NIC_IP_주소>:9114/프로브/카페.예제.com

    그만큼 200OK 응답 코드는 서비스가 트래픽을 수용할 준비가 되었음을 나타냅니다(적어도 하나의 Pod가 정상 상태임). 이 경우 세 개의 포드 모두 Up 상태입니다.

    HTTP/1.1 200 OK 콘텐츠 유형: application/json; 문자 집합=utf-8 날짜:  , 일, 월, 년, 월, 일, 시, 분, 토, 일, 화, 목 ,... 32 {"전체":3,"상승":3,"건강에 해롭다":0}

    그만큼 418'나는 티포트 입니다 ' 상태 코드는 서비스를 이용할 수 없음(모든 포드가 정상적이지 않음)을 나타냅니다.

    HTTP/1.1 418 나는 찻주전자입니다. 콘텐츠 유형: application/json; 문자 집합=utf-8 날짜:  , 일, 월, 년, 월, 일, 시, 분, 토 , 일 ,  , 일 ... 32 {"전체":3,"상승":0,"건강에 해롭다":3}

    그만큼 404찾을 수 없음 상태 코드는 지정된 호스트 이름에서 실행 중인 서비스가 없음을 나타냅니다.

    HTTP/1.1 404 찾을 수 없음날짜:  , 일, 월, 년, 월, 일, 시, 분, 토 , 일 ,  , 일 ... 0

리소스

NGINX Ingress Controller 릴리스 3.0.0의 전체 변경 사항은 릴리스 노트를 참조하세요.

NGINX Plus와 NGINX App Protect와 함께 NGINX Ingress Controller를 사용해 보려면 오늘 30일 무료 평가판을 시작하거나 당사에 문의하여 사용 사례에 대해 논의해 보세요 .


"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."