Anthos Service Mesh を導入、移行、そして使いこなしてみよう

Kozzy Hasebe

Published in

google-cloud-jp

32 min readDec 19, 2020

この記事は Google Cloud Japan Customer Engineer Advent Calendar 2020 の 19 日目の記事です。

皆さんサービスメッシュは導入していますか？？

最近流行ってきているので、名前を聞くことは増えていると思いますが、使っている方、さらに本番導入している方となるとまだまだ少ないのではないのでしょうか。

本日はサービスメッシュの簡単な概要から、GCP のオファリングである Anthos Service Mesh を中心に重要なポイントに絞ってご説明します。後半ではハンズオンの手順を示していますが、実際に試さずとも流れとポイントを掴んで頂ければ幸いです。

tl;dr

マイクロサービスアーキテクチャを採用する場合、サービスメッシュの利用も検討しよう
GCP のプロダクトである Anthos Service Mesh が単体でご利用頂けるようになりました
Anthos Service Mesh はサービスへの影響を限りなく抑えながら導入が可能です。まずシステムの可視化を目的に導入してみましょう

サービスメッシュとは？

近年、システムアーキテクチャ設計においてマイクロサービスアーキテクチャが第一の選択肢に挙がることが当たり前になってきました。また新規のシステムだけではなく、既存のシステムも Re-architect 、または Re-build しマイクロサービス化するということも増えてきています。マイクロサービスの導入が進むにつれ、その問題点も見えてきました。サービスメッシュはそれらの問題点のうち、特にネットワークレイヤーに関する諸問題を解決するテクノロジーで、下記のような機能を提供します。

マイクロサービス間の連携を柔軟に行えるトラフィック管理機能
認証、認可、そして通信の暗号化などのセキュリティ関連機能
マイクロサービス間の連携を見える化する機能
これらを統一的に一元管理する機能

別のアプローチとしては、すべてのマイクロサービスで前述の機能をもたせた共通ライブラリを利用する、また個別実装するというものもあります。しかし、ライブラリの更新が必要になったというケースを考えると、そちらを運用していく大変さは想像がつくかと思います。

Anthos Service Mesh とは？

Anthos Service Mesh (以降 ASM と記載します) は GCP が提供しているサービスメッシュで、2019 年 9 月に Beta 版がリリースされ、2019 年 12 月に一般提供が開始されました。下記のような特徴があります。

OSS の Istio がベースになっている
コントロールプレーンの各種機能がマネージドで提供されている
エンタープライズの利用に適したサポートがついている

まとめると、多機能 (Istio ベース) で、運用負荷 (マネージドなコントロールプレーン) を抑え、より安心 (手厚いサポート) してお使い頂けるサービスメッシュということになります。

ASM のライセンス

ASM は 2020 年 11 月にライセンスに関して、大きな発表がありました。これまでは ASM を利用するには Anthos のサブスクリプションライセンスもしくは Anthos PAYG (全てのAnthosの機能が利用可能) が必要で、ライセンス費用がかかっていました。

詳しくはリンク先を読んで頂ければと思いますが、簡単に言うと Anthos のライセンス無しでも利用できるオプションが用意され、ASM だけを使った分だけのお支払いで利用できるようになりました。つまり、GKE、GCE などその他の GCP のサービスと同じように使えます。

さらに、ASM の利用料は 2021 年 6 月まで無料となります！
ぜひこれを機に試してみてはいかがでしょうか。

1 つご注意ですが、ASM が Inject するサイドカーコンテナのリソース利用料は別途必要になります。これは ASM の利用料ではなく、GKE (GCE) の費用増分となります。大規模に導入を試す際には注意しましょう。

なにがマネージドなのか？

さきほど ASM は OSS の Istio がベースとなっており、コントロールプレーンの各種機能がマネージドで提供されていると書きました。具体的に何がマネージドになっているのかをアーキテクチャ図で見ていきましょう。

今現在 Istio における下記の機能群がマネージドとなっています。

