Istio API를 사용하여 게이트웨이 설치 및 업그레이드

참고: 이 가이드는 Istio API가 포함된 Cloud Service Mesh만 지원하고 Google Cloud API는 지원하지 않습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

Cloud Service Mesh는 서비스 메시의 일부로 게이트웨이를 배포 및 관리하는 옵션을 제공합니다. 게이트웨이는 메시의 에지에서 작동하고 들어오거나 나가는 HTTP/TCP 연결을 수신하는 부하 분산기를 설명합니다. 게이트웨이는 주로 인그레스 트래픽을 관리하는 데 사용되지만 다른 유형의 트래픽을 관리하도록 게이트웨이를 구성할 수도 있습니다.

• 이그레스 게이트웨이: 이그레스 게이트웨이를 사용하면 메시에서 나가는 트래픽의 전용 출구 노드를 구성하여 외부 네트워크에 액세스할 수 있거나 액세스해야 하는 서비스를 제한하거나, 이그레스 트래픽을 안전하게 제어할 수 있습니다(예: 메시에 보안 추가).

• 인그레스 게이트웨이: 인그레스 게이트웨이를 사용하면 들어오는 HTTP/TCP 연결을 수신하는 전용 진입 노드를 구성할 수 있습니다.

• East-west 게이트웨이: 서비스 워크로드가 다른 네트워크의 다중 기본 메시의 클러스터 경계를 넘어 통신할 수 있도록 하는 east-west 트래픽의 프록시입니다. 기본적으로 이 게이트웨이는 인터넷에 공개됩니다.

이 페이지에서는 게이트웨이 프록시를 배포하고 업그레이드하는 방법과 고유한 istio-ingressgateway 및 istio-egressgateway 게이트웨이 프록시를 구성하는 예시에 대한 권장사항을 설명합니다.

다른 방법으로 게이트웨이를 배포할 수 있고 동일한 클러스터 내에서 2개 이상의 토폴로지를 사용할 수 있습니다. 이러한 토폴로지에 대한 자세한 내용은 Istio 문서의 게이트웨이 배포 토폴로지를 참조하세요.

게이트웨이 배포 권장사항

게이트웨이 배포 권장사항은 관리형 데이터 영역 또는 비관리형 데이터 영역을 사용하는지에 따라 달라집니다.

관리형 데이터 영역 권장사항

1. 관리형 데이터 영역을 사용 설정합니다.
2. 네임스페이스에 관리형 버전 라벨을 추가합니다.
3. 제어 영역과 게이트웨이를 개별적으로 배포하고 관리합니다.
4. 보안 권장사항에 따라 제어 영역의 다른 네임스페이스에 게이트웨이를 배포하는 것이 좋습니다.
5. 자동 사이드카 삽입(자동 삽입)을 사용하여 서비스에 대해 사이드카 프록시를 삽입하는 방법과 비슷한 게이트웨이에 대해 프록시 구성을 삽입합니다.

권장사항을 따라 다음을 수행할 수 있습니다.

• 최신 개선사항 및 보안 업데이트를 통해 자동으로 관리형 게이트웨이의 최신 상태를 유지합니다.
• 게이트웨이 인스턴스의 관리 및 유지보수를 Cloud Service Mesh 관리 데이터 영역으로 오프로드합니다.

비관리형 데이터 영역 권장사항

1. 제어 영역과 게이트웨이를 개별적으로 배포하고 관리합니다.
2. 보안 권장사항에 따라 제어 영역의 다른 네임스페이스에 게이트웨이를 배포하는 것이 좋습니다.
3. 자동 사이드카 삽입(자동 삽입)을 사용하여 서비스에 대해 사이드카 프록시를 삽입하는 방법과 비슷한 게이트웨이에 대해 프록시 구성을 삽입합니다.

권장사항을 따라 다음을 수행할 수 있습니다.

