Cloud Service Mesh와 Traffic Director가 이제 Cloud Service Mesh로 통합되었습니다. 자세한 내용은 Cloud Service Mesh 개요를 참조하세요.

이 페이지는 Cloud Translation API를 통해 번역되었습니다.

현대화를 위한 구성 업데이트

이 문서에서는 메시를 ISTIOD 컨트롤 플레인에서 TRAFFIC_DIRECTOR 컨트롤 플레인으로 현대화하기 전에 관리형 Cloud Service Mesh에 적용해야 할 수 있는 구성 업데이트를 설명합니다.

다음은 클러스터 현대화를 위해 클러스터를 준비하는 데 필요한 구성 업데이트 목록입니다. 업데이트 안내는 각 섹션을 참고하세요.

멀티 클러스터
GKE용 워크로드 아이덴티티 제휴 사용 설정
관리형 CNI 사용 설정
사이드카의 비표준 바이너리 사용
Istio 인그레스 게이트웨이로 마이그레이션

현대화 워크플로에 관한 자세한 내용은 관리형 컨트롤 플레인 현대화 페이지를 참고하세요.

Istio 보안 비밀에서 multicluster_mode로 마이그레이션

클러스터에서 TRAFFIC_DIRECTOR 컨트롤 플레인을 사용하는 경우 멀티 클러스터 보안 비밀은 지원되지 않습니다. 이 문서에서는 Istio 멀티 클러스터 보안 비밀 사용에서 multicluster_mode 사용으로 현대화하는 방법을 설명합니다.

Istio 보안 비밀과 선언적 API 개요

오픈소스 Istio 멀티 클러스터 엔드포인트 검색은 istioctl 또는 기타 도구를 사용하여 클러스터에 Kubernetes 보안 비밀을 만드는 방식으로 작동합니다. 이 보안 비밀을 사용하면 클러스터가 메시의 다른 클러스터로 트래픽 부하를 분산할 수 있습니다. 그러면 ISTIOD 컨트롤 플레인에서 이 보안 비밀을 읽고 다른 클러스터로 트래픽 라우팅을 시작합니다.

Cloud Service Mesh에는 Istio 보안 비밀을 직접 만드는 대신 멀티 클러스터 트래픽을 제어하는 선언적 API가 있습니다. 이 API는 Istio 보안 비밀을 구현 세부정보로 취급하며 Istio 보안 비밀을 수동으로 만드는 것보다 안정적입니다. 향후 Cloud Service Mesh 기능은 선언적 API에 종속되며 Istio 보안 비밀로 이러한 새 기능을 직접 사용할 수 없습니다. 선언적 API는 앞으로 지원되는 유일한 경로입니다.

Istio 보안 비밀을 사용하는 경우 선언적 API를 사용하는 것으로 최대한 빨리 마이그레이션하세요. multicluster_mode 설정은 각 클러스터가 메시의 다른 모든 클러스터로 트래픽을 전달하도록 지시합니다. 보안 비밀을 사용하면 더 유연하게 구성할 수 있으므로 각 클러스터에 대해 메시에서 트래픽을 전달할 다른 클러스터를 구성할 수 있습니다. 선언적 API와 Istio 보안 비밀의 지원되는 기능 간의 차이점의 전체 목록은 Istio API를 사용하는 지원 기능을 참고하세요.

Istio 보안 비밀에서 선언적 API로 마이그레이션

Fleet 기능 API를 사용하여 자동 관리를 통해 Cloud Service Mesh를 프로비저닝한 경우 이 안내를 따르지 않아도 됩니다. 이 단계는 asmcli --managed를 사용하여 온보딩한 경우에만 적용됩니다.

이 프로세스는 클러스터를 가리키는 보안 비밀을 변경합니다. 이 과정에서 엔드포인트가 삭제되었다가 다시 추가됩니다. 엔드포인트가 삭제되고 추가되는 사이에 트래픽이 다른 클러스터로 부하 분산되는 대신 잠시 로컬 라우팅으로 되돌아갑니다. 자세한 내용은 GitHub 문제를 참고하세요.

Istio 보안 비밀 사용에서 선언적 API로 전환하려면 다음 단계를 따르세요. 다음 단계를 동시에 또는 연속으로 실행합니다.

multicluster_mode=connected를 설정하여 멀티 클러스터 엔드포인트 검색을 사용 설정하려는 Fleet의 각 클러스터에 선언적 API를 사용 설정합니다. 클러스터를 검색할 수 없도록 하려면 multicluster_mode=disconnected를 명시적으로 설정해야 합니다.

