인그레스 기능

이 페이지에서는 Google Cloud에서 Kubernetes 인그레스를 통해 지원되고 구성 가능한 항목을 포괄적으로 간략하게 설명합니다. Google Kubernetes Engine(GKE) 및 Anthos용 인그레스는 Google Cloud VPC 네트워크와 긴밀하게 통합되는 엔터프라이즈급 부하 분산 기능을 제공합니다.

기능 비교

다음 표에는 Google Cloud에서 인그레스에 지원되는 기능이 나열되어 있습니다.

인그레스 클래스 외부 인그레스 내부 인그레스 멀티 클러스터 인그레스
인그레스 컨트롤러 GKE 인그레스
(GKE 제어 영역에서 호스팅)
Anthos 인그레스
(Google 호스팅)
Google Cloud 부하 분산기 유형 외부 HTTP(S) 부하 분산기 내부 HTTP(S) 부하 분산기 외부 HTTP(S) 부하 분산기
클러스터 범위 단일 클러스터 단일 클러스터 멀티 클러스터
부하 분산기 범위 전역 리전 전역
버전 지원 전체 GKE 1.16.5+ GKE 1.14 이상
환경 지원 GKE GKE GKE
공유 VPC 지원
서비스 주석
컨테이너 기반 부하 분산(NEG)
부하 분산기에서 백엔드로의 HTTPS
HTTP/2
인그레스 주석
고정 IP 주소
Kubernetes 보안 비밀 기반 인증서
Google 자체 관리 SSL 인증서
Google 관리 SSL 인증서
FrontendConfig(베타)
SSL 정책
1.17.6-gke.11B
BackendConfig
백엔드 서비스 제한 시간
Cloud CDN
연결 드레이닝 제한 시간
커스텀 부하 분산기 상태 확인 구성
1.17.6-gke.11B

1.17.6-gke.11B
Google Cloud Armor 보안 정책
HTTP 액세스 로깅 구성
1.16.10-gke.6G

1.16.10-gke.6B
IAP(Identity-Aware Proxy)
세션 어피니티
사용자 정의 요청 헤더
1.15.3-gke.1G

G이 기능은 지정된 버전부터 일반 안정화 버전으로 지원됩니다.

B이 기능은 지정된 버전부터 베타 버전으로 제공됩니다. 나열된 버전이 없는 기능은 사용 가능한 모든 GKE 및 Anthos 버전에서 지원됩니다.

인그레스 기능 구성

기본 컨트롤러를 사용하여 인그레스를 만들 때 인그레스 객체에 주석을 사용하여 부하 분산기 유형(외부 HTTP(S) 부하 분산기 또는 내부 HTTP(S) 부하 분산기)을 선택할 수 있습니다. GKE에서 영역 NEG를 만들지 또는 각 서비스 객체에 주석을 사용하여 인스턴스 그룹을 사용할지 여부를 선택할 수 있습니다.

FrontendConfig 및 BackendConfig 커스텀 리소스 정의(CRD)를 사용하면 부하 분산기를 추가로 맞춤설정할 수 있습니다. 이 CRD를 사용하면 주석보다 더욱 구조화된 방식으로 추가적인 부하 분산기 기능을 계층화하여 정의할 수 있습니다. 인그레스(및 이 CRD)를 사용하려면 HTTP 부하 분산 부가기능을 사용 설정해야 합니다. GKE 클러스터에는 기본적으로 HTTP 부하 분산이 사용 설정되어 있으며 사용 중지하면 안 됩니다.

FrontendConfig는 인그레스 객체에서 참조되고 BackendConfig는 서비스 객체에서 참조됩니다. 일관적인 구성으로 인해 여러 서비스 또는 인그레스 객체에서 같은 CRD를 참조할 수 있습니다. FrontendConfig CRD와 BackendConfig CRD는 해당하는 인그레스 및 서비스 리소스와 동일한 수명 주기를 공유하며 종종 함께 배포됩니다.

