Anthos を使ったエンタープライズ向けクラスタの設計とアップグレード戦略のススメ （CloudNative Days Tokyo 2021 発表資料） 2021年11月4日（木） NTTデータ 金融事業推進部 技術戦略推進部 システム企画担当 宇都宮 雅彦

1. Anthos を使った
エンタープライズ向けクラスタの設計と
アップグレード戦略のススメ
Masahiko Utsunomiya
NTT DATA
2021/11/04

2. 掲載内容は個人の見解であり、
所属する企業や組織の立場、戦略、意見を
代表するものではありません

3. Masahiko Utsunomiya
Infrastructure Engineer, Relationship Builder
NTT DATA
Speaker
✔ 金融分野のお客様のクラウド導入支援
✔ Jagu’e’r, Cloud Native 分科会メンバ
✔ コンテナ/クラウドネイティブ技術関連のコミュニティ活動
polar3130 polar3130

4. これから Google Cloud で GKE 上にマイクロサービスを
構築しようと考えている方
- Google Cloud の基本的な知識がある
- GKE を使ったことがある
- Istio (サービスメッシュ) の基本的な知識がある
想定聴講者
※ GKE : Google Kubernetes Engine

5. 前置き
本資料中の GKE, ASM の挙動・仕様については、
以下のバージョンをベースに動作確認しています
- GKE : 1.21.3-gke.2001
- Node Image : cos_containerd
- ASM (In-cluster) : 1.11.2-asm.17
- Managed ASM : Regular channel (1.10.4-asm.9)
- asmcli : 1.11.2-asm.17+config2
※ ASM : Anthos Service Mesh
※ 基本 In-cluster Control Plane の ASM の話ですが、所々で Managed ASM にも言及しています

6. 1. GKE x ASM の推奨構成とアップグレード計画
2. GKE のアップグレード戦略とプラクティス
3. ASM のアップグレード戦略とプラクティス
4. おわりに
Agenda

7. 1
GKE x ASM の推奨構成と
アップグレード計画

8. クラスタ設計の要件
このセッションにおけるエンタープライズのイメージ
● アプリは新規もあれば Lift & Shift もあるマルチテナント
● NW・セキュリティとクラスタ運用の権限分掌
● 可用性要求の高い傾向
● ノードは VPC 上のプライベート NW で運用したい
● 厳格な構成管理
※ エンタープライズとひとくちに言っても企業によって事情は様々
私の経験に基づくひとつの例と捉えて頂ければ幸いです
8

9. Shared VPC
各テナントのアプリケーションやクラスタの管理を VPC と分離
● アプリは新規もあれば Lift & Shift もあるマルチテナント
● NW・セキュリティとクラスタ運用の権限分掌
Shared VPC
Network
Shared VPC
Connectivity
Shared VPC
Host Project
Shared VPC
Service Project
namespace: app-A
namespace: app-B
app A
project
app B
project
cluster
project

10. Regional Cluster
Control Plane の SLA 99.95 %, メンテナンスのダウンタイムなし
● 可用性要求の高い傾向
10
Kubernetes
Engine
Zone
Region

11. VPC Peering
Public
Endpoint
VPC Native & Private Cluster
ノードを内部 IP アドレスのみで構成、Control Plane のアクセス制限
● ノードは VPC 上のプライベート NW で運用したい
Primary Subnet Pod Range Service Range
Private
Endpoint

12. VPC Peering
Public
Endpoint
VPC Native & Private Cluster
ノードを内部 IP アドレスのみで構成、Control Plane のアクセス制限
● ノードは VPC 上のプライベート NW で運用したい
Primary Subnet Pod Range Service Range
Private
Endpoint

13. VPC Peering
Public
Endpoint
VPC Native & Private Cluster
ノードを内部 IP アドレスのみで構成、Control Plane のアクセス制限
● ノードは VPC 上のプライベート NW で運用したい
Primary Subnet Pod Range Service Range
Private
Endpoint
Master
Authorized
Networks

