공유 제어 영역 단일 VPC 아키텍처로 GKE에서 멀티 클러스터 서비스 메시 빌드

이 가이드에서는 Istio 멀티 클러스터 서비스 메시를 사용하여 여러 Kubernetes 클러스터에 앱을 배포하는 방법을 설명합니다. Istio 멀티 클러스터 서비스 메시를 사용하면 여러 Kubernetes 클러스터에서 실행되는 서비스가 서로 안전하게 통신할 수 있습니다. Kubernetes 클러스터는 Google Cloud에서 실행되는 Google Kubernetes Engine(GKE) 클러스터나 온프레미스 데이터 센터에서 실행되는 Kubernetes 클러스터와 같은 다양한 Cloud Platform 어디서나 실행될 수 있습니다.

Istio는 Kubernetes 클러스터에서 실행되는 서비스를 검색하고, 동적으로 경로를 지정하고, 안전하게 연결할 수 있는 서비스 메시를 오픈소스로 구현한 것입니다. Istio는 또한 애플리케이션 코드를 거의 또는 전혀 변경하지 않고도 라우팅, 부하 분산, 제한, 원격 분석, 회로 차단, 인증, 승인 서비스 호출에 사용되는 정책 기반 프레임워크를 메시에서 제공합니다. Istio는 Kubernetes 클러스터에 설치되면 Kubernetes 서비스 레지스트리를 사용하여 클러스터에서 실행되는 상호 연결된 서비스(또는 마이크로서비스)의 서비스 메시를 자동으로 검색하고 만듭니다.

참고: Istio는 오픈소스 도구이며 공식 Google 제품이 아닙니다.

Istio의 구성요소는 데이터 영역 및 제어 영역으로 설명할 수 있습니다. 데이터 영역은 메시에서 네트워크 트래픽 전달을 담당하고, 제어 영역은 메시 구성과 관리를 담당합니다.

• 데이터 영역: Istio는 메시 내 서비스의 각 pod에서 프록시를 실행할 사이드카 컨테이너를 삽입하여 서비스 통신에 참여합니다. 사이드카는 Envoy라는 지능형 프록시를 실행하여 서비스의 라우팅, 보안, 관측 가능성을 제공합니다.
• 제어 영역: Pilot이라는 구성요소가 Envoy 사이드카에 구성을 제공합니다. 인증서는 Citadel이라는 구성요소에 의해 각 서비스에 할당됩니다.

Kubernetes 클러스터 하나에서 실행 중인 마이크로서비스가 다른 Kubernetes 클러스터에서 실행 중인 마이크로서비스와 통신해야 할 수 있습니다. 예를 들어 마이크로서비스가 여러 리전에 걸쳐 통신해야 하고 환경 또는 마이크로서비스 소유자가 유지보수하는 자체 Kubernetes 클러스터가 있을 수 있습니다. Istio를 사용하면 단일 Kubernetes 클러스터를 벗어나는 서비스 메시를 만들어 원격 클러스터에서 실행되는 마이크로서비스 및 Kubernetes 외부의 VM에서 실행되는 외부 마이크로서비스까지 포함할 수 있습니다.

Istio는 멀티 클러스터 배포용으로 다음 두 가지 기본 구성을 제공합니다.

• 공유 제어 영역이 있는 멀티 클러스터 서비스 메시
• 여러 제어 영역이 있는 멀티 클러스터 서비스 메시

공유 Istio 제어 영역 구성은 클러스터 중 하나에서 실행되는 Istio 제어 영역을 사용합니다. 제어 영역의 Pilot은 로컬 및 원격 클러스터에서 서비스 구성을 관리하고, 모든 클러스터의 Envoy 사이드카를 구성합니다. 이 구성을 사용하면 여러 Kubernetes 클러스터에서 실행되는 서비스를 포함하는 단일 Istio 서비스 메시가 생성됩니다. 공유 제어 영역 구성에서는 Istio 제어 영역 클러스터에서 실행되는 Pilot에 모든 클러스터에서 실행되는 모든 pod에 대한 IP 주소 액세스 권한이 있어야합니다.

다음 두 가지 방법 중 하나로 클러스터 사이에서 pod 간 IP 주소 연결이 가능합니다.