• 네임스페이스 관리자가 권한을 전체 클러스터로 승격할 필요 없이 게이트웨이를 관리할 수 있도록 합니다.
• 관리자가 Kubernetes 애플리케이션 관리를 위해 사용하는 것과 동일한 배포 도구 또는 메커니즘을 사용해서 게이트웨이를 배포하고 관리할 수 있도록 합니다.
• 관리자에게 게이트웨이 배포를 완벽하게 제어하도록 권한을 부여하고 작업을 간소화할 수도 있습니다. 새 업그레이드를 사용할 수 있거나 구성이 변경되었으면 관리자가 게이트웨이 포드를 다시 시작하여 업데이트합니다. 그러면 게이트웨이 배포를 작동하는 환경이 서비스에 대해 사이드카 프록시를 작동하는 것과 동일하게 됩니다.

샘플 게이트웨이 배포

기존 배포 도구를 사용하는 사용자를 지원하기 위해 Cloud Service Mesh에서는 게이트웨이를 Istio로 배포하는 것과 동일한 방법인 IstioOperator, Helm, Kubernetes YAML을 지원합니다. 각 방법은 동일한 결과를 생성합니다. 사용자가 가장 익숙한 방법을 선택할 수 있지만, 수정이 쉽고 소스 제어에 하이드레이션된 매니페스트를 저장할 수 있으므로 Kubernetes YAML 방법을 사용하는 것이 좋습니다.

다음 단계에서는 샘플 게이트웨이를 배포하는 방법을 보여줍니다.

1. 아직 없으면 게이트웨이의 네임스페이스를 만듭니다. GATEWAY_NAMESPACE를 네임스페이스의 이름으로 바꿉니다.

   kubectl create namespace GATEWAY_NAMESPACE
   

2. 네임스페이스의 삽입을 사용 설정합니다. 이 단계는 컨트롤 플레인 구현에 따라 다릅니다.

   관리형(TD)

   1. 기본 삽입 라벨을 네임스페이스에 적용합니다.

   kubectl label namespace GATEWAY_NAMESPACE \
       istio.io/rev- istio-injection=enabled --overwrite
   

   관리형(Istiod)

   권장: 다음 명령어를 실행하여 네임스페이스에 기본 삽입 라벨을 적용합니다.

     kubectl label namespace GATEWAY_NAMESPACE \
         istio.io/rev- istio-injection=enabled --overwrite
   

   관리형 Istiod 컨트롤 플레인이 있는 기존 사용자: 기본 삽입을 사용하는 것이 좋지만 버전 기반 삽입은 지원됩니다. 다음 안내를 따르세요.

   1. 다음 명령어를 실행하여 사용 가능한 출시 채널을 찾습니다.

      kubectl -n istio-system get controlplanerevision
      

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

      NAME                AGE
      asm-managed-rapid   6d7h
      

      참고: 위 목록에 두 개의 컨트롤 플레인 버전이 표시되면 하나를 삭제합니다. 클러스터에 여러 컨트롤 플레인 채널을 두는 방식은 지원되지 않습니다.

      출력에서 NAME 열 아래의 값은 Cloud Service Mesh 버전에 사용 가능한 출시 채널에 해당하는 버전 라벨입니다.

   2. 네임스페이스에 버전 라벨을 적용합니다.

      kubectl label namespace GATEWAY_NAMESPACE \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

   클러스터 내

   권장: 다음 명령어를 실행하여 네임스페이스에 기본 삽입 라벨을 적용합니다.

     kubectl label namespace GATEWAY_NAMESPACE \
         istio.io/rev- istio-injection=enabled --overwrite
   

   기본 삽입을 사용하는 것이 좋지만 버전 기반 삽입이 지원됩니다. 다음 안내를 따르세요.

   1. 다음 명령어를 사용하여 istiod에서 버전 라벨을 찾습니다.

      kubectl get deploy -n istio-system -l app=istiod -o \
         jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
      

   2. 네임스페이스에 버전 라벨을 적용합니다. 다음 명령어에서 REVISION_LABEL은 이전 단계에서 확인한 istiod 버전 라벨의 값입니다.

      kubectl label namespace GATEWAY_NAMESPACE \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

3. anthos-service-mesh 저장소에서 샘플 게이트웨이의 구성 파일을 복사합니다.

4. 디렉터리를 samples 디렉터리로 변경합니다. 올바른 디렉터리에 있는지 확인합니다. ls 명령어를 실행하여 디렉터리 콘텐츠를 나열하고 다음 단계에서 액세스할 gateways 디렉터리 및 online-boutique 디렉터리가 있는지 확인합니다.

