GKE 인그레스 트래픽 보안

Autopilot Standard

이 페이지에서는 Google Kubernetes Engine (GKE) 인그레스의 트래픽을 보호하고 최적화하는 방법을 보여줍니다. 클라이언트와 부하 분산기 간에 SSL 인증서를 구성하고 부하 분산기와 백엔드 애플리케이션 간의 트래픽을 보호할 수 있습니다. 계속하기 전에 GKE에서 HTTPS로 인그레스를 보호하는 방법을 숙지해야 합니다.

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

클라이언트와 부하 분산기 간 트래픽 보안 및 최적화

클라이언트의 HTTPS 요청을 수락하려면 부하 분산기에 클라이언트에게 ID를 증명할 수 있는 인증서가 있어야 합니다. HTTPS 핸드셰이크를 완료하려면 부하 분산기에 비공개 키도 있어야 합니다. HTTP(S) 부하 분산기에 SSL 인증서를 제공하는 방법에 대해 자세히 알아보려면 클라이언트와 부하 분산기 간 TLS 구성을 참고하세요.

Google 관리형 인증서 사용

하나 이상의 Google 관리 SSL 인증서를 구성하고 인그레스에 연결하려면 다음을 수행해야 합니다.

• 인그레스와 동일한 네임스페이스에 ManagedCertificate 객체를 하나 이상 만듭니다. 부하 분산기에 최대 15개의 인증서를 지정할 수 있습니다.
• 인그레스에 networking.gke.io/managed-certificates 주석을 추가하여 ManagedCertificate 객체를 인그레스에 연결합니다. 이 주석은 ManagedCertificate 객체의 쉼표로 구분된 목록입니다.

참고: 인그레스와 함께 Google 관리형 SSL 인증서를 사용해도 인그레스 트래픽 규칙 구성 방식에는 영향을 미치지 않습니다.

제한사항

이 섹션에서는 Google 관리 인증서의 제한사항을 설명합니다. 자체 관리형 인증서가 필요하거나 인그레스에 구성하려는 SSL 인증서를 이미 소유한 경우에는 클라이언트와 부하 분산기 간 HTTPS (TLS) 설정을 참고하세요.

• Google 관리 인증서는 사용자가 직접 가져오고 관리하는 인증서보다 유연성이 낮습니다. Google 관리 인증서는 와일드 카드가 아닌 도메인을 최대 100개까지 지원합니다. 자체 관리형 인증서와 달리 Google 관리형 인증서는 와일드 카드 도메인을 지원하지 않습니다.

• 인그레스가 지원하는 인증서의 개수와 유형은 Google 관리형 SSL 인증서의 한도에 따라 정의됩니다.

• Google 관리형 인증서의 업데이트는 지원되지 않습니다. 자세한 내용은 Google 관리 인증서 수동 업데이트를 참조하세요.

• 인증서가 인증 기관에서 직접 취소된 경우 Google은 인증서를 자동으로 순환하지 않습니다. ManagedCertificate를 삭제하고 새 인증서를 만들어야 합니다.

• GKE 인그레스는 인증서 관리자로 관리되는 인증서를 지원하지 않습니다. 인증서 관리자가 관리하는 인증서를 사용하려면 Gateway API를 사용하세요.

경고: 인그레스 리소스에서 생성된 부하 분산기 대상 프록시는 Compute Engine SSL 인증서를 최대 15개까지 참조할 수 있습니다. 인그레스 주석 ingress.gcp.kubernetes.io/pre-shared-cert에는 부하 분산기 대상 프록시로 프로비저닝된 모든 SSL 인증서 managed-certificates 및 self-managed가 포함됩니다.

기본 요건

• 도메인 이름을 소유하고 있어야 합니다. 도메인 이름은 63자(영문 기준) 이하여야 합니다. 모든 도메인 이름 등록기관을 사용하여 도메인 이름을 가져올 수 있습니다.

  참고: Google Domains는 더 이상 운영되지 않습니다. 이제 Squarespace에서 이전에 Google Domains에서 구매한 도메인을 관리합니다. Squarespace 계정에서 도메인과 DNS 레코드를 관리할 수 있습니다.