아래 다이어그램은 다음이 어떻게 참조되는지 보여줍니다.

  • 인그레스 또는 MultiClusterIngress 객체의 주석은 FrontendConfig CRD를 참조합니다. FrontendConfig CRD는 Google Cloud SSL 정책을 참조합니다.

  • 서비스 또는 MultiClusterService 객체의 주석은 BackendConfig CRD를 참조합니다. BackendConfig CRD는 해당 백엔드 서비스의 상태 확인용 커스텀 설정을 지정합니다.

BackendConfig 및 FrontendConfig 개요
그림: BackendConfig 및 FrontendConfig 개요

FrontendConfig를 인그레스와 연결

FrontendConfig CRD는 인그레스 또는 MultiClusterIngress 리소스의 주석에서 참조됩니다. FrontendConfig는 다음 예시와 같이 전체 인그레스/MultiClusterIngress 리소스에 해당합니다.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    networking.gke.io/v1beta1.FrontendConfig: "frontendconfig"
...

BackendConfig를 인그레스와 연결

BackendConfig CRD는 서비스 또는 MultiClusterService 리소스의 주석에서 참조됩니다. 서비스 또는 MultiClusterService는 cloud.google.com/backend-config 주석을 사용하여 BackendConfig 이름을 지정합니다. 서비스 또는 MultiClusterService와 연결된 BackendConfig는 Google Cloud 백엔드 서비스 설정을 파악할 수 있습니다. 다음 예시에서는 BackendConfig를 서비스 또는 MultiClusterService에 연결하는 방법을 보여줍니다. default 키는 서비스 내의 모든 포트가 인그레스에서 참조될 때 my-backendconfig BackendConfig와 연결되어 있음을 의미합니다.

1.16-gke.3+

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

지원되는 모든 버전

apiVersion: v1
kind: Service
metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"default": "my-backendconfig"}'
...

동일한 서비스 내의 여러 포트에 고유한 BackendConfig 설정이 필요한 경우 특정 BackendConfig 리소스를 해당 포트에 명시적으로 연결할 수 있습니다. 다음 예시에서 ports 키는 포트의 명시적 연결을 허용합니다.

1.16-gke.3+

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{"ports": {
    "port-1":"backendconfig-1",
    "port-2":"backendconfig-2"
    }}'
spec:
  ports:
  - name:service-name-1
    port: 8001
    protocol: TCP
    targetPort: service-port-1
  - name: service-name-2
    port: 8002
    protocol: TCP
    targetPort: service-port-2
...

지원되는 모든 버전

apiVersion: v1
kind: Service
metadata:
  annotations:
    beta.cloud.google.com/backend-config: '{"ports": {
    "port-1":"backendconfig-1",
    "port-2":"backendconfig-2"
    }}'
spec:
  ports:
  - name: service-name-1
    port: 8001
    protocol: TCP
    targetPort: service-port-1
  - name: service-name-2
    port: 8002
    protocol: TCP
    targetPort: >service-port-2
...

port-1service-port-1(번호) 또는 service-name-1(이름)을 통해 서비스 내의 포트를 참조할 수 있습니다(GKE에서만 지원됨). 각 포트는 Google Cloud 부하 분산기 백엔드 서비스에 매핑되므로 서비스 내 포트의 구성이 다를 수 있습니다.

FrontendConfig 매개변수를 통한 인그레스 기능 구성

다음 섹션에서는 특정 인그레스 기능을 사용 설정하도록 FrontendConfig를 설정하는 방법을 보여줍니다.

SSL 정책

SSL 정책을 사용하면 부하 분산기가 클라이언트의 HTTPS 트래픽을 종료하는 데 사용하는 TLS 버전과 암호화 집합을 지정할 수 있습니다. 먼저 GKE 외부에서 SSL 정책을 만들어야 합니다. 만든 후에는 FrontendConfig CRD에서 이를 참조할 수 있습니다.