1. 예를 들어 클러스터 사이에서 pod 간 IP 주소 연결을 허용하는 방화벽 규칙이 있는 단일 VPC와 같은 평면적인 네트워크에서 모든 클러스터를 만듭니다. 클러스터는 VPN 연결 네트워크에도 있을 수 있습니다. 어느 경우든 제어 클러스터의 Pilot pod는 pod IP 주소를 통해 직접 원격 클러스터의 모든 pod에 액세스할 수 있습니다.
2. 클러스터가 단일 네트워크에 있지 않고, 제어 클러스터의 Pilot pod가 원격 클러스터의 pod에 도달하기 위해 다른 메커니즘을 사용합니다. 이 시나리오에서는 Pilot pod가 pod IP로 다른 pod에 직접 액세스할 수 없으므로 Istio 인그레스 게이트웨이를 사용하여 서로 다른 네트워크의 클러스터 간에 네트워크 연결을 수행합니다.

이 가이드에서는 단일 VPC 네트워크에서 공유 제어 영역 아키텍처를 사용하여 두 GKE 클러스터에 Istio를 배포합니다. Istio 제어 영역 클러스터의 Pilot pod는 원격 클러스터에서 실행되는 pod에 대한 직접 IP 주소 연결을 갖습니다. 이를 위해 GKE 클러스터 두 개로 분할된 Online Boutique라는 10등급의 데모 마이크로서비스 앱을 사용합니다. 마이크로서비스는 다양한 프로그래밍 언어로 작성됩니다. 각 마이크로서비스의 언어를 확인하려면 README 페이지를 참조하세요.

Google Cloud 프로젝트 내에서 다음 아키텍처를 빌드합니다.

이 아키텍처에는 control 클러스터와 remote 클러스터가 있습니다. Istio 제어 영역은 control 클러스터에 배포됩니다. 클러스터는 로컬로(동일한 클러스터에 있는 경우) 그리고 비로컬로(다른 클러스터에 있는 경우) 다양한 마이크로서비스와 통신합니다.

목표

• 단일 VPC에서 control과 remote라는 두 개의 GKE 클러스터를 만듭니다.
• 두 GKE 클러스터 모두에 멀티 클러스터 모드로 Istio를 설치하고 control 클러스터에 Istio 제어 영역을 배포합니다.
• 두 클러스터에 분할된 Online Boutique 앱을 설치합니다.
• 두 클러스터에서 확장된 서비스 메시를 관찰합니다.

비용

이 가이드에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.

• Compute Engine
• GKE
• Cloud Load Balancing
• 네트워킹

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. Google Cloud를 처음 사용하는 사용자는 무료 체험판을 사용할 수 있습니다.

이 가이드를 마치면 만든 리소스를 삭제하여 비용이 계속 청구되지 않게 할 수 있습니다. 자세한 내용은 삭제를 참조하세요.

시작하기 전에

1. Google Cloud 계정에 로그인합니다. Google Cloud를 처음 사용하는 경우 계정을 만들고 Google 제품의 실제 성능을 평가해 보세요. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.

2. Google Cloud Console의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.

   참고: 이 절차에서 생성한 리소스를 유지하지 않으려면 기존 프로젝트를 선택하지 말고 프로젝트를 새로 만드세요. 작업이 끝나면 프로젝트를 삭제하여 프로젝트와 관련된 모든 리소스를 삭제할 수 있습니다.

   프로젝트 선택기로 이동

3. Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다. 프로젝트에 결제가 사용 설정되어 있는지 확인하는 방법을 알아보세요.

4. GKE and Cloud Source Repositories API를 사용 설정합니다.

   API 사용 설정

환경 설정

Cloud Shell에서 이 가이드의 모든 터미널 명령어를 실행합니다.

1. Google Cloud Console에서 Cloud Shell을 엽니다.

   Cloud Shell 열기

2. 다음 GitHub 저장소를 클론하여 이 가이드에 필요한 파일을 다운로드합니다.

   cd $HOME
   git clone https://github.com/GoogleCloudPlatform/istio-multicluster-gke.git
   

