관리형 Cloud Service Mesh의 멀티 클러스터 메시 설정

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

이 가이드에서는 Mesh CA 또는 Certificate Authority Service를 사용하여 두 클러스터를 단일 Cloud Service Mesh로 조인하고 클러스터 간 부하 분산을 사용 설정하는 방법을 설명합니다. 이 프로세스를 손쉽게 확장하여 여러 개의 클러스터를 메시에 조인할 수 있습니다.

멀티 클러스터 Cloud Service Mesh 구성은 확장, 위치, 격리와 같은 중요한 기업 문제를 해결할 수 있습니다. 자세한 내용은 멀티 클러스터 사용 사례를 참조하세요.

기본 요건

이 가이드에서는 다음 요구사항을 충족하는 Google Cloud GKE 클러스터가 2개 이상 있다고 가정합니다.

• 클러스터에 설치된 Cloud Service Mesh. asmcli, istioctl 도구, asmcli에서 --output_dir에 지정된 디렉터리로 다운로드하는 샘플이 필요합니다.
• Cloud Service Mesh를 구성하려면 먼저 메시의 클러스터가 모든 포드 간에 연결되어 있어야 합니다. 또한 동일한 프로젝트에 없는 클러스터를 조인하는 경우 클러스터는 동일한 Fleet 호스트 프로젝트에 등록되어야 하며 클러스터가 동일한 네트워크의 공유 VPC 구성에 함께 있어야 합니다. 또한 공유 VPC를 호스팅할 하나의 프로젝트와 클러스터를 만들기 위한 2개의 서비스 프로젝트를 두는 것이 좋습니다. 자세한 내용은 공유 VPC를 사용하여 클러스터 설정을 참조하세요.
• Certificate Authority Service를 사용하는 경우 모든 클러스터에 동일한 루트 CA 풀에 연결된 각각의 하위 CA 풀이 있어야 합니다. 그렇지 않으면 모두 동일한 CA 풀을 사용해야 합니다.

프로젝트 및 클러스터 변수 설정

1. 다음과 같은 프로젝트 ID, 클러스터 영역 또는 리전, 클러스터 이름, 컨텍스트의 환경 변수를 만듭니다.

   export PROJECT_1=PROJECT_ID_1
   export LOCATION_1=CLUSTER_LOCATION_1
   export CLUSTER_1=CLUSTER_NAME_1
   export CTX_1="gke_${PROJECT_1}_${LOCATION_1}_${CLUSTER_1}"
   
   export PROJECT_2=PROJECT_ID_2
   export LOCATION_2=CLUSTER_LOCATION_2
   export CLUSTER_2=CLUSTER_NAME_2
   export CTX_2="gke_${PROJECT_2}_${LOCATION_2}_${CLUSTER_2}"
   

2. 새로 생성된 클러스터가 있으면 다음 gcloud 명령어로 각 클러스터에 대해 사용자 인증 정보를 가져와야 합니다. 그렇지 않으면 연결된 context를 이 가이드의 다음 단계에서 사용할 수 없습니다.

   명령어는 클러스터 유형(리전 또는 영역)에 따라 달라집니다.

   리전

   gcloud container clusters get-credentials ${CLUSTER_1} --region ${LOCATION_1}
   gcloud container clusters get-credentials ${CLUSTER_2} --region ${LOCATION_2}
   

   영역

   gcloud container clusters get-credentials ${CLUSTER_1} --zone ${LOCATION_1}
   gcloud container clusters get-credentials ${CLUSTER_2} --zone ${LOCATION_2}
   

방화벽 규칙 만들기

일부 경우에는 클러스터 간 트래픽이 허용되도록 방화벽 규칙을 만들어야 합니다. 예를 들어 다음과 같은 경우 방화벽 규칙을 만들어야 합니다.

• 메시의 클러스터에 다른 서브넷을 사용하는 경우
• pod가 443 및 15002 외의 포트를 여는 경우

GKE는 각 노드에 방화벽 규칙을 자동으로 추가하여 동일한 서브넷 내의 트래픽을 허용합니다. 메시에 여러 서브넷이 포함된 경우, 서브넷 간 트래픽을 허용하도록 방화벽 규칙을 명시적으로 설정해야 합니다. 각 서브넷에 대해 새 방화벽 규칙을 추가하여 소스 IP CIDR 블록과 모든 수신 트래픽의 타겟 포트를 허용해야 합니다.

