애플리케이션 부하 분산기의 GKE 인그레스

Autopilot Standard

이 페이지에서는 애플리케이션 부하 분산기용 Google Kubernetes Engine (GKE) 인그레스를 간략하게 설명하고, 인그레스 컨트롤러가 애플리케이션 부하 분산기를 프로비저닝하여 VPC 네트워크 내부 또는 외부의 HTTP(S) 트래픽에 애플리케이션을 노출하는 방법을 설명합니다.

이 페이지는 GKE 인그레스의 작동 방식을 이해하기 위한 기본 진입점 역할을 합니다. 기본 네트워킹 아키텍처, 트래픽 라우팅 패턴, 보안 구현을 자세히 살펴보려면 GKE 인그레스 라우팅 및 보안 정보를 참고하세요.

이 페이지에서는 사용자가 다음 사항을 알고 있다고 가정합니다.

이 페이지는 조직의 네트워크를 계획 및 설계하고 네트워크 장비를 설치, 구성, 지원하는 네트워킹 전문가를 대상으로 합니다.Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참조하세요.

개요

GKE는 GKE 인그레스라고 하는 기본 제공 관리형 인그레스 컨트롤러를 제공합니다. GKE에서 인그레스 리소스를 만들면 컨트롤러는 HTTP 또는 HTTPS 트래픽이 서비스에 도달하도록 허용하는 HTTPS 부하 분산기를 자동으로 구성합니다. 인그레스 컨트롤러는 부하 분산기를 구성하고 Ingress 매니페스트 및 연결된 서비스 객체에 지정된 규칙에 따라 클러스터에서 실행되는 애플리케이션으로 트래픽을 라우팅합니다.

인그레스 객체는 하나 이상의 서비스 객체와 연결되며, 서비스 객체는 포드 집합과 연결됩니다. 인그레스가 서비스를 사용하여 애플리케이션을 노출하는 방법을 자세히 알아보려면 서비스 네트워킹 개요를 참고하세요.

인그레스를 사용하려면 HTTP 부하 분산 부가기능을 사용 설정해야 합니다. GKE 클러스터는 기본적으로 이 부가기능을 사용 설정합니다. 사용 중지하면 안 됩니다.

Kubernetes 서비스와 Google Cloud 백엔드 서비스의 차이점

Kubernetes 서비스 객체와 Google Cloud 백엔드 서비스 객체는 비슷하지만 서로 다른 용도로 사용됩니다. 이 두 가지는 밀접한 관련이 있지만 항상 일대일 관계는 아닙니다.

GKE 인그레스 컨트롤러는 이 두 개념 간의 변환기 역할을 합니다. 인그레스 리소스를 만들면 컨트롤러가Google Cloud 부하 분산기를 프로비저닝합니다. 그러면 컨트롤러가 Ingress 매니페스트에 참조된 고유한 (service.name, service.port) 조합마다 전용Google Cloud 백엔드 서비스를 만듭니다.

예를 들어 인그레스 매니페스트의 Kubernetes 서비스 이름은 동일하지만 두 개의 별도 host 또는 path 규칙에 대해 서로 다른 service.port를 가리킬 수 있습니다. 이 경우 GKE 인그레스 컨트롤러는 두 개의 별도 백엔드 서비스를 만듭니다. 따라서 Kubernetes 서비스 객체 하나가 여러 Google Cloud 백엔드 서비스와 관련될 수 있습니다.

외부 및 내부 트래픽 인그레스

GKE 인그레스 리소스에는 두 가지 유형이 있습니다.

외부 애플리케이션 부하 분산기용 인그레스는 기본 애플리케이션 부하 분산기를 배포합니다. 이 인터넷 연결 부하 분산기는 확장 가능한 관리형 부하 분산 리소스 풀로 Google 에지 네트워크에 전역으로 배포됩니다. 외부 애플리케이션 부하 분산기용 인그레스의 설정 및 사용 방법을 알아보세요.
내부 애플리케이션 부하 분산기용 인그레스는 내부 애플리케이션 부하 분산기를 배포합니다. 이러한 내부 애플리케이션 부하 분산기는 GKE 클러스터 외부에 있지만 VPC 네트워크 내부에 있는 Envoy 프록시 시스템으로 지원됩니다. 내부 애플리케이션 부하 분산기용 인그레스의 설정 및 사용 방법을 알아보세요.