Citadel
証明書を発行、管理する機能。ASM では MeshCA が担当
運用管理系 (Prometheus、Grafana、Kiali)
ログ、モニタリング、サービスメッシュの可視化を行う機能。ASM では ASM dashboard, Operations が担当

またデータプレーン (図上半分のプロキシ、サービス群) は Istio の構成と同一です。今後、Istio の Pilot が提供しているトラフィック管理の機能もマネージドになる予定です。

ASM の構成を決定するプロファイル

ASM では Istio をインストールするときに利用する設定ファイル (YAML 形式) と同じように、インストール時に設定ファイル (プロファイル) を指定する必要があり、導入するプラットフォーム、システム構成に応じて使うプロファイルが変わります。詳細はこちらに記載されていますが、今は 3 つのプロファイルが提供されています。簡単に対象の環境を示します。

asm-gcp
対象のクラスタは GCP 上で動いており、同じ GCP プロジェクト上に存在する
asm-gcp-multiproject
対象のクラスタは GCP 上で動いているが、複数の GCP プロジェクトに存在する
asm-multicloud
対象のクラスタは GCP、On-premise、AWS など複数の環境で動いている

プロファイルは随時更新されているため、ウォッチしておくことをおすすめします。

以降の手順では、GCP 上、かつ 1 つのプロジェクトで環境を構築する前提 (asm-gcp プロファイル) で進めていきます。

ハンズオン

ASM の導入はバージョンが上がるたびにわかりやすく、そして簡易に行えるようになってきました。新しいクラスタに ASM をインストール、その後アプリケーションを動かすというのはこちらの手順に従えば簡単にできるため、今回は少し手順を変え、大きくは下記の流れでハンズオンを進めていきます。

GKE に新しいクラスタを作成
サンプルアプリケーション (bank-of-anthos) をデプロイ
稼働中のアプリケーションに ASM を導入
本番に適した構成への更新

今回の手順は Cloud Shell 上で試すことを想定しています。また事前に Billing を有効にした新規プロジェクトをご用意ください。

初期設定

プロジェクト ID、環境を構築するゾーン (東京) を設定します。

PROJECT_ID="今回環境を構築するプロジェクトID"
ZONE="asia-northeast1-b"
gcloud config set project $PROJECT_ID
gcloud config set compute/zone $ZONE

API の有効化

今回のハンズオンで利用する機能を事前に有効化しておきます。

gcloud services enable container.googleapis.com

新しいクラスタを作成

今回利用するクラスタ (bank-of-anthos) を作成します。
ASM ではデプロイするクラスタについて前提条件があり、そちらを満たすようにしています。

machine-type: e2-standard-4
4 vcpus 以上のマシンタイプ
release-channel regular
今回導入する最新版 ASM 1.8.1 をサポートするバージョン。また GKE クラスタを Release channel に入れておくことで、アップグレードを管理する。
enable-ip-alias
VPC ネイティブクラスタとして作成。後ほど Ingress を使いコンテナネイティブ負荷分散を行う。

gcloud container clusters create bank-of-anthos \
--project=${PROJECT_ID} --zone=${ZONE} \
--machine-type=e2-standard-4 --num-nodes=3 \
--enable-stackdriver-kubernetes --subnetwork=default \
--enable-ip-alias --release-channel regular

クラスタが作成されるまで 5 分程度かかります。

bank-of-anthos のデプロイ

今回はサンプルアプリケーションとして、マイクロサービスアーキテクチャで作られている bank-of-anthos を利用します。

1. リポジトリをクローン

git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git
cd bank-of-anthos

2. bank-of-anthos のデプロイ

提供されているマニフェストを使いデプロイを行います。

kubectl apply -f extras/jwt/jwt-secret.yaml
kubectl apply -f kubernetes-manifests

3. デプロイの確認

すべての Pod が Ready になるまで待ちます。

while true; do kubectl get pods | grep '1/1' | wc -l | grep -q '9' && echo 'Bank of Anthos started.' && break || echo "Waiting for Bank of Anthos..."; sleep 5; done

4. アプリケーションをブラウザから確認

コマンドの出力をクリックして bank-of-anthos が表示されることを確認します。