3. 저장소 폴더를 이 가이드와 관련된 모든 태스크를 수행하는 $WORKDIR 폴더로 만듭니다.

   cd $HOME/istio-multicluster-gke
   WORKDIR=$(pwd)
   

   가이드를 완료하면 폴더를 삭제할 수 있습니다.

4. kubectx/kubens를 설치합니다.

   git clone https://github.com/ahmetb/kubectx $WORKDIR/kubectx
   export PATH=$PATH:$WORKDIR/kubectx
   

   이러한 도구를 사용하면 컨텍스트 또는 네임스페이스를 전환하여 여러 Kubernetes 클러스터 작업을 더 쉽게 수행할 수 있습니다.

GKE 클러스터 만들기

이 섹션에서는 별칭 IP 주소가 사용 설정된 기본 VPC에 두 개의 GKE 클러스터를 만듭니다. 별칭 IP 범위를 사용하면 GKE 클러스터가 Google Cloud에 알려진 CIDR 블록에서 IP 주소를 할당할 수 있습니다. 이 구성을 사용하면 VPC 내에서 IP 주소를 기본적으로 라우팅할 수 있으므로 여러 클러스터의 pod가 직접 IP 주소에 연결할 수 있습니다.

1. Cloud Shell에서 Istio 제어 영역이 설치된 control이라는 클러스터 하나와 Istio 멀티 클러스터 서비스 메시에 추가할 remote라는 두 번째 클러스터 등 두 개의 GKE 클러스터를 만듭니다. 두 클러스터는 기본 VPC에 만들되 리전은 달라야 합니다.

   gcloud container clusters create control --zone us-west2-a --username "admin" \
       --machine-type "n1-standard-2" --image-type "COS" --disk-size "100" \
       --num-nodes "4" --network "default" --enable-stackdriver-kubernetes --enable-ip-alias --async
   
   gcloud container clusters create remote --zone us-central1-f --username "admin" \
       --machine-type "n1-standard-2" --image-type "COS" --disk-size "100" \
       --num-nodes "4" --network "default" --enable-stackdriver-kubernetes --enable-ip-alias
   

2. 두 클러스터가 모두 생성될 때까지 몇 분 정도 기다립니다. 각 클러스터의 상태가 RUNNING인지 확인합니다.

   gcloud container clusters list
   

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

   NAME     LOCATION       MASTER_VERSION    MASTER_IP        MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
   remote   us-central1-f  1.16.15-gke.6000  104.197.183.119  n1-standard-2  1.16.15-gke.6000  4          RUNNING
   control  us-west2-a     1.16.15-gke.6000  34.94.180.21     n1-standard-2  1.16.15-gke.6000  4          RUNNING
   

3. 이 가이드의 새 kubeconfig 파일을 사용하도록 KUBECONFIG 변수를 설정합니다.

   touch ${WORKDIR}/istiokubecfg
   export KUBECONFIG=${WORKDIR}/istiokubecfg
   

4. 두 클러스터 모두에 연결하여 kubeconfig 파일에 항목을 생성합니다.

   export PROJECT_ID=$(gcloud info --format='value(config.project)')
   gcloud container clusters get-credentials control --zone us-west2-a --project ${PROJECT_ID}
   gcloud container clusters get-credentials remote --zone us-central1-f --project ${PROJECT_ID}
   

   kubeconfig 파일은 클러스터에 인증하는 데 사용됩니다. kubeconfig 파일을 만든 후 클러스터 간에 컨텍스트를 빠르게 전환할 수 있습니다.

5. 편의상 kubectx를 사용하여 컨텍스트 이름을 바꿉니다.

   kubectx control=gke_${PROJECT_ID}_us-west2-a_control
   kubectx remote=gke_${PROJECT_ID}_us-central1-f_remote
   

네트워킹 구성

이 섹션에서는 두 클러스터의 pod가 직접 IP 주소 연결을 갖도록 VPC 경로를 구성합니다. GKE 클러스터에 별칭 IP 범위를 사용 설정하면 각 클러스터에 두 개의 보조 서브넷이 생성됩니다. 기본 서브넷은 노드 IP 주소에 사용되고 두 개의 보조 서브넷은 Pod CIDR 및 서비스 IP 주소에 사용됩니다.