다음 안내를 따라 프로젝트의 모든 클러스터 간 통신 또는 $CLUSTER_1 및 $CLUSTER_2 간 통신만 허용할 수 있습니다.

1. 클러스터 네트워크에 대한 정보를 수집합니다.

   모든 프로젝트 클러스터

   클러스터가 같은 프로젝트에 있으면 다음 명령어를 사용하여 프로젝트의 모든 클러스터 간에 통신할 수 있습니다. 프로젝트에서 노출하지 않으려는 클러스터가 있으면 특정 클러스터 탭의 명령어를 사용합니다.

   function join_by { local IFS="$1"; shift; echo "$*"; }
   ALL_CLUSTER_CIDRS=$(gcloud container clusters list --project $PROJECT_1 --format='value(clusterIpv4Cidr)' | sort | uniq)
   ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}"))
   ALL_CLUSTER_NETTAGS=$(gcloud compute instances list --project $PROJECT_1 --format='value(tags.items.[0])' | sort | uniq)
   ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
   

   특정 클러스터

   다음 명령어는 $CLUSTER_1 및 $CLUSTER_2 간 통신을 허용하며 프로젝트의 다른 클러스터를 노출하지 않습니다.

   function join_by { local IFS="$1"; shift; echo "$*"; }
   ALL_CLUSTER_CIDRS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P container clusters list --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(clusterIpv4Cidr)'; done | sort | uniq)
   ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}"))
   ALL_CLUSTER_NETTAGS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P compute instances list  --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(tags.items.[0])' ; done | sort | uniq)
   ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
   

2. 방화벽 규칙 만들기

   GKE

   gcloud compute firewall-rules create istio-multicluster-pods \
       --allow=tcp,udp,icmp,esp,ah,sctp \
       --direction=INGRESS \
       --priority=900 \
       --source-ranges="${ALL_CLUSTER_CIDRS}" \
       --target-tags="${ALL_CLUSTER_NETTAGS}" --quiet \
       --network=YOUR_NETWORK
   

   Autopilot

   TAGS=""
   for CLUSTER in ${CLUSTER_1} ${CLUSTER_2}
   do
       TAGS+=$(gcloud compute firewall-rules list --filter="Name:$CLUSTER*" --format="value(targetTags)" | uniq) && TAGS+=","
   done
   TAGS=${TAGS::-1}
   echo "Network tags for pod ranges are $TAGS"
   
   gcloud compute firewall-rules create asm-multicluster-pods \
       --allow=tcp,udp,icmp,esp,ah,sctp \
       --network=gke-cluster-vpc \
       --direction=INGRESS \
       --priority=900 --network=VPC_NAME \
       --source-ranges="${ALL_CLUSTER_CIDRS}" \
       --target-tags=$TAGS
   

엔드포인트 검색 구성

참고: 엔드포인트 검색에 대한 자세한 내용은 여러 컨트롤 플레인이 있는 엔드포인트 검색을 참고하세요.

경고: 클러스터 간에 엔드포인트 검색이 사용 설정된 경우 클러스터 간 서비스는 적절한 DNS 구성이 없으면 서로 통신할 수 없습니다. 이는 GKE 서비스가 트래픽 라우팅을 위해 각 서비스의 정규화된 도메인 이름(FQDN)을 사용하기 때문입니다. DNS 프록시를 사용 설정하여 클러스터 간 검색을 허용할 수 있습니다. DNS 프록시는 모든 DNS 요청을 캡처하고 컨트롤 플레인의 정보를 사용하여 확인합니다.

선언적 API로 공개 또는 비공개 클러스터 간 엔드포인트 검색 사용 설정

Fleet API로 관리형 Cloud Service Mesh를 사용 설정하면 이 클러스터에 엔드포인트 검색이 사용 설정됩니다. 다른 도구로 관리형 Cloud Service Mesh를 프로비저닝한 경우 asm-options configmap의 "multicluster_mode":"connected" 구성을 적용하여 Fleet의 공개 또는 비공개 클러스터 간에 엔드포인트 검색을 수동으로 사용 설정할 수 있습니다. 동일한 Fleet에 이 구성이 사용 설정된 클러스터는 서로 간에 상호 클러스터 서비스 검색이 자동으로 사용 설정됩니다.