FrontendConfig의 sslPolicy 필드는 GKE 클러스터와 동일한 Google Cloud 프로젝트의 SSL 정책 이름을 참조합니다. 인그레스에서 외부 HTTP(S) 부하 분산기용으로 만든 대상 HTTPS 프록시에 SSL 정책을 연결합니다. 동일한 FrontendConfig 리소스와 SSL 정책은 여러 인그레스 리소스에서 참조할 수 있습니다. 참조되는 SSL 정책이 변경되면 인그레스에 의해 생성된 외부 HTTP 부하 분산기를 구동하는 Google 프런트엔드(GFE)에 변경사항이 전파됩니다.

다음 FrontendConfig 매니페스트는 gke-ingress-ssl-policy라는 SSL 정책을 사용 설정합니다.

apiVersion: networking.gke.io/v1beta1
kind: FrontendConfig
metadata:
  name: my-frontend-config
spec:
  sslPolicy: gke-ingress-ssl-policy

BackendConfig 매개변수를 통한 인그레스 기능 구성

다음 섹션에서는 특정 인그레스 기능을 사용 설정하도록 BackendConfig를 설정하는 방법을 보여줍니다. BackendConfig 리소스 변경사항은 지속적으로 조정되므로 BackendConfig 변경사항을 반영하기 위해 인그레스를 삭제한 후 다시 만들 필요가 없습니다.

BackendConfig 제한사항에 대한 자세한 내용은 제한사항 섹션을 참조하세요.

백엔드 서비스 제한 시간

BackendConfig를 사용하여 백엔드 서비스 제한 시간을 초 단위로 설정할 수 있습니다. 값을 지정하지 않을 경우 기본값은 30초입니다.

다음 BackendConfig 매니페스트는 제한 시간을 40초로 지정합니다.

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40

Cloud CDN

BackendConfig를 사용하여 Cloud CDN을 사용 설정할 수 있습니다.

다음 BackendConfig 매니페스트는 Cloud CDN을 사용 설정할 때 사용할 수 있는 모든 필드를 보여줍니다.

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: cdnEnabled
    cachePolicy:
      includeHost: includeHost
      includeProtocol:includeProtocol
      includeQueryString: includeQueryString
      queryStringBlacklist:queryStringBlacklist
      queryStringWhitelist: queryStringWhitelist

다음을 바꿉니다.

  • cdnEnabled: true로 설정하면 이 인그레스 백엔드에 Cloud CDN이 사용 설정됩니다.
  • includeHost: true로 설정하면 서로 다른 호스트에 대한 요청이 개별적으로 캐시됩니다.
  • includeProtocol: true로 설정하면 HTTP 및 HTTPS 요청이 개별적으로 캐시됩니다.
  • includeQueryString: true로 설정하면 쿼리 문자열 매개변수는 queryStringBlacklist 또는 queryStringWhitelist에 따라 캐시 키에 포함됩니다. 어느 것도 설정되지 않으면 전체 쿼리 문자열이 포함됩니다. false로 설정하면 전체 쿼리 문자열이 캐시 키에서 제외됩니다.
  • queryStringBlacklist: 캐시 키에서 제외할 쿼리 문자열 매개변수의 이름으로 문자열 배열을 지정합니다. 다른 모든 매개변수가 포함됩니다. queryStringBlacklist 또는 queryStringWhitelist 중 하나를 지정할 수 있지만 둘 다 지정할 수 없습니다.
  • queryStringWhitelist: 캐시 키에 포함할 쿼리 문자열 매개변수의 이름으로 문자열 배열을 지정합니다. 다른 모든 매개변수는 제외됩니다. queryStringBlacklist 또는 queryStringWhitelist 중 하나를 지정할 수 있지만 둘 다 지정할 수 없습니다.

다음 섹션을 펼치면 인그레스를 통해 Cloud CDN을 배포한 후 애플리케이션 콘텐츠가 캐시되는지 검사하는 예시를 볼 수 있습니다.

연결 드레이닝 제한 시간