1. Cloud Shell에서 두 클러스터의 IP 주소를 검사합니다.

   gcloud compute networks subnets describe default --region=us-west2 --format=json | jq '.secondaryIpRanges[]'
   gcloud compute networks subnets describe default --region=us-central1 --format=json | jq '.secondaryIpRanges[]'
   

   control 클러스터의 경우 출력은 다음과 비슷합니다.

   {
     "ipCidrRange": "10.56.0.0/14",
     "rangeName": "gke-control-pods-47496b0c"
   }
   {
     "ipCidrRange": "10.0.0.0/20",
     "rangeName": "gke-control-services-47496b0c"
   }
   

   remote 클러스터의 경우 출력은 다음과 비슷합니다.

   {
     "ipCidrRange": "10.0.16.0/20",
     "rangeName": "gke-remote-services-66101313"
   }
   {
     "ipCidrRange": "10.60.0.0/14",
     "rangeName": "gke-remote-pods-66101313"
   }
   

2. 클러스터의 pod IP 범위와 기본 IP 주소 범위를 나중에 사용할 수 있도록 변수에 저장합니다.

   CONTROL_POD_CIDR=$(gcloud container clusters describe control --zone us-west2-a --format=json | jq -r '.clusterIpv4Cidr')
   REMOTE_POD_CIDR=$(gcloud container clusters describe remote --zone us-central1-f --format=json | jq -r '.clusterIpv4Cidr')
   CONTROL_PRIMARY_CIDR=$(gcloud compute networks subnets describe default --region=us-west2 --format=json | jq -r '.ipCidrRange')
   REMOTE_PRIMARY_CIDR=$(gcloud compute networks subnets describe default --region=us-central1 --format=json | jq -r '.ipCidrRange')
   

3. 모든 IP CIDR 범위 모두에 대한 목록 변수를 만듭니다.

   ALL_CLUSTER_CIDRS=$CONTROL_POD_CIDR,$REMOTE_POD_CIDR,$CONTROL_PRIMARY_CIDR,$REMOTE_PRIMARY_CIDR
   

   모든 노드가 서로 통신하고 pod CIDR 범위와 통신할 수 있어야 합니다.

4. 클러스터 노드의 네트워크 태그를 변수에 저장합니다.

   ALL_CLUSTER_NETTAGS=$(gcloud compute instances list --format=json | jq -r '.[].tags.items[0]' | uniq | awk -vORS=, '{ print $1 }' | sed 's/,$/\n/')
   

   이 네트워크 태그는 나중에 방화벽 규칙에서 사용합니다.

5. 클러스터의 pod CIDR 범위와 노드 사이의 트래픽을 허용하는 방화벽 규칙을 만듭니다.

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

두 GKE 클러스터 모두에 Istio 설치

이 섹션에서는 Istio Operator를 사용하여 두 GKE 클러스터 모두에 멀티 클러스터 구성으로 Istio를 설치하고 구성합니다.

1. Cloud Shell에서 Istio를 다운로드합니다.

   cd ${WORKDIR}
   export ISTIO_VER=1.8.2
   curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VER} TARGET_ARCH=x86_64 sh -
   

   프로덕션 환경에서는 일관된 동작을 보장하기 위해 앱 버전을 하드 코딩하는 것이 좋습니다(즉, 알려지고 테스트를 거친 버전의 번호 사용).

멀티 클러스터 서비스 메시 배포를 수행하려면 메시의 모든 클러스터 간에 신뢰 관계를 설정해야 합니다. 공통 루트 인증 기관(CA)을 사용하여 여러 클러스터에 대해 중간 인증서를 생성할 수 있습니다. 기본적으로 모든 클러스터는 자체 서명된 인증서를 만듭니다. 루트 CA는 메시 내의 모든 워크로드에서 신뢰할 수 있는 루트로 사용됩니다. 각 Istio CA는 루트 CA에서 서명한 중간 CA 서명 키와 인증서를 사용합니다. 하나의 메시 내에 여러 Istio CA가 존재하는 경우 CA 간에 신뢰할 수 있는 계층 구조가 설정됩니다. Istio 저장소에는 교육용으로만 사용할 수 있는 샘플 인증서가 함께 제공됩니다. 각 클러스터 내에서 이전에 만든 올바른 클러스터 인증서로 istio-system 네임스페이스와 cacrts라는 보안 비밀을 만듭니다.

