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

by polar3130

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

前置き本資料中の 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+conﬁg2 ※ ASM : Anthos Service Mesh ※ 基本 In-cluster Control Plane の ASM の話ですが、所々で Managed ASM にも言及しています

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

エンタープライズにおける 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)

Slide 16

Slide 16 text

✔ 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

Slide 17

Slide 17 text

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 Conﬁg to Envoys User’s Cluster

Slide 18

Slide 18 text

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 Conﬁg to Envoys User’s Cluster Data Plane ※ managed Data Plane は割愛

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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 のアップグレード検討が必要

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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 とは独立したサポート期間が設定されている

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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 バージョンを加味して構成を選択する

Slide 27

Slide 27 text

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 か月周期にアップグレードする例を考える

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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 本番運用の間、新規クラスタが作れる状態を維持しようとすると...

Slide 31

Slide 31 text

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 もうひとつ先のバージョンへのアップグレードが必要になる場合も

Slide 32

Slide 32 text

通常の（直上バージョンへの）アップグレードを 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 ① ② ③ ④ ⑤ ⑥

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

補足：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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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 のアップグレード検討が必要

Slide 38

Slide 38 text

② ① 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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

クラスタ内で完結するアップグレード戦略 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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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 はひとつだけにしています

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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 ...

Slide 49

Slide 49 text

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 ...

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

補足：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

Slide 57

Slide 57 text

補足：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

Slide 58

Slide 58 text

補足：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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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 には影響しない

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

Gateway のアップグレード戦略の選択肢基本は Inplace で十分、より詳細に制御したい場合は Canary も検討 Canary with external traﬃc 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

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

補足：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

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Slide 80

Slide 80 text

補足：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

Slide 81

Slide 81 text

4 おわりに

Slide 82

Slide 82 text

より大規模・複雑な環境 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

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

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

Slide 85

Slide 85 text

まとめ 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 リソースのアップグレードは特に可用性の事前確認を十分に

Slide 86

Slide 86 text

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