게이트웨이 설치 및 업그레이드

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

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

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

이 페이지에서는 게이트웨이 프록시를 배포하고 업그레이드하는 방법과 고유한 istio-ingressgateway 및 istio-egressgateway 게이트웨이 프록시를 구성하는 예시에 대한 권장사항을 설명합니다. 트래픽 분할, 리디렉션, 재시도 논리와 같은 것들은 게이트웨이 구성을 게이트웨이 프록시에 적용하여 사용할 수 있습니다. 그런 후 동일한 API 리소스에 애플리케이션 레이어 트래픽 라우팅(L7)을 추가하는 대신 가상 서비스를 게이트웨이에 바인딩합니다. 이렇게 하면 서비스 메시의 다른 데이터 영역 트래픽과 같이 게이트웨이 트래픽을 관리할 수 있습니다.

다른 방법으로 게이트웨이를 배포할 수 있고 동일한 클러스터 내에서 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. 자동 삽입을 사용 설정하려면 네임스페이스에 기본 삽입 라벨을 지정하거나(기본 태그가 설정되어 있는 경우), 버전 라벨을 네임스페이스에 지정합니다. 또한 추가하는 라벨은 관리형 Cloud Service Mesh를 배포했거나 클러스터 내 컨트롤 플레인을 설치했는지에 따라 달라집니다. 라벨은 사이드카 인젝터 웹훅에서 삽입된 사이드카를 특정 컨트롤 플레인 버전과 연결하는 데 사용됩니다.

   설치 유형(관리형 또는 클러스터 내)에 따라 다음 탭을 선택합니다.

   관리됨

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

   kubectl -n istio-system get controlplanerevision
   

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

   NAME                AGE
   asm-managed         6d7h
   asm-managed-rapid   6d7h
   

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

   클러스터 내

   클러스터 내 컨트롤 플레인의 경우 istiod 서비스 및 배포에는 일반적으로 istio.io/rev=asm-1233-2과 유사한 버전 라벨이 있습니다. 여기서 asm-1233-2은 Cloud Service Mesh 버전을 식별합니다. 버전은 istiod 서비스 이름의 일부가 됩니다(예: istiod-asm-1233-2.istio-system).

   다음 명령어를 사용하여 클러스터 컨트롤 플레인에 대해 istiod에서 버전 라벨을 찾습니다.

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

3. 네임스페이스의 삽입을 사용 설정합니다. REVISION을 버전 라벨의 값으로 바꿉니다.

   참고: 기본 태그가 구성된 경우 istio.io/rev 대신 istio-injection=enabled 라벨을 사용할 수 있습니다. OUTPUT_DIR에서 istioctl로 istioctl tag list를 실행하여 기본 태그가 있는지 확인합니다.

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

4. asmcli를 사용하여 Cloud Service Mesh를 설치한 경우 --output_dir에서 지정한 디렉터리로 변경한 다음 cd를 samples 디렉터리로 변경합니다.

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

   asmcli를 사용하여 설치하지 않은 경우 anthos-service-mesh 저장소에서 게이트웨이의 구성 파일을 복사합니다.

5. samples/gateways/ 디렉터리에 있는 예시 게이트웨이 구성을 있는 그대로 배포하거나 필요에 따라 수정할 수 있습니다.

   인그레스

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

   Egress

   kubectl apply -n GATEWAY_NAMESPACE -f 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 Anthos 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" \
-n GATEWAY_NAMESPACE

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

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 버전 1.14 이상의 경우 게이트웨이 서버의 기본 최소 TLS 버전은 1.2입니다. minProtocolVersion 필드를 사용하여 최소 TLS 버전을 구성할 수 있습니다. 자세한 내용은 ServerTLSSettings를 참조하세요.

게이트웨이 문제 해결

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

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