マルチプライマリコントロールプレーンマルチネットワークアーキテクチャを使用した GKE でのマルチクラスタサービスメッシュの構築

Last reviewed 2019-10-29 UTC

このチュートリアルでは、Istio マルチクラスタサービスメッシュを使用して、複数の Kubernetes クラスタにアプリケーションをデプロイする方法について説明します。Istio マルチクラスタサービスメッシュを使用すると、複数の Kubernetes クラスタ上で実行されているサービス間で安全に通信を行うことができます。Kubernetes クラスタはさまざまな場所で実行されています。Google Cloud で実行される Google Kubernetes Engine（GKE）クラスタや、オンプレミスのデータセンターで実行される Kubernetes クラスタなど、異なるクラウドプラットフォームで実行されている場合もあります。

このチュートリアルでは、複数のネットワークにまたがる複数の GKE クラスタにサービスメッシュを作成する方法を説明します。このチュートリアルでは、Deployment、Service、Ingress など、Kubernetes の基本的な知識が必要になります。Istio の基礎知識は必要ありませんが、あったほうが内容を理解しやすくなります。

Istio は、Kubernetes クラスタで実行される Service の検出、動的ルーティング、安全な接続を行うためのオープンソースのサービスメッシュです。Istio は、メッシュ内でルーティング、ロードバランシング、スロットリング、テレメトリ、サーキットブレーク、認証、サービス呼び出しの認可を行うためのポリシーベースのフレームワークを提供します。これにより、アプリケーションのコードをほとんど変更せずに、これらの機能を実現できます。Istio を Kubernetes クラスタにインストールすると、Istio は Kubernetes の Service レジストリを使用して、複数の GKE クラスタで実行される相互接続サービス（またはマイクロサービス）を自動的に検出し、サービスメッシュを作成します。Istio では、各 Pod で実行される Envoy サイドカープロキシを使用して、Pod 間のトラフィックのルーティングとセキュリティを管理し、クラスタ内で実行されるすべてのマイクロサービスとワークロードのオブザーバビリティを提供します。

1 つの Kubernetes クラスタで実行されるマイクロサービスで、他の Kubernetes クラスタで実行されるマイクロサービスとの通信が必要になる場合があります。たとえば、複数のマイクロサービスがリージョンを超えて通信を行う場合もあれば、環境やマイクロサービスのオーナーが独自の Kubernetes クラスタを維持する場合もあります。Istio を使用すると、1 つの Kubernetes クラスタを超えるサービスメッシュを作成し、リモートクラスタで実行されているマイクロサービスや、Kubernetes の外部にある VM で実行されている外部マイクロサービスを管理することが可能になります。

Istio は、マルチクラスタ環境に 2 つの主な構成を提供します。

プライマリリモートコントロールプレーンを使用したマルチクラスタサービスメッシュ
マルチプライマリコントロールプレーンを使用したマルチクラスタサービスメッシュ

マルチプライマリコントロールプレーン構成では、各クラスタに独自の Istio コントロールプレーンがインストールされ、各コントロールプレーンが独自のローカルサービスメッシュを管理します。Istio ゲートウェイ、共通のルート認証局（CA）、複数の GKE クラスタでの自動サービスディスカバリを使用して、各クラスタのマイクロサービスを含む単一の論理サービスメッシュを構成します。これにより、すべてのクラスタが独自のマルチクラスタサービスメッシュを管理し、クラスタのすべての受信アクセスが Istio East-West ゲートウェイを経由するようになります。Istio East-West ゲートウェイがすべてのクラスタから到達可能である限り、このアプローチに特別なネットワーク要件はありません。

このチュートリアルでは、マルチプライマリコントロールプレーンアーキテクチャを使用して Istio を 2 つの GKE クラスタにデプロイします。このチュートリアルでは、2 つの GKE クラスタに分割された Online Boutique というデモマイクロサービスアプリを使用します。マイクロサービスの言語については、README ページをご覧ください。

Cloud プロジェクト内に次のアーキテクチャを構築します。

マルチコントロールプレーンアーキテクチャを使用して Istio が 2 つの GKE クラスタにデプロイされています。

このアーキテクチャでは、1 つの Istio East-West ゲートウェイを使用する 2 つの別々のネットワーク（または VPC）に、1 つの west クラスタと 1 つの central クラスタが存在します。クラスタは、ローカル（同じクラスタ）とローカル以外（他のクラスタ）のマイクロサービスと通信を行います。

目標