14. GKE のバージョニング（構成管理）
エンタープライズの本番環境では Static (no channel) がおすすめ
- Node pool の GKE バージョンを自動で最新にキープできるという恩恵がある一方、
自動アップグレードがサービスの SLA に及ぼす影響を事前に把握し切るのは困難
な場合がある
e.g.
- インシデントの検証中にアップグレードが走って再現環境の構成が変わってしまう
- Static なバージョンを選定する際は Regular channel を指標とするのがおすすめ
（Regular channel のリリースを起点にサポート期間が設定されるため）
14

15. エンタープライズにおける GKE の構成例
15
Shared VPC Network
Shared VPC
Connectivity
Kubernetes
Engine
Shared VPC
Host Project
Shared VPC
Service Project
(Cluster Project)
Public Endpoint
+ master authorized networks
Zone
✔ Shared VPC
✔ Regional
✔ VPC Native
✔ Private
✔ Static (no channel)

16. ✔ Shared VPC
✔ Regional
✔ VPC Native
✔ Private
✔ Static (no channel)
エンタープライズにおける GKE の構成例
16
Anthos Service
Mesh
+
Shared VPC Network
Shared VPC
Connectivity
Kubernetes
Engine
Shared VPC
Host Project
Shared VPC
Service Project
(Cluster Project)
Zone
Public Endpoint
+ master authorized networks

17. Google が提供するマネージドサービスメッシュ
- Istiod は、Google 管理 か In-cluster か、ホスト先を選択可能
Anthos Service Mesh
HTTP/S, gRPC, TCP
mTLS
Mesh CA
Managed
backends
Istiod
Service A Service B
Envoy Envoy
In-cluster control plane
Data
Plane
Control
Plane
Telemetry
TLS certs
to Envoys
Config to Envoys
User’s Cluster

18. Anthos Service Mesh
Google が提供するマネージドサービスメッシュ
- Istiod は、Google 管理 か In-cluster か、ホスト先を選択可能
- Google 管理 の場合、ASM はリリースチャンネルの利用が必須
HTTP/S, gRPC, TCP
mTLS
Mesh CA
Managed
backends
(Managed
Istiod)
Service A Service B
Envoy Envoy
Managed Anthos Service Mesh
Control
Plane
Telemetry
TLS certs
to Envoys
Config to Envoys
User’s Cluster
Data
Plane
※ managed Data Plane は割愛

19. ASM のメリット
- サービスメッシュの維持運用がある程度省ける
- Cloud Operations との統合でテレメトリの収集が容易
- MCS (Multi Cluster Service) , MCI (Multi Cluster Ingress) を活用できる
- 中身がほぼ Istio なのでソースコードを読んで解析ができる
- Google のサポートが得られる (要 サポート契約)
19

20. ASM のメリット
- サービスメッシュの維持運用がある程度省ける
- Cloud Operations との統合でテレメトリの収集が容易
- MCS (Multi Cluster Service) , MCI (Multi Cluster Ingress) を活用できる
- 中身がほぼ Istio なのでソースコードを読んで解析ができる
- Google のサポートが得られる (要 サポート契約)
20

21. ASM のバージョニング
エンタープライズの本番環境では Static (In-cluster) がおすすめ
- ASM のアップグレードはサービスメッシュを利用する全サービスに影響するため、
マイナーバージョン間の変更差分を特定・検証したうえで本番適用したほうが安全
- ASM がサポートする GKE のバージョンは以下を確認
https://cloud.google.com/service-mesh/docs/supported-features#supported_platforms
Managed Control Plane の場合はリリースチャンネルが必須
- Rapid, Regular, Stable から選択でき、Namespace 毎に適用する
- GKE リリースチャンネルとは独立している
21

22. GKE (Static) x ASM (In-cluster control plane)
22
GKE Nodepool
GKE Control Plane
Service
Envoy
ASM Control Plane
(namespace: istio-system)
Application
Namespace
この構成は以下のような場合におすすめ：
- Kubernetes + Istio の環境が欲しいが、
Control Plane の運用は楽をしたい
- サービスメッシュの設計や運用の過程で
Google のサポートを受けたい
- GKE や ASM のマイナーバージョンを
Static に管理したい
バージョン管理がユーザの責務となるので、
GKE, ASM のアップグレード検討が必要

