NGINX Ingress Controller의 심층적인 서비스 인사이트로 더 나은 의사결정 내리기

Akash Ananthanarayanan기술 마케팅 매니저 | F5 NGINX

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는 백엔드 서비스 Pod의 상태 정보(NGINX Ingress Controller에서 수집)를 전용 엔드포인트를 통해 제공하여 이 문제를 해결합니다. 시스템은 이 엔드포인트에 액세스해 해당 정보를 활용함으로써 더 나은 라우팅 결정을 내릴 수 있습니다.

이 게시물에서는 Deep Service Insight가 해결하는 문제를 심층적으로 살펴보고, 몇 가지 일반적인 사용 사례에서 어떻게 작동하는지 설명한 다음, 구성 방법을 보여드립니다.

왜 Deep Service Insight인가?

표준 Kubernetes 활성, 준비 상태 및 시작 프로브를 통해 클러스터에서 실행 중인 백엔드 서비스에 관한 일부 정보를 얻을 수 있지만, 전체 스택에서 더 나은 라우팅 결정을 내리는 데 필요한 수준의 인사이트를 확보하기에는 충분하지 않습니다. Kubernetes 배포가 복잡해지고 중단 없는 가동 시간에 대한 비즈니스 요구가 더욱 절실해질수록 적절한 정보의 부재는 더 큰 문제가 됩니다.

Kubernetes 환경을 확장하면서 가동 시간을 개선하기 위해 흔히 사용하는 방법은 클러스터 앞단에 로드 밸런서, DNS 관리자 및 기타 자동화된 의사 결정 시스템을 배포하는 것입니다. 그러나 Ingress 컨트롤러의 작동 방식 때문에 Kubernetes 클러스터 앞단에 있는 로드 밸런서는 일반적으로 클러스터 내 Ingress 컨트롤러 뒤에 있는 서비스의 상태 정보에 접근할 수 없으며, Ingress 컨트롤러 Pod 자체가 정상적으로 작동하고 트래픽을 수신하고 있는지만 확인할 수 있습니다.

반면 NGINX Ingress Controller는 서비스 상태 정보를 파악하고 있습니다. 클러스터의 업스트림 Pod 상태를 모니터링하기 위해 HTTP, TCP, UDP, gRPC 서비스에 주기적으로 수동 상태 검사를 수행하고, 요청 응답성을 모니터링하며, 성공 응답 코드와 기타 메트릭을 추적합니다. 이 정보를 바탕으로 서비스의 Pod에 트래픽을 분산하는 방식을 결정하여 일관되고 예측 가능한 사용자 경험을 제공합니다. 일반적으로 NGINX Ingress Controller는 이 모든 작업을 백그라운드에서 조용히 수행하므로, 내부에서 어떤 일이 일어나는지 전혀 신경 쓰지 않을 수도 있습니다. Deep Service Insight는 이 유용한 정보를 외부로 드러내어 스택의 다른 계층에서 더욱 효과적으로 활용할 수 있게 해 줍니다.

Deep Service Insight은 어떻게 작동하나요?

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

• VirtualServer의 경우 – <IP_address> :<port> /probe/<hostname>
• TransportServer의 경우 – <IP_address> :<port> /probe/ts/<service_name>

여기서

• <IP_address>는 NGINX Ingress Controller에 속합니다
• <port>는 Deep Service Insight 포트 번호입니다(기본값: 9114).
• <hostname>은(는) VirtualServer 리소스의 spec.host 필드에 정의된 서비스의 도메인 이름입니다.
• <service_name>은(는) TransportServer 리소스의 spec.upstreams.service 필드에 정의된 서비스 이름입니다

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

1. 호스트 이름 또는 서비스 이름에 대한 HTTP 상태 코드:
   • 200 OK – 하나 이상의 Pod가 정상 상태입니다
   • 418 나는 주전자 입니다 – 정상 상태인 파드가 없습니다
   • 404 찾을 수 없음 Found – 지정된 호스트 이름 또는 서비스 이름과 일치하는 파드가 없습니다
2. 지정된 호스트 이름 또는 서비스 이름에 대한 세 가지 카운터:
   • 전체 서비스 인스턴스(pod) 수
   • Number of pods in the Up 상태(정상)인 파드 수
   • Number of pods in the 비정상 상태인 파드 수

서비스의 세 개 파드가 모두 정상인 경우의 예는 다음과 같습니다:

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가 Pod의 정상 여부를 판단하는 기준을 더욱 세부적으로 조정할 수 있습니다. 상태 확인을 전송할 경로와 포트, 지정된 기간 내에 Pod를 비정상으로 간주하기 위해 발생해야 하는 상태 확인 실패 횟수, 예상 상태 코드, 연결 또는 응답 수신 제한 시간 등을 구성할 수 있습니다. Upstream.Healthcheck 필드를 VirtualServer 또는 TransportServer 리소스에 포함하세요.

심층 서비스 인사이트 활용 사례

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

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

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

Deep Service Insight 활성화

Deep Service Insight를 활성화하려면 Kubernetes 매니페스트에 -enable-service-insight 명령줄 인수를 포함하거나, 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입니다.

예: Cafe 애플리케이션에 Deep Service Insight 사용 설정

Deep Service Insight의 실제 작동 방식을 확인하려면 NGINX Ingress Controller 설명서에서 예제로 자주 사용되는 Cafe 애플리케이션에 이 기능을 사용하도록 설정할 수 있습니다.

1. NGINX 사용자 지정 리소스를 지원하고 Deep Service Insight를 활성화하도록 NGINX Ingress Controller의 NGINX Plus 에디션을 설치합니다:
   • If using Helm을 사용하는 경우 serviceInsight.create 매개변수를 true로 설정합니다.
   • If using a Kubernetes 매니페스트(Deployment 또는 DaemonSet)를 사용하는 경우 매니페스트 파일에 -enable-service-insight 인수를 포함합니다.
2. NGINX Ingress Controller가 실행 중인지 확인합니다:

$ kubectl get pods -n nginx-ingressNAME                                          READY ...
ingress-plus-nginx-ingress-6db8dc5c6d-cb5hp   1/1   ...  

    ...  STATUS   RESTARTS   AGE
    ...  Running   0          9d

1. 다음의 README에 있는 지침에 따라 Cafe 애플리케이션을 배포합니다.
2. Cafe 애플리케이션용 NGINX VirtualServer 사용자 지정 리소스가 배포되었는지 확인합니다(가독성을 위해 IP 주소는 생략됨):

$ kubectl get vs NAME   STATE   HOST               IP    PORTS      AGE
cafe   Valid   cafe.example.com   ...   [80,443]   7h1m

1. 다음 주소에서 실행 중인 Cafe 서비스의 업스트림 Pod가 3개인지 확인합니다: cafe.example.com:

$ 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

1. Deep Service Insight 엔드포인트에 액세스합니다:

$ curl -i <NIC_IP_address>:9114/probe/cafe.example.com

1. The 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}

1. The 418 I’m a teapot 상태 코드는 서비스를 사용할 수 없음을 나타냅니다(모든 파드가 비정상 상태임).

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}

1. The 404 Not Found 상태 코드는 지정된 호스트 이름에서 실행 중인 서비스가 없음을 나타냅니다.

HTTP/1.1 404 Not FoundDate: Day, DD Mon YYYY hh:mm:ss TZ
Content-Length: 0

리소스

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

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

작성자 소개

Akash Ananthanarayanan기술 마케팅 매니저 | F5 NGINX

Akash Ananthanarayanan의 다른 블로그 게시물