1. 두 GKE 클러스터 모두에서 istio-system 네임스페이스와 cacerts 보안 비밀을 만듭니다.

   kubectl --context control create namespace istio-system
   kubectl --context control create secret generic cacerts -n istio-system \
     --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-cert.pem \
     --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-key.pem \
     --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/root-cert.pem \
     --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/cert-chain.pem
   kubectl --context remote create namespace istio-system
   kubectl --context remote create secret generic cacerts -n istio-system \
     --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-cert.pem \
     --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/ca-key.pem \
     --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/root-cert.pem \
     --from-file=${WORKDIR}/istio-$ISTIO_VER/samples/certs/cert-chain.pem
   

2. control 클러스터의 istio 구성을 만듭니다.

   cat <<EOF > ${WORKDIR}/istio_control.yaml
   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   metadata:
     name: istio-control
   spec:
     values:
       global:
         meshID: mesh1
         multiCluster:
           clusterName: control
         network: network1
     components:
       ingressGateways:
         - name: istio-eastwestgateway
           label:
             istio: eastwestgateway
             app: istio-eastwestgateway
             topology.istio.io/network: network1
           enabled: true
           k8s:
             env:
               # sni-dnat adds the clusters required for AUTO_PASSTHROUGH mode
               - name: ISTIO_META_ROUTER_MODE
                 value: "sni-dnat"
               # traffic through this gateway should be routed inside the network
               - name: ISTIO_META_REQUESTED_NETWORK_VIEW
                 value: network1
             serviceAnnotations:
               cloud.google.com/load-balancer-type: "Internal"
               networking.gke.io/internal-load-balancer-allow-global-access: "true"
             service:
               ports:
                 - name: status-port
                   port: 15021
                   targetPort: 15021
                 - name: tls
                   port: 15443
                   targetPort: 15443
                 - name: tls-istiod
                   port: 15012
                   targetPort: 15012
                 - name: tls-webhook
                   port: 15017
                   targetPort: 15017
   EOF
   

3. control 클러스터에 Istio 제어 영역을 설치합니다.

   ${WORKDIR}/istio-${ISTIO_VER}/bin/istioctl install --context control -f ${WORKDIR}/istio_control.yaml
   

   y를 입력하여 설치를 계속합니다. Istio를 설치하는 데 2~3분 정도 걸립니다.

4. 모든 Istio 배포가 실행 중인지 확인합니다.

   kubectl --context control get pods -n istio-system
   

   모든 Pod가 실행 중이거나 완료되면 Istio가 준비된 것입니다.

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

   NAME                                     READY   STATUS    RESTARTS   AGE
   istio-eastwestgateway-69b49b9785-f5msp   1/1     Running   0          9m11s
   istio-ingressgateway-5c65f88f66-rdd2r    1/1     Running   0          52m
   istiod-6c56d9cbd8-k9klt                  1/1     Running   0          52m
   

5. istio-eastwestgateway 서비스에 외부 IP 주소가 할당될 때까지 기다립니다. istio-eastwestgateway의 외부 IP 주소를 검사합니다.

   kubectl --context control get svc istio-eastwestgateway -n istio-system
   

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

   NAME                    TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)                                                           AGE
   istio-eastwestgateway   LoadBalancer   10.60.7.19   10.168.0.6    15021:31557/TCP,15443:30306/TCP,15012:31791/TCP,15017:32341/TCP   14m
   

   외부 IP 주소는 내부 부하 분산기 IP 주소입니다. 두 클러스터 모두 동일한 VPC에 있고 내부 부하 분산기를 통해 통신할 수 있으므로 내부 부하 분산기가 필요합니다.

