Anthos を使ったエンタープライズ向けクラスタの設計とアップグレード戦略のススメ / Design and operations of GKE and Anthos Service Mesh for enterprises

CloudNative Days Tokyo 2021 ( CNDT2021 )
Day 1, Track D「Anthos を使ったエンタープライズ向けクラスタの設計とアップグレード戦略のススメ」のスライド資料です

GKE + Anthos Service Mesh の設計・運用をしてきた経験から、エンタープライズ向けの推奨構成やアップグレードについてご紹介しています

Transcript

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 ! 本資料に記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です