다음 명령어를 사용하여 멀티 클러스터 엔드포인트 검색을 위한 클러스터를 선택합니다.
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
```
다음 명령어를 사용하여 클러스터에서 엔드포인트 검색을 선택 해제합니다.
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
이전 보안 비밀을 삭제합니다.

클러스터에서 multicluster_mode=connected를 설정하면 각 클러스터에 multicluster_mode=connected가 설정된 다른 모든 클러스터에 대해 새 보안 비밀이 생성됩니다. 보안 비밀은 istio-system 네임스페이스에 배치되며 다음 형식입니다.
```
istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
```
각 보안 비밀에 istio.io/owned-by: mesh.googleapis.com 라벨도 적용됩니다.

새 보안 비밀이 생성되면 istioctl create-remote-secret으로 수동으로 만든 보안 비밀을 삭제할 수 있습니다.
```
kubectl delete secret SECRET_NAME -n istio-system
```

마이그레이션이 완료되면 요청 측정항목을 확인하여 예상대로 라우팅되는지 확인합니다.

GKE용 워크로드 아이덴티티 제휴 사용 설정

워크로드 아이덴티티 제휴는 Google Kubernetes Engine 워크로드에 권장되는 안전한 방법입니다. 이를 통해 Compute Engine, BigQuery, Machine Learning API와 같은 Google Cloud 서비스에 액세스할 수 있습니다. 워크로드 아이덴티티 제휴는 IAM 정책을 사용하므로 수동 구성이나 서비스 계정 키 파일과 같은 보안 수준이 낮은 방법이 필요하지 않습니다. 워크로드 아이덴티티 제휴에 관한 자세한 내용은 GKE용 워크로드 아이덴티티 제휴 작동 방식을 참고하세요.

다음 섹션에서는 워크로드 아이덴티티 제휴를 사용 설정하는 방법을 설명합니다.

클러스터에서 워크로드 아이덴티티 제휴 사용 설정

클러스터에 워크로드 아이덴티티 제휴가 사용 설정되어 있는지 확인합니다. 이렇게 하려면 IAM 사용자 인증 정보 유효성 검사에 필수적인 워크로드 아이덴티티 제휴 풀이 GKE 클러스터에 구성되어 있는지 확인합니다.

다음 명령어를 사용하여 클러스터에 설정된 워크로드 ID 풀을 확인합니다.
```
gcloud container clusters describe CLUSTER_NAME \
  --format="value(workloadIdentityConfig.workloadPool)"
