HTTP(S) 부하 분산용 GKE 인그레스

이 페이지에서는 HTTP(S) 부하 분산용 인그레스 작동 방식에 대한 일반적인 내용을 간략하게 설명합니다. Google Kubernetes Engine(GKE)은 GKE 인그레스라고 하는 관리형 인그레스 컨트롤러를 기본 제공합니다. 이 컨트롤러는 인그레스 리소스를 GKE의 HTTP(S) 워크로드용 Google Cloud 부하 분산기로 구현합니다.

개요

GKE에서 인그레스 객체는 HTTP(S) 트래픽을 클러스터에서 실행되는 애플리케이션으로 라우팅하는 규칙을 정의합니다. 인그레스 객체는 각각 pod 집합에 연결된 서비스 객체 한 개 이상과 연결됩니다. 인그레스가 서비스를 사용하여 애플리케이션을 노출하는 방법에 대한 자세한 내용은 서비스 네트워킹 개요를 참조하세요.

인그레스 객체를 만들면 GKE 인그레스 컨트롤러Google Cloud HTTP(S) 부하 분산기를 만들고 인그레스 및 연결된 서비스의 정보에 따라 구성합니다.

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

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

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

HTTP(S) 부하 분산 특징

인그레스에 의해 구성되는 HTTP(S) 부하 분산의 특징은 다음과 같습니다.

  • 서비스의 유연한 구성. 인그레스는 트래픽이 서비스에 도달하는 방법과 트래픽이 애플리케이션으로 라우팅되는 방법을 정의합니다. 또한 인그레스는 클러스터의 여러 서비스에 단일 IP 주소를 제공할 수 있습니다.
  • Google Cloud 네트워크 서비스와 통합
  • 여러 TLS 인증서에 대한 지원. 인그레스는 요청 종료를 위한 여러 TLS 인증서 사용을 지정할 수 있습니다.

전체 목록은 인그레스 기능을 참조하세요.

컨테이너 기반 부하 분산

컨테이너 기반 부하 분산네트워크 엔드포인트 그룹(NEG)을 사용하여 GKE의 pod 엔드포인트로 직접 부하 분산을 수행하는 방법입니다.

인스턴스 그룹을 사용할 때 Compute Engine 부하 분산기는 트래픽을 VM IP에 백엔드로 전송합니다. 컨테이너가 동일한 호스트 인터페이스를 공유하는 VM에서 컨테이너를 실행하는 경우, 이로 인해 몇 가지 제한이 적용됩니다.

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

VM IP를 통과하고 kube-proxy 네트워킹을 사용하는 것과 반대로 NEG에서는 트래픽이 부하 분산기에서 pod IP로 직접 부하 분산됩니다. 또한 pod 준비 게이트는 Kubernetes 클러스터 내 상태 프로브만이 아니라 부하 분산기의 관점에서 pod 상태를 확인하도록 구현됩니다. 이렇게 하면 부하 분산기 인프라가 pod 시작, pod 손실, VM 손실과 같은 수명 주기 이벤트를 인식하여 전반적인 트래픽 안정성이 향상됩니다. 이러한 기능은 위의 제한 사항을 해결하고 성능 및 안정성이 뛰어난 네트워킹을 지원합니다.

컨테이너 기반 부하 분산은 다음 조건이 모두 충족될 때 서비스에 대해 기본적으로 사용 설정됩니다.

  • GKE 클러스터 1.17.6-gke.7 이상으로 생성된 서비스
  • VPC 기반 클러스터 사용
  • 공유 VPC 사용 안 함
  • GKE 네트워크 정책 사용하지 않음

이러한 조건에서 서비스에는 서비스 내에서 pod IP를 미러링하기 위해 NEG를 만들어야 함을 나타내는 cloud.google.com/neg: '{"ingress": true}' 주석이 자동으로 추가됩니다. NEG는 Compute Engine 부하 분산기가 pod와 직접 통신하도록 허용합니다. GKE 1.17.6-gke.7+ 이전에 생성된 기존 서비스는 서비스 컨트롤러에서 자동으로 주석이 추가되지 않습니다.