BackendConfig를 사용하여 연결 드레이닝 제한 시간을 구성할 수 있습니다. 연결 드레이닝 제한 시간은 연결이 드레이닝될 때까지 기다리는 시간(초)입니다. 지정된 제한 시간 동안 삭제된 백엔드에 대한 기존 요청에 완료할 시간이 제공됩니다. 부하 분산기는 새로운 요청을 삭제된 백엔드에 보내지 않습니다. 제한 시간에 도달하면 백엔드에 남아있는 모든 연결이 닫힙니다. 제한 시간을 0~3600초로 지정할 수 있습니다. 기본값은 0이며 이 경우 연결 드레이닝이 중지됩니다.

다음 BackendConfig 매니페스트는 연결 드레이닝 제한 시간을 60초로 지정합니다.

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  connectionDraining:
    drainingTimeoutSec: 60

커스텀 상태 확인 구성

인그레스를 통해 배포할 때 GKE는 Google Cloud 부하 분산기 상태 확인을 다양한 방법으로 구성할 수 있습니다. GKE 인그레스가 상태 확인을 배포하는 방법에 대한 자세한 내용은 인그레스 상태 확인을 참조하세요.

한 가지 방법은 BackendConfig를 통해 명시적으로 상태 확인을 구성하는 것입니다. 이 매개변수를 설정하면 Kubernetes 준비 프로브 설정과 상태 확인 기본값이 대체됩니다.

재사용 가능한 템플릿과 동일한 BackendConfig를 참조하도록 여러 GKE 서비스를 구성할 수 있습니다. healthCheck 매개변수의 경우 각 GKE 서비스에 해당하는 백엔드 서비스마다 고유한 Google Cloud 상태 확인이 생성됩니다.

다음 BackendConfig 매니페스트는 BackendConfig 상태 확인을 구성할 때 사용할 수 있는 모든 필드를 보여줍니다.

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  healthCheck:
    checkIntervalSec: interval
    timeoutSec: timeout
    healthyThreshold: health-threshold
    unhealthyThreshold: unhealthy-threshold
    type: protocol
    requestPath: path
    port: port

다음을 바꿉니다.

  • interval: 각 상태 확인 프로버에 check-interval을 초 단위로 지정합니다. 이 값은 한 프로버에서 확인을 시작한 후 다음 번에 확인을 시작할 때까지 걸리는 시간입니다. 이 매개변수를 생략하면 Google Cloud 기본값인 5초가 사용됩니다. 자세한 구현 내용은 여러 프로브 및 빈도를 참조하세요.
  • timeout: Google Cloud가 프로브에 대한 응답을 기다리는 시간을 지정합니다. timeout 값은 interval 이하여야 합니다. 단위는 초입니다. 각 프로브에는 프로브 시간 초과 전에 HTTP 200 (OK) 응답 코드가 전송되어야 합니다.
  • health-thresholdunhealthy-threshold: 프로버 최소 한 개 이상에서 상태가 정상에서 비정상으로 또는 그 반대로 변경되기 위해 성공 또는 실패해야 하는 순차적인 연결 시도 수를 지정합니다. 이러한 매개변수 중 하나를 생략하면 Google Cloud에서 기본값 2를 사용합니다.
  • protocol: 프로브 시스템에서 상태 확인에 사용되는 프로토콜을 지정합니다. BackendConfig는 HTTP, HTTPS 또는 HTTP2 프로토콜을 사용한 상태 확인 생성만 지원합니다. 자세한 내용은 HTTP, HTTPS, HTTP/2의 성공 기준을 참조하세요. 이 매개변수를 생략할 수 없습니다.
  • path: HTTP, HTTPS 또는 HTTP2 상태 확인에 프로브 시스템을 연결할 request-path를 지정합니다. 이 매개변수를 생략하면 Google Cloud에서 기본값 /를 사용합니다.
  • port: 포트 번호를 사용하여 포트를 지정합니다. 이 매개변수를 생략하면 Google Cloud에서 기본값 80을 사용합니다. 컨테이너 기반 부하 분산을 사용하면 프로브 시스템이 제공 pod의 IP 주소에 연결됩니다. 그렇지 않으면 상태 확인 프로브가 제공 pod가 실행 중인 노드의 IP 주소에 연결됩니다.

Google Cloud Armor 보안 정책