• GKE Standard 클러스터를 사용하는 경우 HttpLoadBalancing 부가기능을 사용 설정해야 합니다.

• 인그레스 매니페스트에 kubernetes.io/ingress.class: "gce" 주석이 포함되어야 합니다. ingressClassName 필드는 지원되지 않습니다.

• 같은 프로젝트와 네임스페이스에 Ingress 및 ManagedCertificate 리소스를 적용해야 합니다.

• 예약된(고정) 외부 IP 주소를 만듭니다. 고정 IP 주소를 예약하면 인그레스를 삭제해도 이 주소는 내 소유로 유지됩니다. IP 주소를 예약하지 않으면 주소가 변경되어 도메인의 DNS 레코드를 다시 구성해야 할 수도 있습니다. Google Cloud CLI 또는 Google Cloud 콘솔을 사용하여 예약 IP 주소를 만듭니다.

  gcloud

  예약된 IP 주소를 만들려면 다음 명령어를 실행합니다.

  gcloud compute addresses create ADDRESS_NAME --global
  

  ADDRESS_NAME을 만들고 있는 예약 IP 주소의 이름으로 바꿉니다.

  만든 고정 IP 주소를 찾으려면 다음 명령어를 실행합니다.

  gcloud compute addresses describe ADDRESS_NAME --global
  

  출력은 다음과 비슷합니다.

  address: 203.0.113.32
  ...
  

  콘솔

  예약 IP 주소를 만들려면 다음 단계를 수행합니다.

  1. Google Cloud 콘솔에서 외부 IP 주소 페이지로 이동합니다.

     외부 IP 주소로 이동

  2. IP 주소의 이름을 지정합니다(예시: example-ip-address).

  3. IPv4 또는 IPv6 주소 사용 여부를 지정합니다.

  4. 유형에 전역 옵션을 선택합니다.

  5. 예약을 클릭합니다. IP 주소가 외부 주소 열에 나열됩니다.

  구성 커넥터

  참고: 이 단계에는 구성 커넥터가 필요합니다. 설치 안내를 따라 클러스터에 구성 커넥터를 설치합니다.

  apiVersion: compute.cnrm.cloud.google.com/v1beta1
  kind: ComputeAddress
  metadata:
    name: example-ip-address
  spec:
    location: global

  이 매니페스트를 배포하려면 compute-address.yaml로 머신에 다운로드하고 다음을 실행합니다.

  kubectl apply -f compute-address.yaml
  

Google 관리 인증서 설정

1. ManagedCertificate 객체를 만듭니다. 이 리소스는 SSL 인증서의 도메인을 지정합니다. 와일드 카드 도메인은 지원되지 않습니다.

   다음 매니페스트에서는 ManagedCertificate 객체를 설명합니다. 매니페스트를 managed-cert.yaml로 저장합니다.

   apiVersion: networking.gke.io/v1
   kind: ManagedCertificate
   metadata:
     name: FIRST_CERT_NAME
   spec:
     domains:
       - FIRST_DOMAIN
   ---
   apiVersion: networking.gke.io/v1
   kind: ManagedCertificate
   metadata:
     name: SECOND_CERT_NAME
   spec:
     domains:
       - SECOND_DOMAIN
   

   다음을 바꿉니다.

   • FIRST_CERT_NAME: 첫 번째 ManagedCertificate 객체의 이름입니다.
   • FIRST_DOMAIN: 소유한 첫 번째 도메인입니다.
   • SECOND_CERT_NAME: 두 번째 ManagedCertificate 객체의 이름입니다.
   • SECOND_DOMAIN: 소유하고 있는 두 번째 도메인입니다.

   ManagedCertificate 객체의 이름은 생성하는 실제 인증서의 이름과 다릅니다. 인그레스에서 사용하려면 ManagedCertificate 객체의 이름만 알면 됩니다.