23. アップグレードサイクルの検討
GKE, ASM をセットにしてでも、短いアップグレード周期 (3か月程度) で
Regular channel 相当の追従を維持してゆくことを推奨
- GKE, ASM 両方のサポートバージョンを加味した運用サイクルの検討が必要
- チームが耐えられるなら GKE と ASM のアップグレードのタイミングを分け、
各回の変更を小さく、頻度を上げたほうが有事の切り分けはしやすいが...
- GKE と ASM のアップグレード時期をずらして、かつ高頻度のアップグレードサイクルを
維持しようとすると、（チームの初期段階は特に）インフラの運用負荷が高すぎる
- いずれにしても影響確認のためアップグレード前の十分な検証が必要
23

24. GKE のサポート期間とリリース実績
GKE
1.17
1.18
1.19
1.20
1.21
1.22
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
2021 2022 2023
6か月経過、以後
新規クラスタ作成不可
※ 実際は月単位ではなく日単位でサポートポリシーが設定されている
https://cloud.google.com/kubernetes-engine/docs/release-schedule
Regular Channel リリース後から
14か月間のサポートが提供される
サポート終了後は
強制アップグレード
GKE は、Kubernetes とは独立したサポート期間が設定されている

25. GKE x ASM の有効な組み合わせ
GKE
1.17
1.18
1.19
1.20
1.21
1.22
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
ASM
1.7
1.8
1.9
1.10
1.11
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
2021 2022 2023
ASM も Istio とは独立したサポート期間が設定されている
https://cloud.google.com/service-mesh/docs/getting-support#version_support_policy

26. GKE x ASM の有効な組み合わせ
26
GKE
1.17
1.18
1.19
1.20
1.21
1.22
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
ASM
1.7
1.8
1.9
1.10
1.11
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
2021 2022 2023
各 ASM がサポートする GKE バージョンを加味して構成を選択する

27. GKE x ASM の有効な組み合わせ
27
GKE
1.17
1.18
1.19
1.20
1.21
1.22
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
ASM
1.7
1.8
1.9
1.10
1.11
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
2021 2022 2023
GKE, ASM をセットで 3 か月周期にアップグレードする例を考える

28. GKE x ASM の有効な組み合わせ
28
GKE
1.17
1.18
1.19
1.20
1.21
1.22
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
ASM
1.7
1.8
1.9
1.10
1.11
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
2021 2022 2023
GKE 1.18 x ASM 1.8 → GKE 1.19 x ASM 1.9

29. GKE x ASM の有効な組み合わせ
29
GKE
1.17
1.18
1.19
1.20
1.21
1.22
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
ASM
1.7
1.8
1.9
1.10
1.11
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
2021 2022 2023
GKE 1.19 x ASM 1.9 → GKE 1.20 x ASM 1.10

30. GKE x ASM の有効な組み合わせ
30
GKE
1.17
1.18
1.19
1.20
1.21
1.22
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
ASM
1.7
1.8
1.9
1.10
1.11
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
2021 2022 2023
本番運用の間、新規クラスタが作れる状態を維持しようとすると...

31. GKE x ASM の有効な組み合わせ
31
GKE
1.17
1.18
1.19
1.20
1.21
1.22
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
ASM
1.7
1.8
1.9
1.10
1.11
9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1
2021 2022 2023
もうひとつ先のバージョンへのアップグレードが必要になる場合も

32. 通常の（直上バージョンへの）アップグレードを 2回転することを推奨
- ASM も含めて Version Skew を避け、変更点追跡やテストを複雑化させない
サポート切れが近い場合のアップグレード
Nodepool
1.18
1.18
Master
1.19
1.19
1.20
1.20
ASM
1.9 1.10 1.11
①
②
③
④
⑤
⑥

33. ダウングレードが必要な場合
本番運用では、アップグレード失敗時のロールバックで必要になる
- Node pool のみのダウングレードか、新規クラスタへの移行で対応する
- ロールバックが発生する可能性を考慮してアップグレードスケジュールを立てる
- 新規クラスタを作成できないと Control Plane 込みのロールバックはできない
1.20
1.21
1.21
Node pool
Master
1.21
1.21
1.20
1.20