외부 애플리케이션 부하 분산기에 필요한 네트워킹 환경

외부 애플리케이션 부하 분산기는 Google의 에지 네트워크에 배포된 Google 프런트엔드 (GFE) 프록시를 사용하는 관리형 전역 분산 시스템입니다. 이러한 프록시는 VPC 네트워크 내에 있지 않습니다. 클라이언트가 부하 분산기의 외부 IP 주소로 요청을 보내면 요청은 Google의 애니캐스트 네트워크를 사용하여 가장 가까운 GFE로 라우팅됩니다. GFE는 사용자 트래픽 (TLS 포함, 구성된 경우)을 종료한 후 트래픽을 GKE 클러스터의 백엔드 포드로 전달합니다.

이 흐름이 작동하려면 GKE 인그레스 컨트롤러가 GFE 및Google Cloud의 상태 점검 시스템에서 포드에 도달하는 트래픽을 허용하는 방화벽 규칙을 자동으로 만듭니다. 이러한 규칙은 Google의 알려진 IP 주소 범위 (130.211.0.0/22 및 35.191.0.0/16)의 트래픽을 허용합니다.

외부 애플리케이션 부하 분산기의 작동 방식은 다음과 같습니다.

클라이언트는 부하 분산기 전달 규칙의 IP 주소와 포트로 요청을 전송합니다.
요청은 Google의 글로벌 네트워크에 있는 Google 프런트엔드 (GFE) 프록시로 라우팅됩니다. 이 프록시는 클라이언트의 네트워크 연결을 종료합니다.
GFE 프록시는 부하 분산기의 URL 맵과 백엔드 서비스에 따라 GKE 클러스터의 적절한 백엔드 포드 엔드포인트로 요청을 전달합니다.

내부 애플리케이션 부하 분산기와 달리 외부 애플리케이션 부하 분산기의 경우 VPC 네트워크에서 프록시 전용 서브넷을 구성할 필요가 없습니다.

내부 애플리케이션 부하 분산기에 필요한 네트워킹 환경

내부 애플리케이션 부하 분산기는 네트워크의 프록시 풀을 제공합니다. 프록시는 URL 맵, BackendService의 세션 어피니티, 각 백엔드 NEG의 분산 모드 등 기타 요인을 기반으로 이동하는 각 HTTP(S) 요청의 위치를 평가합니다.

리전의 내부 애플리케이션 부하 분산기는 VPC 네트워크의 해당 리전에 프록시 전용 서브넷을 사용하여 Google Cloud에 의해 생성된 각 프록시에 내부 IP 주소를 할당합니다.

기본적으로 부하 분산기의 전달 규칙에 할당되는 IP 주소는 프록시 전용 서브넷 대신 GKE에서 할당한 노드의 서브넷 범위에서 가져옵니다. 또한 규칙을 만들 때 모든 서브넷에서 전달 규칙의 IP 주소를 수동으로 지정할 수 있습니다.

다음 다이어그램은 이전 단락에서 설명한 대로 내부 애플리케이션 부하 분산기의 트래픽 흐름을 간략하게 보여줍니다.

내부 애플리케이션 부하 분산기 작동 방식은 다음과 같습니다.

클라이언트는 부하 분산기 전달 규칙의 IP 주소와 포트에 연결됩니다.
프록시는 클라이언트의 네트워크 연결을 수신하고 종료합니다.
프록시는 부하 분산기의 URL 맵과 백엔드 서비스에서 지정한 대로 NEG의 적절한 엔드포인트(Pod)에 대한 연결을 설정합니다.

