Anthos Service Mesh 1.8 문서를 보고 있습니다. 최신 문서를 보거나 사용 가능한 다른 버전을 선택합니다.

Anthos Service Mesh에 GKE 클러스터 추가

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

멀티 클러스터 Anthos Service Mesh 구성은 확장, 위치, 격리와 같은 중요한 기업 문제를 해결할 수 있습니다. 자세한 내용은 멀티 클러스터 사용 사례를 참조하세요. 또한 서비스 메시의 이점을 최대한 활용하려면 애플리케이션을 최적화해야 합니다. 자세한 내용은 Anthos Service Mesh용 애플리케이션 준비를 참조하세요.

기본 요건

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

  • 클러스터에 설치된 Anthos Service Mesh 버전 1.6.8 이상
    • 클러스터가 동일한 프로젝트에 있으면 설치 개요를 참조하여 클러스터를 필수 버전으로 설치하거나 업그레이드합니다.
    • 클러스터가 서로 다른 프로젝트에 있는 경우 다중 프로젝트 설치 및 마이그레이션을 참조하여 클러스터를 필수 버전으로 설치하거나 업그레이드합니다.
  • 동일한 프로젝트에 없는 클러스터를 조인하는 경우 해당 클러스터는 asm-gcp-multiproject 프로필을 사용해 설치되고 동일한 네트워크의 공유 VPC 구성에 있어야 합니다. 또한 공유 VPC를 호스트하는 프로젝트 1개와 클러스터를 생성하는 서비스 프로젝트 2개를 사용하는 것이 좋습니다. 자세한 내용은 공유 VPC를 사용하여 클러스터 설정을 참조하세요.
  • Citadel CA를 사용하는 경우 두 클러스터에 동일한 커스텀 루트 CA를 사용하세요.
  • Anthos Service Mesh가 비공개 클러스터에 빌드된 경우 동일한 VPC에 단일 서브넷을 생성하는 것이 좋습니다. 그렇지 않으면 다음을 확인합니다.
    1. 제어 영역은 클러스터 비공개 IP를 통해 원격 비공개 클러스터 제어 영역에 연결할 수 있습니다.
    2. 호출 제어 영역의 IP 범위를 원격 비공개 클러스터의 승인된 네트워크에 추가할 수 있습니다. 자세한 내용은 비공개 클러스터 간 엔드포인트 디스커버리 구성을 참조하세요.

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

  1. 편의를 위해 작업 폴더를 설정합니다. 이 폴더는 기본 요건 단계인 Anthos Service Mesh 설치 준비 단계에서 Anthos Service Mesh 파일을 다운로드하여 추출한 폴더입니다.

    export PROJECT_DIR=YOUR_WORKING_FOLDER
  2. 각 클러스터의 컨텍스트 변수를 만듭니다. 컨텍스트는 클러스터 프로젝트 ID, 클러스터 이름, 위치를 사용하여 구성된 문자열입니다. 위치 값에는 클러스터의 위치(예: us-west2-a)를 사용하세요. 이 예시에서는 이미 클러스터 1개가 포함된 메시에 다른 클러스터를 추가해 보겠습니다.

    export CTX_1=gke_CLUSTER_1_PROJECT_ID_CLUSTER_1_LOCATION_CLUSTER_1_NAME
    export CTX_2=gke_CLUSTER_2_PROJECT_ID_CLUSTER_2_LOCATION_CLUSTER_2_NAME

클러스터 간 엔드포인트 검색 구성

다음 명령어를 사용하여 클러스터 간 부하 분산의 엔드포인트 검색을 구성합니다. 이 단계에서는 다음 태스크를 수행합니다.

  • istioctl 명령어는 클러스터의 Kube API 서버에 대한 액세스 권한을 부여하는 보안 비밀을 만듭니다.
  • kubectl 명령어는 보안 비밀을 또 다른 클러스터에 적용하여 두 번째 클러스터에서 첫 번째 클러스터의 서비스 엔드포인트를 읽을 수 있도록 합니다.
istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1_NAME} | \
  kubectl apply -f - --context=${CTX_2}
istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2_NAME} | \
  kubectl apply -f - --context=${CTX_1}

비공개 클러스터 간 엔드포인트 디스커버리 구성

비공개 클러스터를 사용할 때는 공개 IP에 액세스할 수 없으므로 공개 IP 대신 원격 클러스터의 비공개 IP를 구성해야 합니다.

  1. 공개 IP를 사용하여 보안 비밀을 임시 파일에 씁니다.

    istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1_NAME} > ${CTX_1}.secret
    
    istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2_NAME} > ${CTX_2}.secret
    
  2. 비공개 클러스터의 비공개 IP를 검색하고 임시 파일의 보안 비밀에서 공개 IP를 비공개 IP로 바꿉니다.

    IFS="_" read -r -a VALS <<< ${CTX_1}
    PROJECT_1=${VALS[1]}
    LOCATION_1=${VALS[2]}
    CLUSTER_1=${VALS[3]}
    PRIV_IP=`gcloud container clusters describe "${CLUSTER_1}" --project "${PROJECT_1}" \
       --zone "${LOCATION_1}" --format "value(privateClusterConfig.privateEndpoint)"`
    sed -i 's/server\:.*/server\: https:\/\/'"${PRIV_IP}"'/' ${CTX_1}.secret
    
    IFS="_" read -r -a VALS <<< ${CTX_2}
    PROJECT_2=${VALS[1]}
    LOCATION_2=${VALS[2]}
    CLUSTER_2=${VALS[3]}
    PRIV_IP=`gcloud container clusters describe "${CLUSTER_2}" --project "${PROJECT_2}" \
       --zone "${LOCATION_2}" --format "value(privateClusterConfig.privateEndpoint)"`
    sed -i 's/server\:.*/server\: https:\/\/'"${PRIV_IP}"'/' ${CTX_2}.secret
    
  3. 클러스터에 새 보안 비밀을 적용합니다.

    kubectl apply -f ${CTX_1}.secret --context=${CTX_2}
    
    kubectl apply -f ${CTX_2}.secret --context=${CTX_1}
    

비공개 클러스터에 승인된 네트워크 구성

다음 모든 조건이 메시에 적용되는 경우에만 이 섹션을 따르세요.

Anthos Service Mesh에 여러 클러스터를 배포할 때 각 클러스터의 Istiod가 원격 클러스터의 GKE 제어 영역을 호출해야 합니다. 트래픽을 허용하려면 호출 클러스터의 Pod 주소 범위를 원격 클러스터의 승인된 네트워크에 추가해야 합니다.

  1. 각 클러스터의 Pod IP CIDR 블록을 가져옵니다.

    POD_IP_CIDR_1=`gcloud container clusters describe ${CLUSTER_1} --zone ${LOCATION_1} \
       --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
    
    POD_IP_CIDR_2=`gcloud container clusters describe ${CLUSTER_2} --zone ${LOCATION_2} \
       --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
    
  2. Kubernetes 클러스터 Pod IP CIDR 블록을 원격 클러스터에 추가합니다.

    EXISTING_CIDR_1=`gcloud container clusters describe ${CLUSTER_1} --zone ${LOCATION_1} \
     --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
    gcloud container clusters update ${CLUSTER_1} --zone ${LOCATION_1} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${POD_IP_CIDR_2},${EXISTING_CIDR_1/;/,}
    
    EXISTING_CIDR_2=`gcloud container clusters describe ${CLUSTER_2} --zone ${LOCATION_2} \
     --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
    gcloud container clusters update ${CLUSTER_2}  --zone ${LOCATION_2} \
    --enable-master-authorized-networks \
    --master-authorized-networks ${POD_IP_CIDR_1},${EXISTING_CIDR_2/;/,}
    

    자세한 내용은 승인된 네트워크로 클러스터 만들기를 참조하세요.

  3. 승인된 네트워크가 업데이트되었는지 확인합니다.

    gcloud container clusters describe ${CLUSTER_1} --zone ${LOCATION_1} \
     --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
    
    gcloud container clusters describe ${CLUSTER_2} --zone ${LOCATION_2} \
     --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
    