2. 매니페스트를 클러스터에 적용합니다.

   kubectl apply -f managed-cert.yaml
   

3. 안내에 따라 Deployment 및 Service를 만들어 애플리케이션을 인터넷에 노출합니다.

4. 이 ManagedCertificate 객체를 Active 상태로 전환하려면 다음 예와 같이 networking.gke.io/managed-certificates 주석을 사용하여 인그레스에 연결합니다. ManagedCertificate이 이미 Active 상태여야만 인그레스에 연결할 수 있는 것은 아닙니다.

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: my-gmc-ingress
      annotations:
        networking.gke.io/managed-certificates: "FIRST_CERT_NAME,SECOND_CERT_NAME"
    spec:
      rules:
      - host: FIRST_DOMAIN
        http:
          paths:
          - pathType: ImplementationSpecific
            backend:
              service:
                name: my-mc-service
                port:
                  number: 60001
      - host: SECOND_DOMAIN
        http:
          paths:
          - pathType: ImplementationSpecific
            backend:
              service:
                name: my-mc-service
                port:
                  number: 60002
    ```
   
   Replace <code><var>FIRST_DOMAIN</var></code> and
   <code><var>SECOND_DOMAIN</var></code> with your domain names.
   
   This manifest describes an Ingress that lists pre-shared certificate
   resources in an annotation.
   
   Note: It might take several hours for Google Cloud to provision the load
   balancer and the managed certificates, and for the load balancer to begin
   using the new certificates. For more information, see
   [Deploy a Google-managed certificate with load balancer authorization](/certificate-manager/docs/deploy-google-managed-lb-auth#wait_until_the_certificate_has_been_activated).
   

5. Google 관리 인증서에서 프로비저닝을 완료할 때까지 기다립니다. 여기에는 최대 60분이 걸릴 수 있습니다. 다음 명령어를 사용하여 인증서 상태를 확인할 수 있습니다.

   kubectl describe managedcertificate managed-cert
   

   출력은 다음과 비슷합니다.

   Name:         managed-cert
   Namespace:    default
   Labels:       <none>
   Annotations:  <none>
   API Version:  networking.gke.io/v1
   Kind:         ManagedCertificate
   (...)
   Spec:
    Domains:
      FQDN_1
      FQDN_2
   Status:
    CertificateStatus: Active
   (...)
   

   Status.CertificateStatus 필드 값은 인증서가 프로비저닝되었음을 나타냅니다. Status.CertificateStatus가 Active가 아닌 경우 인증서가 아직 프로비저닝되지 않은 것입니다.

6. https:// 프리픽스로 도메인에 방문하여 SSL이 작동하는지 확인합니다. 브라우저에 연결이 안전하다고 표시되며 인증서 세부정보를 볼 수 있습니다.

자체 관리형 인증서에서 Google 관리형 인증서로 이전

자체 관리형 SSL 인증서에서 Google 관리형 SSL 인증서로 인그레스를 이전하는 경우, Google 관리형 SSL 인증서가 활성화되기 전에 자체 관리형 SSL 인증서를 삭제하지 마세요. Google 관리형 SSL 인증서는 성공적으로 프로비저닝된 후 자동으로 활성화됩니다. Google 관리형 SSL 인증서가 활성화되면 자가 관리형 SSL 인증서를 삭제할 수 있습니다.

다음 안내에 따라 자가 관리형에서 Google 관리형 SSL 인증서로 이전하세요.

1. 이전 섹션의 설명에 따라 인그레스에 새 Google 관리 인증서를 추가합니다.

2. Google 관리형 인증서 리소스의 상태가 Active가 될 때까지 기다립니다. 다음 명령어로 인증서 상태를 확인합니다.

   kubectl describe managedcertificate managed-cert
   

3. Active 상태가 되면 인그레스를 업데이트하여 자체 관리형 인증서에 대한 참조를 삭제합니다.

Google 관리 인증서 삭제

클러스터에서 Google 관리 인증서를 삭제하려면 ManagedCertificate 객체를 삭제하고 해당 리소스를 참조하는 인그레스 주석을 삭제해야 합니다.

1. ManagedCertificate 객체를 삭제합니다.

   kubectl delete -f managed-cert.yaml
   

   출력은 다음과 비슷합니다.

   managedcertificate.networking.gke.io "managed-cert" deleted
   

2. 인그레스에서 주석을 삭제합니다.

   kubectl annotate ingress managed-cert-ingress networking.gke.io/managed-certificates-
   

   명령어 끝부분의 빼기 기호 -를 확인합니다.

3. 부하 분산기용으로 예약한 고정 IP 주소를 해제합니다.

   Google Cloud CLI, Google Cloud 콘솔 또는 구성 커넥터를 사용하여 예약 IP 주소를 해제할 수 있습니다.

   gcloud

   다음 명령어를 사용하여 예약 IP 주소를 해제합니다.

   gcloud compute addresses delete ADDRESS_NAME --global
   

   ADDRESS_NAME을 IP 주소의 이름으로 바꿉니다.

   콘솔

   예약 IP 주소를 해제하려면 다음 단계를 수행합니다.

   1. Google Cloud 콘솔에서 외부 IP 주소 페이지로 이동합니다.

      외부 IP 주소로 이동

   2. 해제하려는 IP 주소 옆에 있는 체크박스를 선택합니다.

   3. IP 주소 해제를 클릭합니다.

   구성 커넥터

   참고: 이 단계에는 구성 커넥터가 필요합니다. 설치 안내를 따라 클러스터에 구성 커넥터를 설치합니다.

   apiVersion: compute.cnrm.cloud.google.com/v1beta1
   kind: ComputeAddress
   metadata:
     name: example-ip-address
   spec:
     location: global

   이 매니페스트를 배포하려면 compute-address.yaml로 머신에 다운로드하고 다음을 실행합니다.

   kubectl delete -f compute-address.yaml
   

인증서 및 키 만들기

사전 공유 인증서 또는 Kubernetes 보안 비밀을 사용하려면 먼저 해당 비공개 키가 있는 하나 이상의 인증서가 필요합니다. 각 인증서에는 소유 중인 도메인 이름과 일치하는 일반 이름 (CN)이 있어야 합니다. 적절한 일반 이름 값이 있는 인증서 파일 2개를 이미 가지고 있는 경우 다음 섹션으로 건너뛸 수 있습니다.

1. 첫 번째 키를 만듭니다.

   openssl genrsa -out test-ingress-1.key 2048
   

2. 첫 번째 인증서 서명 요청을 만듭니다.

   openssl req -new -key test-ingress-1.key -out test-ingress-1.csr \
       -subj "/CN=FIRST_DOMAIN"
   

   FIRST_DOMAIN을 소유하고 있는 도메인 이름(예: example.com)으로 바꿉니다.

3. 첫 번째 인증서를 만듭니다.

   openssl x509 -req -days 365 -in test-ingress-1.csr -signkey test-ingress-1.key \
       -out test-ingress-1.crt
   

4. 두 번째 키를 만듭니다.

   openssl genrsa -out test-ingress-2.key 2048
   

5. 두 번째 인증서 서명 요청을 만듭니다.

   openssl req -new -key test-ingress-2.key -out test-ingress-2.csr \
       -subj "/CN=SECOND_DOMAIN"
   

   SECOND_DOMAIN을 소유하고 있는 다른 도메인 이름(예: examplepetstore.com)으로 바꿉니다.

6. 두 번째 인증서를 만듭니다.

   openssl x509 -req -days 365 -in test-ingress-2.csr -signkey test-ingress-2.key \
       -out test-ingress-2.crt
   

인증서 및 키에 대한 자세한 내용은 SSL 인증서 개요를 참조하세요.

이제 두 개의 인증서 파일과 두 개의 키 파일이 있습니다.

나머지 작업에서는 다음 자리표시자를 사용하여 도메인, 인증서, 키를 참조합니다.

• FIRST_CERT_FILE: 첫 번째 인증서 파일의 경로입니다.
• FIRST_KEY_FILE: 첫 번째 인증서와 함께 전달되는 키 파일의 경로입니다.
• FIRST_DOMAIN: 소유하고 있는 도메인 이름입니다.
• FIRST_SECRET_NAME: 첫 번째 인증서 및 키가 포함된 보안 비밀의 이름입니다.
• SECOND_CERT_FILE: 두 번째 인증서 파일의 경로입니다.
• SECOND_KEY_FILE: 두 번째 인증서와 함께 전달되는 키 파일의 경로입니다.
• SECOND_DOMAIN: 소유하고 있는 두 번째 도메인 이름입니다.
• SECOND_SECRET_NAME: 두 번째 인증서 및 키가 포함된 보안 비밀의 이름입니다.

참고: FIRST와 SECOND라는 단어는 순서를 의미하지 않습니다. 이러한 단어는 두 개의 도메인, 두 개의 인증서 파일, 해당 키 파일을 혼동하지 않는 데 도움이 됩니다.

사전 공유 인증서 사용

Google Cloud 프로젝트에 업로드하는 자체 관리형 SSL 인증서를 사용할 수 있습니다. 이를 사전 공유 인증서라고 합니다. 인그레스에 대해 하나 이상의 사전 공유 인증서를 지정할 수 있습니다.

여러 사전 공유 인증서를 사용하려면 다음 단계를 따르세요.

1. 각 인증서 및 키 쌍에 대해 Google Cloud에서 공개적으로 표시되는 SSL 인증서 리소스를 만듭니다.

    gcloud compute ssl-certificates create FIRST_CERT_NAME \
        --certificate=FIRST_CERT_FILE \
        --private-key=FIRST_KEY_FILE
    ```
   
   ```sh
    gcloud compute ssl-certificates create SECOND_CERT_NAME \
        --certificate=SECOND_CERT_FILE \
        --private-key=SECOND_KEY_FILE
    ```
   
   Replace the following:
   

   • FIRST_CERT_NAME, SECOND_CERT_NAME: 첫 번째 및 두 번째 인증서의 이름입니다.
   • FIRST_CERT_FILE, SECOND_CERT_FILE: 첫 번째 및 두 번째 인증서 파일입니다.
   • FIRST_KEY_FILE, SECOND_KEY_FILE: 첫 번째 및 두 번째 키 파일입니다.