경고: 클러스터가 기존 클러스터 내 원격 보안 비밀을 사용하는 경우에는 이 방법을 사용하지 마세요.

이는 관리형 (TD) 컨트롤 플레인 구현이 있는 경우 멀티 클러스터 엔드포인트 검색을 구성하는 유일한 방법이며 관리형 (Istiod) 구현의 경우에는 이를 구성하는 데 권장되는 방법입니다.

계속하기 전에 방화벽 규칙을 만들어야 합니다.

사용 설정

asm-options configmap이 클러스터에 이미 존재하는 경우 클러스터에 엔드포인트 검색을 사용 설정합니다.

      kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'

asm-options configmap이 클러스터에 아직 없는 경우에는 이를 연결된 데이터로 만들고 클러스터의 엔드포인트 검색을 사용 설정합니다.

      kubectl --context ${CTX_1} create configmap asm-options -n istio-system --from-file <(echo '{"data":{"multicluster_mode":"connected"}}')

사용 중지

클러스터의 엔드포인트 검색 사용 중지:

      kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"manual"}}'

엔드포인트 검색을 사용 중지하지 않고 Fleet에서 클러스터를 등록 취소하면 보안 비밀이 클러스터에 남아 있을 수 있습니다. 나머지 보안 비밀은 수동으로 삭제해야 합니다.

1. 다음 명령어를 실행하여 삭제해야 할 보안 비밀을 찾습니다.

   kubectl get secrets -n istio-system -l istio.io/owned-by=mesh.googleapis.com,istio/multiCluster=true
   

2. 각 보안 비밀을 삭제합니다.

   kubectl delete secret SECRET_NAME
   

   남은 보안 비밀마다 이 단계를 반복합니다.

멀티 클러스터 연결 확인

이 섹션에서는 샘플 HelloWorld 및 Sleep 서비스를 멀티 클러스터 환경에 배포하여 클러스터 간 부하 분산 작동 방식을 확인하는 방법을 설명합니다.

참고: 이러한 샘플 서비스는 asmcli로 다운로드된 samples 디렉터리(OUTPUT_DIR/samples에 위치)가 아닌 istioctl tar 파일에 포함된 Istio samples 디렉터리(OUTPUT_DIR/istio-${ASM_VERSION%+*}/samples에 위치)에 있습니다.

샘플 디렉터리의 변수 설정

1. asmcli가 다운로드된 위치로 이동하고 다음 명령어를 실행하여 ASM_VERSION을 설정합니다.

   export ASM_VERSION="$(./asmcli --version)"
   

2. 작업 폴더를 클러스터 간 부하 분산이 작동하는지 확인하는 데 사용하는 샘플로 설정합니다. 샘플은 asmcli install 명령어에 지정된 --output_dir 디렉터리의 하위 디렉터리에 있습니다. 다음 명령어에서 OUTPUT_DIR를 --output_dir에 지정한 디렉터리로 변경합니다.

   export SAMPLES_DIR=OUTPUT_DIR/istio-${ASM_VERSION%+*}
   

사이드카 삽입 사용 설정

1. 각 클러스터에 샘플 네임스페이스를 만듭니다.

   for CTX in ${CTX_1} ${CTX_2}
   do
       kubectl create --context=${CTX} namespace sample
   done
   

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

   관리형(TD)

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

   for CTX in ${CTX_1} ${CTX_2}
   do
      kubectl label --context=${CTX} namespace sample \
         istio.io/rev- istio-injection=enabled --overwrite
   done
   

   관리형(Istiod)

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

    for CTX in ${CTX_1} ${CTX_2}
    do
       kubectl label --context=${CTX} namespace sample \
          istio.io/rev- istio-injection=enabled --overwrite
    done
   

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

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

      kubectl -n istio-system get controlplanerevision
      

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

      NAME                AGE
      asm-managed-rapid   6d7h
      

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

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

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

      for CTX in ${CTX_1} ${CTX_2}
      do
        kubectl label --context=${CTX} namespace sample \
           istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      done
      

