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

Autopilot Standard

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

개요

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

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

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

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

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

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

GKE 인그레스 컨트롤러 동작

GKE 버전 1.18 이상을 실행하는 클러스터의 경우 GKE 인그레스 컨트롤러가 인그레스를 처리하는지 여부는 kubernetes.io/ingress.class 주석의 값에 따라 달라집니다.

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

이전 GKE 버전을 실행하는 클러스터의 경우 GKE 컨트롤러는 kubernetes.io/ingress.class 주석이 없거나 gce 또는 gce-internal 값의 주석이 있는 인그레스를 처리합니다.

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

kubernetes.io/ingress.class 주석은 Kubernetes에서 지원 중단되었지만 GKE는 이 주석을 계속 사용합니다.

ingressClassName 필드를 사용하여 GKE 인그레스를 지정할 수 없습니다. kubernetes.io/ingress.class 주석을 사용해야 합니다.

외부 애플리케이션 부하 분산기 특징

인그레스에 의해 구성되는 외부 애플리케이션 부하 분산기에는 다음 기능이 포함됩니다.

서비스의 유연한 구성. 인그레스는 트래픽이 서비스에 도달하는 방법과 트래픽이 애플리케이션으로 라우팅되는 방법을 정의합니다. 또한 인그레스는 클러스터의 여러 서비스에 단일 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를 사용 중지할 수는 없습니다.

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

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

공유 VPC

인그레스 및 MultiClusterIngress 리소스는 공유 VPC에서 지원되지만 추가 준비가 필요합니다.

인그레스 컨트롤러는 GKE 제어 영역에서 실행되며 클러스터 프로젝트의 GKE 서비스 계정을 사용하여 Google Cloud에 API 호출을 수행합니다. 기본적으로 공유 VPC 서비스 프로젝트에 있는 클러스터에 공유 VPC 네트워크가 사용될 때 인그레스 컨트롤러는 서비스 프로젝트의 GKE 서비스 계정을 사용해서 호스트 프로젝트에서 인그레스 허용 방화벽 규칙을 만들고 업데이트할 수 없습니다.

호스트 프로젝트에서 VPC 방화벽 규칙을 만들고 관리하도록 서비스 프로젝트의 GKE 서비스 계정에 권한을 부여할 수 있습니다. 이러한 권한을 부여함으로써 GKE는 다음에 대해 인그레스 허용 방화벽 규칙을 만듭니다.

외부 인그레스를 위한 외부 애플리케이션 부하 분산기에서 사용하는 Google 프런트엔드(GFE) 프록시 및 상태 점검 시스템입니다. 자세한 내용은 외부 애플리케이션 부하 분산기 개요를 참조하세요.
내부 인그레스에서 사용되는 내부 애플리케이션 부하 분산기의 상태 점검 시스템입니다.

참고: 공유 VPC 사용 여부에 관계없이 클러스터에 내부 인그레스가 사용되는 경우에는 클러스터의 VPC 네트워크 및 리전에 있는 프록시 전용 서브넷의 트래픽만 허용하도록 수동으로 인그레스 허용 방화벽 규칙을 만들어야 합니다. 이러한 규칙을 수동으로 만들어야 하는 이유는 GKE 인그레스 컨트롤러가 내부 애플리케이션 부하 분산기의 프록시 전용 서브넷에 대해 트래픽을 허용하도록 인그레스 허용 방화벽 규칙을 만들 수 없기 때문입니다. 자세한 내용은 내부 애플리케이션 부하 분산기용 인그레스에 필요한 네트워킹 환경을 참조하세요.

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

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

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

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

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 열에 표시됩니다.

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

참고: 각 인그레스 유형에 따라 서로 다른 규칙이 필요합니다. 트래픽을 허용하는 사용자 고유의 커스텀 인그레스 방화벽 규칙이 있더라도 GKE에 방화벽 규칙 경고가 표시될 수 있습니다. 이 경우에는 경고를 무시해도 됩니다.

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

서비스 프로젝트의 GKE 클러스터가 호스트 프로젝트의 방화벽 리소스를 만들고 관리하도록 하려면 서비스 프로젝트의 GKE 서비스 계정에 다음 전략 중 하나를 사용하여 적절한 IAM 권한을 부여해야 합니다.