Google Cloud Armor 보안 정책을 사용하면 웹 기반 공격으로부터 부하 분산 애플리케이션을 보호할 수 있습니다. Google Cloud Armor 보안 정책을 구성한 후에는 BackendConfig를 사용하여 이를 참조할 수 있습니다.

BackendConfig에 보안 정책 이름을 추가합니다. 다음 BackendConfig 매니페스트는 example-security-policy라는 보안 정책을 지정합니다.

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  namespace: cloud-armor-how-to
  name: my-backendconfig
spec:
  securityPolicy:
    name: "example-security-policy"

HTTP 액세스 로깅

인그레스는 클라이언트의 모든 HTTP 요청을 Cloud Logging에 로깅할 수 있습니다. BackendConfig를 사용하여 액세스 로깅을 사용 설정하거나 중지하고 액세스 로깅 샘플링 레이트를 설정할 수 있습니다.

액세스 로깅을 구성하려면 BackendConfig의 logging 필드를 사용합니다. logging을 생략하면 액세스 로깅이 기본 동작으로 설정됩니다. 이는 GKE 버전에 따라 달라집니다. 액세스 로깅의 기본값은 GKE 1.18 이전의 모든 버전에서 '켜짐'이지만 1.16.8-gke.10부터는 구성 가능한 필드로 노출됩니다.

다음 필드를 구성할 수 있습니다.

  • enable: true로 설정하면 이 인그레스에 액세스 로깅이 사용 설정되며 Cloud Logging에 로그가 제공됩니다. 그렇지 않으면 이 인그레스에 액세스 로깅이 중지됩니다.
  • sampleRate: 0.0~1.0 범위의 값을 지정합니다. 이때 0.0은 패킷이 로깅되지 않음을 의미하고 1.0은 패킷 모두가 로깅됨을 의미합니다. 이 필드는 enabletrue로 설정된 경우에만 관련이 있습니다. sampleRate는 선택적 필드이지만 구성되는 경우 enable: true를 설정해야 합니다. 그렇지 않으면 enable: false로 해석됩니다.

다음 BackendConfig는 액세스 로깅을 사용 설정하고 지정된 인그레스 리소스의 샘플링 레이트를 HTTP 요청의 50%로 설정합니다.

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  logging:
    enable: true
    sampleRate: 0.5

IAP(Identity-Aware Proxy)

IAP(Identity-Aware Proxy)용 BackendConfig를 구성하려면 BackendConfig의 iap 블록에 enabled 값과 secretName 값을 지정해야 합니다. 이러한 값을 지정하려면 compute.backendServices.update 권한이 있어야 합니다.

다음 BackendConfig 매니페스트는 IAP(Identity-Aware Proxy)를 사용 설정합니다.

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name:  my-backendconfig
spec:
  iap:
    enabled: true
    oauthclientCredentials:
      secretName: my-secret

자세한 안내는 IAP 문서의 GKE에 IAP 사용 설정을 참조하세요.

세션 어피니티

BackendConfig를 사용하여 세션 어피니티를 클라이언트 IP나 생성된 쿠키로 설정할 수 있습니다.

클라이언트 IP 어피니티

BackendConfig를 사용하여 클라이언트 IP 어피니티를 설정하려면 다음 예시와 같이 affinityType"CLIENT_IP"로 설정합니다.

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "CLIENT_IP"

BackendConfig를 사용하여 생성된 쿠키 어피니티를 설정하려면 BackendConfig 매니페스트에서 affinityTypeGENERATED_COOKIE로 설정합니다. 또한 affinityCookieTtlSec을 사용하여 쿠키가 활성 상태로 유지되는 기간을 설정할 수 있습니다.

다음 매니페스트는 어피니티 유형을 생성된 쿠키로 설정하고 쿠키에 TTL 50초를 제공합니다.

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  sessionAffinity:
    affinityType: "GENERATED_COOKIE"
    affinityCookieTtlSec: 50

사용자 정의 요청 헤더