34. 補足：メンテナンスウィンドウの設定
Regional Cluster でも、エンタープライズの本番環境では設定を推奨
- ダウンタイム影響の少ない時間帯を指定してメンテナンスする
- （メンテナンスポリシーの有効な範囲内で）一時的なメンテナンス除外も可能

35. 補足：Private Cluster と ASM
ASM (In-cluster) の導入は、Private Cluster の構成を限定しない
- 3パターン※1いずれも構成可能だが、セキュリティの観点から、Public Endpoint を
有効化するなら Master Authorized Networks は設定したほうが良い
- Managed ASM の場合は Public Endpoint を無効化できないが、有効にさえすれば
Managed Istiod は対象クラスタの Data Plane にアクセスできる※2
（Master Authz NWs の有無を問わない、とされているが運用上は asmcli の実行元の登録が必要）
- VPC Service Controls を利用する場合は Mesh CA (+ Cloud Ops) も併せて境界内
に含めることが必要
※1 https://cloud.google.com/kubernetes-engine/docs/concepts/private-cluster-concept#endpoints_in_private_clusters
※2 https://cloud.google.com/service-mesh/docs/supported-features-mcp#environments
35

36. 2
GKE のアップグレード戦略と
プラクティス

37. GKE (Static) + ASM (In-cluster control plane) (再掲)
37
GKE Nodepool
GKE Control Plane
Service
Envoy
ASM Control Plane
(namespace: istio-system)
Application
Namespace
以降は 1章で取り上げたこの構成を題材に、
GKE x ASM のアップグレード戦略の選択肢と
推奨を紹介
（この構成では）
バージョン管理がユーザの責務となるので、
GKE, ASM のアップグレード検討が必要

38. ②
①
GKE のアップグレード戦略の選択肢
可用性、コスト、リリース頻度など様々な指標に影響
e.g. Cloud DNS
1.20
Cluster Migration
Inplace
1.20
1.21
1.20
1.21
Blue/Green with Node pool
①
1.20
1.21
② 1.21
1.20
1.21
38

39. Cluster Migration の難しさ
アップグレード毎にクリーンな状態のクラスタを利用できる一方、
クラスタ内で完結するアップグレードより考慮事項が多い
- 例えば CI/CD パイプラインの移行、ステートフルワークロードの移行など、
アプリとインフラの構成によって影響は様々
- マルチテナントクラスタなら尚更。移行期間をある程度長く確保して
各アプリのタイミングで移行してもらう、と今度はコストの問題も出てくる
- マルチクラスタ構成をとり、クラスタ毎に順次アップグレードする手もあるが、
ある程度大規模でないと運用負荷に負けてしまうので初手には向いていない
39

40. GKE の強み
Kubernetes の Control Plane を運用する必要がない
- etcd を擁するステートフルなシステムとも言える Control Plane のアップグレード
に関して頭を悩ませる必要がない
- パッチバージョンは自動アップグレードで常に最新化される
セルフホスト Kubernetes の環境と比べて、Cluster Migration が
必要なケースは限定される
40

41. クラスタ内で完結するアップグレード戦略
Inplace と Blue/Green with Node pool のふたつの選択肢
- クラスタへのアクセスが継続的に確保できる Blue/Green with Node pool がおすすめ
- Inplace は GKE 任せになるため、アップグレード中は操作を受け付けない
41
②
①
Inplace
1.20
1.21
1.20
1.21
Blue/Green with Node pool
①
1.20
1.21
② 1.21
1.20

42. クラスタ内で完結するアップグレード戦略
Inplace と Blue/Green with Node pool のふたつの選択肢
- クラスタへのアクセスが継続的に確保できる Blue/Green with Node pool がおすすめ
- Inplace は GKE 任せになるため、アップグレード中は操作を受け付けない
42
Inplace
①
1.20
1.21
② 1.21
1.20

43. おすすめの GKE アップグレード戦略
まずは 「Blue/Green with Node pool を原則として、必要なときだけ
Cluster Migration を用いる」という戦略で始めてみては？
今回紹介している構成で Cluster Migration が必要になるケース
- クラスタの作成時にしか有効化できない新機能を導入したい
- やむを得ない理由で Control Plane をダウングレードしたい
- （クラスタの Control Plane の動作に問題があり、自動修復で回復しない）
43