각 프록시는 해당 부하 분산기의 전달 규칙에서 지정한 IP 주소와 포트를 리슨합니다. 프록시에서 엔드포인트로 전송되는 각 패킷의 소스 IP 주소는 프록시 전용 서브넷에서 프록시에 할당된 내부 IP 주소입니다.

GKE 인그레스 컨트롤러 동작

GKE 인그레스 컨트롤러가 인그레스를 처리하는지 여부는 kubernetes.io/ingress.class 주석의 값에 따라 달라집니다.

`kubernetes.io/ingress.class` 값	`ingressClassName` 값	GKE 인그레스 컨트롤러 동작
설정되지 않음	설정되지 않음	인그레스 매니페스트를 처리하고 외부 애플리케이션 부하 분산기를 만듭니다.
설정되지 않음	모든 값	수행할 작업이 없습니다. 인그레스 매니페스트가 타사 인그레스 컨트롤러(배포된 경우)로 처리될 수 있습니다.
`gce`	모든 값 이 필드는 무시됩니다.	인그레스 매니페스트를 처리하고 외부 애플리케이션 부하 분산기를 만듭니다.
`gce-internal`	모든 값 이 필드는 무시됩니다.	인그레스 매니페스트를 처리하고 내부 애플리케이션 부하 분산기를 만듭니다.
`gce` 또는 `gce-internal` 이외의 값으로 설정	모든 값	수행할 작업이 없습니다. 인그레스 매니페스트가 타사 인그레스 컨트롤러(배포된 경우)로 처리될 수 있습니다.

`kubernetes.io/ingress.class` 주석 지원 중단

kubernetes.io/ingress.class 주석은 Kubernetes에서 지원 중단되었지만 GKE는 이 주석을 계속 사용합니다. 이 주석을 사용하여 인그레스 클래스를 식별해야 합니다.

구성을 적용할 때 지원 중단 경고가 표시될 수 있습니다. 이 경고는 주석이 지원 중단되었으며 대신 ingressClassName 필드를 사용해야 한다고 안내합니다. GKE Ingress는 kubernetes.io/ingress.class 주석만 계속 사용하므로 경고를 무시해도 됩니다.

인그레스에서 Compute Engine으로 리소스 매핑

GKE 인그레스 컨트롤러는 클러스터에 배포된 인그레스 리소스에 따라 Compute Engine 부하 분산기 리소스를 배포 및 관리합니다. Compute Engine 리소스 매핑은 인그레스 리소스 구조에 따라 다릅니다.

다음 매니페스트는 인그레스를 설명합니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-products
            port:
              number: 60000
      - path: /discounted
        pathType: ImplementationSpecific
        backend:
          service:
            name: my-discounted-products
            port:
              number: 80

이 인그레스 매니페스트는 GKE가 다음 Compute Engine 리소스를 만들도록 지시합니다.