BackendConfig를 사용하여 사용자 정의 요청 헤더를 구성할 수 있습니다. 부하 분산기는 지정된 헤더를 백엔드로 전달하는 요청에 추가합니다.

사용자 정의 요청 헤더를 사용 설정하려면 BackendConfig 리소스의 customRequestHeaders 속성에 헤더 목록을 지정합니다. 각 헤더를 header-name:header-value 문자열로 지정합니다.

다음 BackendConfig 매니페스트는 요청 헤더 세 개를 추가합니다.

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  customRequestHeaders:
    headers:
    - "X-Client-Region:{client_region}"
    - "X-Client-City:{client_city}"
    - "X-Client-CityLatLong:{client_city_lat_long}"

연습: 백엔드 서비스를 사용한 인그레스 제한 시간 설정

다음 연습에서는 BackendConfig 리소스로 인그레스에 제한 시간과 연결 드레이닝을 구성하는 데 필요한 단계를 보여줍니다.

인그레스의 백엔드 속성을 구성하려면 다음 태스크를 완료합니다.

  1. 배포를 만듭니다.
  2. BackendConfig를 만듭니다.
  3. 서비스를 만들고 포트 중 하나를 BackendConfig에 연결합니다.
  4. 인그레스를 만들고 (서비스, 포트) 쌍과 연결합니다.
  5. 백엔드 서비스 속성의 유효성을 검사합니다.
  6. 삭제합니다.

배포 만들기

BackendConfig와 서비스를 만들기 전에 배포를 만들어야 합니다.

다음은 my-deployment.yaml이라는 배포의 매니페스트 예시입니다.

# my-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  selector:
    matchLabels:
      purpose: bsc-config-demo
  replicas: 2
  template:
    metadata:
      labels:
        purpose: bsc-config-demo
    spec:
      containers:
      - name: hello-app-container
        image: gcr.io/google-samples/hello-app:1.0

다음 명령어를 실행하여 배포를 만듭니다.

kubectl apply -f my-deployment.yaml

BackendConfig 만들기

BackendConfig를 사용하여 사용하려는 인그레스 기능을 지정합니다.

my-backendconfig.yaml이라는 이 BackendConfig 매니페스트는 다음을 지정합니다.

  • 제한 시간 40초
  • 연결 드레이닝 제한 시간 60초
# my-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  timeoutSec: 40
  connectionDraining:
    drainingTimeoutSec: 60

BackendConfig를 사용하여 설정할 수 있는 기능의 전체 목록은 기능 표의 BackendConfig 섹션을 참조하세요.

다음 명령어를 실행하여 BackendConfig를 만듭니다.

kubectl apply -f my-backendconfig.yaml

서비스 만들기

BackendConfig는 서비스에 포트가 여러 개 있더라도 서비스-포트 조합 하나에 일치합니다. 각 포트를 BackendConfig CRD 하나와 연결할 수 있습니다. 서비스 포트가 인그레스에서 참조되는 경우와 서비스 포트가 BackendConfig와 연결되는 경우 HTTP(S) 부하 분산 백엔드 서비스는 BackendConfig에서 해당 구성을 사용합니다.

다음은 my-service.yaml이라는 서비스 매니페스트의 예시입니다.

# my-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-service
  labels:
    purpose: bsc-config-demo
  annotations:
    cloud.google.com/backend-config: '{"ports": {"80":"my-backendconfig"}}'
    cloud.google.com/neg: '{"ingress": true}'
spec:
  type: ClusterIP
  selector:
    purpose: bsc-config-demo
  ports:
  - port: 80
    protocol: TCP
    targetPort: 8080

cloud.google.com/backend-config 주석은 포트와 BackendConfig 객체 사이의 매핑을 지정합니다. my-service.yaml 파일은 다음과 같습니다.

  • purpose: bsc-config-demo 라벨이 있는 모든 pod가 서비스의 구성원입니다.
  • 서비스의 TCP 포트 80이 my-backendconfig라는 BackendConfig와 연결됩니다. cloud.google.com/backend-config 주석에 이 항목이 지정되어 있습니다.
  • 서비스의 포트 80에 전송된 요청은 포트 8080의 구성원 pod 중 하나로 전달됩니다.

