컨테이너 기반 부하 분산

이 페이지에서는 Google Kubernetes Engine(GKE)에 있는 컨테이너 기반 부하 분산을 설명합니다. 컨테이너 기반 부하 분산을 사용하면 여러 종류의 부하 분산기가 직접 포드를 대상으로 지정하고 트래픽을 포드에 균일하게 분산시킬 수 있습니다.

컨테이너 기반 부하 분산 아키텍처

컨테이너 기반 부하 분산은 GCE_VM_IP_PORT 네트워크 엔드포인트 그룹(NEG)을 사용합니다. NEG의 엔드포인트는 포드 IP 주소입니다.

컨테이너 기반 부하 분산은 항상 내부 GKE 인그레스에 사용되며 외부 인그레스에 대해서는 선택사항입니다. 인그레스 컨트롤러는 가상 IP 주소, 전달 규칙, 상태 점검, 방화벽 규칙을 포함하여 부하 분산기를 만듭니다.

인그레스에 컨테이너 기반 부하 분산을 사용하는 방법은 인그레스를 통한 컨테이너 기반 부하 분산을 참조하세요.

유연성을 향상하기 위해 독립적인 NEG를 만들 수도 있습니다. 이 경우 부하 분산기의 모든 측면을 만들고 관리해야 합니다.

컨테이너 기반 부하 분산의 이점

컨테이너 기반 부하 분산의 이점은 다음과 같습니다.

포드는 부하 분산에 사용되는 핵심 객체입니다.
kube-proxy는 노드의 iptables 규칙을 구성하여 트래픽을 포드에 분산합니다. 컨테이너 기반 부하 분산이 없으면 부하 분산기 트래픽은 노드 인스턴스 그룹으로 이동하여 iptables 규칙을 통해 같은 노드에 있거나 없을 수 있는 포드로 라우팅됩니다. 컨테이너 기반 부하 분산을 사용하면 트래픽을 수신해야 하는 포드에 부하 분산기 트래픽이 직접 분산되어 추가 네트워크 홉이 제거됩니다. 컨테이너 기본 부하 분산은 포드를 직접 대상 지정하기 때문에 상태 점검 개선에도 도움이 됩니다.

기본 동작(왼쪽)과 컨테이너 기반 부하 분산기 동작 비교
네트워크 성능 향상
컨테이너 기반 부하 분산기가 포드와 직접 통신하고 연결에서 네트워크 홉이 줄어들기 때문에 지연 시간과 처리량이 모두 향상됩니다.
가시성 향상
컨테이너 기반 부하 분산을 통해 애플리케이션 부하 분산기에서 포드로의 지연 시간에 대한 가시성을 얻을 수 있습니다. 애플리케이션 부하 분산기에서 각 포드로의 지연 시간이 표시되고, 노드 IP 기반 컨테이너 기반 부하 분산으로 집계됩니다. 이를 통해 NEG 수준에서 서비스 문제를 쉽게 해결할 수 있습니다.
고급 부하 분산 기능 지원
GKE의 컨테이너 기반 부하 분산은 Google Cloud Armor, Cloud CDN, IAP(Identity-Aware Proxy)와 같은 Google Cloud 서비스와의 통합과 같은 외부 애플리케이션 부하 분산기의 여러 기능을 지원합니다. 또한 정확한 트래픽 분산을 위한 부하 분산 알고리즘을 제공합니다.
Cloud Service Mesh 지원
NEG 데이터 모델은 서비스 메시를 위한 Google Cloud의 완전 관리형 트래픽 컨트롤 플레인인 Cloud Service Mesh를 사용하는 데 필요합니다.

포드 준비

관련 포드의 경우 해당 인그레스 컨트롤러는 cloud.google.com/load-balancer-neg-ready 유형의 준비 게이트를 관리합니다. 인그레스 컨트롤러는 NEG에 있는 모든 엔드포인트 상태를 포함하여 부하 분산기의 상태 점검 상태를 폴링합니다. 부하 분산기의 상태 점검 상태가 특정 포드에 해당하는 엔드포인트가 정상임을 나타내면 인그레스 컨트롤러는 포드의 준비 게이트 값을 True로 설정합니다. 이 준비 게이트의 값과 포드의 준비 프로브(정의된 경우)를 고려하여 각 노드에서 실행되는 kubelet이 포드의 유효 준비를 계산합니다.