44. GKE アップグレードの流れ (Blue/Green with Node pool)
(1) Control Plane のアップグレード
Data Plane のバージョンが Control Plane を超えることはできない
44
1.20
1.20
1.21
Ready Ready Ready
※ 説明の簡略化のため Node pool は
ひとつだけにしています

45. GKE アップグレードの流れ (Blue/Green with Node pool)
(2) 新しいバージョンの Node pool を追加
移行元の Node pool で展開されているワークロード以上のリソースが必要
45
1.20
1.21
1.21
Ready Ready Ready
Ready Ready Ready

46. GKE アップグレードの流れ (Blue/Green with Node pool)
(3) 移行元 Node pool の全 Node を Cordon
新規のワークロードが移行元 Node pool にデプロイされなくなる
46
1.21
1.21
Ready, SchedulingDisabled Ready Ready Ready
$ kubectl cordon ...
1.20

47. GKE アップグレードの流れ (Blue/Green with Node pool)
(4) 移行元 Node pool の Node を順次 Drain
移行元のワークロードが再スケジュールされ、新バージョンの Node pool へ
47
1.21
1.21
Ready, SchedulingDisabled Ready Ready Ready
$ kubectl drain ...
1.20

48. GKE アップグレードの流れ (Blue/Green with Node pool)
(4) 移行元 Node pool の Node を順次 Drain
移行元のワークロードが再スケジュールされ、新バージョンの Node pool へ
48
1.20
1.21
1.21
Ready, SchedulingDisabled Ready Ready Ready
$ kubectl drain ...

49. GKE アップグレードの流れ (Blue/Green with Node pool)
(4) 移行元 Node pool の Node を順次 Drain
移行元のワークロードが再スケジュールされ、新バージョンの Node pool へ
49
1.20
1.21
1.21
Ready Ready Ready
$ kubectl drain ...

50. GKE アップグレードの流れ (Blue/Green with Node pool)
(4) 移行元 Node pool の Node を順次 Drain
移行元のワークロードが再スケジュールされ、新バージョンの Node pool へ
50
1.20
1.21
1.21
Ready Ready Ready

51. GKE アップグレードの流れ (Blue/Green with Node pool)
(5) 古い Node pool を削除して完了
51
1.21
1.21
Ready Ready Ready

52. GKE アップグレードの流れ (Blue/Green with Node pool)
補足.1 Cordon せずに Drain してしまうと...
移行元 Node pool の別の Node にスケジュールされてしまう可能性がある
52
1.21
1.21
Ready Ready Ready
Ready Ready
$ kubectl drain ...
1.20

53. GKE アップグレードの流れ (Blue/Green with Node pool)
補足.2 新しいバージョンの Node の Ready を確認せず Drain すると...
クラスタオートスケーラーが有効な場合、移行元がスケールしてしまう可能性がある
53
1.21
1.21
Ready, SchedulingDisabled NotReady...
$ kubectl drain ...
1.20

54. Ready
GKE アップグレードの流れ (Blue/Green with Node pool)
補足.2 新しいバージョンの Node の Ready を確認せず Drain すると...
クラスタオートスケーラーが有効な場合、移行元がスケールしてしまう可能性がある
54
1.21
1.21
Ready, SchedulingDisabled NotReady...
$ kubectl drain ...
1.20

55. サービスの可用性維持
アップグレードにあたり、可用性に影響する各種設定は忘れずに
- Pod Disruption Budget
- Graceful な Pod の終了
- PreStop ライフサイクルフックによるアプリケーションの正常終了処理
- terminationGracePeriodSeconds の設定見直し
etc.
ワークアラウンドな手段として、Drain のオプションで待ち時間を指定することも可能
- kubectl drain --grace-period=xx (sec.)
55

56. 補足：Istiod と Drain の関係
Istiod がデプロイされている Node を手動で Drain するときは
--delete-local-data (~1.19) / --delete-emptydir-data (1.20+) オプションが必要
- ASM の Control Plane である Istiod が Local Storage を利用しているため
- Cluster Autoscaler や Node Auto-Provisioning が有効な環境では
Local Storage を利用する Pod がデプロイされた Node を自動終了できなかったが、
GKE 1.22+ では以下ラベルでの指定がない限り終了可能になる
- Pod -> cluster-autoscaler.kubernetes.io/safe-to-evict: “false”
- Node -> cluster-autoscaler.kubernetes.io/scale-down-disabled: “true”
56