FRONTEND_IP=$(kubectl get service frontend -o json | jq -r '.status.loadBalancer.ingress[0].ip')
echo http://$FRONTEND_IP/

ここまでで作成した環境をアーキテクチャ図にしてみます。素直に GKE でアプリケーションを構築した状態です。

ASM の導入

作成したクラスタに対して ASM を導入します。

1. インストールスクリプトのダウンロード、検証

curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.8 > install_asm
curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.8.sha256 > install_asm.sha256
sha256sum -c --ignore-missing install_asm.sha256

“Install_asm: OK” と出力されることを確認します。

2. インストールスクリプトを実行可能に更新

chmod +x install_asm

3. インストールスクリプトの実行

適切なオプションを付け、スクリプトを実行します。インストールに使われるファイル群を残しておくため、専用のディレクトリ (asm_output) を作成しています。

mkdir -p asm_output
./install_asm \
-p $PROJECT_ID \
-n bank-of-anthos \
-l $ZONE \
-m install \
-D asm_output \
--enable-all

完了まで、10 分強待ちます。“Successfully installed ASM.” というメッセージが最後に出ていることを確認します。

4. ASM がインストールされていることを確認

ブラウザから ASM コンソールを開き、bank-of-anthos で稼働しているサービス群 (合計 8 サービス) が見えていることを確認します。

bank-of-anthos への ASM 適用

ここまでの手順で ASM が対象のクラスタにインストールされましたが、bank-of-anthos はサイドカープロキシが入っておらず ASM の各種機能を利用することができません。bank-of-anthos にサイドカープロキシを導入しましょう。

1. ASM が使っているリビジョン情報を取得

特定の名前空間に存在する Pod に簡単にサイドカープロキシを導入するため Auto injection 機能を使います。まず Auto Injection 機能で利用するリビジョン情報を取得します。すでに作成されている ASM のリソースから取得します。

REV=$(kubectl -n istio-system get pods -l app=istiod -ojson | jq -r '.items[0].metadata.labels["istio.io/rev"]')
echo $REV

2. サイドカーの Auto injection 機能を有効化

bank-of-anthos がデプロイされている名前空間 (default) に対して、Auto injection を有効化します。

kubectl label namespace default istio.io/rev=$REV istio-injection- --overwrite
kubectl get ns default --show-labels

3. bank-of-anthos を再デプロイ

再デプロイ (Deployment の再起動) を行うことで、Auto injection 機能によりサイドカープロキシが入った状態で Pod が起動します。再デプロイが完了するまで待ちます。

kubectl rollout restart deployment -n default
while true; do kubectl get pods | grep '2/2' | wc -l | grep -q '7' && echo 'Auto injection completed.' && break || echo "Waiting for the auto injection for Bank of Anthos..."; sleep 5; done

4. サービス稼働状況、サービス連携の確認

ブラウザから ASM コンソールを開き、サービスの稼働状況を確認します。正しくサイドカーが導入できた場合、サービスごとの 1 秒あたりリクエスト数、エラー率、レイテンシなどの情報が見えるようになっているはずです。表示されるまで少し時間がかかります。

また図の中の右上にある[トポロジ]をクリックすると、下記のようなマイクロサービスの連携状況が確認できます。こちらも表示されるまでに 10 分以上かかる場合があります。先の手順を進めておいて戻ってくるのも良いでしょう。

この図を bank-of-anthos のアーキテクチャ図と見比べてみましょう。

DB 関連サービスは StatefulSet で稼働しているため、Deployment の再起動による Auto injection の対象外ですが、それ以外のサービスは連携情報が正しく描画されていることが確認できます。

ここでは DB がステートフルなワークロードとして GKE 上で動いています。しかし、GKE クラスタのアップデート、データの扱いなど運用の手間を考えると DB、またミドルウェアなどは本番環境ではメッシュ外に置くことをおすすめします。bank-of-anthos でもマネージドな RDBMS である Cloud SQL に置き換える手順が用意されています。

ここまでで作成した環境をアーキテクチャ図にしてみます。ポイントは ASM 関連コンポーネントが導入されたこと、DB を除いたサービスにサイドカープロキシが入ったことと、そして Istio ingress-gateway (Deployment, Service で構成) が作られたことです。