6. istio-eastwestgateway 게이트웨이와 VirtualService를 사용하여 control 클러스터에서 istiod 서비스를 노출합니다. remote 클러스터의 Envoy 프록시는 control 클러스터의 istiod 서비스와 통신할 수 있어야 합니다. 다음 명령어를 실행하여 게이트웨이와 VirtualService를 만듭니다.

   kubectl --context control apply -f ${WORKDIR}/istio-1.8.2/samples/multicluster/expose-istiod.yaml
   

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

   gateway.networking.istio.io/istiod-gateway created
   virtualservice.networking.istio.io/istiod-vs created
   

   control 클러스터의 Istio 제어 영역에 remote 클러스터 API 서버에 대한 액세스 권한을 부여합니다. 이렇게 하면 다음이 가능합니다.

   1. 제어 영역이 remote 클러스터에서 실행되는 워크로드의 연결 요청을 인증하게 됩니다. API 서버에 액세스할 수 없으면 제어 영역이 요청을 거부합니다.
   2. remote 클러스터에서 실행되는 서비스 엔드포인트를 검색할 수 있습니다.

7. control 클러스터의 Istio 제어 영역에 remote 클러스터 API 서버에 대한 액세스 권한을 부여하려면 다음 명령어를 실행합니다.

   ${WORKDIR}/istio-${ISTIO_VER}/bin/istioctl x create-remote-secret \
   --context=remote \
   --name=remote | \
   kubectl apply -f - --context=control
   

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

   secret/istio-remote-secret-remote created
   

   다음 단계에서는 remote 클러스터의 리소스에 액세스할 수 있는 권한으로 control 클러스터를 구성합니다.

   Istio 제어 영역은 서비스, 엔드포인트, pod 속성을 검색하기 위해 메시의 모든 클러스터에 대한 액세스 권한이 필요합니다. 이 액세스 권한을 얻으려면 control 클러스터에서 보안 비밀로 추가되는 remote 클러스터의 kubeconfig 파일을 만듭니다. istio-remote Helm 차트는 remote 클러스터에 최소 필수 역할 기반 액세스 제어(RBAC) 액세스 권한이 있는 istio-multi라는 Kubernetes 서비스 계정을 만듭니다. 다음 단계에서는 istio-multi 서비스 계정의 사용자 인증 정보를 사용하여 remote 클러스터의 kubeconfig 파일을 생성합니다.

8. remote 클러스터의 istio 구성을 만듭니다.

   cat <<EOF > ${WORKDIR}/istio_remote.yaml
   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   spec:
     profile: remote
     values:
       global:
         meshID: mesh1
         multiCluster:
           clusterName: remote
         network: network1
         remotePilotAddress: ${DISCOVERY_ADDRESS}
   EOF
   

9. remote 클러스터에 Istio를 설치합니다.

   ${WORKDIR}/istio-${ISTIO_VER}/bin/istioctl install --context=remote -f ${WORKDIR}/istio_remote.yaml
   

   y를 입력하여 설치를 계속합니다. Istio를 설치하는 데 2~3분 정도 걸립니다.

10. remote 클러스터에서 Istio 배포를 검사합니다.

    kubectl --context remote -n istio-system get pods
    

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

    NAME                                   READY   STATUS    RESTARTS   AGE
    istio-ingressgateway-c68779485-4fpmm   1/1     Running   0          3m50s
    istiod-866555cf49-w6qsx                1/1     Running   0          3m57s
    

    이제 두 클러스터가 remote 클러스터에 Istio 제어 영역을 제공하며 control 클러스터로 설정됩니다. 다음 섹션에서는 두 클러스터 간에 분할된 샘플 애플리케이션을 배포합니다.

Online Boutique 앱 배포

이 섹션에서는 Online Boutique 애플리케이션을 두 클러스터 모두에 설치합니다.

1. Cloud Shell에서 두 클러스터 모두에 online-boutique 네임스페이스를 만듭니다.

   for cluster in $(kubectx);
   do
       kubectx $cluster;
       kubectl create namespace online-boutique;
   done
   

2. 자동 Istio 사이드카 프록시 주입을 위해 두 클러스터 모두의 online-boutique 네임스페이스에 라벨을 지정합니다.

   for cluster in $(kubectx);
   do
       kubectx $cluster;
       kubectl label namespace online-boutique istio-injection=enabled
   done
   

   이 단계로 online-boutique 네임스페이스에서 생성되는 모든 Pod에 Envoy 사이드카 컨테이너가 배포됩니다.