HelloWorld 서비스 설치

참고: HelloWorld 서비스 예시에서는 Docker Hub를 사용합니다. 비공개 클러스터에서 컨테이너 런타임은 기본적으로 Artifact Registry에서 컨테이너 이미지를 가져올 수 있습니다. 컨테이너 런타임은 인터넷의 다른 컨테이너 이미지 레지스트리에서 이미지를 가져올 수 없습니다. 이미지를 다운로드하고 Artifact Registry로 푸시하거나 Cloud NAT를 사용하여 특정 비공개 노드에 아웃바운드 인터넷 액세스 권한을 제공할 수 있습니다. 자세한 내용은 외부 컨테이너 마이그레이션 및 비공개 클러스터 만들기를 참조하세요.

• 두 클러스터에서 HelloWorld 서비스를 만듭니다.

  kubectl create --context=${CTX_1} \
      -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
      -l service=helloworld -n sample
  

  kubectl create --context=${CTX_2} \
      -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
      -l service=helloworld -n sample
  

HelloWorld v1 및 v2를 각 클러스터에 배포

1. 나중에 클러스터 간 부하 분산을 확인하는 데 도움이 되도록 HelloWorld v1을 CLUSTER_1에, v2를 CLUSTER_2에 배포합니다.

   kubectl create --context=${CTX_1} \
     -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
     -l version=v1 -n sample

   kubectl create --context=${CTX_2} \
     -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
     -l version=v2 -n sample

2. 다음 명령어를 사용하여 HelloWorld v1 및 v2가 실행 중인지 확인합니다. 출력이 다음과 비슷한지 확인합니다.

   kubectl get pod --context=${CTX_1} -n sample

   NAME                            READY     STATUS    RESTARTS   AGE
   helloworld-v1-86f77cd7bd-cpxhv  2/2       Running   0          40s

   kubectl get pod --context=${CTX_2} -n sample

   NAME                            READY     STATUS    RESTARTS   AGE
   helloworld-v2-758dd55874-6x4t8  2/2       Running   0          40s

Sleep 서비스 배포

1. 두 클러스터에 Sleep 서비스를 배포합니다. 이 포드는 데모용으로 인위적인 네트워크 트래픽을 생성합니다.

   for CTX in ${CTX_1} ${CTX_2}
   do
       kubectl apply --context=${CTX} \
           -f ${SAMPLES_DIR}/samples/sleep/sleep.yaml -n sample
   done
   

2. 각 클러스터에서 Sleep 서비스가 시작될 때까지 기다립니다. 출력이 다음과 비슷한지 확인합니다.

   kubectl get pod --context=${CTX_1} -n sample -l app=sleep

   NAME                             READY   STATUS    RESTARTS   AGE
   sleep-754684654f-n6bzf           2/2     Running   0          5s

   kubectl get pod --context=${CTX_2} -n sample -l app=sleep

   NAME                             READY   STATUS    RESTARTS   AGE
   sleep-754684654f-dzl9j           2/2     Running   0          5s

클러스터 간 부하 분산 확인

HelloWorld 서비스를 여러 번 호출하고 출력을 확인하여 v1과 v2에서 번갈아 응답을 보내는지 확인합니다.

1. HelloWorld 서비스를 호출합니다.

   kubectl exec --context="${CTX_1}" -n sample -c sleep \
       "$(kubectl get pod --context="${CTX_1}" -n sample -l \
       app=sleep -o jsonpath='{.items[0].metadata.name}')" \
       -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
   

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

   Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
   Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
   ...

2. HelloWorld 서비스를 다시 호출합니다.

   kubectl exec --context="${CTX_2}" -n sample -c sleep \
       "$(kubectl get pod --context="${CTX_2}" -n sample -l \
       app=sleep -o jsonpath='{.items[0].metadata.name}')" \
       -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
   

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

   Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
   Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
   ...

수고하셨습니다. 멀티 클러스터 Cloud Service Mesh의 부하 분산이 성공적으로 완료되었습니다.

HelloWorld 서비스 삭제

부하 분산이 확인되면 클러스터에서 HelloWorld 및 Sleep 모드를 삭제합니다.

kubectl delete ns sample --context ${CTX_1}
kubectl delete ns sample --context ${CTX_2}