Istio ingress-gateway の利用

今の状態はまだ ASM 導入の最終形ではありません。最後に Istio ingress-gateway を使うように設定しましょう。Istio ingress-gateway は名前の通りサービスメッシュの入り口 (ゲートウェイ) となるリソースで、ロードバランサのように動きます。通常、本番利用する際にはこのリソースを使い、より柔軟なトラフィック制御を行うことになります。

1. Istio ingress-gateway の確認

Istio ingress-gateway は ASM のインストール時に作成済みです。動いているものを確認してみましょう。

kubectl get service,deploy -n istio-system istio-ingressgateway

出力のサンプル

NAME                           TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)                                                
                      AGE
service/istio-ingressgateway   LoadBalancer   10.4.4.18    34.85.58.49   15021:32094/TCP,80:32039/TCP,443:30757/TCP,15012:30519/
TCP,15443:30821/TCP   8m4s
NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/istio-ingressgateway   2/2     2            2           8m6s

Kubernetes の Deployment, Service (Type: Loadbalancer)で実現されていることがわかります。

2. bank-of-anthos 用の設定を投入

bank-of-anthos には Istio 用の Istio ingress-gateway と連携する設定ファイルが用意されています。そちらの設定を入れてみます。

kubectl apply -f istio-manifests/

3. アプリケーションをブラウザから確認 (Istio ingress-gateway 経由)

ING_GW_IP=$(kubectl get svc -n istio-system istio-ingressgateway -o json | jq -r '.status.loadBalancer.ingress[0].ip')
echo http://$ING_GW_IP/

無事、先の手順で確認した bank-of-anthos の画面が見えれば成功です。

ここまでで作成した環境をアーキテクチャ図にしてみます。Istio ingress-gateway と frontend が紐付けられ、その経路を経由してアクセスしています。

ここまでの手順で、既存のサービスに ASM を導入することができました。ポイントを下記に示します。

サービスに影響を与えずに ASM が導入できた
手順の中で取得した IP アドレスにアクセスをし続けているとわかるのですが、利用者から見るとサービス影響はありません。
サービスのソースコードに手を加えずにサービス群を可視化できた
サービスのコードは何も修正せずに、有用なメトリクス、サービス群の連携状況が可視化できました。

ASM は初めに示したように様々な機能がありますが、サービス群を簡単に可視化できるというだけでも導入の価値はあるのではないでしょうか。

少し横道に逸れますが、Google ではサービス管理、運用、また安定化の専門家として Site Reliability Engineering (SRE) というチームが存在します。SRE books (日本語版もあります) と呼ばれる一連のプラクティスをまとめた書籍を読んだことがある方もいらっしゃるかと思います。そのプラクティスの 1 つとして障害から原因特定、問題解決までを迅速にするために監視項目は重要なものだけに絞り、それを共通化にするという考え方があります。実はそこで挙げられている監視項目 (Golden signals：下記参照) は ASM がデフォルトで可視化してくれている項目になります。

Latency
Traffic
Errors
Saturation

これで bank-of-anthos の ASM 導入が完了しました！
サービスメッシュの特徴であるトラフィック制御、セキュリティ向上、要件に応じた可視化など、下記のリンクを参考に、ご自身で設定を追加しいろいろな機能を試してみてください

参考リンク

本番での利用

ASM は導入できましたが、本番で利用できる構成になっているとは言えません。今回はサービスを本番で公開する場合に必須となる、下記の 2 つのシナリオを実現する手順を説明します。

Ingress (HTTP/HTTPS ロードバランサ) の利用
現在、Istio ingress-gateway はネットワークロードバランサとして動いています。Kubernetes で Web サービスを公開する場合、Ingress (HTTP/HTTPS ロードバランサ) 、Service (NEG が使える GKE ではClusterIP、それ以外の場合は NodePort) リソースを組み合わせて使うことが普通になっているかと思います。ASM でも同じように Ingress を組み合わせてみましょう。
Istio ingress-gateway のスケールアップ、アウト
ASM 導入の中で Istio ingress-gateway を導入しましたが、メッシュの入り口と書きました。つまりメッシュ内のサービスを増やしていくと、負荷がかかるポイントとなります。ASM のインストール時にサイズが決まっていますが、これを変更し大きくしてみましょう。この手順で ASM をカスタマイズする手順を学びます。