リージョンと VPC が異なる 2 つの GKE クラスタ（west と central）を作成します。
マルチプライマリモードで両方の GKE クラスタに Istio をインストールします。
Online Boutique アプリを両方のクラスタに分割してインストールします。
両方のクラスタでサービスメッシュを検査します。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい 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.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the GKE and Cloud Source Repositories APIs.

Enable the APIs

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Go to project selector

Make sure that billing is enabled for your Google Cloud project.

Enable the GKE and Cloud Source Repositories APIs.

Enable the APIs

環境設定

このチュートリアルで使用するターミナルコマンドはすべて Cloud Shell から実行します。

Google Cloud Console で Cloud Shell を開きます。

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 クラスタを作成する

このセクションでは、2 つの VPC を作成し、それぞれの VPC に GKE クラスタを 1 つずつ作成します。複数のネットワーク上の Istio マルチプライマリ実装に追加のネットワーク要件が不要であることを示すためには、2 つの異なる VPC が必要です。他のクラスタとの Service 間トラフィックは、インターネットを介して安全に送信されます。公共のインターネットでクラスタ間のトラフィックを転送する場合、次のような利点があります。

クラスタ間で重複する IP アドレスを使用できます。Node、Pod、Service の IP アドレスがクラスタ間で重複していても問題ありません。
クラスタ間の追加接続は必要ありません。クラスタネットワーク間のピアリング、相互接続、VPN は不要です。
複数の環境にクラスタを配置できます。たとえば、クラスタを Google Cloud とオンプレミスのデータセンターに配置できます。この状況では、オペレーターがネットワークまたは IP アドレスを制御できない場合でも、Kubernetes クラスタで実行されるマイクロサービスに安全に接続する必要があります。

クラスタ間でも相互 TLS（mTLS）接続を使用すると、別のクラスタと Service 間通信を安全に行うことができます。Citadel から発行された有効な証明書を検証することで、これらの接続に対する中間者攻撃を回避できます。

プライベート IP アドレスを使用して、クラスタ間の通信を行うことができます。ただし、この方法ではネットワーキングの設計をさらに検討する必要があります。たとえば、マルチクラスタメッシュに参加するすべてのクラスタ間で重複しない IP アドレスを割り当てる必要があります。また、すべての Pod がプライベートな（RFC 1918）アドレス空間で通信を行えるようにする必要があります。つまり、Google Cloud のグローバル VPC に適切なファイアウォールルールを設定する必要があります。Google Cloud 以外のネットワークに接続する場合には、相互接続または 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-kubeconfig
```

2 つの GKE クラスタを作成します。1 つは、west という名前で vpc-west ネットワークの us-west2-a ゾーンに作成します。もう 1 つは central という名前で、vpc-central ネットワークの us-central1-a ゾーンに作成します。

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 プロキシ（Workload Sidecar プロキシ、East-West および Egress ゲートウェイプロキシ）に証明書を配布します。デフォルトでは、Citadel は自己署名のルート証明書と鍵を生成し、この証明書と鍵でワークロードの証明書に署名します。Citadel では、オペレーターが指定した証明書と鍵を使用してワークロードの証明書に署名することもできます。このチュートリアルでは、west クラスタと central クラスタで別々のサービスメッシュを維持し、それぞれの Citadel サービスでワークロードの署名を行います。

クラスタのマイクロサービス間で信頼関係を確立するには、両方の Citadel 署名（CA）証明書が共通のルート認証局（ルート CA）によって署名されている必要があります。Citadel 署名証明書とルート CA 間にあるすべての中間 CA の信頼チェーンを検証するため、ワークロードには証明書チェーンファイルも必要です。この構成は、Kubernetes クラスタで Secret を使用して行います。これらの証明書ファイルについては、このチュートリアルの中で説明します。本番環境では、PKI システムまたはセキュリティチームが生成した証明書を使用できます（たとえば、独自の CA として機能している場合）。作成された Secret には次の特長があります。この Secret は Citadel によって使用されます。

Secret の名前は cacert です。
Secret は 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 をデフォルトでインストールした場合、コマンドに使用される事前定義の Secret とファイル名に基づいて証明書と鍵の場所を構成するようにコマンドラインオプションが設定されます。つまり、Secret の名前は cacert、ルート証明書のファイル名は root-cert.pem、Citadel キーは ca-key.pem になります。

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:$PATH

Cloud Shell で、適切な証明書ファイルを使用して Secret を作成します。

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

専用の East-West ゲートウェイを使用して、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
EOF

west クラスタに構成を適用します。
```
istioctl install --context=west -f istio-west.yaml
```
y を押して続行します。

istio-system Namespace 内の Deployment を検査します。

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

East-West ゲートウェイに外部 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

クラスタは別々のネットワーク上にあるため、すべてのサービス（*.local）を両方のクラスタの east-west ゲートウェイ上で公開する必要があります。East-West ゲートウェイはインターネットで公開されているため、その背後にあるサービスには、信頼できる mTLS 証明書とワークロード ID を持つサービスのみがアクセスできます。これらは、同じネットワーク上にあるように見えます。
```
kubectl --context=west apply -n istio-system -f \
${WORKDIR}/istio-${ISTIO_VERSION}/samples/multicluster/expose-services.yaml
```

central クラスタにデフォルトネットワークを設定します。

kubectl --context=central label namespace istio-system topology.istio.io/network=network2

専用の East-West ゲートウェイを使用して、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
EOF

central クラスタに構成を適用します。
```
istioctl install --context=central -f istio-central.yaml
```
y を押して続行します。

istio-system Namespace 内の Deployment を検査します。

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

East-West ゲートウェイに外部 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

中央のクラスタの East-West ゲートウェイにすべてのサービス（*.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=west
```
west クラスタの 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 に分割します。

