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

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

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

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 프로젝트 내에서 다음 아키텍처를 빌드합니다.

두 클러스터에 10개의 마이크로서비스를 배포하는 아키텍처.

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

목표

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

비용

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

프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요. 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 앱 액세스

  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 홈페이지

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

    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를 확인합니다.

    앱에 트래픽을 생성하는 `loadgenerator`를 보여주는 트래픽 애니메이션.

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

삭제

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

프로젝트 삭제

  1. Cloud Console에서 리소스 관리 페이지로 이동합니다.

    리소스 관리로 이동

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

kubeconfig 재설정

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

    unset KUBECONFIG
    rm ${WORKDIR}/istiokubecfg
    

다음 단계