NEG 주석이 자동으로 처리되는 GKE 1.17.6-gke.7+ 클러스터의 경우, 필요한 경우 NEG를 사용 중지하고 Compute Engine 부하 분산기가 인스턴스 그룹을 백엔드로 사용하도록 만들 수 있습니다. 이렇게 하려면 cloud.google.com/neg: '{"ingress": false}'를 사용하여 서비스를 명시적으로 주석 처리하면 됩니다.

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

kind: Service
...
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
...

공유 VPC

인그레스 및 MultiClusterIngress 리소스는 공유 VPC 토폴로지에서 지원되지만 작동하려면 일부 선점이 필요합니다. GKE 인그레스 컨트롤러는 Google Cloud 서비스 계정을 사용하여 Google Cloud 리소스를 배포하고 관리합니다. GKE 클러스터가 공유 VPC의 서비스 프로젝트에 있는 경우 이 서비스 계정에는 호스트 프로젝트에서 소유한 네트워크 리소스를 관리할 권한이 없습니다. 인그레스 컨트롤러는 여러 부하 분산기 간과 중앙 집중식 상태 확인기와 pod 간의 액세스를 제공하도록 방화벽 규칙을 적극적으로 관리합니다.

하지만 공유 VPC에서 GKE 인그레스 컨트롤러에는 방화벽 규칙을 관리할 권한이 없습니다. 호스트 프로젝트에서 방화벽 규칙을 수동으로 프로비저닝하거나 호스트 프로젝트 방화벽 규칙을 관리할 GKE 인그레스 컨트롤러 권한을 제공하여 권한을 추가할 수 있습니다.

호스트 프로젝트에서 수동으로 방화벽 규칙 프로비저닝

보안 정책에서 호스트 프로젝트의 방화벽 관리만 허용하는 경우 이러한 방화벽 규칙을 수동으로 프로비저닝할 수 있습니다. 공유 VPC에 인그레스를 배포할 때 인그레스 리소스 이벤트는 액세스를 제공하는 데 필요한 특정 방화벽 규칙을 제공합니다.

규칙을 수동으로 프로비저닝하려면 다음 안내를 따르세요.

  1. 인그레스 리소스 이벤트를 확인합니다.

    kubectl describe ingress INGRESS_NAME
    

    INGRESS_NAME을 인그레스의 이름으로 바꿉니다.

    다음과 비슷한 출력이 표시됩니다.

    Events:
    Type    Reason  Age                    From                     Message
    ----    ------  ----                   ----                     -------
    Normal  Sync    9m34s (x237 over 38h)  loadbalancer-controller  Firewall change required by security admin: `gcloud compute firewall-rules update k8s-fw-l7--6048d433d4280f11 --description "GCE L7 firewall rule" --allow tcp:30000-32767,tcp:8080 --source-ranges 130.211.0.0/22,35.191.0.0/16 --target-tags gke-l7-ilb-test-b3a7e0e5-node --project <project>`
    

    추천하는 필수 방화벽 규칙이 Message 열에 표시됩니다.

  2. 호스트 프로젝트에서 추천한 방화벽 규칙을 복사하여 적용합니다. 규칙을 적용하면 부하 분산기 및 Google Cloud 상태 검사기에서 pod에 대한 액세스를 제공합니다.

호스트 프로젝트 방화벽 규칙을 관리하기 위한 인그레스 컨트롤러 권한 제공

자동화된 접근 방식은 GKE 인그레스 컨트롤러 서비스 계정에 방화벽 규칙 업데이트 권한을 제공하는 것입니다. 방화벽 규칙을 직접 관리하고 이 역할을 GKE 인그레스 서비스 계정에 부여하는 기능을 제공하는 커스텀 IAM 역할을 만듭니다.

  1. 호스트 프로젝트에서 compute.firewalls.*compute.networks.updatePolicy 권한이 있는 커스텀 역할을 서비스 프로젝트의 GKE 서비스 계정에 부여합니다.

    gcloud iam roles create ROLE_NAME \
       --project PROJECT_ID \
       --title ROLE_TITLE \
       --description ROLE_DESCRIPTION \
       --permissions=compute.networks.updatePolicy, compute.firewalls.*\
       --stage GA
    

    다음을 바꿉니다.

    • ROLE_NAME: 역할의 이름을 추가합니다.
    • PROJECT_ID: 호스트 프로젝트의 프로젝트 ID를 추가합니다.
    • ROLE_TITLE: 만들려는 역할의 제목을 추가합니다.
    • ROLE_DESCRIPTION: 만들려는 역할의 설명을 추가합니다.
  2. 이 커스텀 역할을 GKE 인그레스 서비스 계정에 적용합니다.

    gcloud projects add-iam-policy-binding my-project \
        --member=user:SERVICE_ACCOUNT  \
        --role=roles/gke-ingress-fw-management
    

    GKE 인그레스와 멀티 클러스터 인그레스의 SERVICE_ACCOUNT 값은 서로 다릅니다.

    • GKE 인그레스를 사용하는 경우 SERVICE_ACCOUNTPROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com입니다.

    • 멀티 클러스터 인그레스를 사용하는 경우 SERVICE_ACCOUNTPROJECT_NUMBER@gcp-sa-multiclusteringress.iam.gserviceaccount.com입니다.

    PROJECT_NUMBER를 호스트 프로젝트의 프로젝트 번호로 바꿉니다.