57. 補足：Preemptible VM / Spot VM の利用
GKE 1.20+ では、Preemptible VM / Spot VM なノードの kubelet で
Graceful Node Shutdown がデフォルト有効になっている
- terminationGracePeriodSeconds は最大 25秒までしかリクエストできない
- コスト削減目的で開発環境だけ Preemptible VM / Spot VM を利用、といった場合は
Pod の終了に長時間を要するワークロードの可用性試験などに影響するので注意
- Evict された場合、Status が Failed となり、次回の Pod GC でクリーンアップされる
https://cloud.google.com/kubernetes-engine/docs/concepts/spot-vms#termination_and_graceful_shutdown_of

58. 補足：Graceful Node Shutdown
Kubelet がノードの終了を検出し、Pod を安全に終了させるための機能
- Kubernetes では 1.21 からベータに昇格した機能
- ノードの終了を検知すると、systemd-logind の inhibitor-locks を利用して
ShutdownGracePeriod の期間だけシャットダウンを遅らせる
- ShutdownGracePeriod の期間のうち、ShutdownGracePeriodCriticalPods で指定
した期間を CriticalPods (Priority Class が system-cluster-critical or system-node-critical の Pod)
の終了のために予約する
58
https://kubernetes.io/docs/concepts/architecture/nodes/#graceful-node-shutdown

59. 3
ASM のアップグレード戦略と
プラクティス

60. ASM (Control Plane) のアップグレード戦略
Istio のアップグレード戦略には Inplace と Canary が使えるが、
ASM の場合は原則 Canary になる
ASM
Control Plane
ASM
Control Plane
mTLS
Service A Service B
Envoy Envoy
Canary
Inplace
ASM
Control Plane
mTLS
Service A Service B
Envoy Envoy
1.10
1.11
1.10 1.11
60

61. ASM のアップグレードツール
install_asm
- 従来提供されてきた ASM のインストール・アップグレードを補助するスクリプト
- 後継となる asmcli の GA に伴い、サポート提供は ASM 1.11 まで
asmcli
- ASM のインストール・アップグレードに必須となる新しいコマンドラインツール
- 今後はインストール先のプラットフォーム (e.g. Anthos on AWS / VMware, ...) を問わず
asmcli で共通的なオペレーションが可能になる
61

62. 補足：install_asm から asmcli への移行
確認できている主な変更点
- 実行モード（インストール or アップグレード）の自動判別ができる
- デフォルトの Ingress gateway が自動挿入されなくなった
- 利用にあたりフリートの登録が必須になった
- リビジョンを指定したインストール・アップグレードが可能になった
- install_asm の頃はリビジョンがスクリプト内に直書きされており、ダウングレードなどで
特定バージョンの ASM をインストールしたい場合はスクリプトを改変する必要があった
62

63. Inplace
asmcli によるインストール/アップグレード
asmcli はターゲットとなるプラットフォームの状態に応じて
ASM のインストール方法を自動で切り替える
ASM
Control Plane
$ asmcli install -r asm-XXXX-X
1.10.4-asm.14
① check
Canary
② ? current ver. == asm-XXXX-X

64. ASM アップグレードの流れ
ASM 1.10 の環境を ASM 1.11 にアップグレードする場合を考える
ASM Control Plane
v1.10
mTLS
Service A Service B
Envoy Envoy
Namespace: istio-system
Namespace: tenant-B
Namespace: tenant-A

65. ASM アップグレードの流れ
ASM Control Plane
v1.10
mTLS
Service A Service B
Envoy Envoy
Namespace: istio-system
Namespace: tenant-B
Namespace: tenant-A
$ asmcli install -r asm-1112-17
ASM 1.11 をインストール
- この時点では既存の ASM Data Plane には影響しない

