K8s Ingress Controller – Deep Service Insight(인사이트)

NGINX Ingress Controller Deep Service Insight는 Load Balancer와 같은 라우팅 결정 시스템이 하나 이상의 Kubernetes 클러스터 앞에 위치할 때 최적의 기능을 방해하는 제한 사항, 즉 시스템이 클러스터에서 실행 중인 서비스의 상태에 대한 정보에 액세스할 수 없다는 한계를 해결합니다. 따라서 트래픽을 정상 Pod로만 라우팅하지 못하여 사용자가 404 및 500과 같은 중단 및 오류에 노출될 가능성이 있습니다.

Deep Service Insight는 시스템이 더 나은 라우팅 결정을 위해 액세스하고 사용할 수 있는 전용 Endpoint에 Backend 서비스 Pod의 상태(NGINX Ingress Controller 에 의해 수집됨)를 Expose 하여 이러한 문제를 해결합니다.

이번 포스트에서는 Deep Service Insight로 해결되는 문제를 자세히 살펴보고, 몇 가지 일반적인 사용 사례에서 어떻게 작동하는지 설명하며, 구성하는 방법을 보여드립니다.

목차

1. 왜 Ingress Controller Deep Service Insight인가?
2. Ingress Controller Deep Service Insight는 어떻게 작동하나요?
2-1. Deep Service Insight의 샘플 사용 사례
3. Ingress Controller Deep Service Insight 활용
3-1. 예제: Cafe 애플리케이션에 대한 Deep Service Insight 활성화하기

1. 왜 Ingress Controller Deep Service Insight인가?

표준 Kubernetes 활성 상태, 준비 상태, 시작 Probe는 클러스터에서 실행 중인 Backend 서비스에 대한 일부 정보를 제공하지만, 더 나은 라우팅 결정을 내리는 데 필요한 Insight를 얻기에는 충분하지 않습니다. 올바른 정보가 부족하면 Kubernetes 배포가 복잡해지고 중단 없는 가동 시간에 대한 비즈니스 요구 사항이 더욱 시급해지면서 문제가 더욱 심각해집니다.

Kubernetes 환경을 확장하면서 가동 시간을 개선하기 위한 일반적인 접근 방식은 Load Balancer, DNS 관리자 및 기타 자동화된 의사 결정 시스템을 클러스터 앞에 배포하는 것입니다. 그러나, Ingress Controller의 작동 방식 때문에, Kubernetes 클러스터 앞에 위치한 Load Balancer는 일반적으로 클러스터의 Ingress Controller 뒤에 있는 서비스에 대한 상태 정보에 액세스할 수 없으며, Ingress Controller Pod 자체가 정상이고 트래픽을 수신하고 있는지만 확인할 수 있습니다.

반면에 NGINX Ingress Controller 는 서비스 상태에 대한 정보를 가지고 있습니다. 이 Controller는 이미 HTTP, TCP, UDP, gRPC 서비스에 대한 주기적인 수동 상태 확인을 보내고, 요청 응답성을 모니터링하고, 성공적인 응답 코드 및 기타 지표를 추적하여 클러스터의 Upstream pod의 상태를 모니터링합니다. 이 정보를 사용하여 일관되고 예측 가능한 사용자 경험(UX)을 제공하기 위해 서비스 Pod 간에 트래픽을 분산하는 방법을 결정합니다. 일반적으로 NGINX Ingress Controller 는 백그라운드에서 이 모든 작업을 조용히 수행하므로 사용자는 내부에서 어떤 일이 일어나고 있는지 두 번 생각하지 않을 수 있습니다. Deep Service Insight는 이 귀중한 정보를 “표면화” 하여 사용자가 보다 효과적으로 사용할 수 있도록 합니다.

2. Ingress Controller Deep Service Insight는 어떻게 작동하나요?

Deep Service Insight는 NGINX VirtualServer 및 TransportServer 사용자 정의 리소스(각각 HTTP 및 TCP/UDP 용)를 사용하여 배포하는 서비스에 대해 사용할 수 있습니다. Deep Service Insight는 NGINX Plus API를 사용하여 Deep Service Insight 고유의 전용 Endpoint에서 Backend 서비스의 개별 pod에 대한 NGINX Ingress Controller 의 보기를 공유합니다.

  • 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 필드에 정의된 서비스 이름입니다.

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

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

  • 200 OK – 적어도 하나의 Pod가 정상입니다.
  • 418 I’m a teapot – Pod에 문제가 없습니다.
  • 404 Not Found – 지정된 호스트 이름 또는 서비스 이름과 일치하는 Pod가 없습니다.