여러 백엔드 서비스

각각의 외부 HTTP(S) 부하 분산기 또는 내부 HTTP(S) 부하 분산기는 하나 이상의 백엔드 서비스를 나타내는 단일 URL 맵을 사용합니다. 하나의 백엔드 서비스는 인그레스로 참조되는 각 서비스에 해당합니다.

예를 들어 URL 경로에 따라 서로 다른 백엔드 서비스로 요청을 라우팅하도록 부하 분산기를 구성할 수 있습니다. your-store.example로 전송되는 요청은 정가 품목을 표시하는 백엔드 서비스로 라우팅될 수 있고, your-store.example/discounted로 전송되는 요청은 할인 품목을 표시하는 백엔드 서비스로 라우팅될 수 있습니다.

호스트 이름에 따라 요청을 라우팅하도록 부하 분산기를 구성할 수도 있습니다. your-store.example로 전송되는 요청과 your-experimental-store.example로 전송되는 요청은 서로 다른 백엔드 서비스로 라우팅될 수 있습니다.

GKE 클러스터에서는 Kubernetes Ingress 객체를 만들어 HTTP(S) 부하 분산기를 만들고 구성합니다. 인그레스 객체는 각각 pod 집합과 연결된 서비스 객체 한 개 이상과 연결되어야 합니다.

다음은 my-ingress라는 인그레스의 매니페스트입니다.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
      paths:
      - path: /*
        backend:
          serviceName: my-products
          servicePort: 60000
      - path: /discounted
        backend:
          serviceName: my-discounted-products
          servicePort: 80

인그레스를 만들면 GKE 인그레스 컨트롤러는 인그레스 및 연결된 서비스에 있는 정보에 따라 외부 HTTP(S) 부하 분산기 또는 내부 HTTP(S) 부하 분산기를 만들고 구성합니다. 또한 부하 분산기에는 도메인 이름과 연결할 수 있는 안정적인 IP 주소가 제공됩니다.

앞의 예에서 부하 분산기의 IP 주소를 도메인 이름 your-store.example에 연결했다고 가정해 보세요. 클라이언트가 요청을 your-store.example에 전송하면 요청은 포트 60000에서 my-products라는 Kubernetes 서비스로 라우팅됩니다. 클라이언트가 요청을 your-store.example/discounted에 전송하면 요청은 포트 80에서 my-discounted-products라는 Kubernetes 서비스로 라우팅됩니다.

인그레스의 path 필드에서 지원되는 유일한 와일드카드 문자는 * 문자입니다. * 문자는 슬래시(/) 다음에 와야 하며, 패턴의 마지막 문자여야 합니다. 예를 들어 /*, /foo/*, /foo/bar/*는 유효한 패턴이지만, *, /foo/bar*, /foo/*/bar는 그렇지 않습니다.