서비스 프로젝트의 GKE 서비스 계정에 호스트 프로젝트에 대한 Compute 보안 관리자 역할을 부여합니다. 다음 예시에서는 이 전략을 보여줍니다.
세분화된 방식의 경우 compute.networks.updatePolicy, compute.firewalls.list, compute.firewalls.get, compute.firewalls.create, compute.firewalls.update, compute.firewalls.delete 권한만 포함된 커스텀 IAM 역할을 만듭니다. 서비스 프로젝트의 GKE 서비스 계정에 호스트 프로젝트에 대한 커스텀 역할을 부여합니다.

서비스 프로젝트 두 개 이상에 클러스터가 있는 경우 전략 중 하나를 선택하고 각 서비스 프로젝트의 GKE 서비스 계정에 이를 반복해야 합니다.

gcloud projects add-iam-policy-binding HOST_PROJECT_ID \
  --member=serviceAccount:service-SERVICE_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
  --role=roles/compute.securityAdmin

다음을 바꿉니다.

HOST_PROJECT_ID: 공유 VPC 호스트 프로젝트의 프로젝트 ID입니다.
SERVICE_PROJECT_NUMBER: 클러스터가 포함된 서비스 프로젝트의 프로젝트 번호입니다.

여러 백엔드 서비스

각 외부 애플리케이션 부하 분산기 또는 내부 애플리케이션 부하 분산기는 하나 이상의 백엔드 서비스를 참조하는 단일 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/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 인그레스 컨트롤러는 인그레스 및 연결된 서비스에 있는 정보에 따라 외부 애플리케이션 부하 분산기 또는 내부 애플리케이션 부하 분산기를 만들고 구성합니다. 또한 부하 분산기에는 도메인 이름과 연결할 수 있는 안정적인 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에서 리슨하는 컨테이너가 있어야 합니다.

기본 백엔드

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

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

기본 백엔드를 지정하지 않으면 GKE은 404를 반환하는 기본 백엔드를 제공합니다. 이것은 kube-system 네임스페이스의 클러스터에 default-http-backend NodePort 서비스로 생성됩니다.

404 HTTP 응답은 다음과 비슷합니다.

response 404 (backend NotFound), service rules for the path non-existent

고객 기본 백엔드로 GKE 인그레스를 설정하려면 커스텀 기본 백엔드가 있는 GKE 인그레스를 참조하세요.

인그레스에서 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 서비스의 결과로 생성됩니다.

SSL 인증서 제공 옵션

다음 방법을 사용하여 HTTP(S) 부하 분산기에 SSL 인증서를 제공할 수 있습니다.

Google 관리형 인증서: 개발자 도메인의 Google 관리 SSL 인증서가 프로비저닝, 배포, 갱신, 관리됩니다. 관리형 인증서는 와일드 카드 도메인을 지원하지 않습니다.

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

상태 점검

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

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