비공개 클러스터에서 교차 서브넷 트래픽용 포트 열기

다음 모든 조건이 메시에 적용되는 경우에만 이 섹션을 따르세요.

  • 비공개 클러스터를 사용 중입니다.
  • 메시의 클러스터에 다른 서브넷을 사용합니다.
  • Pod가 443 및 15002 외의 포트를 엽니다.

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

방화벽 규칙을 만듭니다.

TARGET_TAG_1=`gcloud compute firewall-rules list --filter="name~gke-${CLUSTER_1}-[0-9a-z]*-master" --format 'value(targetTags)'`
NEW_FIREWALL_NAME_1=new_firewall_name_1

gcloud compute firewall-rules create ${NEW_FIREWALL_NAME_1} \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges ${POD_IP_CIDR_2} \
    --rules protocol:port[,protocol,port] \
    --target-tags ${TARGET_TAG_1}
TARGET_TAG_2=`gcloud compute firewall-rules list --filter="name~gke-${CLUSTER_2}-[0-9a-z]*-master" --format "value(targetTags)"`
NEW_FIREWALL_NAME_2=new_firewall_name_2
gcloud compute firewall-rules create ${NEW_FIREWALL_NAME_2} \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges ${POD_IP_CIDR_1} \
    --rules protocol:port[,protocol,port] \
    --target-tags ${TARGET_TAG_2}

각 매개변수는 다음과 같습니다.

  • protocol:port는 원하는 포트 및 프로토콜(tcp 또는 udp)입니다.

배포 완료를 확인하기

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

사이드카 삽입 사용 설정

  1. 다음 명령어를 사용하여 istiod 서비스에서 이후 단계에 사용할 버전 라벨 값을 찾습니다.

    kubectl -n istio-system get pods -l app=istiod --show-labels

    결과는 다음과 유사합니다.

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    istiod-asm-173-3-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586
    istiod-asm-173-3-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586
    

    출력의 LABELS 열 아래에서 istio.io/rev= 프리픽스 다음에 있는 istiod 버전 라벨의 값을 확인합니다. 이 예시에서 값은 asm-173-3입니다. 다음 섹션의 단계에서 버전 값을 사용하세요.

HelloWorld 서비스 설치

각 클러스터에서 샘플 네임스페이스와 서비스 정의를 만듭니다.

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

    kubectl create --context=${CTX_1} namespace sample
    
    kubectl create --context=${CTX_2} namespace sample
    
  2. 버전 라벨을 덮어씁니다.

    kubectl label --context=${CTX_1} namespace sample \
          istio-injection- istio.io/rev=REVISION --overwrite
    
    kubectl label --context=${CTX_2} namespace sample \
      istio-injection- istio.io/rev=REVISION --overwrite
    

    여기서 REVISION은 이전에 기록한 istiod 버전 라벨입니다.

    출력은 다음과 같습니다.

    label "istio-injection" not found.
    namespace/sample labeled
    

    label "istio-injection" not found.를 안전하게 무시할 수 있습니다.

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

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

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

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

    kubectl create --context=${CTX_1} \
      -f ${PROJECT_DIR}/samples/helloworld/helloworld.yaml \
      -l version=v1 -n sample
    kubectl create --context=${CTX_2} \
      -f ${PROJECT_DIR}/samples/helloworld/helloworld.yaml \
      -l version=v2 -n sample
  2. 다음 명령어를 사용하여 HelloWorld v1v2가 실행 중인지 확인합니다. 출력이 다음과 비슷한지 확인합니다.

    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 서비스를 배포합니다. 이 pod는 데모용으로 인위적인 네트워크 트래픽을 생성합니다.

    for CTX in ${CTX_1} ${CTX_2}
      do
        kubectl apply --context=${CTX} \
          -f ${PROJECT_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}')" \
        -- curl -sS helloworld.sample:5000/hello
    

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

    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}')" \
        -- curl -sS helloworld.sample:5000/hello
    

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

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

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

HelloWorld 서비스 삭제

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

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