66. ASM アップグレードの流れ
ASM 1.11 をインストール
- この時点では既存の ASM Data Plane には影響しない
ASM Control Plane
v1.10
ASM Control Plane
v1.11
mTLS
Service A Service B
Envoy Envoy
Namespace: istio-system
Namespace: tenant-B
Namespace: tenant-A

67. ASM アップグレードの流れ
移行するテナントの Namespace のラベルを書き換え、Pod を再起動
- 図はテナント B が ASM 1.11 に移行した状態
ASM Control Plane
v1.10
ASM Control Plane
v1.11
mTLS
Service A Service B
Envoy Envoy
Namespace: istio-system
Namespace: tenant-B
Namespace: tenant-A

68. ASM アップグレードの流れ
すべての Data Plane を新バージョンの ASM に移行
ASM Control Plane
v1.10
ASM Control Plane
v1.11
mTLS
Service A Service B
Envoy Envoy
Namespace: istio-system
Namespace: tenant-B
Namespace: tenant-A

69. ASM アップグレードの流れ
旧バージョンの Control Plane を削除してアップグレード完了
ASM Control Plane
v1.11
mTLS
Service A Service B
Envoy Envoy
Namespace: istio-system
Namespace: tenant-B
Namespace: tenant-A

70. ASM アップグレード時のリソース消費
Canary Upgrade では一時的に倍のリソースが必要になることに注意
- ノードリソースや、ResourceQuota などに余裕がある状態で実施すること
ASM
Control Plane
ASM
Control Plane
1.10 1.11
70

71. Gateway のアップグレード戦略の選択肢
基本は Inplace で十分、より詳細に制御したい場合は Canary も検討
Canary
with external traffic shifting
Inplace Canary
Istio-Ingress
Istio-Ingress
1.10 1.10
Istio-
Ingress-
canary
Istio-Ingress
Istio-Ingress
1.11
1.10
canary
Istio-Ingress
1.11
1.10
Istio-
Ingress-
canary
1.10
1.11

72. Gateway リソースのアップグレード
ASM 1.11+ では、Gateway Injection によるアップグレードが可能
- Gateway 用の新たな Injection Template (inject.istio.io/templates=gateway) が提供される
- Gateway リソースを配置する Namespace に istio-proxy のリビジョンを指定したラベルを付与
- アプリケーションの Sidecar として istio-proxy を自動挿入するときと同様の仕組みで、
Admission Webhook によるアップグレードが可能になった
Ingress
Gateway
Egress
Gateway
Namespace: istio-gateway
Labels: istio.io/rev= asm-1104-14
→ asm-1112-17
edit
restart restart
https://istio.io/latest/docs/setup/additional-setup/gateway/
72

73. Gateway リソースの配置先 (ASM 1.11+)
ASM 1.11+ では Gateway リソースを Control Plane とは別の
Namespace に配置する構成がベストプラクティス
- ただし、ASM 1.10 までを install_asm でインストールしてきたユーザの多くは istio-system 内
で Control Plane と同居した構成になっているはず
- Gateway リソースを別の Namespace に移行する際は、各種関連リソースにも注意
- Network Policy, Service Entry, Virtual Service, ...
ASM
Control Plane
Ingress
Gateway
Namespace: istio-system Namespace: istio-gateway
Egress
Gateway
https://cloud.google.com/service-mesh/docs/gateways#best_practices_for_deploying_gateways

74. 本番の ASM をアップグレードする前に...
ツールや API バージョンの変更頻度が高いこともあり、
アップグレードするバージョン間の差分調査や影響確認の試験は
欠かさず実施することを推奨
- asmcli は install_asm と並行してサポート提供されるバージョンが ASM 1.11 のみ
となるため、1.11 のうちにツールの移行を推奨
- 直近では、GKE 1.22 の API 廃止に伴い、ASM としてはパッチバージョン間で
API バージョンが変更されたケースもある (ASM 1.10.3 -> 1.10.4)
74

75. 補足：asmcli 実行後の不要な権限の削除
75
asmcli (および install_asm) は実行ユーザに対して強力な権限を付与する
- 付与した権限は実行後も残るため、不要な権限は都度削除が必要
asmcli / install_asm が付与する権限を確認するには --verbose オプションを追加
- Kubernetes RBAC
- 対象の Google アカウントに対する cluster-admin の権限が残る
- Cloud IAM
- 対象の Google アカウントに対する Mesh Config Admin などの権限が残る