2. 인그레스 매니페스트에 ingress.gcp.kubernetes.io/pre-shared-cert 주석을 추가합니다. 주석 값은 쉼표로 구분된 인증서 이름 목록입니다. 또한 spec.rules 섹션에 host 필드를 포함하여 서비스의 도메인을 지정합니다.

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: my-psc-ingress
      annotations:
        ingress.gcp.kubernetes.io/pre-shared-cert: "FIRST_CERT_NAME,SECOND_CERT_NAME"
    spec:
      rules:
      - host: FIRST_DOMAIN
        http:
          paths:
          - pathType: ImplementationSpecific
            backend:
              service:
                name: my-mc-service
                port:
                  number: 60001
      - host: SECOND_DOMAIN
        http:
          paths:
          - pathType: ImplementationSpecific
            backend:
              service:
                name: my-mc-service
                port:
                  number: 60002
    ```
   
   Replace <code><var>FIRST_DOMAIN</var></code> and
   <code><var>SECOND_DOMAIN</var></code> with your domain names.
   
   This manifest describes an Ingress that lists pre-shared certificate
   resources in an annotation.
   

Kubernetes 보안 비밀 사용

개발자가 직접 만든 인증서와 키를 사용하는 HTTP(S) 부하 분산기를 제공하려면 하나 이상의 Kubernetes 보안 비밀 객체를 만듭니다. 각 보안 비밀에는 인증서와 키가 포함되어 있습니다. Ingress 매니페스트의 tls 필드에 보안 비밀을 추가합니다. 부하 분산기는 서버 이름 표시 (SNI)를 사용하여 TLS 핸드셰이크의 도메인 이름을 기준으로 클라이언트에 제공할 인증서를 결정합니다.

여러 인증서를 사용하려면 다음 단계를 따르세요.

1. 각 인증서 및 키 쌍의 보안 비밀을 만듭니다.

    kubectl create secret tls FIRST_SECRET_NAME \
        --cert=FIRST_CERT_FILE \
        --key=FIRST_KEY_FILE
    ```
   
   ```sh
    kubectl create secret tls SECOND_SECRET_NAME \
        --cert=SECOND_CERT_FILE \
        --key=SECOND_KEY_FILE
    ```
   