전달 규칙 및 IP 주소.
부하 분산기 상태 점검에 대한 트래픽 및 Google 프런트엔드 또는 Envoy 프록시의 애플리케이션 트래픽을 허용하는 Compute Engine 방화벽 규칙.
TLS를 구성한 경우 대상 HTTP 프록시 및 대상 HTTPS 프록시.
단일 호스트 규칙으로 단일 경로 일치자를 참조하는 URL 맵. 경로 일치자에는 /* 및 /discounted에 대해 하나씩 두 개의 경로 규칙이 있습니다. 각 경로 규칙은 고유한 백엔드 서비스에 매핑됩니다.
각 서비스의 포드 IP 주소 목록을 엔드포인트로 보관하는 NEG. 이는 my-discounted-products 및 my-products 서비스의 결과로 생성됩니다.

부하 분산 메서드

GKE는 컨테이너 기반 부하 분산 및 인스턴스 그룹을 지원합니다.

컨테이너 기반 부하 분산

컨테이너 기반 부하 분산은 GKE의 포드 엔드포인트로 직접 부하를 분산하는 방법입니다. 컨테이너 기반 부하 분산은 엔드포인트가 포드의 IP 주소인 GCE_VM_IP_PORT 유형의 네트워크 엔드포인트 그룹 (NEG)을 사용합니다.

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

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

다음 조건을 모두 충족하면 GKE에서 컨테이너 기반 부하 분산을 자동으로 사용 설정합니다.

클러스터가 VPC 기반입니다.
클러스터가 공유 VPC 네트워크를 사용하지 않습니다.
클러스터에서 GKE 네트워크 정책을 사용하지 않습니다.
클러스터에 HttpLoadBalancing 부가기능이 사용 설정되어 있습니다. GKE 클러스터에는 기본적으로 HttpLoadBalancing 부가기능이 사용 설정되어 있습니다. 중지하면 안 됩니다.

GKE에서 컨테이너 기반 부하 분산을 사용 설정하면 서비스에 cloud.google.com/neg: '{"ingress": true}'가 자동으로 주석으로 추가됩니다. 이 주석은 포드 IP를 미러링하는 NEG 생성을 트리거하여 Compute Engine 부하 분산기가 포드와 직접 통신할 수 있도록 합니다.

NEG가 기본값이 아닌 클러스터의 경우 컨테이너 기반 부하 분산을 사용하는 것이 가장 좋지만, 서비스별 기준에 따라 명시적으로 사용 설정되어야 합니다.

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

이점

NEG를 사용하면 컨테이너 기반 부하 분산이 더 안정적이고 성능이 우수한 네트워킹을 제공합니다.

네트워크 성능 개선: 컨테이너 기반 부하 분산이 없으면 트래픽이 노드 인스턴스 그룹으로 이동한 후 kube-proxy에서 구성한 iptables 규칙을 사용하여 타겟 Pod로 라우팅됩니다. 컨테이너 기반 부하 분산을 사용하면 트래픽이 포드로 직접 부하 분산되므로 노드에서 VM IP와 kube-proxy 네트워킹을 통해 라우팅할 필요가 없습니다. 이 흐름은 추가 네트워크 홉을 없애고 지연 시간과 처리량을 개선합니다.

향상된 상태 확인: 포드 준비 게이트가 구현되어 클러스터 내 상태 프로브에만 의존하지 않고 부하 분산기의 관점에서 포드 상태를 확인합니다. 이 중요한 기능을 사용하면 부하 분산기가 포드 수명 주기 이벤트 (시작, 손실 등)를 인식하고 트래픽 안정성이 향상됩니다. 포드 준비 게이트를 사용하여 포드 상태를 확인하는 방법을 자세히 알아보려면 포드 준비를 참고하세요.

가시성 향상: 컨테이너 기반 부하 분산을 사용하면 애플리케이션 부하 분산기에서 각 포드로의 지연 시간을 직접 확인할 수 있습니다. 지연 시간이 더 이상 노드 IP 수준에서 집계되지 않으므로 NEG 수준에서 서비스 문제를 쉽게 해결할 수 있습니다.

Cloud Service Mesh 지원: NEG 데이터 모델은 서비스 메시를 위한 Google Cloud의 완전 관리형 트래픽 컨트롤 플레인인 Cloud Service Mesh를 사용하는 데 필요합니다.

컨테이너 기반 부하 분산기의 제한사항

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

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

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

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

인스턴스 그룹

인스턴스 그룹을 사용할 때 Compute Engine 부하 분산기는 트래픽을 VM IP 주소에 백엔드로 전송합니다. 컨테이너가 동일한 호스트 인터페이스를 공유하는 VM에서 컨테이너를 실행하는 경우 다음과 같은 제한사항이 있습니다.

부하 분산의 2개 홉이 발생하는데, 한 홉은 부하 분산기에서 VM NodePort로 그리고 다른 홉은 kube-proxy 라우팅을 통해 다른 VM에 있을 수 있는 포드 IP 주소로 발생합니다.
추가 홉으로 인해 지연 시간이 추가되어 트래픽 경로가 더 복잡해집니다.
Compute Engine 부하 분산기는 Pod를 직접 볼 수 없으므로 최적화되지 않은 트래픽 분산이 발생합니다.
VM 또는 Pod 손실과 같은 환경 이벤트는 이중 트래픽 홉으로 인해 간헐적으로 트래픽 손실이 발생할 가능성이 높습니다.

외부 인그레스 및 경로 기반 클러스터

외부 인그레스에 경로 기반 클러스터를 사용하는 경우 GKE 인그레스 컨트롤러가 GCE_VM_IP_PORT 네트워크 엔드포인트 그룹(NEG)을 사용하여 컨테이너 기반 부하 분산을 사용할 수 있습니다. 대신 인그레스 컨트롤러가 모든 노드 풀의 모든 노드를 포함하는 비관리형 인스턴스 그룹 백엔드를 사용합니다. 이러한 비관리형 인스턴스 그룹이 LoadBalancer 서비스에도 사용된 경우 단일 부하 분산 인스턴스 그룹 제한과 관련된 문제가 발생할 수 있습니다.

VPC 기반 클러스터에 생성된 오래된 몇몇 외부 인그레스 객체는 생성하는 각 외부 애플리케이션 부하 분산기의 백엔드 서비스에서 인스턴스 그룹 백엔드를 사용할 수 있습니다. 내부 인그레스 리소스가 항상 GCE_VM_IP_PORT NEG를 사용하고 VPC 기반 클러스터를 필요로 하기 때문에 이러한 제한은 내부 인그레스와 관련이 없습니다.

외부 인그레스에서 502 오류를 문제 해결하는 방법은 외부 인그레스로 HTTP 502 오류 발생을 참조하세요.

GKE 인그레스 컨트롤러의 제한사항

GKE 인그레스는 인증서 관리자로 관리되는 인증서를 지원하지 않습니다. 인증서 관리자가 관리하는 인증서를 사용하려면 Gateway API를 사용하세요.
NEG 사용 클러스터에서 인그레스 조정 시간은 인그레스 수의 영향을 받을 수 있습니다. 예를 들어 한 클러스터에 인그레스가 20개 있고, 각 인그레스에 20개의 고유 NEG 백엔드가 있는 경우, 인그레스 변경을 조정할 때 지연 시간이 30분 이상 걸릴 수 있습니다. 이 문제는 특히 필요한 NEG 수 증가로 인해 리전 클러스터에 영향을 줍니다.
URL 맵 할당량이 적용됩니다.
Compute Engine 리소스 할당량이 적용됩니다.
GKE 인그레스 컨트롤러에서 NEG를 사용하지 않으면 GKE 클러스터의 노드 수는 1,000개로 제한됩니다. 서비스가 NEG로 배포되면 GKE 노드 제한이 없습니다. 인그레스를 통해 노출된 비NEG 서비스는 노드가 1,000개를 초과하는 클러스터에서 제대로 작동하지 않습니다.
GKE 인그레스 컨트롤러가 readinessProbes를 상태 확인으로 사용하려면 인그레스를 만들 때 인그레스의 Pod가 있어야 합니다. 복제본 크기를 0으로 조정하면 기본 상태 점검이 적용됩니다. 자세한 내용은 상태 점검 관련 GitHub 문제 설명을 참조하세요.
포드의 readinessProbe 변경사항이 발생해도 인그레스는 영향을 받지 않습니다.
외부 애플리케이션 부하 분산기는 클라이언트와 부하 분산기 간의 지연 시간을 최소화하기 위해 전역으로 분산된 위치에서 TLS를 종료합니다. TLS의 종료 위치를 지리적으로 제어해야 하는 경우 LoadBalancer 유형의 GKE 서비스를 통해 제공된 커스텀 인그레스 컨트롤러를 대신 사용해야 하고, 필요한 리전에 있는 백엔드에서 TLS를 종료해야 합니다.
여러 인그레스 리소스를 단일 Google Cloud 부하 분산기에 결합할 수 없습니다.
외부 애플리케이션 부하 분산기에는 지원되지 않으므로 애플리케이션에서 상호 TLS를 사용 중지해야 합니다.
인그레스는 프런트엔드에 HTTP 포트 80 및 443만 노출할 수 있습니다.