3. control 클러스터에 Online Boutique 앱 리소스를 설치합니다.

   kubectl --context control -n online-boutique apply -f $WORKDIR/istio-single-controlplane/single-network/control
   

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

   deployment.apps/emailservice created
   deployment.apps/checkoutservice created
   deployment.apps/frontend created
   deployment.apps/paymentservice created
   deployment.apps/productcatalogservice created
   deployment.apps/currencyservice created
   deployment.apps/shippingservice created
   deployment.apps/adservice created
   gateway.networking.istio.io/frontend-gateway created
   virtualservice.networking.istio.io/frontend-ingress created
   serviceentry.networking.istio.io/currency-provider-external created
   virtualservice.networking.istio.io/frontend created
   serviceentry.networking.istio.io/whitelist-egress-googleapis created
   service/emailservice created
   service/checkoutservice created
   service/recommendationservice created
   service/frontend created
   service/paymentservice created
   service/productcatalogservice created
   service/cartservice created
   service/currencyservice created
   service/shippingservice created
   service/redis-cart created
   service/adservice created
   

4. remote 클러스터에 Online Boutique 앱 리소스를 설치합니다.

   kubectl --context remote -n online-boutique apply -f $WORKDIR/istio-single-controlplane/single-network/remote
   

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

   deployment.apps/loadgenerator created
   deployment.apps/cartservice created
   deployment.apps/recommendationservice created
   service/emailservice created
   service/checkoutservice created
   service/recommendationservice created
   service/frontend created
   service/paymentservice created
   service/productcatalogservice created
   service/cartservice created
   service/currencyservice created
   service/shippingservice created
   service/redis-cart created
   service/adservice created
   

5. control 클러스터에서 모든 워크로드가 실행 중인지 확인합니다.

   kubectl --context control -n online-boutique get pods
   

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

   NAME                                     READY   STATUS    RESTARTS   AGE
   adservice-5db678b487-zs6g9               2/2     Running   0          69s
   checkoutservice-b5b8858c7-djnzk          2/2     Running   0          70s
   currencyservice-954d8c5f-mv7kh           2/2     Running   0          70s
   emailservice-5c5555556b-9jk59            2/2     Running   0          71s
   frontend-6fbb48ffc6-gmnsv                2/2     Running   0          70s
   paymentservice-5684b97df7-l9ccn          2/2     Running   0          70s
   productcatalogservice-55479b967c-vqw6w   2/2     Running   0          70s
   shippingservice-59bd8c7b8c-wln4v         2/2     Running   0          69s
   

6. remote 클러스터에서 모든 워크로드가 실행 중인지 확인합니다.

   kubectl --context remote -n online-boutique get pods
   

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

   NAME                                     READY   STATUS    RESTARTS   AGE
   cartservice-5db5d5c5f9-vvwgx             2/2     Running   0          63s
   loadgenerator-8bcfd68db-gmlfk            2/2     Running   0          63s
   recommendationservice-859c7c66d5-f2x9m   2/2     Running   0          63s
   

이전 두 단계의 결과는 Online Boutique 앱 마이크로서비스가 control 클러스터와 remote 클러스터 사이에 분할된 것을 보여줍니다.

참고: Online Boutique 앱에서 모든 배포가 실행되려면 2~3분 정도 걸립니다.

Online Boutique 앱 액세스

1. Cloud Shell에서 control 클러스터의 Istio 인그레스 게이트웨이 IP 주소를 가져옵니다.

   kubectl --context control get -n istio-system service istio-ingressgateway -o json | jq -r '.status.loadBalancer.ingress[0].ip'
   

   출력에 Istio 인그레스 게이트웨이 IP 주소가 표시됩니다.

2. Istio 인그레스 게이트웨이 IP 주소를 복사하여 웹브라우저 탭에 붙여넣은 후 페이지를 새로고침합니다. Online Boutique 홈페이지가 표시됩니다.

   

   앱을 둘러보고, 다양한 제품을 살펴보고, 장바구니에 담고, 결제하는 등 작업을 수행합니다.

   Online Boutique 앱이 두 환경의 두 Kubernetes 클러스터에서 완벽하게 작동하며 실행됩니다.

서비스 메시 모니터링

Kiali를 사용하면 서비스 메시를 시각화할 수 있습니다. Kiali는 서비스 메시 관측 가능성 도구입니다. Kiali를 사용하려면 Prometheus 및 Kiali를 control 클러스터에 설치해야 합니다.