Ingress (HTTP/HTTPS ロードバランサ) の利用

今稼働している bank-of-anthos に影響を与えずに In-place で Ingress を導入するのは難しいため、ASM を入れ直す形で構築を進めます。

Ingress を利用すると、L7 のレイヤーでトラフィックをコントロールでき、柔軟なバックエンドサービスの構成、複数の TLS 証明書の管理、それらを利用した TLS の終端、Cloud Armor、Cloud CDN との連携など高度な機能が使えるようになります。詳細はこちらをご確認ください。

ASM、bank-of-anthos の削除

1. bank-of-anthos を削除

kubectl delete -f istio-manifests/
kubectl delete -f kubernetes-manifests/
kubectl delete -f extras/jwt/jwt-secret.yaml

2. ASM を削除

asm_output/istio-*/bin/istioctl manifest generate --set profile=asm-gcp | kubectl delete --ignore-not-found=true -f -
kubectl delete ns asm-system istio-system

3. サイドカーの Auto injection 機能を無効化

kubectl label namespace default istio.io/rev-

ここまでで ASM、bank-of-anthos を削除し、クラスタは初期状態になりました。ここから、ASM、bank-of-anthos を Ingress と共に導入していきます。

Ingress ＋ ASM、bank-of-anthos の導入

Ingress を ASM と組み合わせて導入します。Ingress の設定は最小で済む形で構築します。

以降の手順で利用する IstioOperator と Overlay について説明します。

IstioOperator
Istio をインストール、更新するための方法の 1 つで Kubernetes の CRD を使った Operator パターンで実現されています。IstioOperator を使うことで利用者はコマンドラインツールである istioctl だけでインストールができるようになりました。以前は Helm がインストールの主流でした。
Overlay
IstioOperator によるインストール時に、オーバーレイファイル (YAML ファイル) で設定をオーバーライドする方法で、例えばオプション扱いの機能を有効化する、Istio が作成する Kubernetes リソースの設定を上書きするなど、Istio をカスタマイズする際に必須の手続きとなります。

1. Ingress 用の IstioOperator 設定ファイルを用意

Istio ingress-gateway は ASM をそのままインストールすると type: Loadbalancer として作成されていました。これを Ingress と連携させるため、 ClusterIP で作成するための設定ファイルを作成します。更に後ほど設定を行う BackendConfig との紐付けと、NEG の設定を追加しています。

cat <<EOF > ingressgateway-type-overlay.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          serviceAnnotations:
            cloud.google.com/backend-config: '{"default": "ingress-backendconfig"}'
            cloud.google.com/neg: '{"ingress": true}'
          service:
            type: ClusterIP
EOF

2. ASM の再インストール

Overlay で Istio ingress-gateway の設定を上書き (手順 1 のファイルを利用) し ASM をインストールします。