```
CLUSTER_NAME을 GKE 클러스터 이름으로 바꿉니다. gcloud의 기본 영역 또는 리전을 아직 지정하지 않았으면 이 명령어를 실행할 때 --region 또는 --zone 플래그를 지정해야 할 수도 있습니다.
출력이 비어 있으면 기존 클러스터 업데이트의 안내에 따라 기존 GKE 클러스터에서 워크로드 ID를 사용 설정합니다.

노드 풀에서 워크로드 아이덴티티 제휴 사용 설정

클러스터에서 워크로드 아이덴티티 제휴를 사용 설정한 후에는 GKE 메타데이터 서버를 사용하도록 노드 풀을 구성해야 합니다.

Standard 클러스터의 모든 노드 풀을 나열합니다. gcloud container node-pools list 명령어를 실행합니다.
```
gcloud container node-pools list --cluster CLUSTER_NAME
```
CLUSTER_NAME을 GKE 클러스터 이름으로 바꿉니다. gcloud의 기본 영역 또는 리전을 아직 지정하지 않았으면 이 명령어를 실행할 때 --region 또는 --zone 플래그를 지정해야 할 수도 있습니다.
각 노드 풀이 GKE 메타데이터 서버를 사용하고 있는지 확인합니다.
```
gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"
```
다음을 바꿉니다.
- NODEPOOL_NAME을 노드 풀 이름으로 바꿉니다.
- CLUSTER_NAME을 GKE 클러스터 이름으로 바꿉니다.
출력에 GKE_METADATA가 포함되지 않으면 기존 노드 풀 업데이트 가이드를 사용하여 노드 풀을 업데이트합니다.

관리형 컨테이너 네트워크 인터페이스(CNI) 사용 설정

이 섹션에서는 Google Kubernetes Engine에서 Cloud Service Mesh에 관리형 CNI를 사용 설정하는 방법을 안내합니다.

관리형 CNI 개요

관리형 컨테이너 네트워크 인터페이스(CNI)는 Istio CNI의 Google 관리 구현입니다. CNI 플러그인은 iptables 규칙을 구성하여 포드 네트워킹을 간소화합니다. 이렇게 하면 애플리케이션과 Envoy 프록시 간에 트래픽 리디렉션이 가능해져 iptables를 관리하는 데 필요한 init-container에 대한 권한이 필요하지 않게 됩니다.

Istio CNI 플러그인이 istio-init 컨테이너를 대체합니다. 이전에는 istio-init 컨테이너가 Istio 사이드카의 트래픽 가로채기를 사용 설정하기 위해 포드의 네트워크 환경을 설정하는 역할을 했습니다. CNI 플러그인은 동일한 네트워크 리디렉션 함수를 수행하지만 승격된 권한의 필요성을 줄여 보안을 강화하는 추가 이점이 있습니다.

따라서 보안 및 안정성을 강화하고 관리 및 문제 해결을 간소화하려면 모든 관리형 Cloud Service Mesh 배포에서 관리형 CNI가 필요합니다.

init 컨테이너에 미치는 영향

init 컨테이너는 설정 태스크를 위해 애플리케이션 컨테이너 전에 실행되는 특수화된 컨테이너입니다. 설정 태스크에는 구성 파일 다운로드, 외부 서비스와 통신, 적용 전 초기화 수행과 같은 태스크가 포함될 수 있습니다. 클러스터에서 관리형 CNI가 사용 설정된 경우 네트워크 액세스를 사용하는 init 컨테이너에 문제가 발생할 수 있습니다.

관리형 CNI를 사용한 포드 설정 프로세스는 다음과 같습니다.

CNI 플러그인은 포드 네트워크 인터페이스를 설정하고 포드 IP를 할당하며 아직 시작되지 않은 Istio 사이드카 프록시로 트래픽을 리디렉션합니다.
모든 init 컨테이너가 실행되고 완료됩니다.
Istio 사이드카 프록시는 애플리케이션 컨테이너와 함께 시작됩니다.

따라서 init 컨테이너가 아웃바운드 네트워크 연결을 시도하거나 메시 내의 서비스에 연결하려고 하면 init 컨테이너의 네트워크 요청이 삭제되거나 잘못 라우팅될 수 있습니다. 이는 요청이 있을 때 포드의 네트워크 트래픽을 관리하는 Istio 사이드카 프록시가 실행되지 않기 때문입니다. 자세한 내용은 Istio CNI 문서를 참고하세요.

클러스터에 관리형 CNI 사용 설정

클러스터에서 관리형 CNI를 사용 설정하려면 이 섹션의 단계를 따르세요.

init 컨테이너에서 네트워크 종속 항목을 삭제합니다. 다음 대안을 고려해 보세요.
- 애플리케이션 로직 또는 컨테이너 수정: 사이드카 프록시가 시작된 후 네트워크 요청이 필요하거나 애플리케이션 컨테이너 내에서 네트워크 작업을 수행하는 init 컨테이너에 대한 종속 항목을 삭제하도록 서비스를 수정할 수 있습니다.
- Kubernetes ConfigMap 또는 보안 비밀 사용: 네트워크 요청에서 가져온 구성 데이터를 Kubernetes ConfigMap 또는 보안 비밀에 저장하고 애플리케이션 컨테이너에 마운트합니다. 대체 솔루션은 Istio 문서를 참고하세요.
클러스터에서 관리형 CNI를 사용 설정합니다.
1. 다음과 같이 구성을 변경합니다.
  1. 다음 명령어를 실행하여 controlPlaneRevision을 찾습니다.
```
kubectl get controlplanerevision -n istio-system
```
  2. ControlPlaneRevision(CPR) 커스텀 리소스(CR)에서 라벨 mesh.cloud.google.com/managed-cni-enabled를 true로 설정합니다.
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/managed-cni-enabled=true \
    --overwrite
```
    CPR_NAME을 이전 단계의 출력에서 NAME 열 아래의 값으로 바꿉니다.
  3. asm-options ConfigMap에서 ASM_OPTS 값을 CNI=on으로 설정합니다.