1. Prometheus 및 Kiali 부가기능을 control 클러스터에 배포합니다.

   kubectl --context control apply -f https://raw.githubusercontent.com/istio/istio/release-1.8/samples/addons/prometheus.yaml
   kubectl --context control apply -f https://raw.githubusercontent.com/istio/istio/release-1.8/samples/addons/kiali.yaml
   

   Kiali 설치가 오류가 나면서 실패하면 동일한 명령어를 다시 실행해 봅니다. 명령어를 다시 실행하면 해결되는 시간 문제가 있을 수 있습니다.

2. Prometheus 및 Kiali pod가 실행 중인지 확인합니다.

   kubectl --context control get pods -n istio-system
   

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

   kiali-cb9fb9554-x2r5z                    1/1     Running   0          7m46s
   prometheus-6d87d85c88-zv8cr              2/2     Running   0          3m57s
   

3. Cloud Shell에서 Kiali를 control 클러스터에 노출합니다.

   kubectl --context control port-forward svc/kiali 8080:20001 -n istio-system --context control >> /dev/null &
   

4. control 클러스터에서 Kiali 웹 인터페이스를 엽니다. 웹 미리보기를 선택한 다음 포트 8080에서 미리보기를 선택합니다.

5. Kiali 로그인 프롬프트에서 사용자 이름 admin과 비밀번호 admin으로 로그인합니다.

6. 메뉴에서 그래프를 선택합니다.

7. 네임스페이스 선택 드롭다운 목록에서 online-boutique를 선택합니다.

8. 그래프 아래의 메뉴에서 서비스 그래프를 선택합니다.

9. 원하는 경우 표시 메뉴에서 트래픽 애니메이션을 선택하여 앱에 트래픽을 생성하는 loadgenerator를 확인합니다.

   

앞의 이미지는 두 클러스터에 분산된 마이크로서비스의 공유 Istio 서비스 메시를 보여줍니다. 클러스터에 관계없이 새 마이크로서비스가 추가되면 자동으로 검색되고 메시에 추가됩니다. 평면적 네트워크 연결에서는 여러 클러스터를 유연하게 관리하면서 공유 제어 영역을 통해 모든 마이크로서비스를 쉽게 제어할 수 있습니다.

삭제

이 가이드를 마쳤으면 나중에 요금이 청구되지 않도록 Google Cloud에서 만든 리소스를 삭제합니다. 다음 섹션에서는 이러한 리소스를 삭제하는 방법을 설명합니다.

프로젝트 삭제

주의: 프로젝트를 삭제하면 다음과 같은 효과가 발생합니다.
• 프로젝트의 모든 항목이 삭제됩니다. 이 가이드의 기존 프로젝트를 사용한 경우 프로젝트를 삭제하면 프로젝트에서 수행한 다른 작업도 삭제됩니다.
• 커스텀 프로젝트 ID가 손실됩니다. 이 프로젝트를 만들 때 앞으로 사용할 커스텀 프로젝트 ID를 만들었을 수 있습니다. appspot.com URL과 같이 프로젝트 ID를 사용하는 URL을 보존하려면 전체 프로젝트를 삭제하는 대신 프로젝트 내에서 선택한 리소스만 삭제합니다.
1. Cloud Console에서 리소스 관리 페이지로 이동합니다.

   리소스 관리로 이동

2. 프로젝트 목록에서 삭제할 프로젝트를 선택하고 삭제를 클릭합니다.
3. 대화상자에서 프로젝트 ID를 입력한 후 종료를 클릭하여 프로젝트를 삭제합니다.

kubeconfig 재설정

• KUBECONFIG 변수 설정을 취소합니다.

  unset KUBECONFIG
  rm ${WORKDIR}/istiokubecfg
  

다음 단계

• Google Cloud의 Istio 자세히 알아보기
• 복제된 제어 영역 아키텍처를 사용하여 GKE에서 멀티 클러스터 서비스 메시 빌드 알아보기
• 서비스 메시 시대: 하이브리드 클라우드의 미래에서 Istio의 역할 블로그 읽어보기
• 다른 Google Cloud 기능을 직접 사용해보세요. 가이드 살펴보기.