2. 인그레스 매니페스트의 spec.tls 섹션에 만든 보안 비밀을 나열합니다. 또한 spec.rules 섹션에 host 필드를 포함하여 서비스의 도메인을 지정합니다.

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-mc-ingress
   spec:
     tls:
     - secretName: FIRST_SECRET_NAME
     - secretName: SECOND_SECRET_NAME
     rules:
     - host: FIRST_DOMAIN
       http:
         paths:
         - pathType: ImplementationSpecific
           backend:
             service:
               name: my-mc-service
               port:
                 number: 60001
     - host: SECOND_DOMAIN
       http:
         paths:
         - pathType: ImplementationSpecific
           backend:
             service:
               name: my-mc-service
               port:
                 number: 60002
   

   FIRST_DOMAIN 및 SECOND_DOMAIN을 소유하고 있는 도메인 이름(예: example.com 및 examplepetstore.com)으로 바꿉니다.

보안 비밀 변경사항은 정기적으로 수집됩니다. 따라서 보안 비밀에 있는 데이터를 수정할 경우 변경사항이 부하 분산기에 적용되는 데 최대 10분이 소요됩니다.

GKE 클러스터의 HTTPS 암호화된 인그레스를 보호하려면 보안 인그레스 예시를 참조하세요.

HTTP 중지