```
kubectl patch configmap asm-options -n istio-system \
    -p '{"data":{"ASM_OPTS":"CNI=on"}}'
```
  4. ControlPlaneRevision(CPR) 커스텀 리소스(CR)에서 라벨 mesh.cloud.google.com/force-reprovision을 true로 설정합니다. 이 작업은 컨트롤 플레인 재시작을 트리거합니다.
    
    참고: 이 방법은 컨트롤 플레인을 다시 시작하는 데 권장되지 않으며 Cloud Service Mesh 현대화 작업에만 사용해야 합니다.
```
kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/force-reprovision=true \
    --overwrite
```
2. 기능 상태를 확인합니다. 다음 명령어를 사용하여 기능 상태를 가져옵니다.
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
  FLEET_PROJECT_ID를 Fleet 호스트 프로젝트의 ID로 바꿉니다. 일반적으로 FLEET_PROJECT_ID의 이름은 프로젝트와 동일합니다.
  - MANAGED_CNI_NOT_ENABLED 조건이 servicemesh.conditions에서 삭제되었는지 확인합니다.
  - 상태가 업데이트되는 데 최대 15~20분이 걸릴 수 있습니다. 몇 분 정도 기다린 후 명령어를 다시 실행해 보세요.
3. 클러스터의 기능 상태에서 controlPlaneManagement.state가 Active가 되면 포드를 다시 시작합니다.

사이드카에서 비표준 바이너리 사용에서 전환

이 섹션에서는 배포를 distroless Envoy 프록시 이미지와 호환되도록 하는 방법을 제안합니다.

Distroless Envoy 프록시 사이드카 이미지

Cloud Service Mesh는 컨트롤 플레인 구성에 따라 두 가지 유형의 Envoy 프록시 사이드카 이미지(다양한 바이너리가 포함된 Ubuntu 기반 이미지 및 Distroless 이미지)를 사용합니다. Distroless 기본 이미지는 필수 구성요소만 포함하여 보안 및 리소스 최적화에 우선순위를 두는 최소 컨테이너 이미지입니다. 취약점을 방지하기 위해 공격 표면이 줄어듭니다. 자세한 내용은 Distroless 프록시 이미지 문서를 참고하세요.

바이너리 호환성

컨테이너 런타임의 콘텐츠를 필요한 패키지로만 제한하는 것이 좋습니다. 이 접근 방법은 CVE(Common Vulnerabilities and Exposure) 스캐너의 보안과 신호 대 잡음비를 향상시킵니다. Distroless Sidecar 이미지는 최소한의 종속 항목 세트를 보유하고 있으며, 모든 비필수 실행 파일, 라이브러리, 디버깅 도구가 제거됩니다. 따라서 컨테이너 내에서 셸 명령어를 실행하거나 curl, ping 또는 kubectl exec와 같은 기타 디버그 유틸리티를 사용할 수 없습니다.

클러스터를 distroless 이미지와 호환되도록 만들기

구성에서 지원되지 않는 바이너리(예: bash 또는 curl)에 대한 참조를 삭제합니다. 특히 준비, 시작, 활성 프로브 내부와 istio-proxy, istio-init 또는 istio-validation 컨테이너 내의 Lifecycle PostStart 및 PreStop 후크 내부에서 삭제합니다.
특정 사용 사례의 경우 holdApplicationUntilProxyStarts와 같은 대안을 고려하세요.
디버깅의 경우 임시 컨테이너를 사용하여 실행 중인 워크로드 포드에 연결할 수 있습니다. 그런 다음 이를 검사하고 커스텀 명령어를 실행할 수 있습니다. 예시는 Cloud Service Mesh 로그 수집을 참고하세요.

특정 사용 사례에 대한 해결 방법을 찾을 수 없는 경우 지원 받기에서 Google Cloud지원팀에 문의하세요.

Istio 인그레스 게이트웨이로 마이그레이션

이 섹션에서는 Istio 인그레스 게이트웨이로 마이그레이션하는 방법을 보여줍니다. Istio 인그레스 게이트웨이로 마이그레이션하는 방법에는 두 가지가 있습니다.

트래픽 분할을 사용한 단계별 마이그레이션

이 방법은 중단을 최소화하는 데 우선순위를 두며, 새 Istio 게이트웨이로 트래픽을 점진적으로 전송하여 요청의 일부에 대한 성능을 모니터링하고 필요한 경우 빠르게 되돌릴 수 있습니다. 일부 애플리케이션의 경우 레이어 7 트래픽 분할을 구성하기 어려울 수 있으므로 전환 중에 두 게이트웨이 시스템을 동시에 관리해야 합니다. 단계는 트래픽 분할을 사용한 단계별 마이그레이션을 참고하세요.
직접 마이그레이션