76. 補足：ASM Data Plane のアップグレード
Istio-proxy (Envoy) のアップグレードの流れは Istio と変わらず
- Namespace のラベル istio.io/rev のリビジョンを入れ替え、Pod を再起動
ASM Control Plane
v1.10
ASM Control Plane
v1.11
Service A
Envoy
Namespace: tenant-A
Labels: istio.io/rev=asm-110x-xx
76

77. 補足：ASM Data Plane のアップグレード
Istio-proxy (Envoy) のアップグレードの流れは Istio と変わらず
- Namespace のラベル istio.io/rev のリビジョンを入れ替え、Pod を再起動
ASM Control Plane
v1.10
ASM Control Plane
v1.11
Service A
Envoy
Namespace: tenant-A
Labels: istio.io/rev=asm-110x-xx
edit
77

78. 補足：ASM Data Plane のアップグレード
Istio-proxy (Envoy) のアップグレードの流れは Istio と変わらず
- Namespace のラベル istio.io/rev のリビジョンを入れ替え、Pod を再起動
ASM Control Plane
v1.10
ASM Control Plane
v1.11
Service A
Envoy
Namespace: tenant-A
Labels: istio.io/rev=asm-111x-xx
edit
78

79. 補足：ASM Data Plane のアップグレード
Istio-proxy (Envoy) のアップグレードの流れは Istio と変わらず
- Namespace のラベル istio.io/rev のリビジョンを入れ替え、Pod を再起動
ASM Control Plane
v1.10
ASM Control Plane
v1.11
Service A
Envoy
Namespace: tenant-A
Labels: istio.io/rev=asm-111x-xx
$ kubectl rollout restart ...
79

80. 補足：ASM Data Plane のアップグレード
Istio-proxy (Envoy) のアップグレードの流れは Istio と変わらず
- Namespace のラベルを入れ替え、Pod を再起動
ASM Control Plane
v1.10
ASM Control Plane
v1.11
Service A
Envoy
Namespace: tenant-A
Labels: istio.io/rev=asm-111x-xx
injecton
80

81. 4
おわりに

82. より大規模・複雑な環境
Anthos の各種サービスを活用することで、
より大規模・複雑な要件にも応えるアーキテクチャを構成できる
- マルチプラットフォーム環境の複数クラスタの統合管理
- 異なる GCP プロジェクトのマルチクラスタメッシュ構成
- etc...
先日の Google Cloud Next '21 でも Anthos 関連で多数のリリース
https://cloud.google.com/blog/ja/topics/hybrid-cloud/introducing-anthos-for-vms-and-other-app-modernization-tools
82

83. アーキテクチャや運用戦略の背景にあるもの
エンタープライズとひとくちに言ってもその事情は各社様々
- ハイブリッド or マルチクラウド環境
- マルチテナントの単一クラスタ or テナント別のマルチクラスタ
- 組織構造、運用体制
- etc...
条件が違えば、適したアーキテクチャ、運用戦略も変わってくる
83

84. エンタープライズ向けの Google Cloud 公式ユーザコミュニティ
- 参加企業 140+, 登録会員 600+
- NDA ベースで事例共有やディスカッション
- 分科会
- デジタル／クラウド人材育成分科会
- データ利活用分科会
- Cloud Native 分科会
エンタープライズにおける Cloud Native 技術の
活用など意見交換したい方、お待ちしています！
所属コミュニティ Jagu'e'r のご紹介
84
https://jaguer.jp

85. まとめ
GKE x ASM のエンタープライズ向け推奨構成を紹介
- GKE (Static) x ASM (In-cluster control plane)
- アップグレードは 3か月間隔で計画することを推奨
GKE のアップグレードは Blue/Green with Node pool を推奨
- クラスタ再作成の必要に応じて Cluster Migration と使い分け
ASM のアップグレードは原則 Canary Upgrade
- 今後は asmcli を使ったオペレーションが必須
- Gateway リソースのアップグレードは特に可用性の事前確認を十分に

86. Thank you for your attention !
本資料に記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です