서비스를 만들려면 다음 명령어를 실행합니다.

kubectl apply -f my-service.yaml

인그레스 만들기

다음은 my-ingress.yaml.이라는 인그레스 매니페스트입니다. 이 예시에서 들어오는 요청은 my-service라는 서비스의 포트 80으로 라우팅됩니다.

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

인그레스를 만들려면 다음 명령어를 실행합니다.

kubectl apply -f my-ingress.yaml

인그레스 컨트롤러에서 HTTP(S) 부하 분산과 연결된 백엔드 서비스를 구성할 때까지 몇 분 정도 기다립니다. 이 작업이 완료되면 제한 시간 40초, 연결 드레이닝 제한 시간 60초를 사용하도록 인그레스가 구성됩니다.

백엔드 서비스 속성 유효성 검사

BackendConfig를 통해 올바른 부하 분산기 설정이 적용되었는지 검사할 수 있습니다. 이렇게 하려면 인그레스에서 배포한 백엔드 서비스를 파악하고 해당 설정이 배포 매니페스트와 일치하는지 검사합니다.

먼저 my-ingress 리소스를 설명하고 인그레스와 연결된 백엔드 서비스를 나열하는 주석을 필터링합니다. 예를 들면 다음과 같습니다.

kubectl describe ingress my-ingress | grep ingress.kubernetes.io/backends

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

ingress.kubernetes.io/backends: '{"k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY","k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"}

출력에는 백엔드 서비스에 대한 정보가 제공됩니다. 예를 들어 이 주석에는 백엔드 서비스 두 개가 포함되어 있습니다.

  • "k8s1-27fde173-default-my-service-80-8d4ca500":"HEALTHY"my-service Kubernetes 서비스에 연결된 백엔드 서비스에 대한 정보를 제공합니다.
    • k8s1-27fde173은 클러스터를 설명하는 데 사용되는 해시입니다.
    • default는 Kubernetes 네임스페이스입니다.
    • HEALTHY는 백엔드가 정상임을 나타냅니다.
  • "k8s1-27fde173-kube-system-default-http-backend-80-18dfe76c":"HEALTHY"기본 백엔드(404-server)에 연결된 백엔드 서비스에 대한 정보를 제공합니다.
    • k8s1-27fde173은 클러스터를 설명하는 데 사용되는 해시입니다.
    • kube-system은 네임스페이스입니다.
    • default-http-backend는 Kubernetes 서비스 이름입니다.
    • 80은 호스트 포트입니다.
    • HEALTHY는 백엔드가 정상임을 나타냅니다.

다음으로 gcloud를 사용하여 my-service와 연결된 백엔드 서비스를 검사합니다. "drainingTimeoutSec""timeoutSec"을 필터링하여 Google Cloud 부하 분산기 제어 영역에서 설정되어 있는지 확인합니다. 예를 들면 다음과 같습니다.

# Optionally, set a variable
export BES=k8s1-27fde173-default-my-service-80-8d4ca500

# Filter for drainingTimeoutSec and timeoutSec
gcloud compute backend-services describe ${BES} --global | grep -e "drainingTimeoutSec" -e "timeoutSec"

출력:

  drainingTimeoutSec: 60
  timeoutSec: 40

출력에서 drainingTimeoutSectimeoutSec을 확인하면 값이 BackendConfig를 통해 올바르게 설정되었는지 확인할 수 있습니다.

삭제

계정에서 원치 않는 비용이 발생하지 않도록 하려면 이 연습용으로 만든 Kubernetes 객체를 삭제합니다.

kubectl delete ingress my-ingress
kubectl delete service my-service
kubectl delete backendconfig my-backendconfig
kubectl delete deployment my-deployment

BackendConfig 제한사항