클라이언트와 부하 분산기 사이의 모든 트래픽이 HTTPS를 사용하도록 하려면 인그레스 매니페스트에 kubernetes.io/ingress.allow-http 주석을 포함시켜 HTTP를 사용 중지하면 됩니다. 주석 값을 "false"로 설정합니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress-2
  annotations:
    kubernetes.io/ingress.allow-http: "false"
spec:
  tls:
  - secretName: SECRET_NAME
  ...

이 매니페스트에는 자신이 만든 보안 비밀의 이름인 SECRET_NAME이 포함됩니다.

참고: networking.gke.io/managed-certificates 주석을 사용하는 경우 kubernetes.io/ingress.allow-http: false 주석을 사용할 수 없습니다. 외부 애플리케이션 부하 분산기가 완전히 프로그래밍된 후에만 인그레스를 업데이트하고 kubernetes.io/ingress.allow-http: false 주석을 추가할 수 있습니다.

주의: 멀티 클러스터 인그레스에서는 HTTP 중지가 지원되지 않습니다.

클라이언트와 부하 분산기 간 HTTP/2

클라이언트는 HTTP/2를 사용하여 부하 분산기에 요청을 보낼 수 있습니다. 별도로 구성할 필요는 없습니다.

부하 분산기와 애플리케이션 간 트래픽 보호 및 최적화

부하 분산기와 애플리케이션 포드 간의 통신에 사용되는 프로토콜을 구성하여 엔드 투 엔드 보안을 보장하거나 내부 트래픽 성능을 최적화할 수 있습니다. 부하 분산기는 백엔드 연결에 기본적으로 암호화되지 않은 HTTP/1.1을 사용하지만 애플리케이션의 특정 요구사항을 충족하기 위해 HTTPS 또는 HTTP/2를 사용 설정할 수 있습니다.

