Kubernetesクラスタ設計・運用実践ガイド

第10章：アップグレード戦略

Kubernetes は継続的に更新され、アップグレードは避けられません。
本章では、Version Skew（互換性）を前提に、アップグレードを「例外作業」ではなく「定常の変更管理」として実施するための論点を整理します。

学習目標

  • アップグレード対象（Kubernetes 本体/ノード/アドオン/CRD）を棚卸しできる
  • Version Skew Policy を踏まえて、実施順序と互換性チェックを組み立てられる
  • ロールバック可否と中断条件を定義し、復旧（バックアップ/リストア）と接続できる
  • 検証（staging/canary/smoke test）を計画に組み込める

扱う範囲 / 扱わない範囲

扱う範囲

  • リリースノート/非互換の読み方（API 廃止、挙動変更）
  • 互換性（Version Skew）を踏まえた計画、順序、検証
  • アドオン（CNI/CSI/DNS/Ingress 等）の互換性管理
  • ロールバック/復旧計画（責任範囲、バックアップ、演習）
  • 変更管理（承認、周知、証跡）の標準化

扱わない範囲

  • ベンダ/ディストリビューション固有の手順書（EKS/GKE/AKS、kubeadm 等）の詳細
  • すべてのアドオンの互換性表の網羅

アップグレードは「棚卸し」から始める

Kubernetes 本体だけ上げても、周辺（アドオン/CRD）で非互換が起きます。最低限、以下を棚卸しします。

  • Control Plane（マネージドの場合はプロバイダが管理する範囲）
  • Node（kubelet、ランタイム、OS）
  • 基盤アドオン（CNI/CSI/CoreDNS/Ingress Controller、監視/ログ基盤）
  • CRD/Admission（Gatekeeper/Kyverno 等）、Webhook
  • クラスタ運用ジョブ（バックアップ、証明書更新、定常点検）

Version Skew（互換性）の前提

互換性は Kubernetes の Version Skew Policy に従って設計します。
本書では数値を固定せず、公式ポリシーを一次情報として参照してください。

実施順序（一般論）

詳細は環境に依存しますが、一般的には次の順序で「影響の大きいものから」段階的に実施します。

  1. 事前準備（変更凍結、バックアップ、関係者周知、検証計画）
  2. Control Plane（HA の場合は段階的に）
  3. Node（ノードプール単位でロール）
  4. アドオン（互換性が前提。事前/事後どちらが適切かはアドオン設計に依存）
  5. 事後検証（smoke test、監視/ログ、SLO 影響の確認）

関連: 事前確認の最小チェックリストは 付録A：運用チェックリストPack（アップグレード前チェックリスト） を参照してください。

ロールバック/中断条件

ロールバックは「可能かどうか」が環境で大きく異なります。

  • マネージドでは Control Plane のロールバックが提供されない場合があります（代替として復旧手段/移行手段を定義）。
  • 自前運用では etcd バックアップ/リストアが根幹になります（第3章の運用と接続）。

中断条件（例）:

  • API 到達性やレイテンシが許容範囲を超え、復旧できない
  • 主要ワークロードの稼働率が SLO を逸脱し継続する
  • アドオン互換の問題で、回避策が一時的にしか成立しない

検証（staging/canary/smoke test）

検証は「変更の安全性」を担保する工程です。

  • staging: 本番相当の構成で事前検証（可能なら）
  • canary: ノードプール/テナントを限定して段階適用
  • smoke test: API、DNS、Ingress、ストレージ、代表ワークロードの最小疎通

検証項目は 付録A：運用チェックリストPack（変更時チェックリスト）へ落とし込み、毎回同じ形式で実施できるようにします。

運用物テンプレ：アップグレード実施計画（雛形）

アップグレードを「属人作業」にしないために、毎回同じフォーマットで計画/記録します。
詳細なチェック観点は 付録A：運用チェックリストPack（アップグレード前チェックリスト） をベースにしてください。

事前確認（例）

  • 対象範囲の棚卸し（Control Plane/Node/アドオン/CRD/Webhook）
  • Version Skew の確認（公式ポリシー、クライアント互換）
  • 非互換（API 廃止、挙動変更）の確認（リリースノート、利用 API の棚卸し）
  • アドオン互換（CNI/CSI/DNS/Ingress、監視/ログ基盤）
  • 事前バックアップ（成功の証跡、リストア手順の確認）
  • 変更凍結の合意（期間、例外手続き）

検証観点（例）

  • smoke test（API/DNS/Ingress/ストレージ/代表ワークロード）
  • SLO 影響（エラーレート/レイテンシ/可用性の許容範囲）を 第9章 と接続して定義
  • 監視の欠測がない（メトリクス/ログ/アラートが機能している）

中断条件/ロールバック（例）

  • 何をもって「中断」と判断するか（SLO 逸脱の継続、主要機能の停止、復旧見込み）
  • ロールバック可否（Control Plane/Node/アドオン/CRD の戻し方、戻せない場合の代替策）
  • 判断責任者（誰が最終判断するか）と、エスカレーション経路

周知/証跡（例）

  • 変更ID（チケット）/承認者/実施者/実施日時（開始・終了）
  • 影響評価（顧客影響、テナント影響、データ影響）
  • 実施ログ（コマンド/変更差分/設定、リンク先）
  • 検証結果（合否、観測した指標、発生した事象と対応）
  • 事後レビュー（ポストモーテム/改善バックログ、次回への反映）

実務チェック観点（最低5項目）

  • アップグレード対象の棚卸し（アドオン/CRD/Webhook 含む）と責任範囲が明確である
  • Version Skew を一次情報（公式ポリシー）で確認し、互換性チェックが計画に含まれている
  • 事前バックアップと復旧手順（演習含む）が整備され、ロールバック可否が明文化されている
  • 段階適用（canary）と事後検証（smoke test、監視/ログ確認）が標準化されている
  • 変更管理（承認、周知、証跡、変更凍結、中断条件）が運用されている

よくある落とし穴

  • Kubernetes 本体だけを対象として計画し、アドオン/CRD の互換性で停止する
  • ロールバック不可の環境で代替手段（復旧/移行/中断判断）を用意せず、変更が長期化する

まとめ / 次に読む

Edit this page on GitHub