Kubernetes 부하 분산을 위한 NGINX 및 NGINX Plus Ingress Controller

Michael Pleshakov

여러 머신으로 구성된 클러스터 전반에서 컨테이너 기반 마이크로서비스 애플리케이션을 대규모로 실행하고 관리하는 것은 쉽지 않은 작업입니다. Kubernetes는 강력한 컨테이너 오케스트레이션 솔루션을 제공하여 이러한 과제를 해결할 수 있도록 지원합니다. 내결함성, 자동 확장, 롤링 업데이트, 스토리지, 서비스 검색, 부하 분산 등 여러 가지 중요한 기능을 제공합니다.

이 블로그 게시물에서는 NGINX Open Source 또는 NGINX Plus를 HTTP 트래픽을 위한 Kubernetes 기본 제공 부하 분산 프레임워크인 Ingress와 함께 사용하는 방법을 설명합니다. Ingress를 사용하면 외부 트래픽을 Kubernetes 클러스터의 서비스로 라우팅하는 방식을 제어하는 규칙을 구성할 수 있습니다. Ingress controller를 제공하는 부하 분산 장치라면 무엇이든 선택할 수 있습니다. Ingress 컨트롤러는 Kubernetes와 부하 분산 장치를 통합하기 위해 클러스터에 배포하는 소프트웨어입니다. 여기서는 Ingress와 NGINX Plus 및 NGINX용으로 제공되는 Ingress 컨트롤러를 사용하여 마이크로서비스 애플리케이션의 부하 분산을 구성하는 방법을 보여 줍니다.

[편집자 주 – 이전에 NGINX와 NGINX Plus용으로 각각 분리되어 있던 컨트롤러가 두 제품 모두를 지원하는 하나의 Ingress 컨트롤러로 통합되었습니다.]

이 블로그 게시물에서는 Ingress를 사용한 Kubernetes의 HTTP 부하 분산만 살펴봅니다. 다른 부하 분산 옵션에 대해 자세히 알아보려면 블로그의 NGINX Plus를 사용한 Kubernetes 서비스 부하 분산을 참조하세요.

참고: 이 블로그 게시물에서 설명하는 절차에 대한 전체 지침은 당사의 GitHub 리포지토리에서 확인할 수 있습니다. 이 게시물에서는 필요한 모든 단계를 일일이 설명하는 대신 해당 지침으로 연결되는 링크를 제공합니다.

NGINX 및 NGINX Plus용 Ingress Controller

샘플 애플리케이션을 배포하고 이에 대한 부하 분산을 구성하기 전에, 먼저 로드 밸런서를 선택하고 해당 Ingress 컨트롤러를 배포해야 합니다.

Ingress 컨트롤러는 특정 로드 밸런서를 Kubernetes와 통합하는 소프트웨어입니다. 당사는 NGINX Open Source와 NGINX Plus용 Ingress 컨트롤러를 개발했으며, 현재 당사의 GitHub 리포지토리에서 이용할 수 있습니다. 타사에서 개발한 다른 구현도 있습니다. 자세한 내용은 Kubernetes GitHub 리포지토리의 Ingress Controllers 페이지를 참조하세요.

클러스터에 NGINX 또는 NGINX Plus Ingress 컨트롤러를 배포하는 방법에 대한 전체 지침은 GitHub 리포지토리에서 확인하세요.

샘플 마이크로서비스 애플리케이션

샘플 애플리케이션은 각각 별도로 배포되는 여러 서비스로 구성된 일반적인 마이크로서비스 웹 애플리케이션입니다. cafe라는 이 애플리케이션에서는 tea 서비스를 통해 차를 주문하거나 coffee 서비스를 통해 커피를 주문할 수 있습니다. HTTP 요청의 URI로 원하는 음료를 지정합니다. URI가 /tea로 끝나면 차를, /coffee로 끝나면 커피를 받을 수 있습니다. 애플리케이션 연결은 SSL/TLS로 보호해야 합니다.

