이 가이드에서는 Istio 멀티 클러스터 서비스 메시를 사용하여 여러 Kubernetes 클러스터에 애플리케이션을 배포하는 방법을 설명합니다. Istio 멀티 클러스터 서비스 메시를 사용하면 여러 Kubernetes 클러스터에서 실행되는 서비스가 서로 안전하게 통신할 수 있습니다. Kubernetes 클러스터는 Google Cloud에서 실행되는 Google Kubernetes Engine(GKE) 클러스터나 온프레미스 데이터 센터에서 실행되는 Kubernetes 클러스터와 같은 다양한 Cloud Platform 어디서나 실행될 수 있습니다.
이 가이드는 다양한 네트워크의 여러 GKE 클러스터에서 서비스 메시를 만들고자 하는 운영자를 대상으로 합니다. 배포, 서비스, 인그레스 등 Kubernetes에 대한 기본 지식이 필요합니다. Istio에 대한 기본 지식이 있으면 좋지만 필수 요건은 아닙니다.
Istio는 Kubernetes 클러스터에서 실행되는 서비스를 검색하고, 동적으로 경로를 지정하고, 안전하게 연결할 수 있는 서비스 메시를 오픈소스로 구현한 것입니다. Istio는 또한 애플리케이션 코드를 거의 또는 전혀 변경하지 않고도 라우팅, 부하 분산, 제한, 원격 분석, 회로 차단, 인증, 승인 서비스 호출에 사용되는 정책 기반 프레임워크를 메시에서 제공합니다. Istio는 Kubernetes 클러스터에 설치되면 Kubernetes 서비스 레지스트리를 사용하여 여러 GKE 클러스터에서 실행되는 상호 연결된 서비스(또는 마이크로서비스)의 서비스 메시를 자동으로 검색하고 만듭니다. Istio는 각 Pod에서 실행되는 Envoy 사이드카 프록시를 사용하여 Pod 간 트래픽 라우팅 및 보안을 관리하고 클러스터에서 실행되는 모든 마이크로서비스와 워크로드를 감시합니다.
Kubernetes 클러스터 하나에서 실행 중인 마이크로서비스가 다른 Kubernetes 클러스터에서 실행 중인 마이크로서비스와 통신해야 할 수 있습니다. 예를 들어 마이크로서비스가 여러 리전에 걸쳐 통신해야 하고 환경 또는 마이크로서비스 소유자가 유지보수하는 자체 Kubernetes 클러스터가 있을 수 있습니다. Istio를 사용하면 단일 Kubernetes 클러스터를 벗어나는 서비스 메시를 만들어 원격 클러스터에서 실행되는 마이크로서비스 및 Kubernetes 외부의 VM에서 실행되는 외부 마이크로서비스까지 포함할 수 있습니다.
Istio는 멀티 클러스터 배포용으로 다음 두 가지 기본 구성을 제공합니다.
- 기본-원격 제어 영역을 포함하는 멀티 클러스터 서비스 메시
- 다중 기본 제어 영역을 포함하는 멀티 클러스터 서비스 메시
다중 기본 제어 영역 구성에서 각 클러스터에는 자체 Istio 제어 영역 설치가 있고 각 제어 영역에서 자체 로컬 서비스 메시를 관리합니다. 여러 GKE 클러스터 간에 Istio 게이트웨이, 공통 루트 인증 기관(CA), 자동 서비스 검색을 사용하여 각 클러스터에서 참여하는 마이크로서비스로 구성된 단일 논리적 서비스 메시를 구성합니다. 이렇게 하면 각 클러스터가 Istio 횡방향 게이트웨이를 통과하는 모든 클러스터 인바운드 액세스로 자체 멀티 클러스터 서비스 메시를 관리합니다. 이 방식에서는 모든 클러스터에서 Istio 횡방향 게이트웨이에 연결할 수 있는 한 특별한 네트워킹 요구사항이 없습니다.
이 가이드에서는 다중 기본 제어 영역 아키텍처를 사용하여 Istio를 GKE 클러스터 두 개에 배포합니다. 이를 위해 GKE 클러스터 두 개로 분할된 Online Boutique라는 데모 마이크로서비스 앱을 사용합니다. 각 마이크로서비스의 언어를 확인하려면 README 페이지를 참조하세요.
Cloud 프로젝트 내에서 다음 아키텍처를 빌드합니다.
이 아키텍처는 2개의 개별 네트워크(또는 VPC)에 있는 west 클러스터 및 central 클러스터로 구성되며, 각 클러스터에는 Istio 횡방향 게이트웨이가 있습니다. 클러스터는 로컬로(동일한 클러스터에 있는 경우) 그리고 비로컬로(다른 클러스터에 있는 경우) 다양한 마이크로서비스와 통신합니다.
목표
- GKE 클러스터 두 개(
west와central)를 서로 다른 리전 두 개와 서로 다른 VPC 두 개에 만듭니다. - 두 GKE 클러스터 모두에 다중 기본 모드로 Istio를 설치합니다.
- 두 클러스터에 분할된 Online Boutique 앱을 설치합니다.
- 두 클러스터에서 서비스 메시를 검사합니다.
비용
이 문서에서는 비용이 청구될 수 있는 다음과 같은 Google Cloud 구성요소를 사용합니다.
프로젝트 사용량을 기준으로 예상 비용을 산출하려면 가격 계산기를 사용하세요.
이 문서에 설명된 태스크를 완료했으면 만든 리소스를 삭제하여 청구가 계속되는 것을 방지할 수 있습니다. 자세한 내용은 삭제를 참조하세요.
시작하기 전에
- Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the GKE and Cloud Source Repositories APIs.
-
In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
-
Make sure that billing is enabled for your Google Cloud project.
-
Enable the GKE and Cloud Source Repositories APIs.
환경 설정
이 가이드의 모든 터미널 명령어는 Cloud Shell에서 실행됩니다.
Google Cloud Console에서 Cloud Shell을 엽니다.
다음 GitHub 저장소를 클론하여 이 가이드에 필요한 파일을 다운로드합니다.
cd $HOME git clone https://github.com/GoogleCloudPlatform/istio-multicluster-gke.git저장소 폴더를 이 가이드와 관련된 모든 태스크를 수행하는
$WORKDIR폴더로 만듭니다.cd $HOME/istio-multicluster-gke WORKDIR=$(pwd)가이드를 마친 후에 이 폴더를 삭제할 수 있습니다.
kubectx/kubens를 설치합니다.git clone https://github.com/ahmetb/kubectx $WORKDIR/kubectx export PATH=$PATH:$WORKDIR/kubectx이러한 도구를 사용하면 컨텍스트 또는 네임스페이스를 전환하여 여러 Kubernetes 클러스터 작업을 더 쉽게 수행할 수 있습니다.
VPC 및 GKE 클러스터 만들기
이 섹션에서는 각 VPC에 하나씩 VPC 두 개와 GKE 클러스터 두 개를 만듭니다. 다중 네트워크에서 Istio 다중 기본 구현에 추가 네트워킹 요구사항이 필요하지 않음을 보여주기 위해 개별 VPC 2개가 필요합니다. 클러스터 사이의 서비스 간 트래픽은 인터넷을 통해 안전하게 전달됩니다. 공용 인터넷을 통해 클러스터 간에 트래픽을 라우팅하면 다음과 같은 이점이 있습니다.
- 클러스터 간에 IP 주소의 중첩을 지원합니다. 클러스터 간에 노드, Pod, 서비스 IP 주소가 중첩될 수 있습니다.
- 클러스터 간에 추가 연결이 필요하지 않으며 클러스터 네트워크 간에 피어링, 상호 연결 또는 VPN이 필요하지 않습니다.
- 클러스터가 여러 환경에 있을 수 있습니다. 즉, 운영자가 네트워킹이나 IP 주소를 제어할 수 없지만 Kubernetes 클러스터에서 실행되는 마이크로서비스에 안전하게 연결해야 하는 Google Cloud 및 온프레미스 데이터 센터에 클러스터가 있을 수 있습니다.
클러스터 간에도 상호 TLS(mTLS) 연결을 사용하면 클러스터 사이의 서비스 간 통신을 보호할 수 있습니다. 이 연결에서 Citadel에서 발급된 유효한 인증서를 확인하면 중간자 공격을 차단하는 데 도움이 됩니다.
비공개 IP 주소를 사용하여 클러스터 간에 통신할 수 있습니다. 하지만 이 방식에서는 추가적인 네트워킹 설계에 대한 고려가 필요합니다. 예를 들어 멀티 클러스터 메시에 참여하는 모든 클러스터 간에 겹치지 않는 IP 주소를 포함할 수 있습니다. 또한 모든 Pod가 비공개(RFC 1918) 주소 공간을 통해 통신할 수 있습니다. 이는 Google Cloud 전역 VPC 내에서 또는 Google Cloud 이외의 네트워크에 연결할 경우 Interconnect 또는 VPN 내에서 올바른 방화벽 규칙이 적용됨을 의미합니다. 이 가이드에서는 공용 인터넷을 통한 서비스 간 보안 통신에 중점을 둔 아키텍처를 구성하여 네트워킹 유연성을 강화합니다.
Cloud Shell에서 VPC를 만듭니다.
gcloud compute networks create vpc-west --subnet-mode=auto gcloud compute networks create vpc-central --subnet-mode=auto이 가이드의 새
kubeconfig파일을 사용하도록KUBECONFIG변수를 설정합니다.export KUBECONFIG=${WORKDIR}/istio-kubeconfigvpc-west네트워크의us-west2-a영역에서west라는 이름과vpc-central네트워크의us-central1-a영역에서central이라는 이름의 GKE 클러스터 두 개를 만듭니다.gcloud container clusters create west --zone us-west2-a \ --machine-type "e2-standard-2" --disk-size "100" \ --scopes "https://www.googleapis.com/auth/compute",\ "https://www.googleapis.com/auth/devstorage.read_only",\ "https://www.googleapis.com/auth/logging.write",\ "https://www.googleapis.com/auth/monitoring",\ "https://www.googleapis.com/auth/servicecontrol",\ "https://www.googleapis.com/auth/service.management.readonly",\ "https://www.googleapis.com/auth/trace.append" \ --num-nodes "4" --network "vpc-west" --async gcloud container clusters create central --zone us-central1-a \ --machine-type "e2-standard-2" --disk-size "100" \ --scopes "https://www.googleapis.com/auth/compute",\ "https://www.googleapis.com/auth/devstorage.read_only",\ "https://www.googleapis.com/auth/logging.write",\ "https://www.googleapis.com/auth/monitoring",\ "https://www.googleapis.com/auth/servicecontrol",\ "https://www.googleapis.com/auth/service.management.readonly",\ "https://www.googleapis.com/auth/trace.append" \ --num-nodes "4" --network "vpc-central"두 클러스터가 모두 생성될 때까지 몇 분 정도 기다립니다. 각 클러스터의 상태가
RUNNING인지 확인합니다.gcloud container clusters list출력은 다음과 비슷합니다.
NAME LOCATION MASTER_VERSION MASTER_IP MACHINE_TYPE NODE_VERSION NUM_NODES STATUS central us-central1-a 1.17.14-gke.1600 104.197.127.140 e2-standard-2 1.17.14-gke.1600 4 RUNNING west us-west2-a 1.17.14-gke.1600 34.94.217.4 e2-standard-2 1.17.14-gke.1600 4 RUNNING
두 클러스터 모두에 연결하여
kubeconfig파일에 항목을 생성합니다.export PROJECT_ID=$(gcloud info --format='value(config.project)') gcloud container clusters get-credentials west --zone us-west2-a --project ${PROJECT_ID} gcloud container clusters get-credentials central --zone us-central1-a --project ${PROJECT_ID}kubeconfig파일에서 각 클러스터의 사용자와 컨텍스트를 만들어 클러스터에 대한 인증을 만듭니다.kubeconfig파일을 만든 후에는 클러스터 간에 컨텍스트를 빠르게 전환할 수 있습니다.편의상
kubectx를 사용하여 컨텍스트 이름을 바꿉니다.kubectx west=gke_${PROJECT_ID}_us-west2-a_west kubectx central=gke_${PROJECT_ID}_us-central1-a_central두 클러스터 모두에서
cluster-admin역할을 자신(Google 사용자)에게 부여합니다.kubectl create clusterrolebinding user-admin-binding \ --clusterrole=cluster-admin --user=$(gcloud config get-value account) \ --context west kubectl create clusterrolebinding user-admin-binding \ --clusterrole=cluster-admin --user=$(gcloud config get-value account) \ --context central이 역할을 통해 이들 클러스터에서 관리 태스크를 수행할 수 있습니다.
두 클러스터 모두에 인증서 구성
Istio에서 Citadel은 Istio의 인증 기관(CA)이며 서비스 메시의 모든 Envoy 프록시(워크로드 사이드카 프록시, 인그레스, 횡방향, 이그레스 게이트웨이 프록시)에 대한 인증서를 서명하고 배포합니다. 기본적으로 Citadel은 자체 서명 루트 인증서와 키를 생성하고 이를 사용하여 워크로드 인증서에 서명합니다. Citadel은 또한 운영자 지정 인증서와 키를 사용하여 워크로드 인증서에 서명할 수도 있습니다. 이 가이드에서 west 클러스터와 central 클러스터는 각각의 워크로드에 서명하는 개별 Citadel 서비스와 함께 개별 서비스 메시를 유지합니다.
클러스터에서 마이크로서비스 간에 트러스트를 설정하려면 두 Citadel 서명(CA) 인증서 모두 공통 루트 인증 기관(루트 CA)에서 서명되어야 합니다. 또한 Citadel 서명 인증서와 루트 CA 사이에 있는 모든 중간 CA의 트러스트 체인을 확인하려면 워크로드에 인증서 체인 파일이 필요합니다. 이 구성은 Kubernetes 클러스터에서 보안 비밀을 사용하여 수행됩니다. 인증서 파일은 이 가이드의 일부로 제공됩니다. 프로덕션 환경에서는 PKI 시스템 또는 보안팀에서 생성한 인증서를 사용할 수 있습니다(예: 자체 CA 역할을 할 수 있음). 생성된 보안 비밀은 Citadel에서 사용되며 다음 속성을 갖습니다.
- 보안 비밀 이름은
cacert여야 합니다. - 보안 비밀은 인증서 파일 4개(이 가이드에서는 Istio 코드로 제공됨)에서 생성되며, 이들 파일 이름은 다음과 같아야 합니다.
root-cert.pem에는 루트 CA가 포함됩니다. 이 파일은west클러스터와central클러스터의 Citadel 서비스 모두에 동일합니다. 두 Citadel 인증서는 이 루트 CA에서 서명됩니다.ca-cert.pem및ca-key.pem은 Citadel 서비스의 서명 (CA) 인증서 및 개인 키입니다. 두 Citadel 인증서 모두 루트 CA(root-cert.pem)에서 서명되어 합니다.ca-cert.pem은 각 클러스터 내 워크로드를 서명하는 데 사용됩니다.cert-chain.pem은 워크로드 인증서와 루트 CA 간의 트러스트 체인입니다. 이 예시에서cert-chain.pem에는ca-cert.pem인증서만 포함되어 있으므로 이들 파일은 동일합니다. 이 파일은 여러 클러스터에서 실행 중인 마이크로서비스 간에 트러스트를 설정합니다.
기본 Citadel 설치는 명령줄 옵션을 설정하여 명령어에 사용된 사전 정의된 보안 비밀과 파일 이름(즉, cacert라는 보안 비밀, root-cert.pem 파일의 루트 인증서, ca-key.pem의 Citadel 키 등)을 기준으로 인증서와 키의 위치를 구성합니다.
Cloud Shell에서 Istio를 다운로드합니다.
cd ${WORKDIR} export ISTIO_VERSION=1.9.0 curl -L https://istio.io/downloadIstio | ISTIO_VERSION=${ISTIO_VERSION} TARGET_ARCH=x86_64 sh - cd istio-${ISTIO_VERSION} export PATH=$PWD/bin:$PATHCloud Shell에서 적절한 인증서 파일을 사용하여 보안 비밀을 만듭니다.
for cluster in $(kubectx) do kubectl --context $cluster create namespace istio-system kubectl --context $cluster create secret generic cacerts -n istio-system \ --from-file=${WORKDIR}/istio-${ISTIO_VERSION}/samples/certs/ca-cert.pem \ --from-file=${WORKDIR}/istio-${ISTIO_VERSION}/samples/certs/ca-key.pem \ --from-file=${WORKDIR}/istio-${ISTIO_VERSION}/samples/certs/root-cert.pem \ --from-file=${WORKDIR}/istio-${ISTIO_VERSION}/samples/certs/cert-chain.pem; done
Istio 설치
이 섹션에서는 west 및 central 클러스터에 Istio를 설치합니다.
Cloud Shell에서
west클러스터에 대해 기본 네트워크를 설정합니다.kubectl --context=west label namespace istio-system topology.istio.io/network=network1전용 횡방향 게이트웨이가 있는
west클러스터에 대해 Istio 구성을 만듭니다.cd ${WORKDIR} cat <<EOF > istio-west.yaml apiVersion: install.istio.io/v1alpha1 kind: IstioOperator spec: values: global: meshID: mesh1 multiCluster: clusterName: west 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 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 EOFwest클러스터에 구성 적용:istioctl install --context=west -f istio-west.yaml계속하려면
y를 누르세요.istio-system네임스페이스에서 배포를 검사합니다.kubectl --context=west -n istio-system get deployments출력은 다음과 같이 표시됩니다.
NAME READY UP-TO-DATE AVAILABLE AGE istio-eastwestgateway 1/1 1 1 2m11s istio-ingressgateway 1/1 1 1 8m43s istiod 1/1 1 1 8m56s
횡방향 게이트웨이에 외부 IP 주소가 할당될 때까지 기다립니다.
kubectl --context=west get svc istio-eastwestgateway -n istio-system출력은 다음과 같이 표시됩니다.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-eastwestgateway LoadBalancer 10.3.241.43 34.94.214.249 15021:30369/TCP,15443:30988/TCP,15012:31358/TCP,15017:32625/TCP 3m42s
클러스터가 별도의 네트워크에 있으므로 두 클러스터의 east-west 게이트웨이에 모든 서비스(*.local)를 노출해야 합니다. 횡방향 게이트웨이는 인터넷에서는 공개 상태지만, 마치 동일한 네트워크에 있는 것처럼 신뢰할 수 있는 mTLS 인증서와 워크로드 ID를 사용하는 서비스만 이러한 서비스에 액세스할 수 있습니다.
kubectl --context=west apply -n istio-system -f \ ${WORKDIR}/istio-${ISTIO_VERSION}/samples/multicluster/expose-services.yamlcentral클러스터의 기본 네트워크를 설정합니다.kubectl --context=central label namespace istio-system topology.istio.io/network=network2전용 횡방향 게이트웨이가 있는
central클러스터에 대해 Istio 구성을 만듭니다.cd ${WORKDIR} cat <<EOF > istio-central.yaml apiVersion: install.istio.io/v1alpha1 kind: IstioOperator spec: values: global: meshID: mesh1 multiCluster: clusterName: central network: network2 components: ingressGateways: - name: istio-eastwestgateway label: istio: eastwestgateway app: istio-eastwestgateway topology.istio.io/network: network2 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: network2 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 EOFcentral클러스터에 구성 적용:istioctl install --context=central -f istio-central.yaml계속하려면
y를 누르세요.istio-system네임스페이스에서 배포를 검사합니다.kubectl --context=central -n istio-system get deployments출력은 다음과 같이 표시됩니다.
NAME READY UP-TO-DATE AVAILABLE AGE istio-eastwestgateway 1/1 1 1 2m11s istio-ingressgateway 1/1 1 1 8m43s istiod 1/1 1 1 8m56s
횡방향 게이트웨이에 외부 IP 주소가 할당될 때까지 기다립니다.
kubectl --context=central get svc istio-eastwestgateway -n istio-system출력은 다음과 같이 표시됩니다.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-eastwestgateway LoadBalancer 10.3.250.201 35.232.125.62 15021:30810/TCP,15443:31125/TCP,15012:30519/TCP,15017:30743/TCP 37s
중앙 클러스터의 횡방향 게이트웨이에서 모든 서비스(*.local)를 노출합니다.
kubectl --context=central apply -n istio-system -f \ ${WORKDIR}/istio-${ISTIO_VERSION}/samples/multicluster/expose-services.yaml
엔드포인트 검색 사용 설정
central클러스터의 API 서버에 대한 액세스를 제공하는 원격 보안 비밀을west클러스터에 설치합니다.istioctl x create-remote-secret \ --context=central \ --name=central | \ kubectl apply -f - --context=westwest클러스터의 API 서버에 대한 액세스를 제공하는 원격 보안 비밀을central클러스터에 설치합니다.istioctl x create-remote-secret \ --context=west \ --name=west | \ kubectl apply -f - --context=central
Online Boutique 앱 배포
이 섹션에서는 Online Boutique 앱을 두 클러스터 모두에 설치합니다. Online Boutique는 여러 프로그래밍 언어로 작성된 10개의 마이크로서비스로 구성됩니다. 다음 아키텍처에 표시된 대로 이러한 마이크로서비스를 central 클러스터와 west 클러스터에 분할합니다.
두 클러스터에서 Online Boutique 앱의 네임스페이스를 만듭니다.
kubectl --context central create namespace online-boutique kubectl --context west create namespace online-boutique자동 Istio 사이드카 프록시 주입의 네임스페이스에 라벨을 지정합니다.
kubectl --context central label namespace online-boutique istio-injection=enabled kubectl --context west label namespace online-boutique istio-injection=enabledwest및central클러스터에 Online Boutique 앱을 배포합니다.kubectl --context central -n online-boutique apply -f $WORKDIR/istio-multi-primary/central kubectl --context west -n online-boutique apply -f $WORKDIR/istio-multi-primary/westOnline Boutique 앱에서 모든 배포를 작동하고 실행하려면 몇 분 정도 걸립니다.
두 클러스터 모두에서 모든 배포를 사용할 수 있을 때까지 기다립니다.
# In central cluster kubectl --context=central -n online-boutique wait --for=condition=available deployment emailservice --timeout=5m kubectl --context=central -n online-boutique wait --for=condition=available deployment checkoutservice --timeout=5m kubectl --context=central -n online-boutique wait --for=condition=available deployment shippingservice --timeout=5m kubectl --context=central -n online-boutique wait --for=condition=available deployment paymentservice --timeout=5m kubectl --context=central -n online-boutique wait --for=condition=available deployment adservice --timeout=5m kubectl --context=central -n online-boutique wait --for=condition=available deployment currencyservice --timeout=5m # In west cluster kubectl --context=west -n online-boutique wait --for=condition=available deployment frontend --timeout=5m kubectl --context=west -n online-boutique wait --for=condition=available deployment recommendationservice --timeout=5m kubectl --context=west -n online-boutique wait --for=condition=available deployment productcatalogservice --timeout=5m kubectl --context=west -n online-boutique wait --for=condition=available deployment cartservice --timeout=5m kubectl --context=west -n online-boutique wait --for=condition=available deployment redis-cart --timeout=5m kubectl --context=west -n online-boutique wait --for=condition=available deployment loadgenerator --timeout=5m모든 배포의 출력은 다음과 같습니다.
deployment.apps/frontend condition met
Online Boutique 앱 액세스
어느 클러스터에서도 istio-ingressgatway 공개 IP 주소로 Online Boutique 앱에 액세스할 수 있습니다.
두 클러스터 모두에서
istio-ingressgateway서비스의 공개 IP 주소를 가져옵니다.kubectl --context west get -n istio-system service istio-ingressgateway -o json | jq -r '.status.loadBalancer.ingress[0].ip' kubectl --context central get -n istio-system service istio-ingressgateway -o json | jq -r '.status.loadBalancer.ingress[0].ip'출력에는 외부 IP 주소가 표시됩니다.
어느 클러스터에서든 Istio 인그레스 게이트웨이 IP 주소를 복사하여 웹브라우저 탭에 붙여넣은 후 페이지를 새로고침합니다. Online Boutique 홈페이지가 표시됩니다.
앱을 둘러보고, 다양한 제품을 살펴보고, 장바구니에 담고, 결제하는 등 작업을 수행합니다.
Online Boutique가 두 환경의 두 Kubernetes 클러스터에서 완벽하게 작동하며 실행됩니다.
서비스 메시 모니터링
Kiali를 사용하면 서비스 메시를 모니터링하고 시각화할 수 있습니다. Kiali는 Istio 설치의 일부로 설치되는 서비스 메시 관측 가능성 도구입니다.
Prometheus 및 Kiali를
west클러스터에 배포합니다.kubectl --context west apply -f https://raw.githubusercontent.com/istio/istio/release-${ISTIO_VERSION:0:3}/samples/addons/prometheus.yaml kubectl --context west apply -f https://raw.githubusercontent.com/istio/istio/release-${ISTIO_VERSION:0:3}/samples/addons/kiali.yamlKiali 설치가 오류가 나면서 실패하면 동일한 명령어를 다시 실행해 봅니다. 명령어를 다시 실행하면 해결되는 시간 문제가 있을 수 있습니다.
Prometheus 및 Kiali pod가 실행 중인지 확인합니다.
kubectl --context west get pods -n istio-system출력은 다음과 같이 표시됩니다.
kiali-6d5c4bbb64-wpsqx 1/1 Running 0 72s prometheus-6d87d85c88-h2cwl 2/2 Running 0 92s
Cloud Shell에서 Kiali를
west클러스터에 노출합니다.kubectl --context west port-forward svc/kiali 8080:20001 -n istio-system >> /dev/null &west클러스터에서 Kiali 웹 인터페이스를 엽니다. Cloud Shell에서 웹 미리보기를 선택한 후 포트 8080에서 미리보기를 선택합니다.왼쪽 메뉴에서 그래프를 선택합니다.
네임스페이스 선택 드롭다운 목록에서 online-boutique를 선택합니다.
그래프 아래의 메뉴에서 서비스 그래프를 선택합니다.
원하는 경우 표시 메뉴에서 트래픽 애니메이션을 선택하여 앱에 트래픽을 생성하는
loadgenerator를 확인합니다.
여러 클러스터에 분할된 애플리케이션이 성공적으로 설치되었습니다. 마이크로서비스는 Istio 횡방향 게이트웨이를 사용하여 클러스터 간에 mTLS와 안전하게 통신합니다. 각 클러스터가 자체 Istio 제어 영역을 유지관리 및 제어하므로 단일 장애점이 방지됩니다.
정리
이 가이드를 마쳤으면 나중에 요금이 청구되지 않도록 Google Cloud에서 만든 리소스를 삭제합니다. 다음 섹션에서는 이러한 리소스를 삭제하는 방법을 설명합니다.
프로젝트 삭제
- In the Google Cloud console, go to the Manage resources page.
- In the project list, select the project that you want to delete, and then click Delete.
- In the dialog, type the project ID, and then click Shut down to delete the project.
kubeconfig 재설정
kubeconfig파일을 재설정합니다.unset KUBECONFIG rm istio-kubeconfig
다음 단계
- Google Cloud의 Istio 자세히 알아보기
- 서비스 메시 시대: 하이브리드 클라우드의 미래에 Istio가 미치는 영향에서 서비스 메시의 역할과 하이브리드 클라우드 알아보기
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항 살펴보기. Cloud 아키텍처 센터 살펴보기