[Innovators Live] GKE のアップグレード戦略を考える

Transcript

1. GKE のアップグレード戦略 を考える Google Cloud / 内間 和季 アプリケーション モダナイゼーション スペシャリスト
2. 自己紹介
3. 自己紹介 内間 和季 Google Cloud (@kkuchima) Application Modernization Specialist, Customer Engineer 好きな Google Cloud プロダクト： • Google Kubernetes Engine (GKE) • Cloud Run • Anthos Service Mesh
4. 01 03 02 04 GKE の安全なアップグレードを実現するための機能 GKE のアップグレード戦略を考える まとめ Kubernetes アップグレードの課題と概要
5. Kubernetes アップグレードの 課題と概要
6. Kubernetes アップグレードにおける課題 Kubernetes / GKE では脆弱性の対応や既知問題の修正、新機能の導入のた めにアップデートを頻繁にリリースしている 一般的に Kubernetes クラスタのアップグレード作業はタスクが多く 運用負荷 が高い • アップデート内容や影響範囲の特定 • アプリケーション マニフェスト・エコシステムのアップデート • クラスタのアップグレード (各環境ごとに実施) • アプリケーションの動作確認、など 無理なく継続的にアップグレードを行っていくためには、 自動化された仕組み が求められる
7. Google Kubernetes Engine (GKE) Kubernetes 運用のベスト プラクティスを、マネージド サービスとしてご提供 コントロール プレーンの 構築 & 管理 可用性・信頼性 エンジニアリング パッチ管理 & アップグレード セキュリティ & ネットワーク 各種設定 アプリケーション プラットフォーム モニタリング スケーリング DIY Kubernetes ワーカーノード 構築 & 管理 Standard モード 設定の柔軟性を兼ね備えた マネージド Kubernetes Autopilot モード より運用負荷が軽減されるよう 最適化されたマネージド Kubernetes セキュリティ & ネットワーク 各種設定 ワーカーノード 構築 & 運用 Google Kubernetes Engine (GKE) モダンなアプリケー ションプラットフォー ム Modern application platform
8. GKE のアーキテクチャ API Server User Pod Containers Nodes Control plane GKE Standard クラスタ Google 管理 GKE が構築、Google、お客様で管理 User Pod Containers User Pod Containers Scheduler Storage Resource Controllers User Pod Containers API Server User Pod Containers GKE Autopilot クラスタ User Pod Containers User Pod Containers Nodes Control plane Scheduler Storage Resource Controllers User Pod Containers GKE はクラスタという単位で管理され、 1 つの GKE クラスタは Control Plane と Node というコンポーネントから 構成される Node は Node Pool という単位で グルーピングされ管理される
9. GKE のバージョン体系 1.27.8-gke.1067004 Kubernetes マイナーバージョン Kubernetes パッチリリース GKE パッチリリース
10. 一般的な GKE アップグレードの流れ 変更・影響範囲 の把握 開発環境の Control Plane （システム コンポーネント含む） のアップグレード 開発環境の Node の アップグレード (必要に応じて) マニフェストの アップデート 開発環境 アプリケーションの 動作確認 本番環境の Control Plane （システム コンポーネント含む） のアップグレード 本番環境の Node の アップグレード 本番環境 アプリケーションの 動作確認 新バージョンの検知 *1 … 環境が他にもある場合は環境の分実施 *1
11. 本セッションでのフォーカスポイント 変更・影響範囲 の把握 開発環境の Control Plane （システム コンポーネント含む） のアップグレード 開発環境の Nodes の アップグレード (必要に応じて) マニフェストの アップデート 開発環境 アプリケーションの 動作確認 本番環境の Control Plane （システム コンポーネント含む） のアップグレード 本番環境の Nodes の アップグレード 本番環境 アプリケーションの 動作確認 新バージョンの検知 *1 … 環境が他にもある場合は環境の分実施 *1 ①変更内容・影響範囲の把握 ②クラスタの安全なアップグレード ②クラスタの安全なアップグレード ③アップグレード タイミング 　の制御
12. GKE の安全なアップグレードを 実現するための機能
13. クラスタのアップグレード / 脆弱性情報の自動通知 任意の Pub/Sub トピックに対し、 アップグレードや脆弱性に関する通知メッセージを送信 • SecurityBulletinEvent クラスタに影響のある脆弱性情報を通知 • UpgradeAvailableEvent 新バージョンが利用可能になった時に通知 マイナー バージョン: 2 - 4 週間前 パッチ バージョン: 1 週間前 • UpgradeEvent アップグレードが開始されると通知 （自動、手動問わず） ①変更内容・影響範囲の把握 https://cloud.google.com/kubernetes-engine/docs/concepts/cluster-notifications#notification-types
14. 変更内容の確認 GKE アップグレードによる変更内容 / 影響は リリースノートで確認することが可能 脆弱性情報は Security bulletins に集約されている ※日本語訳のタイムラグがあるため Security bulletins は言語を「English」に変更すること を推奨 リリースノート https://cloud.google.com/kubernetes-engine/docs/release-notes Security bulletins https://cloud.google.com/anthos/clusters/docs/security-bulletins ①変更内容・影響範囲の把握
15. 非推奨 API / 構成の自動検出 今後のマイナー バージョンで削除される Kubernetes API や構成がクラスタで使用されてい ることを自動的に検出し通知する機能 削除予定の API / 構成の利用が検出されると、 GKE の自動アップグレードが一時停止されるた め、自動アップグレードによる互換性の問題を回避 可能（手動でのアップグレードは可能） ①変更内容・影響範囲の把握
16. 非推奨 API の移行 Kubernetes API Deprecation の詳細は公式ドキュメント *1 から 確認可能 自動検出機能で検知できないケースも考慮し、 Pluto*2 など OSS ツールを活用することも検討 マニフェストは kubectl-convert*3 により機械的にアップデート することもできる $ kubectl-convert -f pod.yaml \ --output-version apps/v1 ①変更内容・影響範囲の把握 *1 https://cloud.google.com/kubernetes-engine/docs/deprecations?hl=ja *2 https://github.com/FairwindsOps/pluto *3 https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-kubectl-convert-plugin
17. GKE クラスタのアップグレード GKE では Control Plane を Google が管理しており、自動的にパッチ適用・アップグレードされるが Node に ついては自動もしくは手動でのアップグレードを選択可能 (Autopilot は自動のみ) 1. リリースチャンネルを指定したクラスタ ◦ Control Plane: 自動 ◦ Node: 自動 ◦ GKE Autopilot はリリースチャンネルに登録される 2. 静的にバージョンを指定したクラスタ ◦ Control Plane: 自動 ◦ Node: 自動 or 手動 ②クラスタの安全なアップグレード
18. リリース チャンネル バージョニングとアップグレードを行う際のベスト プラクティスを提供する仕組み リリース チャンネルに新しいクラスタを登録すると、 Google により Control Plane と Node のバージョンとアップグレード サイクルが自動的に管理される 利用できる機能と更新頻度の異なる、以下 3 つのチャンネルがある - Rapid … 最新のバージョンが利用可能。検証目的での利用を推奨 (SLA 対象外) - Regular … 機能の可用性とリリースの安定性のバランス - Stable … 新機能よりも安定性を優先する場合 Regular Stable Rapid ②クラスタの安全なアップグレード
19. ノードプールのアップグレード方式 ノードプールのアップグレードは以下 2 種類から方式を選択する 1. サージ アップグレード ◦ ノードを順次新しいバージョンにローリング アップデートする (デフォルト) 2. Blue / Green アップグレード ◦ 新旧 2 つのバージョンのノードを保持したままアップグレードを行う Autopilot の場合はサージ アップグレードのみ利用可能 ②クラスタの安全なアップグレード
20. サージ アップグレード 新しいバージョンの Node を追加し、 ローリング方式でアップグレードする方式 Blue / Green に比べて、アップグレード時の追 加リソースを少なく構成することが可能 max-surge-upgrade*1 や max-unavailable-upgrade*2 パラメータを設定 することにより、アップグレードの 同時実行数などを調整することもできる Pod A Pod B 1. 2. 3. 新しいバージョンの Node を作成 古いバージョンの Node を Drain し、新しい Node 上に Pod を移行 Pod B Pod A maxSurge*1=1, maxUnavailable*2=0 古いバージョンの Node を削除 ※以降、これを繰り返す Pod B Pod A *1 … アップグレード中に追加可能な Node 数 *2 … アップグレード中に使用不可になる Node 数 ②クラスタの安全なアップグレード
21. Blue / Green アップグレード Node レベル Blue / Green アップグレードの 一連の手順を自動的に実行 サージ アップグレードに比べて、問題発生時 のロールバックを迅速に行うことができる 一時的にノード数が 2 倍になるため、Quota 含め充分なリソースが確保できているか事 前に確認が必要 Pod A Pod B 既存のプール (MIG) に cordon を設定 Pod が新しいプール上 で正常に動作しているこ とを確認 2. 3. 5. SOAK_DURATION*2 で定義した時間経過 後、既存のプールを 削除 新バージョンの プール (MIG*1) を作成 既存プール (MIG) に drain を実施 1. Pod A Pod A Pod B 4. *1 MIG .. Managed Instance Group *2 デフォルト 1 時間 (3,600 秒)、最大 7 日間 (604,800 秒) ②クラスタの安全なアップグレード
22. メンテナンスの時間枠と除外 • メンテナンスの時間枠 自動メンテナンスを許可する時間枠 ◦ 32 日周期で最低 48 時間必要 ◦ 各時間枠は 4 時間以上連続した時間 • メンテナンスの除外 自動メンテナンスを禁止する時間枠 ◦ 詳細は後続資料で説明 使い方の例: • 週末を避ける • 大型セールやイベント期間中を避ける • 一時的にアップグレードを延期する ③アップグレード タイミングの制御
23. メンテナンスの除外設定 メンテナンスの除外設定により自動アップグレードを禁止する期間をコントロール • 完全にアップグレードを止める場合 (No upgrades) はメンテナンス除外期間を 最大 30 日間*1まで設定 可能 • Control Plane や Node のマイナーバージョンアップグレードを止める *2場合 (No minor upgrades / No minor or node upgrades) はメンテナンス除外期間を 最大 180 日間*1まで設定可能 *1 マイナーバージョンの EOL を超過することはできない *2 リリースチャンネルを利用しているクラスタが対象 ③アップグレード タイミングの制御
24. Rollout Sequencing ③アップグレード タイミングの制御 クラスタ間のアップグレード順序を制御する機能 アップグレードするクラスタを環境毎にグルーピングし依存関係を持たせることで 段階的な自動アップグレードをすることが可能に（例：開発環境 →ステージング環境→本番環境）
25. GKE のアップグレード戦略を考える
26. GKE アップグレード方式 In-place • サージ アップグレードによる Node 単位でのローリング アッ プデート • アップグレード時間とコストを抑 えたいケース ノードプール Blue / Green • 新 ver. Node の正常稼働を確認 するまで、旧 ver. Node を保持 • Node アップグレード問題発生時 の切り戻しを迅速に行いたいケー ス クラスタ Blue / Green • 新バージョンのクラスタを作成しト ラフィックを切替 • CP レベルでの戻し行いたいなど、 アップグレードのリスクを可能な限 り抑えたいケース 旧バージョン 新バージョン
27. • 大量のクラスタを運用するケースや GKE Autopilot を利用してい るケースなど • ノードのアップグレード方式として サージ アップグレードを選択 • Rollout Sequencing を活用しクラスタ間の依存関係を設定する ことで、複数クラスタのアップグレードを自動化し運用負荷の低減 を実現 • 他のアップグレード方式と比べて アップグレード時間が短く かかる コストが小さいが、ロールバックに時間がかかる In-place アップグレード
28. • 安定性とコストのバランスがとれた方式 • GKE Standard を利用しているケース • ノードのアップグレード方式として Blue / Green アップグレード を選択 ◦ 手動で新規ノードプールを作成しワークロードを移行す る方法も • ノード アップグレードによる問題発生時に 迅速なロールバック が可能だが、一時的にノードプール内に倍のノードが作成され るため In-Place に比べてコストが高くアップグレードにかかる 時間も長い ノードプール Blue / Green アップグレード
29. • コントロールプレーンも含めたロールバックや Canary アップグ レードの実現など最も 安全面に倒した方式（但し最も高コストで 複雑） • 複数クラスタ間のトラフィックを Multi-cluster Gateway 等で制 御し、重みづけやヘッダベースのトラフィック制御を実現 • クラスタ新規作成時にしか変更できないパラメータの変更 やマ イナー バージョンをスキップで上げたい 場合にも ◦ メンテナンス除外を駆使し可能な限りアップグレードを止 めておき、アップグレードが必要なタイミングで新規クラ スタにマイグレーションするケース、など クラスタ Blue / Green アップグレード Load Balancer 新バージョン のクラスタに数%の トラフィックを流す
30. • リリース チャンネルに登録する ◦ メンテナンス除外設定の恩恵 (最大 180 日のアップグレード停止 ) を受けることができる ◦ Stable を選択することで Static (No) Channel 相当の運用をすることも可能 • クラスタの可用性タイプはゾーンではなく リージョンを選択 ◦ Control Plane が複数台構成となり、アップグレード時も継続して K8s API へアクセスできるように • 用途や要件に応じてノードプールを分割 する ◦ 要件に合わせてアップグレード タイミングやノード アップグレード方式を制御可能に • メンテナンス ウィンドウはアップグレードの影響が少ない時間帯に設定 • アプリケーションがアップグレード中に中断しないように Pod Disruption Budget (PDB) や terminationGracePeriodSeconds 等を適切に設定 その他アップグレード関連のおすすめ設定
31. メンテナンス時のワークロードの可用性を保持するための各種設定 Readiness / Liveness probe Pod disruption budget （PDB, Pod 停止予算） Affinity / Anti-Affinity PreStop hook & terminationGracePeriodSe conds kubelet は Probe を使用して、 ポッドの実行、クラッシュ時 の再起動、修復を行います メンテナンス中でも最低限必要と なるレプリカの数を指定し、保護 できます。PDB が構成されると、 Kubernetes はポリシーに沿って ノードをドレインします Pod の Affinity ルールと Anti-Affinity ルールを使用し、 レプリカの配置を制御できます。 例えばノード損失による停止は Pod Anti-Affinity で回避します やむを得ず Pod が停止する場合に も、プロセスがリソースを安全に解 放し、重要なデータを残すためには これらを使います
32. まとめ
33. • GKE ではアップグレード作業を無理なく継続するための各種自動化機能を提供 • アップグレードに求められる要件（ロールバックの粒度や速度、運用コストなど）に応じて、適切なアッ プグレード戦略を選択しましょう • クラスタのアップグレード作業と上手く付き合っていき Happy な GKE ライフを！ まとめ
34. Thank you. Proprietary + Confidential