아래 다이어그램은 애플리케이션을 개념적으로 보여 줍니다. NGINX Plus 로드 밸런서는 클라이언트 요청을 적절한 서비스로 라우팅하고 SSL/TLS로 클라이언트 연결을 보호하는 중요한 역할을 합니다.

클러스터에 애플리케이션을 배포하려면 GitHub 저장소의 안내를 따르세요.

Ingress를 통한 Kubernetes 부하 분산 구성

저희 cafe 앱에서는 로드 밸런서가 다음 두 가지 기능을 제공해야 합니다:

• 요청 URI를 기반으로 한 라우팅(일명 경로 기반 라우팅)
• SSL/TLS 종료

Ingress를 사용하여 부하 분산을 구성하려면 Ingress 리소스에 규칙을 정의합니다. 이 규칙은 외부 트래픽을 클러스터의 서비스로 라우팅하는 방법을 지정합니다.

리소스에서 각각 서로 다른 도메인 이름을 사용하는 여러 가상 서버를 정의할 수 있습니다. 가상 서버는 일반적으로 클러스터에 배포된 단일 마이크로서비스 애플리케이션에 해당합니다. 각 서버에서 다음을 수행할 수 있습니다:

• 여러 경로 기반 규칙을 지정합니다. 요청 URI에 따라 트래픽이 애플리케이션의 서로 다른 서비스로 전송됩니다.
• SSL/TLS 인증서와 키를 참조하여 SSL/TLS 종료를 설정합니다.

Ingress에 대한 더 자세한 설명과 예시는 Ingress 문서 페이지에서 확인할 수 있습니다.

다음은 cafe‑ingress.yaml 파일에 정의된 cafe 앱의 Ingress 리소스입니다:

코드 예제를 로드하는 중…

한 줄씩 살펴보면 다음과 같습니다:

• 4번째 줄에서 리소스 이름을 cafe‑ingress로 지정합니다.
• 6~9번째 줄에서 SSL/TLS 종료를 설정합니다:
  • 9번째 줄에서는 이름을 사용하여 Secret 리소스인 cafe‑secret을 참조합니다. 이 리소스에는 SSL/TLS 인증서와 키가 포함되어 있으며 Ingress 리소스보다 먼저 배포해야 합니다.
  • 8번째 줄에서는 인증서와 키를 cafe.example.com 가상 서버에 적용합니다.
• 11번째 줄에서는 도메인 이름이 cafe.example.com인 가상 서버를 정의합니다.
• 13~21행에서는 경로 기반 규칙 두 개를 정의합니다.
  • 14~17행에 정의된 규칙은 로드 밸런서가 /tea URI가 포함된 요청을 클러스터에 tea‑svc라는 이름으로 배포된 tea 서비스의 컨테이너에 분산하도록 지시합니다.
  • 18~21행에 정의된 규칙은 로드 밸런서가 /coffee URI가 포함된 요청을 클러스터에 coffee‑svc라는 이름으로 배포된 coffee 서비스의 컨테이너에 분산하도록 지시합니다.
  • 두 규칙 모두 로드 밸런서가 요청을 해당 서비스의 포트 80으로 분산하도록 지시합니다.

클러스터에 Ingress 및 Secret 리소스를 배포하는 방법에 대한 전체 지침은 GitHub 리포지토리를 참조하세요.

애플리케이션 테스트

NGINX Plus Ingress 컨트롤러, 애플리케이션, Ingress 리소스 및 Secret 리소스를 배포한 후에는 앱을 테스트할 수 있습니다.

When we make a tea request with the /tea URI로 tea 요청을 보내면 브라우저에 tea 서비스에서 생성한 페이지가 표시됩니다.

We hope you’re not too disappointed that the tea 및 coffee 서비스가 실제로 음료를 제공하는 것이 아니라, 서비스가 실행 중인 컨테이너에 대한 정보와 요청 세부 정보를 제공한다고 해서 너무 실망하지 않으셨으면 합니다. 여기에는 컨테이너 호스트 이름과 IP 주소, 요청 URI, 클라이언트 IP 주소가 포함됩니다. 페이지를 새로 고칠 때마다 다른 컨테이너에서 응답을 받습니다.