보다 구체적인 패턴이 덜 구체적인 패턴보다 우선합니다. /foo/*/foo/bar/*가 있다면 /foo/bar/*에 맞춰 /foo/bar/bat가 사용됩니다.

경로 제한사항과 패턴 일치에 대한 자세한 내용은 URL 맵 문서를 참조하세요.

my-products 서비스의 매니페스트는 다음과 같습니다.

apiVersion: v1
kind: Service
metadata:
  name: my-products
spec:
  type: NodePort
  selector:
    app: products
    department: sales
  ports:
  - protocol: TCP
    port: 60000
    targetPort: 50000

컨테이너 기반 부하 분산을 사용하지 않는 경우 서비스 매니페스트에서 type: NodePort를 사용해야 합니다. 컨테이너 기반 부하 분산을 사용하는 경우 type: ClusterIP를 사용합니다.

서비스 매니페스트에서 selector 필드는 app: products 라벨과 department: sales 라벨이 모두 있는 pod가 이 서비스의 구성원임을 나타냅니다.

포트 60000에서 서비스에 도달하는 요청은 TCP 포트 50000에서 구성원 pod 중 하나로 라우팅됩니다.

각 구성원 pod에는 TCP 포트 50000에서 리슨하는 컨테이너가 있어야 합니다.

my-discounted-products 서비스의 매니페스트는 다음과 같습니다.

apiVersion: v1
kind: Service
metadata:
  name: my-discounted-products
spec:
  type: NodePort
  selector:
    app: discounted-products
    department: sales
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

서비스 매니페스트에서 selector 필드는 app: discounted-products 라벨과 department: sales 라벨이 모두 있는 pod가 이 서비스의 구성원임을 나타냅니다.

포트 80에서 서비스에 도달하는 요청은 TCP 포트 8080에서 구성원 pod 중 하나로 라우팅됩니다.

각 구성원 pod에는 TCP 포트 8080에서 리슨하는 컨테이너가 있어야 합니다.

기본 백엔드

인그레스 매니페스트에 backend 필드를 제공하여 기본 백엔드를 지정할 수 있습니다. rules 필드의 경로와 일치하지 않는 요청은 backend 필드에서 지정된 포트와 서비스로 전송됩니다. 예를 들어 다음 인그레스에서 / 또는 /discounted와 일치하지 않는 요청은 모두 포트 60001에서 my-products라는 서비스로 전송됩니다.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  backend:
    serviceName: my-products
    servicePort: 60001
  rules:
  - http:
      paths:
      - path: /
        backend:
          serviceName: my-products
          servicePort: 60000
      - path: /discounted
        backend:
          serviceName: my-discounted-products
          servicePort: 80

기본 백엔드를 지정하지 않으면 GKE은 404를 반환하는 기본 백엔드를 제공합니다.

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

GKE 인그레스 컨트롤러는 클러스터에 배포된 인그레스 리소스에 따라 Compute Engine 부하 분산기 리소스를 배포 및 관리합니다. Compute Engine 리소스 매핑은 인그레스 리소스 구조에 따라 다릅니다. 이러한 리소스 매핑을 알고 있으면 계획, 설계, 문제해결이 수월해집니다.

여러 백엔드 서비스 섹션에 표시된 my-ingress 매니페스트는 서로 다른 Kubernetes 서비스 두 개를 참조하는 URL 경로 일치 두 개로 외부 인그레스 리소스를 지정합니다. 다음은 my-ingress를 대신하여 생성된 몇 가지 Compute Engine 리소스입니다.

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

인그레스에서 Compute Engine으로의 리소스 매핑 다이어그램

SSL 인증서 제공 옵션

HTTP(S) 부하 분산기에 SSL 인증서를 제공하는 방법에는 3가지가 있습니다.

Google 관리형 인증서
개발자 도메인의 Google 관리 SSL 인증서가 프로비저닝, 배포, 갱신, 관리됩니다. 관리형 인증서는 와일드 카드 도메인을 지원하지 않습니다.
Google Cloud와 공유되는 자체 관리형 인증서
자체 SSL 인증서를 프로비저닝하고 Google Cloud 프로젝트에 인증서 리소스를 만들 수 있습니다. 그런 다음 인그레스의 주석에 인증서 리소스를 나열하여 인증서를 사용하는 HTTP(S) 부하 분산기를 만들 수 있습니다. 자세한 내용은 사전 공유 인증서 안내를 참조하세요.
보안 비밀 리소스로서의 자체 관리형 인증서
자체 SSL 인증서를 프로비저닝하고 저장할 보안 비밀을 만들 수 있습니다. 그런 다음 인그레스 사양의 보안 비밀을 참조하여 인증서를 사용하는 HTTP(S) 부하 분산기를 만들 수 있습니다. 자세한 내용은 보안 비밀의 인증서 사용 안내를 참조하세요.

상태 확인

기본 인그레스 컨트롤러를 사용하여 인그레스를 통해 하나 이상의 서비스를 노출할 때 GKE는 Google Cloud 외부 HTTP(S) 부하 분산기 또는 Google Cloud 내부 HTTP(S) 부하 분산기를 만듭니다. 이러한 부하 분산기는 모두 단일 URL 맵에서 여러 백엔드 서비스를 지원합니다. 각 백엔드 서비스는 Kubernetes 서비스에 해당하며 각 백엔드 서비스가 Google Cloud 상태 확인을 참조해야 합니다. 상태 확인은 클러스터 외부에서 구현되기 때문에 Kubernetes 활성 또는 준비 프로브와 다릅니다.

GKE는 다음 절차에 따라 Kubernetes 서비스에 해당하는 각 백엔드 서비스에 대해 상태 확인을 만듭니다.

  • 서비스가 healthCheck 정보로 BackendConfig CRD를 참조하는 경우, GKE는 이를 사용하여 상태 확인을 만듭니다. Anthos 인그레스 컨트롤러 및 GKE 인그레스 컨트롤러 모두 이 방식으로 상태 확인 만들기를 지원합니다.

  • 서비스가 BackendConfig CRD를 참조하지 않는 경우에는 다음과 같이 수행됩니다.

    • GKE는 제공 pod가 상태 확인 매개변수로 해석될 수 있는 속성을 가진 준비 프로브가 있는 컨테이너와 함께 pod 템플릿을 사용하는 경우 상태 확인의 매개변수 일부 또는 전체를 추론할 수 있습니다. 구현 세부정보는 준비 프로브의 매개변수를, 상태 확인 매개변수를 만드는 데 사용할 수 있는 속성 목록은 기본 및 추론된 매개변수를 참조하세요. GKE 인그레스 컨트롤러만 준비 프로브의 추론 매개변수를 지원합니다.

    • 서비스 제공 pod의 pod 템플릿에 상태 확인 매개변수로 해석될 수 있는 준비 프로브가 있는 컨테이너가 없는 경우 기본값을 사용하여 상태 확인을 만듭니다. Anthos 인그레스 컨트롤러와 GKE 인그레스 컨트롤러는 기본값을 사용해서만 상태 확인을 만들 수 있습니다.

기본 및 추론된 매개변수

다음 매개변수는 BackendConfig CRD를 사용하여 상응하는 서비스의 상태 확인 매개변수를 지정하지 않는 경우에 사용됩니다.

상태 확인 매개변수 기본값 추론 가능 값
프로토콜 HTTP 서비스 주석 cloud.google.com/app-protocols에 있는 경우
요청 경로 / 제공 pod의 spec에 있는 경우:
containers[].readinessProbe.httpGet.path
요청 호스트 헤더 Host: backend-ip-address 제공 pod의 spec에 있는 경우:
containers[].readinessProbe.httpGet.httpHeaders
예상 응답 HTTP 200 (정상) HTTP 200 (정상)
변경 불가
확인 간격
  • 영역 NEG: 15초
  • 인스턴스 그룹: 60초
제공 pod의 spec에 있는 경우:
  • 영역 NEG:
    containers[].readinessProbe.periodSeconds
  • 인스턴스 그룹:
    containers[].readinessProbe.periodSeconds + 60 seconds
제한 시간 확인 5초 제공 pod의 spec에 있는 경우:
containers[].readinessProbe.timeoutSeconds
정상 기준 1 1
변경 불가
비정상 기준
  • 영역 NEG: 2
  • 인스턴스 그룹: 10
기본값과 동일:
  • 영역 NEG: 2
  • 인스턴스 그룹: 10
포트
숫자로 지정
  • 영역 NEG: 서비스의 port
  • 인스턴스 그룹: 서비스의 nodePort
인그레스 객체의 backend.servicePort가 서비스의 port를 참조하는 경우 해당 포트가 사용되며, 다음 포트도 정의됩니다.
  • 제공 pod의 준비 프로브는 다음 포트를 지정해야 합니다.
    spec.containers[].readinessProbe.httpGet.port
  • 서비스의 targetPort는 제공 pod의 containers[].spec.ports.containerPort를 참조합니다.
대상 IP 주소
  • 영역 NEG: pod의 IP 주소
  • 인스턴스 그룹: 노드의 IP 주소
기본값과 동일:
  • 영역 NEG: pod의 IP 주소
  • 인스턴스 그룹: 노드의 IP 주소

준비 프로브의 매개변수

GKE가 서비스의 백엔드 서비스에 대해 상태 확인을 만들 때, GKE는 해당 서비스의 제공 pod에서 사용되는 한 컨테이너의 준비 프로브에서 특정 매개변수를 복사할 수 있습니다. 이 옵션은 GKE 인그레스 컨트롤러에서만 지원됩니다.

상태 확인 매개변수로 해석될 수 있는 지원되는 준비 프로브 속성은 기본 및 추론된 매개변수에 기본값과 함께 나열됩니다. 기본값은 준비 프로브에서 지정되지 않은 모든 속성이나 준비 프로브를 전혀 지정하지 않은 경우에 사용됩니다.

서비스의 제공 pod에 여러 컨테이너가 포함되었거나 Anthos 인그레스 컨트롤러를 사용 중이면 BackendConfig CRD를 사용하여 상태 확인 매개변수를 정의해야 합니다. 자세한 내용은 BackendConfig CRD를 대신 사용해야 하는 경우를 참조하세요.

BackendConfig CRD를 대신 사용해야 하는 경우

다음 상황의 경우, pod 준비 프로브의 매개변수에 의존하는 대신 서비스에서 BackendConfig CRD를 만들어 백엔드 서비스의 상태 확인 매개변수를 명시적으로 정의해야 합니다.

  • Anthos를 사용하는 경우: Anthos 인그레스 컨트롤러는 제공 pod의 준비 프로브에서 상태 확인 매개변수 가져오기를 지원하지 않습니다. 암시적 매개변수를 사용하거나 BackendConfig CRD에 정의된 대로만 상태 확인을 만들 수 있습니다.

  • 제공 pod에 고유한 준비 프로브가 포함된 여러 컨테이너가 있는 경우: 서비스의 제공 pod에 컨테이너가 2개 이상 있고 각 컨테이너에 준비 프로브의 설정이 서로 다른 경우, 해당 서비스에서 BackendConfig CRD를 참조하여 해당 백엔드 서비스의 상태 확인을 정의해야 합니다. 제공 pod에 여러 준비 프로브가 있는 경우 GKE에서는 상태 확인 매개변수를 추론하는 특정 준비 프로브를 선택할 수 없습니다.

  • 부하 분산기의 상태 확인에 사용되는 포트를 제어해야 하는 경우: GKE가 백엔드 서비스의 상태 확인에 준비 프로브의 containers[].readinessProbe.httpGet.port를 사용하는 것은 인그레스 spec.rules[].http.paths[].backend.servicePort에서 참조되는 서비스의 서비스 포트와 일치하는 경우에만 가능합니다.

BackendConfig CRD의 매개변수

해당 서비스에서 참조하는 BackendConfig CRD의 healthCheck 매개변수를 사용하여 백엔드 서비스의 상태 확인 매개변수를 지정할 수 있습니다. 이렇게 하면 인그레스에서 만든 Google Cloud 외부 HTTP(S) 부하 분산기 또는 내부 HTTP(S) 부하 분산기의 상태 확인을 보다 유연하게 제어할 수 있습니다. GKE 버전 호환성은 인그레스 기능을 참조하세요.

BackendConfig CRD 예시는 spec.healthCheck 속성에서 상태 확인 프로토콜(유형), 요청 경로, 포트, 확인 간격을 정의합니다.

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: http-hc-config
spec:
  healthCheck:
    checkIntervalSec: 15
    port: 15020
    type: HTTPS
    requestPath: /healthz

여러 TLS 인증서 사용

HTTP(S) 부하 분산기로 your-store.example과 your-experimental-store.example이라는 두 가지 호스트 이름에서 콘텐츠를 제공하려 한다고 가정해 봅니다. 또한 부하 분산기가 your-store.example과 your-experimental-store.example에 각기 다른 인증서를 사용하도록 하려 합니다.

인그레스 매니페스트에서 여러 인증서를 지정할 수 있습니다. 부하 분산기는 인증서의 일반 이름(CN)이 요청에서 사용되는 호스트 이름과 일치하면 인증서를 선택합니다. 여러 인증서를 구성하는 방법에 대한 자세한 내용은 인그레스를 사용한 HTTPS 부하 분산에서 여러 SSL 인증서 사용을 참조하세요.

Kubernetes 서비스와 Google Cloud 백엔드 서비스 비교

Kubernetes 서비스Google Cloud 백엔드 서비스는 서로 다른 서비스입니다. 이 두 서비스 사이에는 밀접한 관계가 있지만 이 관계가 반드시 일대일 관계는 아닙니다. GKE 인그레스 컨트롤러는 인그레스 매니페스트에서 각 (serviceName, servicePort) 쌍을 위한 Google Cloud 백엔드 서비스를 만듭니다. 따라서 Kubernetes 서비스 객체 하나가 여러 Google Cloud 백엔드 서비스와 관련될 수 있습니다.

제한사항

  • 1.16 이전 버전을 사용하는 클러스터의 경우 네임스페이스의 전체 길이와 인그레스 이름은 40자(영문 기준)를 초과할 수 없습니다. 이 가이드라인을 따르지 않으면 GKE 인그레스 컨트롤러가 비정상적으로 작동할 수 있습니다. 자세한 내용은 GitHub의 이 문제를 참조하세요.

  • NEG를 사용하는 클러스터에서 인그레스 조정 시간은 인그레스 수에 따라 영향을 받을 수 있습니다. 예를 들어 각각 20개의 개별 NEG 백엔드가 포함된 인그레스가 20개 포함된 클러스터의 경우, 인그레스 변경사항이 조정될 때까지 30분 넘게 지연 시간이 발생할 수 있습니다. 이는 필요한 NEG의 증가로 인해 리전 클러스터에 특히 영향을 줍니다.

  • URL 맵 할당량이 적용됩니다.

  • Compute Engine 리소스 할당량이 적용됩니다.

  • GKE 인그레스 컨트롤러에서 NEG를 사용하지 않으면 GKE 클러스터의 노드 수는 1,000개로 제한됩니다. 서비스가 NEG로 배포되면 GKE 노드가 제한되지 않습니다. 인그레스를 통해 노출된 NEG가 아닌 서비스는 노드가 1000개 이상인 클러스터에서 올바르게 작동하지 않습니다.

  • GKE 인그레스 컨트롤러가 readinessProbes를 상태 확인으로 사용하려면 인그레스를 만들 때 인그레스의 pod가 있어야 합니다. 복제본 크기를 0으로 조정하면 기본 상태 확인이 적용됩니다. 자세한 내용은 이 문제 설명을 참조하세요.

  • pod의 readinessProbe 변경사항이 발생해도 인그레스는 영향을 받지 않습니다.

  • 외부 HTTP(S) 부하 분산기는 클라이언트와 부하 분산기 간의 지연 시간을 최소화하기 위해 전역으로 분산된 위치에서 TLS를 종료합니다. TLS의 종료 위치를 지리적으로 제어해야 하는 경우 LoadBalancer 유형의 GKE 서비스를 통해 제공된 커스텀 인그레스 컨트롤러를 대신 사용해야 하고, 필요한 리전에 있는 백엔드에서 TLS를 종료해야 합니다.

  • 여러 인그레스 리소스를 단일 Google Cloud 부하 분산기에 결합할 수 없습니다.

구현 세부정보

  • 인그레스 컨트롤러는 Google Cloud 프로젝트에서 테스트 리소스를 가져와서 서비스 계정 권한을 정기적으로 검사합니다. 이름은 k8s-ingress-svc-acct-permission-check-probe라는 이름의 존재하지 않는 전역 BackendServiceGET으로 표시됩니다. 이 리소스는 정상적으로 존재하지 않아야 하므로 GET 요청은 'not found'를 반환합니다. 이것은 예상된 상황입니다. 컨트롤러에서 승인 문제로 인해 API 호출이 거부되지 않았는지 확인하는 중입니다. 같은 이름으로 BackendService를 만들면 'not found'가 반환되는 대신 GET이 성공합니다.

다음 단계