マイクロサービスは central クラスタと west クラスタに分割され、サービスメッシュが重複しています。図のサービス A

両方のクラスタで Online Boutique アプリの Namespace を作成します。

kubectl --context central create namespace online-boutique
kubectl --context west create namespace online-boutique

Istio サイドカープロキシの挿入を自動的に行うため、Namespace にラベルを付けます。

kubectl --context central label namespace online-boutique istio-injection=enabled
kubectl --context west label namespace online-boutique istio-injection=enabled

west クラスタと 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/west
```
Online Boutique アプリですべての Deployment が起動して稼働するまでに数分かかります。

両方のクラスタですべての Deployment が使用可能になるまで待ちます。

# 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 の出力は次のようになります。

deployment.apps/frontend condition met

Online Boutique アプリへのアクセス

Online Boutique には、いずれかのクラスタからの istio-ingressgatway パブリック IP アドレスからアクセスできます。

両方のクラスタから 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 Ingress ゲートウェイ IP アドレスをコピーして、ウェブブラウザのタブに貼り付け、ページを更新します。Online Boutique のホームページが表示されます。

ここでは、アプリの操作、商品の検索、注文と会計などを行うことができます。

Online Boutique には必要な機能がすべて揃っています。このアプリは 2 つの環境の 2 つの 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.yaml
```
Kiali のインストールがエラーで失敗した場合は、同じコマンドをもう一度実行してください。このエラーはタイミングの問題で、コマンドの再実行で解決する場合があります。

Prometheus Pod と 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 で、west クラスタに Kiali を公開します。

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

west クラスタで Kiali ウェブインターフェースを開きます。Cloud Shell で、[ウェブでプレビュー] をクリックし、[ポート 8080 でプレビュー] を選択します。
左側のメニューから [グラフ] を選択します。
[名前空間を選択してください] プルダウンリストから online-boutique を選択します。
[グラフ] メニューから [Service graph] を選択します。
必要に応じて、[表示] メニューから [Traffic Animation] を選択して、loadgenerator がアプリに生成するトラフィックを確認します。

これで、複数のクラスタにまたがるアプリケーションが正常にインストールされました。マイクロサービスは、mTLS とともに Istio East-West ゲートウェイを使用して、クラスタ間で安全に通信を行います。各クラスタで独自の Istio コントロールプレーンを維持し、管理しているため、単一障害点が回避されます。

クリーンアップ

チュートリアルが終了したら、Google Cloud で作成したリソースをクリーンアップして今後料金が発生しないようにします。以降のセクションでは、このようなリソースを削除する方法を説明します。

プロジェクトの削除

注意: プロジェクトを削除すると、次のような影響があります。

プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
カスタムプロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタムプロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
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 Architecture Center を確認します。

マルチプライマリ コントロールプレーン マルチネットワーク アーキテクチャを使用した GKE でのマルチクラスタ サービス メッシュの構築

目標

費用

始める前に

環境設定

VPC と GKE クラスタを作成する

両方のクラスタで証明書を構成する

Istio のインストール

エンドポイント検出の有効化

Online Boutique アプリのデプロイ

Online Boutique アプリへのアクセス

サービス メッシュのモニタリング

クリーンアップ

プロジェクトの削除

kubeconfig のリセット

次のステップ

マルチプライマリコントロールプレーンマルチネットワークアーキテクチャを使用した GKE でのマルチクラスタサービスメッシュの構築

サービスメッシュのモニタリング