포드 준비 게이트는 인그레스를 통해 컨테이너 기반 부하 분산을 사용할 때 자동으로 사용 설정됩니다.

준비 게이트는 순차적 업데이트 속도를 관리합니다. 순차적 업데이트를 시작하면 GKE에서 새 포드를 만들 때 각 새 포드의 엔드포인트가 NEG에 추가됩니다. 엔드포인트가 부하 분산기의 관점에서 정상이면 인그레스 컨트롤러는 준비 게이트를 True로 설정합니다. 따라서 새로 만든 포드는 GKE에서 이전 포드를 제거하기 전에 최소한 준비 게이트를 통과해야 합니다. 이렇게 하면 포드의 해당 엔드포인트가 이미 부하 분산기의 상태 점검을 통과하고 백엔드 용량이 유지되도록 할 수 있습니다.

컨테이너 이미지가 잘못되었거나 부하 분산기 상태 점검이 잘못 구성되어 포드의 준비 게이트가 포드가 준비되었음을 나타내지 않으면 부하 분산기가 트래픽을 새 포드로 전송하지 않습니다. 업데이트된 배포를 롤아웃하는 동안 이러한 오류가 발생하면 포드의 준비 게이트가 True가 아니므로 새 포드를 만들려고 시도할 때 롤아웃이 중지됩니다. 이 상황을 감지하고 해결하는 방법은 문제 해결 섹션을 참조하세요.

컨테이너 기반 부하 분산 및 준비 게이트가 없으면 GKE는 포드를 준비 상태로 표시하기 전에 부하 분산기의 엔드포인트가 정상인지 감지할 수 없습니다. 이전 Kubernetes 버전에서는 지연 기간(배포 사양에서 minReadySeconds)을 지정하여 포드가 삭제되고 대체되는 속도를 관리합니다.

GKE는 다음 조건 중 하나가 충족되면 포드의 cloud.google.com/load-balancer-neg-ready 값을 True로 설정합니다.

  • 포드의 IP 주소가 GKE 제어 영역에서 관리하는 GCE_VM_IP_PORT NEG의 엔드포인트가 아닙니다.
  • 하나 이상의 포드 IP 주소는 GKE 제어 영역에서 관리되는 GCE_VM_IP_PORT NEG의 엔드포인트입니다. NEG는 백엔드 서비스에 연결됩니다. 백엔드 서비스에는 성공한 부하 분산기 상태 점검이 포함됩니다.
  • 하나 이상의 포드 IP 주소는 GKE 제어 영역에서 관리되는 GCE_VM_IP_PORT NEG의 엔드포인트입니다. NEG는 백엔드 서비스에 연결됩니다. 백엔드 서비스에 대한 부하 분산기 상태 점검은 시간 초과됩니다.
  • 하나 이상의 포드 IP 주소는 하나 이상의 GCE_VM_IP_PORT NEG의 엔드포인트입니다. NEG가 백엔드 서비스에 연결되지 않습니다. 부하 분산기 상태 점검 데이터를 사용할 수 없습니다.

세션 어피니티

컨테이너 기반 부하 분산은 포드 기반 세션 어피니티를 지원합니다.

컨테이너 기반 부하 분산 사용 요구사항

GKE의 인그레스를 통한 컨테이너 기반 부하 분산기의 요구사항은 다음과 같습니다.

  • 클러스터는 VPC 기반이어야 합니다.
  • 클러스터에 HttpLoadBalancing 부가기능이 사용 설정되어 있어야 합니다. GKE 클러스터에는 기본적으로 HttpLoadBalancing 부가기능이 사용 설정되어 있습니다. 중지하면 안 됩니다.

컨테이너 기반 부하 분산기 제약

GKE의 인그레스를 통한 컨테이너 기반 부하 분산기의 제한사항은 다음과 같습니다.

  • 외부 패스 스루 네트워크 부하 분산기를 지원하지 않습니다.
  • GKE에서 만드는 애플리케이션 부하 분산기의 구성을 수동으로 변경하거나 업데이트하면 안 됩니다. 수정하면 GKE가 변경사항을 덮어씁니다.

컨테이너 기반 부하 분산기 가격 책정

이 가이드에서 만드는 인그레스에 의해 프로비저닝되는 애플리케이션 부하 분산기에 대한 요금이 부과됩니다. 부하 분산기 가격 정보는 VPC 가격 책정 페이지의 부하 분산 및 전달 규칙을 참조하세요.

다음 단계