2. 지정된 호스트 이름 또는 서비스 이름에 대한 3개의 Counter입니다.

  • 총 서비스 인스턴스 수(Pod)
  • 가동(정상) 상태의 Pod 개수
  • 상태가 비정상인 Pod의 수

다음은 서비스에 대한 세 개의 Pod가 모두 정상인 예시입니다.

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}

Active Health Check을 구성하여 Pod가 정상인지 판단하는 데 사용하는 기준을 추가로 사용자 정의할 수 있다. Health Check이 전송되는 경로와 포트, Pod가 정상적이지 않은 것으로 간주되기 위해 일정 기간 내에 발생해야 하는 확인 실패 횟수, 예상 상태 코드, 연결 또는 응답 수신 시간 초과 등을 구성할 수 있습니다. 가상 서버 또는 트랜스포트 서버 리소스에 Upstream.Healthcheck 필드를 포함한다.

2-1. Deep Service Insight의 샘플 사용 사례

Deep Service Insight가 특히 유용한 사용 사례 중 하나는 고가용성을 위해 Load Balancer가 두 개의 클러스터에서 실행 중인 서비스로 트래픽을 라우팅하는 경우입니다. 각 클러스터 내에서 NGINX Ingress Controller 는 위에서 설명한 대로 Upstream Pod의 상태를 추적합니다. Deep Service Insight를 활성화하면 정상 및 비정상 Upstream Pod의 수에 대한 정보도 전용 Endpoint에 Expose 됩니다. 라우팅 결정 시스템은 Endpoint에 액세스하고 이 정보를 사용하여 애플리케이션 트래픽을 정상적이지 않은 Pod로부터 정상적이지 않은 Pod로 전환할 수 있습니다.

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

Diagram showing how NGINX Ingress Controller provides information about Kubernetes pod health on the dedicated Deep Service Insight endpoing where a routing decision system uses it to divert traffic away from the cluster where the Tea service pods are unhealthy

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

3. Ingress Controller Deep Service Insight 활용

Deep Service Insight를 활성화하려면 Kubernetes manifest에 -enable-service-insight Command‑Line를 포함하거나 Helm을 사용하는 경우 serviceInsight.create 매개변수를 true로 설정한다.

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

-service-insight-listen-port <port> – 기본값인 9114(<포트>는 1024-65535 범위의 정수)에서 Deep Service Insight 포트 번호를 변경합니다.

-service-insight-tls-string <secret> – Deep Service Insight Endpoint의 TLS Termination를 위한 Kubernetes Secret(TLS 인증서 및 키)(<secret>은 <namespace>/<secret_name>형식의 문자열입니다).

3-1. 예제: Cafe 애플리케이션에 대한 Deep Service Insight 활성화하기

Deep Service Insight가 실제로 작동하는 것을 보려면 NGINX Ingress Controller 설명서에서 예시로 자주 사용되는 Cafe 애플리케이션에 대해 사용하도록 설정하면 됩니다.

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

  • Helm을 사용하는 경우 ServiceInsight.create 매개변수를 true로 설정한다.
  • Kubernetes Manifest(배포 또는 DaemonSet)를 사용하는 경우, Manifest 파일에 -enable-service-insight 인수를 포함하세요.

2. NGINX Ingress Controller가 실행 중인지 확인합니다.

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

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

3. README의 지침에 따라 Cafe 애플리케이션을 배포합니다.

4. Cafe 애플리케이션을 위해 NGINX VirtualServer 사용자 정의 리소스가 배포되었는지 확인합니다(가독성을 위해 IP 주소는 생략했습니다).

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

5. cafe.example.com에서 실행 중인 Cafe 서비스에 대한 Upstream Pod가 3개 있는지 확인합니다.

$ 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

6. Deep Service Insight Endpoint에 액세스합니다.

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

200 OK 응답 코드는 서비스가 트래픽을 수신할 준비가 되었음을 나타냅니다(적어도 하나의 Pod가 정상 상태입니다). 이 경우 세 개의 Pod 모두 가동 상태에 있습니다.

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Date: Day, DD Mon YYYY hh:mm:ss TZ
Content-Length: 32
{"Total":3,"Up":3,"Unhealthy":0}

418 I’m a teapot 상태 코드는 서비스를 사용할 수 없음을 나타냅니다(모든 pod가 정상적이지 않습니다).

HTTP/1.1 418 I'm a teapot
Content-Type: application/json; charset=utf-8
Date: Day, DD Mon YYYY hh:mm:ss TZ
Content-Length: 32
{"Total":3,"Up":0,"Unhealthy":3}

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

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

NGINX Ingress Controller 및 NGINX Plus를 직접 사용해 보거나 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.