フルマネージドに進化した「Anthos Service Mesh」で運用を楽に!

Kazuki Uchima
google-cloud-jp
Published in
19 min readSep 13, 2021

フルマネージドなサービスメッシュである Anthos Service Mesh でマネージド コントロールプレーン 機能が GA となり、またマネージド データプレーン 機能が Preview でご利用いただけるようになりました。

本記事では ”フルマネージド” に進化した Anthos Service Mesh を解説していきたいと思います。

はじめに

Anthos Service Mesh (以降 ASM と記載) は Google が提供するフルマネージドのサービスメッシュです。OSS の Istio をベースに開発されており、Google Cloud だけではなくオンプレミス環境や他社クラウド環境上でもご利用いただくことができます。

本記事では GKE (on Google Cloud) 環境を前提に、ASM をより楽に運用することができるようになるマネージド コントロールプレーン (MCP) マネージド データプレーン (MDP) という機能を解説します。

tl;dr

  • マネージド コントロールプレーン (MCP) により、ユーザー側での Istio コントロールプレーン コンポーネントの運用管理が不要になりました。
  • マネージド データプレーン (MDP) により、データプレーン (istio-proxy) の手動アップグレード作業も不要になりました。

ASM の特徴

先述の通り ASM は Istio をベースに開発していますが、プラスアルファで サービスメッシュをより便利かつ楽に運用できるように各種機能が追加されています。

OSS 版 Istio との大きな違いは以下の通りです:

  • コントロールプレーンの各種機能をマネージドサービスとして提供
  • Google Cloud サービスと簡単に Integration できる (例: GCE との Integration, Cloud Operations 連携など)
  • 専用ダッシュボードでの SLO モニタリングやメッシュ可視化ができる
  • Google の商用サポート有り
ASM アーキテクチャ

その他 ASM の概要については、Kozzy Hasebe さんの「Anthos Service Mesh を導入、移行、そして使いこなしてみよう」をご参照ください。

ASM コントロールプレーンの構成オプション

ASM (on Google Cloud) ではコントロールプレーンの構成を以下 2 種類から選択できます。

  • クラスタ内 コントロールプレーン (以降 In-cluster CP と記載)
  • マネージド コントロールプレーン (以降 MCP と記載)

In-cluster CP はその名の通り、GKE クラスタ上で Istio のコントロールプレーン コンポーネントである istiod が動作する構成です。OSS 版 Istio と同様にユーザー側で istiod のアップグレードやスケール設定、モニタリングなど運用/管理をしていただく必要があります。

一方 MCP は istiod を Google が管理しマネージドサービスとして提供する構成です。マネージドなのでユーザー側で istiod の運用/管理をしていただく必要がなくなり、サービスメッシュの運用負荷を低減することができます。

In-cluster CP vs MCP アーキテクチャの比較

その他、証明書管理も以下の構成オプションから選択することができますが、本記事では詳細を割愛します。MCP では 2021.09 現在 Mesh CA というマネージドの証明書管理サービスのみサポートしています。

MCP リリースチャネル

MCP は下記 ASM 独自のリリースチャネルに従ってコントロールプレーンを自動的にアップグレードします。

MCP リリースチャネル

Rapid チャネルは ASM の最新バージョンを利用したい場合などで利用いただけます。常に最新のパッチバージョンが適用される環境となるため、検証環境などでの利用を推奨します。

Regular チャネルは Rapid チャネルで検証され安定したバージョンを利用できるチャネルです。新機能と安定性のバランスが最も取れており本番環境での利用にもお勧めです。

Stable チャネルは Regular チャネルで運用/検証された、最も安定したバージョンを利用できるチャネルです。新機能の利用よりも安定性を重視する場合は Stable チャネルの利用を推奨します。

※重要なセキュリティパッチはすべてのリリースチャネルに適用されます。

利用するリリースチャネルは Namespace に付与する istio.io/rev ラベルの値でコントロールします。

MCP リリースチャネルと利用リビジョン名

例えば default Namespace に対して Regular チャネルを適用する場合は、以下のようにラベルを付与します。これにより default 内のワークロードは Regular チャネルに対応したバージョンのプロキシが自動的に Injection されるようになります。

kubectl label namespace default istio.io/rev=asm-managed --overwrite

マネージド データプレーン (MDP)

マネージド データプレーン (以降 MDP と記載) は MCP リリースチャネルに基づきクラスタ内のデータプレーンを自動的にアップグレードしてくれる機能です。2021.09 現在 Preview としてご利用いただけます。