이 방법은 테스트를 철저히 수행한 후 모든 트래픽을 새 Istio 게이트웨이로 동시에 리라우팅하는 것입니다. 이 접근 방식의 장점은 기존 설정의 제약 없이 새 게이트웨이를 적응형으로 구성할 수 있도록 이전 게이트웨이의 인프라와 완전히 분리된다는 것입니다. 하지만 전환 중에 새 게이트웨이에 예상치 못한 문제가 발생할 경우 다운타임 위험이 증가합니다. 단계는 직접 마이그레이션을 참고하세요.

다음 마이그레이션 예에서는 애플리케이션 네임스페이스 (기본값)에서 실행되고 Kubernetes Gateway API를 사용하여 외부적으로 노출된 HTTP 서비스 (httpbin)가 있다고 가정합니다. 관련 구성은 다음과 같습니다.

게이트웨이: k8-api-gateway (istio-ingress 네임스페이스) - .example.com로 끝나는 호스트 이름의 포트 80에서 HTTP 트래픽을 리슨하도록 구성됩니다.
HTTPRoute: httpbin-route (default 네임스페이스) - 호스트 이름이 httpbin.example.com이고 경로가 /get로 시작하는 모든 HTTP 요청을 default 네임스페이스 내의 httpbin 서비스로 전달합니다.
httpbin 애플리케이션은 외부 IP 34.57.246.68을 사용하여 액세스할 수 있습니다.

기본 게이트웨이 다이어그램

트래픽 분할을 사용한 단계별 마이그레이션

새 Istio 인그레스 게이트웨이 프로비저닝

샘플 게이트웨이 배포 섹션의 단계에 따라 새 인그레스 게이트웨이를 배포하고 샘플 구성을 요구사항에 맞게 맞춤설정합니다. anthos-service-mesh 저장소의 샘플은 istio-ingressgateway loadBalancer 서비스와 해당 ingress-gateway 포드를 배포하기 위한 것입니다.

게이트웨이 리소스 예시 (istio-ingressgateway.yaml)

 apiVersion: networking.istio.io/v1beta1
 kind: Gateway
 metadata:
   name: istio-api-gateway
   namespace: GATEWAY_NAMESPACE
 spec:
   selector:
     istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:   # or specific hostnames if needed
     - "httpbin.example.com"

게이트웨이 구성을 적용하여 트래픽을 관리합니다.
```
kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE
```
게이트웨이 리소스의 'spec.selector'가 ingress-gateway 포드의 라벨과 일치하는지 확인합니다. 예를 들어 ingress-gateway 포드에 istio=ingressgateway 라벨이 있는 경우 게이트웨이 구성도 이 istio=ingressgateway 라벨을 선택해야 합니다.

새 게이트웨이의 초기 라우팅 구성

Istio VirtualService를 사용하여 애플리케이션의 초기 라우팅 규칙을 정의합니다.

VirtualService 예시 (my-app-vs-new.yaml):

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: APPLICATION_NAMESPACE
spec:
    gateways:
    - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
    hosts:
    - httpbin.example.com
    http:
    - match:
      - uri:
          prefix: /get
      route:
      - destination:
          host: httpbin
          port:
            number: 8000

VirtualService를 적용합니다.

kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE

새로 배포된 Istio 인그레스 게이트웨이를 통해 백엔드 (httpbin) 서비스에 액세스

인그레스 호스트 환경 변수를 최근에 배포된 istio-ingressgateway 부하 분산기와 연결된 외부 IP 주소로 설정합니다.

export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

새 게이트웨이를 사용하여 애플리케이션 (httpbin)에 액세스할 수 있는지 확인합니다.
```
curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"
```
출력은 다음과 비슷합니다.
```
HTTP/1.1 200 OK
```

새 Istio 인그레스 게이트웨이를 사용한 요청 흐름

트래픽 분할을 위해 기존 인그레스 수정

새 게이트웨이 (예: istio-api-gateway)가 성공적으로 설정되었는지 확인한 후 트래픽의 일부를 새 게이트웨이를 통해 라우팅할 수 있습니다. 이렇게 하려면 현재 HTTPRoute를 업데이트하여 소량의 트래픽을 새 게이트웨이로 전달하고, 대부분의 트래픽은 기존 게이트웨이 (k8-api-gateway)를 계속 사용하도록 합니다.

수정할 httproute를 엽니다.

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