rm -rf asm_output/*
./install_asm \
-p $PROJECT_ID \
-n bank-of-anthos \
-l $ZONE \
-m install \
-D asm_output \
--enable-all \
--co ingressgateway-type-overlay.yaml

3. BackendConfig の作成

この手順がとても重要です。ここで実現したいことは、Ingress での負荷分散ターゲットと、ターゲットに対する Health check を別のものするということです。

Istio ingress-gateway はプロキシとしてアクセスを受け付けるポート (例えば HTTP の場合は 80) とは別に Health check 用のアクセスポイント (ポート: 15021, プロトコル: HTTP, パス: /healthz/ready) が用意されています。それに合わせて BackendConfig を設定しています。詳しくはこちらを参照してください。

cat <<EOF > ingress-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: ingress-backendconfig
  namespace: istio-system
spec:
  healthCheck:
    requestPath: /healthz/ready
    port: 15021
    type: HTTP
EOF
kubectl apply -f ingress-backendconfig.yaml

4. Ingress の作成

cat << EOF > ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gke-ingress
  namespace: istio-system
spec:
  backend:
    serviceName: istio-ingressgateway
    servicePort: 80
EOF
kubectl apply -f ingress.yaml

Ingress の作成には 10 分程度かかる場合があります。作成が完了したかは Ingress の Console UI が分かりやすいです。

もし下記のような表示が出ている場合は、もう少し待ってみてください。

5. サイドカーの Auto injection 機能を有効化

bank-of-anthos がデプロイされている名前空間 (default) に対して、Auto injection を有効化します。

kubectl label namespace default istio.io/rev=$REV istio-injection- --overwrite
kubectl get ns default --show-labels

6. bank-of-anthos のデプロイ

kubectl apply -f extras/jwt/jwt-secret.yaml
kubectl apply -f kubernetes-manifests

7. デプロイの確認

すべての Pod が Ready になるまで待ちます。

while true; do kubectl get pods | grep '2/2' | wc -l | grep -q '9' && echo 'Bank of Anthos started.' && break || echo "Waiting for Bank of Anthos..."; sleep 5; done

8. bank-of-anthos 用 Istio 設定を投入

Istio 用の設定ファイルを投入します。

kubectl apply -f istio-manifests/

9. アプリケーションをブラウザから確認 (Ingress + Istio ingress-gateway 経由)

INGRESS_IP=$(kubectl get ing -n istio-system -o json gke-ingress | jq -r '.status.loadBalancer.ingress[0].ip')
echo http://$INGRESS_IP/

ここまでのアーキテクチャ図は下記のようになります。Ingress: HTTP(S) LB が NetworkLB の代わりに使われているところがポイントです。

Istio ingress-gateway のスケールアップ、アウト

無事、Ingress を Istio ingress-gateway と連携させることができました。次に、Istio ingress-gateway をスケールアップ、アウトさせてみましょう。

1. 現在の Istio ingress-gateway の確認

kubectl get deploy -n istio-system istio-ingressgateway -o json | jq ‘.
spec | .replicas, .template.spec.containers[0].resources’

出力のサンプル (コメントを付けています)

2                    # レプリカ数：2
{
  “limits”: {        # Pod に割り当てられる最大の CPU, Memory
    “cpu”: “2”,
    “memory”: “1Gi”
  },
  “requests”: {      # Pod が要求する CPU, Memory
    “cpu”: “100m”,
    “memory”: “128Mi”
  }
}

2. 新しいサイズの定義

今回はデフォルトの値をスケールアップ＋スケールアウトすることにします。

レプリカ数
2 から 3 にスケールアウト
リソース
requests を CPU: 200m, memory を 256MiB にスケールアップ

3. 設定ファイルを作成し、適用

さきほど定義したサイズの patch ファイルを作成します。

cat << EOF > istio-ingressgateway-patch.yaml
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: istio-proxy
        requests:
          cpu: 200m
          memory: 256Mi
EOF
kubectl patch deployment istio-ingressgateway -n istio-system --patch "$(cat istio-ingressgateway-patch.yaml)"

4. Istio ingress-gateway の更新を確認

kubectl get deploy istio-ingressgateway -n istio-system

出力サンプル

NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
istio-ingressgateway   3/3     3            3           162m

レプリカが 3 になっていることを確認します。

cat <<EOF > istio-ingressgateway-patch.yaml
kind: IstioOperator
spec:
  components:
    ingressGateways:
      - k8s:
          hpaSpec:
            minReplicas: 3
          resources:
            requests:
              cpu: 200m
              memory: 256Mi
EOF

最後のアーキテクチャはこちらです。Istio ingress-gateway がスケールアップ＋アウトしています。

ポイント

ここでは Istio ingress-gateway が稼働中だったため、Deployment に patch をあて、設定の更新を行いました。ASM のインストール時に設定する場合は、Ingress ＋ ASM で実施した手順と同じように Overlay で設定ファイルを適用することが可能です。

今回と同じ設定を入れる場合の手順を示します。

1. スケール設定を入れた Overlay ファイルを作成

cat <<EOF > ingressgateway-scale-overlay.yaml
kind: IstioOperator
spec:
  components:
    ingressGateways:
      - k8s:
          hpaSpec:
            minReplicas: 3
          resources:
            requests:
              cpu: 200m
              memory: 256Mi
EOF

2. Overlay ファイルを指定し ASM をインストール

./install_asm \
-p $PROJECT_ID \
-n bank-of-anthos \
-l $ZONE \
-m install \
-D asm_output \
--enable-all \
--co ingressgateway-type-overlay.yaml \
--co ingressgateway-scale-overlay.yaml

クリーンアップ

そのままにしておくと、GCP リソースのコストが掛かってしまいます。ここまで使ってきたリソースを削除しましょう。これらを削除します。

GCP リソース：GKE クラスタ
ハンズオンで利用したファイル群

gcloud container clusters delete bank-of-anthos \
--project=${PROJECT_ID} --zone=${ZONE} --quiet
cd $HOME
rm -rf bank-of-anthos

参考リンク

まとめ

サービスメッシュ、そして GCP のオファリングである ASM はいかがでしたでしょうか。思ったより導入が容易そうだなと感じた方が多いのではないでしょうか。また Anthos Service Mesh が単体でご利用頂けるようになった今こそ、試していただくには絶好のタイミングです。

長くなってしまいましたが、最後までお付き合い頂きありがとうございました。

明日 20 日目は、kuchima さんによる「Traffic Director でプロキシレスサービスメッシュを試してみる」です。ASM (Istio) ではサイドカープロキシが各 Pod に Inject (挿入) されてサービスメッシュが構成されていました。それと大きく異なるプロキシレスサービスメッシュの世界、ぜひお楽しみに！！

Anthos Service Mesh を導入、移行、そして使いこなしてみよう

tl;dr

サービスメッシュとは？

Anthos Service Mesh とは？

ASM のライセンス

なにがマネージドなのか？

ASM の構成を決定するプロファイル

ハンズオン

初期設定

API の有効化

新しいクラスタを作成

bank-of-anthos のデプロイ

1. リポジトリをクローン

2. bank-of-anthos のデプロイ

3. デプロイの確認

4. アプリケーションをブラウザから確認

ASM の導入

1. インストールスクリプトのダウンロード、検証

2. インストールスクリプトを実行可能に更新

3. インストールスクリプトの実行

4. ASM がインストールされていることを確認

bank-of-anthos への ASM 適用

1. ASM が使っているリビジョン情報を取得

2. サイドカーの Auto injection 機能を有効化

3. bank-of-anthos を再デプロイ

4. サービス稼働状況、サービス連携の確認

Istio ingress-gateway の利用

1. Istio ingress-gateway の確認

2. bank-of-anthos 用の設定を投入

3. アプリケーションをブラウザから確認 (Istio ingress-gateway 経由)

本番での利用

Ingress (HTTP/HTTPS ロードバランサ) の利用

ASM、bank-of-anthos の削除

1. bank-of-anthos を削除

2. ASM を削除

3. サイドカーの Auto injection 機能を無効化

Ingress ＋ ASM、bank-of-anthos の導入

1. Ingress 用の IstioOperator 設定ファイルを用意

2. ASM の再インストール

3. BackendConfig の作成

4. Ingress の作成

5. サイドカーの Auto injection 機能を有効化

6. bank-of-anthos のデプロイ

7. デプロイの確認

8. bank-of-anthos 用 Istio 設定を投入

9. アプリケーションをブラウザから確認 (Ingress + Istio ingress-gateway 経由)

Istio ingress-gateway のスケールアップ、アウト

1. 現在の Istio ingress-gateway の確認

2. 新しいサイズの定義

3. 設定ファイルを作成し、適用

4. Istio ingress-gateway の更新を確認

ポイント

1. スケール設定を入れた Overlay ファイルを作成

2. Overlay ファイルを指定し ASM をインストール

クリーンアップ

参考リンク

まとめ

Written by Kozzy Hasebe