これまで、MCP を利用することによりコントロールプレーン側は自動的にアップグレードされていたのですが、Pod の sidecar として inject されるプロキシについては、ユーザー側で都度ワークロードを Restart する等して手動アップグレードをする必要がありました。

今回 Preview となった MDP を有効にすることにより、上記プロキシも ASM 側で自動的にアップグレードしてくれるようになります。

MDP 有効化の方法ですが、フリートというクラスタのグルーピングの仕組みの中でサービスメッシュ機能を有効化にした後、MCP クラスタ内の管理対象 Namespace に対して以下 Annotation を付与するだけでご利用いただけます。(Pod 単位で MDP を有効化したい場合は対象 Pod/Deployment に対して Annotation します)

kubectl annotate --overwrite namespace <対象 NAMESPACE> \
mesh.cloud.google.com/proxy='{"managed":"true"}'

そうすると データプレーンコントローラというリソースがクラスタ内にデプロイされ、自動的に各ワークロードのリスタートを実行することでプロキシのアップグレードを行ってくれるようになります。

MCP / MDP の制約事項

MCP では 2021.09 時点でいくつか制約事項があります。主な制約は以下の通りです:

MDP における 2021.09 時点での制約事項は以下の通りです:

  • Istio CNI が有効化されている必要あり
  • Rapid / Regular チャネルのクラスタのみで利用可能

※上記制約は今後のアップデートにより解消/緩和される可能性があります

MCP / MDP を有効化した ASM 環境の構築