서비스가 healthCheck 정보로 BackendConfig CRD를 참조하는 경우, GKE는 이를 사용하여 상태 점검을 만듭니다. GKE Enterprise 인그레스 컨트롤러 및 GKE 인그레스 컨트롤러 모두 이 방식으로 상태 점검을 만들 수 있습니다.
서비스가 BackendConfig CRD를 참조하지 않는 경우에는 다음과 같이 수행됩니다.
- GKE는 제공 pod가 상태 점검 매개변수로 해석될 수 있는 속성을 가진 준비 프로브가 있는 컨테이너와 함께 pod 템플릿을 사용하는 경우 상태 점검의 매개변수 일부 또는 전체를 추론할 수 있습니다. 구현 세부정보는 준비 프로브의 매개변수를, 상태 점검 매개변수를 만드는 데 사용할 수 있는 속성 목록은 기본 및 추론된 매개변수를 참조하세요. GKE 인그레스 컨트롤러만 준비 프로브의 추론 매개변수를 지원합니다.
- 서비스 서빙 포드의 포드 템플릿에 상태 점검 매개변수로 해석될 수 있는 준비 프로브가 있는 컨테이너가 없는 경우 기본값을 사용하여 상태 점검을 만듭니다. GKE Enterprise 인그레스 컨트롤러와 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`	다음 조건에 모두 해당하는 한 상태 점검 프로브는 `spec.containers[].readinessProbe.httpGet.port`에 지정된 포트 번호로 전송됩니다. 준비 프로브의 포트 번호는 제공 포드의 `containers[].spec.ports.containerPort`와 일치해야 합니다. 제공 포드의 `containerPort`는 서비스의 `targetPort`와 일치합니다. 인그레스 서비스 백엔드 포트 사양은 서비스의 `spec.ports[]`에서 유효한 포트를 참조합니다. 이는 다음 두 가지 방법 중 하나로 수행할 수 있습니다. 인그레스의 `spec.rules[].http.paths[].backend.service.port.name`이 해당 서비스에 정의된 `spec.ports[].name`과 일치합니다. 인그레스의 `spec.rules[].http.paths[].backend.service.port.number`가 해당 서비스에 정의된 `spec.ports[].port`와 일치합니다.
대상 IP 주소	영역 NEG: Pod의 IP 주소 인스턴스 그룹: 노드의 IP 주소	기본값과 동일: 영역 NEG: Pod의 IP 주소 인스턴스 그룹: 노드의 IP 주소

준비 프로브의 매개변수

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

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

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

경고 : 백엔드 서비스의 상태 점검 매개변수가 제공 Pod의 준비 프로브에서 추론되면 GKE는 준비 프로브와 상태 점검을 동기화하지 않습니다.

GKE가 인그레스에 대한 외부 애플리케이션 부하 분산기 또는 내부 애플리케이션 부하 분산기를 만든 후 해당 인그레스가 참조하는 서비스 제공 포드의 준비 프로브를 변경하는 경우 준비 프로브에 대한 변경사항이 부하 분산기의 해당 백엔드 서비스에 대한 상태 점검에 복사되지 않습니다.
반대로, 인그레스를 대신하여 만든 부하 분산기의 백엔드 서비스에서 사용하는 상태 점검을 변경하는 경우 GKE는 준비 프로브를 업데이트하거나 상태 점검에 대한 변경사항을 되돌리지 않습니다.

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

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

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

제공 포드에 컨테이너가 두 개 이상 있는 경우: GKE에는 상태 점검 매개변수를 추론할 특정 컨테이너의 준비 프로브를 선택할 방법이 없습니다. 각 컨테이너에는 자체 준비 프로브가 있을 수 있고 준비 프로브가 컨테이너에 필요한 매개변수가 아니기 때문에 해당 서비스에서 BackendConfig CRD를 참조하여 해당 백엔드 서비스에 대한 상태 점검을 정의해야 합니다.
부하 분산기의 상태 점검에 사용되는 포트를 제어해야 하는 경우: GKE가 백엔드 서비스의 상태 점검에 준비 프로브의 containers[].readinessProbe.httpGet.port를 사용하는 것은 인그레스 spec.rules[].http.paths[].backend.servicePort에서 참조되는 서비스의 서비스 포트와 일치하는 경우에만 가능합니다.

`BackendConfig` CRD의 매개변수

해당 서비스에서 참조하는 BackendConfig CRD의 healthCheck 매개변수를 사용하여 백엔드 서비스의 상태 점검 매개변수를 지정할 수 있습니다. 이렇게 하면 인그레스에서 만든 기본 애플리케이션 부하 분산기나 내부 애플리케이션 부하 분산기의 상태 점검을 보다 유연하게 제어할 수 있습니다. 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

BackendConfig 상태 점검을 구성할 때 사용 가능한 모든 필드를 구성하려면 커스텀 상태 점검 구성 예시를 사용합니다.

커스텀 HTTP 상태 점검을 사용하여 GKE 인그레스를 설정하려면 커스텀 HTTP 상태 점검으로 GKE 인그레스를 참조하세요.

여러 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 인그레스 컨트롤러는 인그레스 매니페스트에서 각 (service.name, service.port) 쌍을 위한 Google Cloud 백엔드 서비스를 만듭니다. 따라서 Kubernetes 서비스 객체 하나가 여러 Google Cloud 백엔드 서비스와 관련될 수 있습니다.

제한사항

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

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

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

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

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

구현 세부정보

인그레스 컨트롤러는 Google Cloud 프로젝트에서 테스트 리소스를 가져와서 서비스 계정 권한을 주기적으로 확인합니다. 이것은 이름이 k8s-ingress-svc-acct-permission-check-probe인 (존재하지 않는) 전역 BackendService의 GET로 표시됩니다. 이 리소스는 일반적으로 존재하지 않으므로, GET 요청이 '찾을 수 없음'을 반환합니다. 이것은 예상된 상황이며, 컨트롤러가 승인 문제로 인해 API 호출이 거부되지 않았는지 확인합니다. 동일한 이름으로 BackendService를 만들면 '찾을 수 없음'을 반환하는 대신 GET이 성공합니다.

인그레스 구성 템플릿

GKE 네트워킹 레시피에는 GKE가 제공하는 템플릿은 일반적으로 많은 인그레스 섹션에서 여러 일반적인 인그레스 사용에 대해 확인할 수 있습니다.