5. 인그레스 또는 이그레스 게이트웨이를 배포합니다. samples/gateways/ 디렉터리에 있는 게이트웨이를 있는 그대로 배포하거나 필요에 따라 수정할 수 있습니다.

   인그레스

   kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
   

   Egress

   kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-egressgateway
   

6. 배포를 만든 후에 새 서비스가 올바르게 작동하는지 확인합니다.

   kubectl get pod,service -n GATEWAY_NAMESPACE
   

   출력이 다음과 비슷하게 표시되는지 확인합니다.

   NAME                                      READY   STATUS    RESTARTS   AGE
   pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s
   
   NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
   service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

게이트웨이 리소스를 다른 Kubernetes 애플리케이션과 비슷한 방법으로 관리합니다. anthos-service-mesh-packages 저장소의 샘플은 안내 및 빠른 시작을 위해 제공되었습니다. 필요에 따라 맞춤설정하세요.

게이트웨이 선택기

istio-ingressgateway 및 istio-egressgateway 프록시에 게이트웨이 구성을 적용하면 어떤 트래픽을 메시로 보내고 내보낼지 지정하여 메시의 인바운드 및 아웃바운드 트래픽을 관리할 수 있습니다. 게이트웨이 배포 포드의 라벨은 게이트웨이 구성 리소스에서 사용되므로 게이트웨이 선택기가 이러한 라벨과 일치하는 것이 중요합니다.

예를 들어 앞선 배포에서 istio=ingressgateway 라벨은 게이트웨이 포드에 설정됩니다. 이러한 배포에 게이트웨이 구성을 적용하려면 동일한 라벨을 선택해야 합니다.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
...

게이트웨이 구성 및 가상 서비스 예시는 Online Boutique 샘플 애플리케이션에서 frontend.yaml을 참조하세요.

게이트웨이 업그레이드

인플레이스 업그레이드

대부분의 사용 사례에서는 인플레이스 업그레이드 패턴에 따라 게이트웨이를 업그레이드해야 합니다. 게이트웨이는 포드 삽입을 사용하므로, 생성된 새 게이트웨이 포드는 버전을 포함하는 최신 구성으로 자동 삽입됩니다.

게이트웨이에서 사용 중인 제어 영역 버전을 변경하려면 게이트웨이 배포에서 istio.io/rev 라벨을 설정합니다. 이렇게 하면 순차적 재시작도 트리거됩니다.

관리형 제어 영역

Google에서 관리형 제어 영역의 제어 영역 업그레이드를 관리하므로 게이트웨이 배포를 다시 시작하기만 하면 최신 구성과 버전의 새 포드가 자동으로 삽입됩니다.

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

클러스터 내 제어 영역

클러스터 내 제어 영역이 있을 때 게이트웨이에 동일한 패턴을 적용하려면 게이트웨이에서 사용 중인 제어 영역 버전을 변경해야 합니다. 게이트웨이 배포에서 순차적 재시작을 트리거하는 istio.io/rev 라벨을 설정합니다. 필요한 단계는 네임스페이스 또는 게이트웨이 포드의 버전 라벨을 업데이트해야 하는지 여부에 따라 다릅니다.

• 네임스페이스의 삽입 라벨을 지정한 경우 네임스페이스의 istio.io/rev 라벨을 새 버전 값으로 설정합니다.

    kubectl label namespace GATEWAY_NAMESPACE \
      istio-injection- istio.io/rev=REVISION \
      --overwrite
  

• 게이트웨이 포드에만 삽입을 사용 설정한 경우 배포의 istio.io/rev 라벨을 다음 Kubernetes YAML 파일과 같은 새 버전 값으로 설정합니다.

  cat <<EOF > gateway-deployment.yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: istio-ingressgateway
    namespace: GATEWAY_NAMESPACE
  spec:
    selector:
      matchLabels:
        istio: ingressgateway
    template:
      metadata:
        annotations:
          # This is required to tell Cloud Service Mesh to inject the gateway with the
          # required configuration.
          inject.istio.io/templates: gateway
        labels:
          istio: ingressgateway
          istio.io/rev: REVISION
      spec:
        containers:
        - name: istio-proxy
          image: auto # The image will automatically update each time the pod starts.
  EOF
  
  kubectl apply -f gateway-deployment.yaml
  

  참고: image가 실제 Cloud Service Mesh 프록시 이미지로 자동 업데이트되지 않으면 컨테이너를 찾을 수 없고 오류가 발생합니다. 다음 단계는 게이트웨이 문제 해결을 참조하세요.