부하 분산기와 애플리케이션 간 HTTPS

GKE pod에서 실행되는 애플리케이션이 HTTPS 요청을 수신할 수 있는 경우 요청을 애플리케이션으로 전달할 때 HTTPS를 사용하도록 부하 분산기를 구성할 수 있습니다. 자세한 내용은 부하 분산기와 애플리케이션 간 HTTPS(TLS)를 참조하세요.

부하 분산기와 애플리케이션 사이에서 사용되는 프로토콜을 구성하려면 서비스 매니페스트에서 cloud.google.com/app-protocols 주석을 사용합니다. 컨테이너 기반 부하 분산을 사용하지 않는 한 이 서비스 매니페스트에는 type: NodePort가 포함되어야 합니다. 컨테이너 기반 부하 분산을 사용하는 경우 type: ClusterIP를 사용합니다.

다음 서비스 매니페스트는 두 포트를 지정합니다. 주석은 HTTP(S) 부하 분산기가 서비스의 포트 80을 대상으로 지정하는 경우, HTTP를 사용해야 한다는 것을 의미합니다. 또한 부하 분산기가 서비스의 포트 443을 대상으로 지정하는 경우에는 HTTPS를 사용해야 합니다.

서비스 매니페스트는 포트 주석에 name 값을 포함해야 합니다. targetPort 값이 아닌 할당된 name을 참조하여 서비스 포트를 수정할 수만 있습니다.

주의: 잠재적인 다운타임을 제한하려면 이 기능을 사용 설정할 때 서비스의 포트 이름을 수정하지 마세요. 서비스 포트에 이름이 없는 경우 cloud.google.com/app-protocols: '{"": "HTTPS"}'와 같이 빈 포트 이름을 주석의 키로 사용합니다. 초기 설정 후 포트 이름 또는 주석을 수정하면 애플리케이션에 다운타임이 발생할 수 있습니다.

apiVersion: v1
kind: Service
metadata:
  name: my-service-3
  annotations:
    cloud.google.com/app-protocols: '{"my-https-port":"HTTPS","my-http-port":"HTTP"}'
spec:
  type: NodePort
  selector:
    app: metrics
    department: sales
  ports:
  - name: my-https-port
    port: 443
    targetPort: 8443
  - name: my-http-port
    port: 80
    targetPort: 50001

부하 분산기와 애플리케이션 간 HTTP/2 사용

GKE Pod에서 실행되는 애플리케이션이 HTTP/2 요청을 수신할 수 있는 경우 요청을 애플리케이션으로 전달할 때 HTTP/2를 사용하도록 부하 분산기를 구성할 수 있습니다.

HTTP/2를 사용 설정하려면 Kubernetes 서비스 매니페스트에서 cloud.google.com/app-protocols 주석을 사용해야 합니다. 이 주석은 부하 분산기가 애플리케이션과 통신하는 데 사용하는 프로토콜을 지정합니다. 부하 분산기가 백엔드에 올바른 HTTP/2 요청을 할 수 있게 하려면 백엔드를 SSL로 구성해야 합니다.

다음은 HTTP/2로 구성된 서비스 매니페스트의 예시입니다.

apiVersion: v1
kind: Service
metadata:
  name: my-http2-service
  annotations:
    cloud.google.com/app-protocols: '{"my-port":"HTTP2"}'
spec:
  type: NodePort
  selector:
    app: my-app
  ports:
  - name: my-port
    protocol: TCP
    port: 443
    targetPort: 8443

다음에 유의하세요.

• cloud.google.com/app-protocols 주석이 '{"my-port":"HTTP2"}'로 설정되어 부하 분산기가 my-port라는 포트로 전송되는 트래픽에 HTTP/2를 사용하도록 지시합니다.
• 포트는 443로 설정되고 targetPort 8443의 포드로 트래픽을 전달합니다.