BackendConfig에는 다음과 같은 제한사항이 있습니다.

  • 여러 인그레스 객체가 (서비스, 포트)를 참조하더라도 (서비스, 포트) 쌍 하나만 BackendConfig를 한 개만 사용할 수 있습니다. 즉, 동일한 (서비스, 포트)를 참조하는 모든 인그레스 객체는 Google Cloud Armor, Cloud IAP, Cloud CDN의 동일한 구성을 사용해야 합니다.

  • 동일한 HTTP(S) 부하 분산 백엔드 서비스에는 IAP 및 Cloud CDN을 사용 설정할 수 없습니다. 즉, 동일한 BackendConfig에서 IAP 및 Cloud CDN을 모두 구성할 수 없습니다.

  • BackendConfig와의 상호작용하려면 kubectl 1.7 이상을 사용해야 합니다.

FrontendConfig 또는 BackendConfig에 지정된 구성 삭제

인그레스 기능을 취소하려면 FrontendConfig CRD나 BackendConfig CRD에서 기능 구성을 명시적으로 중지해야 합니다. 인그레스 컨트롤러는 이러한 CRD에 지정된 구성만 조정합니다.

이전에 사용 설정된 구성을 삭제하거나 중지하려면 필드 유형에 따라 필드 값을 빈 문자열("") 또는 부울 값 false로 설정합니다.

다음 BackendConfig 매니페스트는 Google Cloud Armor 보안 정책과 Cloud CDN을 중지합니다.

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: my-backendconfig
spec:
  cdn:
    enabled: false
  securityPolicy:
    name: ""

FrontendConfig 또는 BackendConfig 삭제

FrontendConfig

FrontendConfig를 삭제하려면 다음 단계를 따르세요.

  1. 인그레스 매니페스트의 networking.gke.io/v1beta1.FrontendConfig 주석에서 FrontendConfig 이름을 삭제합니다.

  2. 변경된 인그레스 매니페스트를 클러스터에 적용합니다. 예를 들어 kubectl apply를 사용합니다.

  3. FrontendConfig를 삭제합니다. 예를 들어 kubectl delete frontendconfig config my-frontendconfig를 사용합니다.

BackendConfig

BackedConfig를 삭제하려면 다음 단계를 따르세요.

  1. 서비스 매니페스트에 있는 cloud.google.com/backend-config 주석에서 BackendConfig 이름을 삭제합니다.

  2. 변경된 서비스 매니페스트를 클러스터에 적용합니다. 예를 들어 kubectl apply를 사용합니다.

  3. BackendConfig를 삭제합니다. 예를 들어 kubectl delete backendconfig my-backendconfig를 사용합니다.

문제해결

BackendConfig를 찾을 수 없음

이 오류는 서비스 포트의 BackendConfig가 서비스 주석에 지정되었지만 실제 BackendConfig 리소스를 찾을 수 없을 때 발생합니다. 이 오류는 개발자가 BackendConfig 리소스를 만들지 않았거나, 잘못된 네임스페이스에 만들었거나, 서비스 주석에서 참조 철자를 잘못 쓴 경우에 발생할 수 있습니다.

Kubernetes 이벤트를 평가하려면 다음 명령어를 실행합니다.

kubectl get event

다음 출력 유형은 BackendConfig를 찾을 수 없음을 나타냅니다.

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: error getting BackendConfig for port 80 on service "default/my-service":
no BackendConfig for service port exists

보안 정책을 찾을 수 없음

인그레스 객체가 생성된 다음 보안 정책이 부하 분산기 서비스와 올바르게 연결되지 않은 경우, Kubernetes 이벤트에서 구성 실수가 있는지 확인합니다. BackendConfig에 존재하지 않는 정책이 지정되면 경고 이벤트가 주기적으로 발생합니다. 이 문제를 해결하려면 BackendConfig에서 올바른 보안 정책 이름을 지정했는지 확인합니다.

Kubernetes 이벤트를 평가하려면 다음 명령어를 실행합니다.

kubectl get event

다음 출력 유형은 보안 정책을 찾을 수 없음을 나타냅니다.

KIND    ... SOURCE
Ingress ... loadbalancer-controller

MESSAGE
Error during sync: The given security policy "my-policy" does not exist.

다음 단계