카나리아 업그레이드(고급)

클러스터 내 제어 영역을 사용 중이고 새 제어 영역 버전의 출시를 더 느리게 제어하려면 카나리아 업그레이드 패턴을 따를 수 있습니다. 게이트웨이 배포의 여러 버전을 실행하고 트래픽 일부에서 모두 예상한 대로 작동하는지 확인할 수 있습니다. 예를 들어 새 버전을 카나리아로 출시하려면 istio.io/rev=REVISION 라벨을 새 버전 및 새 이름으로 설정하여 게이트웨이 배포 복사본을 만듭니다(예: istio-ingressgateway-canary).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway-canary
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION # Set to the control plane revision you want to deploy
    spec:
      containers:
      - name: istio-proxy
        image: auto

참고: image가 실제 Cloud Service Mesh 프록시 이미지로 자동 업데이트되지 않으면 컨테이너를 찾을 수 없고 오류가 발생합니다. 다음 단계는 게이트웨이 문제 해결을 참조하세요.

이 배포가 생성되면 두 가지 버전의 게이트웨이가 생기고, 두 버전은 모두 동일한 서비스에서 선택됩니다.

kubectl get endpoints -o "custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"

NAME                   PODS
istio-ingressgateway   istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf

참고: 메시 내에 배포된 애플리케이션 서비스와 달리 Istio가 제어할 수 없는 외부 클라이언트에서 트래픽이 직접 수신되기 때문에 Istio 트래픽 전환을 사용해서 게이트웨이 버전 간에 트래픽을 분산시킬 수 없습니다. 대신 각 배포의 복제본 수에 따라 트래픽 분산을 제어할 수 있습니다. Istio 앞에 다른 부하 분산기를 사용하는 경우 이를 사용해서 트래픽 분산을 제어할 수도 있습니다.

애플리케이션이 예상한 대로 작동하면 다음 명령어를 사용해서 이전 istio.io/rev 라벨이 설정된 배포를 삭제하여 새 버전으로 전환합니다.

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

새 버전의 게이트웨이를 사용해서 애플리케이션을 테스트할 때 문제가 발생한 경우 다음 명령어를 사용해서 새 istio.io/rev 라벨이 설정된 배포를 삭제하여 이전 버전으로 다시 전환합니다.

kubectl delete deploy/istio-ingressgateway-canary -n GATEWAY_NAMESPACE

고급 구성

게이트웨이 최소 TLS 버전 구성

Cloud Service Mesh의 경우 게이트웨이 서버의 기본 최소 TLS 버전은 1.2입니다. minProtocolVersion 필드를 사용하여 최소 TLS 버전을 구성할 수 있습니다. 자세한 내용은 ServerTLSSettings를 참조하세요.

지원되지 않는 기능

TRAFFIC_DIRECTOR 컨트롤 플레인 구현이 있는 경우 게이트웨이의 다음 필드 또는 값이 지원되지 않습니다.

• AUTO_PASSTHROUGH 값이 있는 ServerTLSSettings.TLSmode
• ServerTLSSettings.verifyCertificateSpki
• ServerTLSSettings.verifyCertificateHash

게이트웨이 문제 해결

auto에서 게이트웨이 이미지 업데이트 실패

게이트웨이를 배포하거나 업그레이드하면 Cloud Service Mesh가 image 필드에 auto를 자리표시자로 삽입합니다. 변형 웹훅 호출 후 Cloud Service Mesh가 이 자리표시자를 실제 Cloud Service Mesh 프록시 이미지로 자동으로 바꿉니다. 웹훅 변형 호출이 실패하면 auto 자리표시자가 유지되고 컨테이너는 찾을 수 없습니다. 일반적으로 잘못된 네임스페이스 라벨이 원인입니다. 올바른 네임스페이스를 구성했는지 확인한 후 게이트웨이를 다시 배포하거나 업그레이드하세요.