또한 NGINX Plus 실시간 활동 모니터링 대시보드에 연결하여 NGINX Plus와 애플리케이션의 각 컨테이너에 대한 실시간 부하 분산 메트릭을 확인할 수 있습니다.

Ingress 컨트롤러 확장 기능

Ingress는 기본적인 HTTP 부하 분산 기능을 제공합니다. 하지만 애플리케이션의 부하 분산 요구 사항이 더 복잡하여 Ingress에서 지원되지 않는 경우가 많습니다. 이러한 요구 사항 중 일부를 충족하기 위해 Ingress 컨트롤러에 여러 확장 기능을 추가했습니다. 이를 통해 부하 분산 장치를 직접 구성하는 대신 Kubernetes 리소스를 사용하여 부하 분산을 구성하는 이점을 유지하면서 고급 부하 분산 기능도 활용할 수 있습니다.

사용 가능한 확장 기능의 전체 목록은 GitHub 저장소에서 확인하세요.

또한 Kubernetes 리소스의 ConfigMap 또는 어노테이션을 통해 NGINX 구성을 사용자 지정할 수 있는 메커니즘을 제공합니다. 예를 들어 proxy_connect_timeout 또는 proxy_read_timeout 지시문의 값을 사용자 지정할 수 있습니다.

부하 분산 요구 사항이 Ingress 및 당사 확장 기능에서 지원하는 범위를 벗어나는 경우, Ingress 컨트롤러를 사용하지 않고 NGINX Plus를 배포하고 구성하는 다른 접근 방식을 권장합니다. 자세한 내용은 당사 블로그의 NGINX Plus를 사용한 Kubernetes 서비스 부하 분산 문서를 참조하세요.

컨트롤러와 함께 NGINX Plus를 사용할 때의 이점

NGINX Plus를 사용하면 Ingress 컨트롤러는 NGINX에서 제공하는 이점 외에도 다음과 같은 이점을 제공합니다:

• 매우 동적인 환경에서의 안정성 – Ingress를 통해 노출되는 서비스의 Pod 수가 변경될 때마다 Ingress 컨트롤러는 변경 사항을 반영하도록 NGINX 또는 NGINX Plus 구성을 업데이트해야 합니다. NGINX Open Source에서는 구성 파일을 수동으로 변경하고 구성을 다시 로드해야 합니다. NGINX Plus에서는 동적 재구성 API를 사용하여 구성 파일을 다시 로드하지 않고도 구성을 업데이트할 수 있습니다. 이를 통해 구성을 매우 자주 다시 로드할 때 발생할 수 있는 메모리 사용량 증가와 전체 시스템 과부하를 방지할 수 있습니다.
• 실시간 통계 – NGINX Plus는 고급 실시간 통계를 제공하며, API 또는 기본 제공 대시보드를 통해 확인할 수 있습니다. 이를 통해 NGINX Plus와 애플리케이션의 성능을 파악할 수 있습니다.
• 세션 지속성 – 세션 지속성을 활성화하면 NGINX Plus는 고정 쿠키 방식을 사용하여 동일한 클라이언트의 모든 요청이 항상 동일한 백엔드 컨테이너로 전달되도록 합니다.

요약

Kubernetes는 Ingress를 통해 외부 트래픽을 클러스터 내 서비스로 라우팅할 수 있도록 기본 제공 HTTP 부하 분산 기능을 제공합니다. NGINX와 NGINX Plus는 Kubernetes 부하 분산과 통합되어 Ingress 기능을 완벽하게 지원하며, 확장된 부하 분산 요구 사항을 충족하기 위한 확장 기능도 제공합니다.

NGINX Plus와 Ingress 컨트롤러를 사용해 보려면 지금 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요.

작성자 소개

Michael Pleshakov

Michael Pleshakov의 다른 블로그 게시물