초기 가중치가 10% 인 새 인그레스 게이트웨이의 로드 밸런서 서비스를 가리키는 새 백엔드 참조를 추가하고 이전 게이트웨이의 백엔드 가중치를 업데이트합니다.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin-route
  namespace: MY_APP_NAMESPACE  # your application's namespace
spec:
  parentRefs:
  - name: k8-api-gateway
    namespace: istio-ingress
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /get
    backendRefs:
    - name: httpbin
      port: 8000
      weight: 90
    - name: istio-ingressgateway # Newly deployed load balancer service
      namespace: GATEWAY_NAMESPACE
      port: 80
      weight: 10

참조 부여를 사용하여 교차 네임스페이스 참조 권한을 부여합니다.

애플리케이션 네임스페이스 (기본값)의 HTTPRoute가 게이트웨이 네임스페이스 (istio-ingress)의 loadbalancer 서비스에 액세스하도록 허용하려면 참조 권한 부여를 만들어야 할 수 있습니다. 이 리소스는 보안 관리 역할을 하며 허용되는 교차 네임스페이스 참조를 명시적으로 정의합니다.

다음 istio-ingress-grant.yaml은 참조 권한 부여의 예를 설명합니다.

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: istio-ingressgateway-grant
  namespace: istio-ingress # Namespace of the referenced resource
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute 
    namespace: MY_APP_NAMESPACE # Namespace of the referencing resource
  to:
  - group: ""               # Core Kubernetes API group for Services
    kind: Service
    name: istio-ingressgateway # Loadbalancer Service of the new ingress gateway

참조 권한을 적용합니다.

kubectl apply -f istio-ingress-grant.yaml -n GATEWAY_NAMESPACE

기존 외부 IP 주소에 대한 요청을 확인합니다 (예: 34.57.246.68)은 실패하지 않습니다. 다음 check-traffic-flow.sh에서는 요청 실패를 확인하는 스크립트를 설명합니다.

# Update the following values based on your application setup
external_ip="34.57.246.68" # Replace with existing external IP
url="http://$external_ip/get"
host_name="httpbin.example.com"

# Counter for successful requests
success_count=0

# Loop 50 times
for i in {1..50}; do
  # Perform the curl request and capture the status code
  status_code=$(curl -s -HHost:"$host_name" -o /dev/null -w "%{http_code}" "$url")
  # Check if the request was successful (status code 200)
  if [ "$status_code" -eq 200 ]; then
    ((success_count++))  # Increment the success counter
  else
    echo "Request $i: Failed with status code $status_code"
  fi
done

# After the loop, check if all requests were successful
if [ "$success_count" -eq 50 ]; then
  echo "All 50 requests were successful!"
else
  echo "Some requests failed.  Successful requests: $success_count"
fi

트래픽 경로와 관계없이 요청이 실패하지 않는지 확인하기 위해 스크립트를 실행합니다.
```
chmod +x check-traffic-flow.sh
./check-traffic-flow.sh
```

기존 게이트웨이와 새 Istio 인그레스 게이트웨이 간에 트래픽이 분할된 요청 흐름

트래픽 비율을 천천히 늘립니다.

기존 외부 IP 주소 (예: 34.57.246.68)에 대한 요청 실패가 표시되지 않으면 HTTPRoute에서 백엔드 가중치를 조정하여 새 Istio 인그레스 게이트웨이로 트래픽을 점진적으로 이동합니다. istio-ingressgateway의 가중치를 늘리고 이전 게이트웨이의 가중치를 10%, 20% 등과 같은 작은 증분으로 줄입니다.

다음 명령어를 사용하여 기존 HTTPRoute를 업데이트합니다.

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

전체 트래픽 이전 및 이전 게이트웨이 삭제

새 Istio 인그레스 게이트웨이가 안정적인 성능을 보이고 요청을 성공적으로 처리하면 모든 트래픽을 새 게이트웨이로 전환합니다. HTTPRoute를 업데이트하여 이전 게이트웨이의 백엔드 가중치를 0로, 새 게이트웨이의 백엔드 가중치를 100로 설정합니다.
트래픽이 새 게이트웨이로 완전히 라우팅되면 새 Istio 인그레스 게이트웨이 프로비저닝에서 생성된 부하 분산기 서비스의 외부 IP 주소를 가리키도록 애플리케이션 호스트 이름 (예: httpbin.example.com)의 외부 DNS 레코드를 업데이트합니다.

마지막으로 이전 게이트웨이와 연결된 리소스를 삭제합니다.

kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE

직접 마이그레이션