ここからは実際に MCP / MDP を有効にした ASM 環境を構築していきたいと思います。(参考:公式ドキュメント

  1. GKE クラスタのデプロイ

Regular リリースチャネルに登録された GKE クラスタをデプロイします。

export PROJECT_ID=$(gcloud config list --format   "value(core.project)")
export CLUSTER_NAME=<クラスタ名>
export CLUSTER_LOCATION=asia-northeast1-a
export WORKLOAD_POOL=${PROJECT_ID}.svc.id.goog
# GKE API が有効化されていない場合
gcloud services enable container.googleapis.com
# GKE クラスタの作成
gcloud container clusters create ${CLUSTER_NAME} \
--zone ${CLUSTER_LOCATION} \
--enable-ip-alias \
--machine-type e2-standard-4 \
--num-nodes=4 \
--workload-pool=${WORKLOAD_POOL} \
--release-channel=regular

2. ASM のインストール

ASM のインストールスクリプトをダウンロードします。

curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.10 > install_asmchmod +x install_asm

スクリプトを実行し MCP 構成の ASM をインストールします。

./install_asm --mode install --managed \
-p ${PROJECT_ID} \
-l ${CLUSTER_LOCATION} \
-n ${CLUSTER_NAME} \
--verbose \
--output_dir ${CLUSTER_NAME} \
--enable-all \
--enable-registration \
--option cni-managed

ASM が無事インストールされたらデプロイされたリソースを確認してみましょう。

$ ${CLUSTER_NAME}/istio-1.10.4-asm.6/bin/istioctl version
no running Istio pods in "istio-system"
1.10.4-asm.6
$ kubectl get all -n istio-system
No resources found in istio-system namespace.

OSS Istio をインストールした際はデフォルトだと istio-system Namespace 内に istiod や Ingress Gateway といったコンポーネントがデプロイされているのですが、MCP の場合はこれが空になっています。

istiod は Google が管理する形になるのでクラスタからいなくなるのは当然なのですが、実は MCP では Ingress Gateway もデフォルトでデプロイされません。なので個別にデプロイしていきます。

3. Ingress Gateway のデプロイ

以下コマンドを実行し istio-system Namespace に Ingress Gateway をデプロイします。今回はistio.io/rev: asm-managed-rapidと設定し、リリースチャネルとして Rapid を選択します。

kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
name: istio-ingressgateway
namespace: istio-system
spec:
type: LoadBalancer
selector:
istio: ingressgateway
ports:
- port: 80
name: http
- port: 443
name: https
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: istio-ingressgateway
namespace: istio-system
spec:
selector:
matchLabels:
istio: ingressgateway
template:
metadata:
annotations:
# This is required to tell Anthos Service Mesh to inject the gateway with the
# required configuration.
inject.istio.io/templates: gateway
labels:
istio: ingressgateway
istio.io/rev: asm-managed-rapid # This is required only if the namespace is not labeled.
spec:
containers:
- name: istio-proxy
image: auto # The image will automatically update each time the pod starts.
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: istio-ingressgateway-sds
namespace: istio-system
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: istio-ingressgateway-sds
namespace: istio-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: istio-ingressgateway-sds
subjects:
- kind: ServiceAccount
name: default
EOF

Ingress Gateway がデプロイされたことを確認します。

$ kubectl get all -n istio-system
NAME READY STATUS RESTARTS AGE
pod/istio-ingressgateway-5894744dbd-4bhvp 1/1 Running 0 11s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/istio-ingressgateway LoadBalancer 10.100.15.187 <External IP> 80:31449/TCP,443:32198/TCP 15s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/istio-ingressgateway 1/1 1 1 15s
NAME DESIRED CURRENT READY AGE
replicaset.apps/istio-ingressgateway-5894744dbd 1 1 1 15s

4. MDP の有効化

サンプルアプリケーションと Ingress Gateway を MDP で管理するため、アプリケーションをデプロイする default Namespace とIngress Gateway をデプロイする istio-system Namespace にアノテーションし、 MDP を有効化します。

kubectl annotate --overwrite namespace default \
mesh.cloud.google.com/proxy='{"managed":"true"}'
kubectl annotate --overwrite namespace istio-system \
mesh.cloud.google.com/proxy='{"managed":"true"}'

フリートでサービスメッシュ機能を有効化します。

gcloud alpha container hub mesh enable --project=${PROJECT_ID}

istio-system 上に データプレーン コントローラがデプロイされ Ready となっていることを確認します。(Ready になるまで 10 分程度時間がかかります)

$ kubectl -n istio-system get dataplanecontrol
NAME REVISION VERSION TARGETBASISPOINTS STATUS AGE
asm-managed-rapid-w5294 asm-managed-rapid 1.10.4-asm.6 10000 Ready 6m1s

5. サンプルアプリケーションのデプロイ

これで準備は完了です。動作確認のため Bookinfo というサンプルアプリケーションをデプロイします。

サンプルアプリケーションをデプロイする default Namespace に Auto injection の設定を入れます。(“label “istio-injection” not found.” というメッセージが出力される場合は無視してください)

$ kubectl label namespace default istio-injection- istio.io/rev=asm-managed-rapid --overwrite

Bookinfo をデプロイします。

$ kubectl apply -f ${CLUSTER_NAME}/istio-1.10.4-asm.6/samples/bookinfo/platform/kube/bookinfo.yaml$ kubectl get pods
NAME READY STATUS RESTARTS AGE
details-v1-79f774bdb9-kvlqj 2/2 Running 0 108s
productpage-v1-6b746f74dc-79jqx 2/2 Running 0 108s
ratings-v1-b6994bb9-q92kx 2/2 Running 0 108s
reviews-v1-545db77b95-tbb7b 2/2 Running 0 108s
reviews-v2-7bf8c9648f-tlgpg 2/2 Running 0 109s
reviews-v3-84779c7bbc-4fx68 2/2 Running 0 108s

Ingress Gateway 経由でアプリケーションにアクセスできるようルーティングを定義します。

$ kubectl apply -f ${CLUSTER_NAME}/istio-1.10.4-asm.6/samples/bookinfo/networking/bookinfo-gateway.yaml

Ingress Gateway Service の External IP アドレスを確認します。

$ kubectl get service istio-ingressgateway -n istio-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-ingressgateway LoadBalancer 10.100.15.187 <External IP> 80:31449/TCP,443:32198/TCP 44m

ブラウザで http://<External IP>/productpage にアクセスし、アプリケーションが利用できることを確認します。画面を更新するたびに画面右側の Book Reviews の表示が変更されることも確認します。

Bookinfo アプリケーションの画面

これで MCP / MDP 環境においても Istio の基本的な機能が利用できることが確認できました!

現在利用されているコントロールプレーンとデータプレーンのバージョンについては Cloud Monitoring でメトリクスとして取得することもできます。本環境では、2021.09.10 現在 1.10.4-asm.6 が利用されており、今後新バージョンがリリースされると自動的にアップグレードされていきます。

まとめ

ASM の MCP / MDP 機能を利用しアップグレードを自動化することにより、サービスメッシュ導入に対するハードルの 1 つとなっていた「運用負荷」を軽減することができるようになりました。

ちなみに ASM は 2021.10 末まで無償でご利用いただけます。そろそろサービスメッシュを検討しようとされていたり、現状のサービスメッシュ運用でお困りの方がいらっしゃいましたらぜひお試しください!

参考資料

--

--

Kazuki Uchima
google-cloud-jp

Application Modernization Specialist at Google Cloud. All views and opinions are my own.