Kubernetesのアップグレード（パート2）：成功するための技術ガイド

Introduction

Kubernetesのアップグレードは、しばしば時間がかかり、リスクの高いプロジェクトに発展し、プラットフォームチームやDevOpsチームに大きな負担をかけます。この技術ガイドでは、アップグレードの自動化と効率化を進めるためのステップバイステップのフレームワークを提供し、リスクを最小限に抑え、AWS EKS、Azure AKS、Google GKE環境での運用効率を向上させる方法を紹介します。

この技術ガイドは、「Kubernetesアップグレードの戦略ガイド」を基にしています。戦略ガイドが組織の変革とビジネス価値に焦点を当てているのに対し、この記事では、プラットフォームチームがEKS、AKS、GKEで効率的にアップグレードを運用できるように、実践的なフレームワーク、ツール、ベストプラクティスを提供します。

このガイドは、プラットフォームエンジニア、SRE、DevOpsチーム、Kubernetes運用担当者など、実際にアップグレードを担うすべての技術者を対象としています。

また本ガイドは、ITマネージャーや部門リーダーにも、Kubernetesのアップグレードがいかに複雑でチームに負荷がかかるかを理解していただくための内容にもなっています。現場チームを支援するためにも、ぜひ目を通してください。

Kubernetesアップグレードを定常運用にするためのツール

成功するKubernetesアップグレード戦略は、適切なツールキットから始まります。以下は、アップグレードを手動のプロジェクトから自動化された繰り返し可能な運用に変えるために不可欠なツールです。

エンタープライズクラスのKubernetesアップグレード用ツールカテゴリ

個々のツールは重要ですが、エンタープライズグレードのKubernetesアップグレード戦略を構築するためには、観測性、オートメーション、テスト、セキュリティなどの広範なツールチェーンも必要です。

インテグレーションおよびワークフロー用ツール

1. GitOpsツール（ArgoCD/Flux）

Gitリポジトリで宣言的な構成を管理
アプリケーションとインフラのデプロイを自動化
アップグレードのためのプログレッシブデリバリーパターンをサポート

2. CI/CDパイプライン（Jenkins/GitHub Actions/GitLab CI）

クラスターの変更のテストと検証を自動化
承認ワークフローとの統合
変更と承認の監査トレイルを作成

なぜインフラストラクチャー・アズ・コード（IaC）がアップグレードにとって重要か

インフラストラクチャー・アズ・コード（IaC）は、信頼性の高いKubernetesアップグレード戦略の基盤を形成します。インフラをコードで定義することにより、以下を実現できます：

すべてのクラスター構成のバージョン履歴
環境の作成および更新のための繰り返し可能なプロセス
プルリクエストやコードレビューを通じて確認できる変更
本番環境に適用する前のテスト機会

EKS用Terraform実装

インフラストラクチャー・アズ・コード（IaC）を使用することで、一貫性があり、監査可能なKubernetesクラスター管理アプローチを実現できます。以下は、EKS用にTerraformを使用してこれを実装する方法の一例です：

# EKS cluster configuration with managed node groups
module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  cluster_name    = "my-cluster"
  cluster_version = "1.30"  # Target version
  
  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  # Managed node group with update configuration
  eks_managed_node_groups = {
    primary = {
      name = "primary-node-group"
      instance_types = ["m5.large"]
      min_size     = 2
      max_size     = 10
      desired_size = 3
      
      # Control maximum unavailable nodes during upgrades
      update_config = {
        max_unavailable_percentage = 25
      }
      
      ami_type = "AL2023_x86_64_STANDARD"
      labels = { Environment = "production" }
    }
  }
  
  # Keep add-ons current
  cluster_addons = {
    coredns = { most_recent = true }
    kube-proxy = { most_recent = true }
    vpc-cni = { most_recent = true }
  }
}

各クラウドプロバイダーは、Kubernetesの管理に関して独自のアプローチを採用しています。

IaC（Infrastructure as Code）ベストプラクティス

確なバージョン指定 - 常に正確なKubernetesバージョンを指定すること
モジュールの活用 - コミュニティのモジュールを活用し、スクラッチから作成するのではなく利用する
関心ごとの分離 - 異なるコンポーネントごとに異なるTerraformモジュールを使用する
状態管理 - 適切なロックを使用してリモート状態を管理する
CI/CD統合 - パイプライン内での計画（plan）と適用（apply）を自動化する

ゼロダウンタイムアップグレード戦略

アップグレードに関する技術的なアプローチは、リスク軽減と運用効率のバランスを取る必要があります。以下は考慮すべき重要なパターンです：

1. Canaryデプロイメント（EKSに最適）

Canary deployment for Kubernetes upgrades diagram

このアプローチでは、既存のノードグループを維持しながら、アップグレードされたKubernetesバージョンを使用する新しいノードグループを作成します。EKSにおいては、ノードグループがCanaryテストのための自然な境界を提供するため、非常に効果的です。

実装手順:

ターゲットKubernetesバージョンで新しいノードグループを作成
特定のワークロードを新しいノードグループにターゲット
Prometheusとログを使用して、新しいノード上でアプリケーションの健全性を監視
Canaryトラフィックを段階的に増加させ、Canaryノードグループをスケールアップし、古いノードグループをスケールダウン
検証が成功したら、移行を完了

2. Blue/Green クラスター展開

規制の厳しい環境や大きなバージョンアップが必要な場合に最適なアプローチです。完全に新しいクラスターを作成し、旧クラスターのトラフィックを新クラスターに切り替えます。

実装手順:

ターゲットKubernetesバージョンで新しいクラスターを作成
Veleroを使用して旧クラスターからリソースのバックアップを作成
新しいクラスターにワークロードを復元
機能を徹底的に検証
DNSやロードバランサー設定を更新してトラフィックを新しいクラスターに切り替え
トラフィックが正常に移行されたら旧クラスターを廃止

このアプローチは、既存のインフラをそのままアップグレードするリスクを排除しますが、その分、追加のインフラストラクチャと調整の複雑さが伴います。

3. Pod Disruption Budgets（PDB）を使用したローリングアップデート

どのクラウドプロバイダーでも、管理されたノードグループでのアップグレード時にPod Disruption Budgets（PDB）は重要です。PDBを利用して、アップグレード中のワークロードの可用性を管理します。

# Example PDB ensuring 70% minimum availability
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: app-pdb
spec:
  minAvailable: 70%
  selector:
    matchLabels:
      app: critical-service

PDB（Pod Disruption Budgets）を適切なノードグループ設定と組み合わせることで、アップグレード中に十分な数のポッドが稼働し続け、サービスの継続性が保たれます。

ノードグループ設定での実装方法は以下の通りです：

EKS：update_config.max_unavailable_percentage をノードグループ設定で使用
AKS：max_surge をノードプール設定で使用
GKE：upgrade_settings.max_surge と upgrade_settings.max_unavailable を設定

自動化された検証フレームワーク

堅牢なテストフレームワークは、「運任せ」のアップグレードを自信を持った検証済みのプロセスに変えます。

アップグレード前の検証

アップグレードを開始する前に、以下の検証を実施します：

1. API 互換性チェック

# Use Pluto to identify deprecated APIs
pluto detect-all-in-cluster -o wide

# Look specifically for critical workloads
kubectl get deployments,statefulsets -A -o yaml | pluto detect -

2. セキュリティ検証:

# Run kube-bench against CIS benchmarks
kube-bench --benchmark cis-1.6

3. クラスター健康状態の評価:

# Check control plane component health
kubectl get componentstatuses

# Verify all nodes are ready
kubectl get nodes

# Check for pending or failed pods
kubectl get pods --all-namespaces | grep -v Running

4. アプリケーションの準備状態:

# Ensure PDBs exist for critical workloads
kubectl get pdb --all-namespaces

# Verify horizontal pod autoscalers
kubectl get hpa --all-namespaces

アップグレード後の検証

アップグレードが完了したら、包括的な検証を実施します：

1. Kubernetes APIの動作確認

# Test creating temporary resources
kubectl run test-pod --image=busybox -- sleep 300
kubectl expose pod test-pod --port=80 --target-port=8080

2. ストレージの検証

# Test persistent volume provisioning
kubectl apply -f test-pvc.yaml
kubectl get pvc

3. アプリケーションテスト

# Verify all deployments are available
kubectl get deployments --all-namespaces

# Check statefulsets
kubectl get statefulsets --all-namespaces

# Run application-specific health checks
./run-app-tests.sh

4. スモークテスト

Kubernetesのコアリソースやアプリケーションの健全性を検証した後は、実際の使用パターンをシミュレートするスモークテストを実行することが重要です。

スモークテストは、以下のような隠れた問題を早期に発見するのに役立ちます：

ネットワークの設定ミス
レイテンシーの急増
予期しないサービスエラー
アプリケーションの準備状態に関する回帰

K6を使ったスモークテストの例:

k6 run smoke-test.js

ヒント：Kubernetes環境での負荷テストやストレステストにK6を活用するための、次回の包括的なガイドをお見逃しなく！

バージョン管理

Kubernetesのバージョン互換性を管理することは、スムーズなアップグレードと運用リスクの最小化にとって重要です。このセクションでは、コントロールプレーン、ノードグループ、ワークロード全体にわたるバージョン互換性を扱うための完全なフレームワークを提供します。

1. 互換性マトリクス

Kubernetes関連のコンポーネント（サービスメッシュ、監視ツール、証明書マネージャなど）は、Kubernetesのリリースに関連した厳格なバージョン要件を持っていることがよくあります。

以下は、Kubernetes 1.30における一般的なコンポーネントの互換性マトリクスの一例です：

Before upgrading, ensure all critical workloads are compatible with the target Kubernetes version.

2. バージョンのずれを管理

各クラウドプロバイダーは、コントロールプレーンとワーカーノードのバージョン間で許容される差を定めています。

ノードのバージョンスキュー（バージョン不一致）を確認するコマンド：

kubectl get nodes -o custom-columns=NAME:.metadata.name,VERSION:.status.nodeInfo.kubeletVersion | sort -k2

3. 最大バージョンスキュー制限

クラスタ管理で遵守すべきシンプルなポリシーとして、以下を強制することが重要です：

EKS: コントロールプレーンが1.30 → ノードは1.28、1.29、または1.30でなければならない。
GKE: コントロールプレーンが1.30 → ノードは1.28、1.29、または1.30でなければならない。
AKS: コントロールプレーンが1.30 → ノードは1.29または1.30（1バージョンのみ）。

許容されるスキュー（バージョンのずれ）を超えると、クラスタ機能が破損したり、アップグレードがブロックされる可能性があります。

4. サポート終了日（EOL）の確認

各Kubernetesのマイナーバージョンのサポートライフサイクルを把握しておくことが重要です。EOLの期限を前もって把握することで、強制アップグレードや延長サポート料金、セキュリティリスクを避けることができます。

Amazon EKS: Kubernetes 1.30の標準サポートは2025年7月に終了します。
Azure AKS: Kubernetes 1.30の標準サポートは2025年7月に終了します。
Google GKE: Kubernetes 1.30の安定チャネルサポートは2025年7月に終了します。

ヒント: EOLの3～6ヶ月前にはアップグレードを計画して、急な移行や延長サポート料金を避けましょう。

5. CNIプラグインとネットワーキングの互換性

Kubernetesのアップグレード時にはネットワーキングコンポーネントが重要です。CNIプラグインが新しいKubernetesバージョンと互換性があるか確認する必要があります：

Amazon EKS: コントロールプレーンのアップグレード後にvpc-cniプラグインをアップグレードします。 aws eks describe-addon-versions --addon-name vpc-cni コマンドで互換性を確認できます。
Azure AKS: ノードプールの自動アップグレードの一環としてAzure CNIをアップグレードします。
Google GKE: GKEはCNIを自動で管理しますが、カスタムCNIプラグインを使用している場合は手動での確認が推奨されます。 CNIバージョンを確認し、ノードプールのアップグレードの前または直後にアップグレードしてください。

一般的なアップグレードの問題のトラブルシューティング

慎重に計画を立てた場合でも、Kubernetesのアップグレードには運用上の課題が発生することがあります。以下は、最も一般的なクラスタ固有の問題、原因、推奨される解決策、および迅速に解決するためのコマンドのガイドです。

クラスタ内で発生する一般的なアップグレードの問題

これらは、特にEKS、AKS、GKEのマネージドクラスタ環境において、Kubernetesのアップグレード中に発生する最も一般的な問題です。

クロスクラウドのKubernetesアップグレードの問題

異なるクラウドプロバイダー間でKubernetesをアップグレードする際には、さらにプラットフォームに依存しない問題が発生することがあります。この表は、クロスクラウドアップグレードで最も一般的な問題とその効果的な対処方法をまとめたものです。

積極的な予防措置

最も効果的なアプローチは、問題が発生する前に防止することです：

AWS Cluster InsightsやGKEの同等ツールを使用して事前チェックを実行
非本番環境でアップグレードを徹底的にテスト
アップグレード前にバックアップを作成
ロールバック手順を文書化し、本番環境へのアップグレード前にテスト
アップグレード中およびその後は積極的に監視を行う

Kubernetes戦略の未来への備え

Looking ahead to Kubernetes 1.31 and beyond, prepare for these upcoming changes:

1. 外部クラウドプロバイダへの移行

Kubernetesは、内部クラウドプロバイダ統合を削除しています。この準備のために：

非本番環境で外部クラウドプロバイダコンポーネントをテスト
Terraform設定を更新し、外部コントローラーを含める

# AWS Cloud Controller Manager deployment
resource "kubernetes_deployment" "aws_cloud_controller_manager" {
  metadata {
    name      = "aws-cloud-controller-manager"
    namespace = "kube-system"
  }
  # Configuration details...
}

2. 非推奨フラグの削除

--keep-terminated-pod-volumes

のようなフラグが削除される予定です。設定を監査して、これらの非推奨フラグを確認しましょう。

# Check for usage in your configurations
grep -r "keep-terminated-pod-volumes" ./k8s-manifests/

# Review kubelet configurations
kubectl get cm -n kube-system kubelet-config -o yaml

3. Container Storage Interface (CSI) への移行

インツリーボリュームプラグインはCSI（コンテナストレージインターフェース）実装に移行します。

# Verify CSI drivers are installed
kubectl get pods -n kube-system | grep csi

# Check for StorageClass configurations using CSI
kubectl get storageclass

包括的なアップグレード戦略の実装

すべての要素を統合し、Kubernetesアップグレードを業務の一環として行うための包括的なアプローチは次の通りです：

1. 定期的なアップグレードスケジュールを確立

予測可能なアップグレードスケジュールを実施：

Kubernetesのマイナーなバージョン：6ヶ月ごと
パッチバージョン：毎月またはセキュリティ更新が必要な場合
標準サポート終了日の明確な設定

2. ロールアウト戦略を定義

ほとんどの企業にとって、段階的アプローチが最適です：

開発環境：新しいバージョンが一般公開され次第アップグレード
テスト/QA環境：開発環境での検証後1ヶ月後にアップグレード
本番環境：テスト環境での検証後1〜2ヶ月後にアップグレード

3. 自動化を徹底する

Kubernetesのアップグレードをリスクの高いプロジェクトではなく、日常的な業務にするためには、自動化が必要です。目標はシンプルです：手作業なし、推測なし、驚きなし。

次の部分の自動化に注力：

発見と検証： Pluto、kube-bench、カスタムスクリプトなどのツールを使用して、アップグレード前に非推奨API、セキュリティのギャップ、準備不足の問題を自動で検出。
バックアップと復旧： Veleroを使って、コントロールプレーンとノードグループのアップグレード前にクラスターのスナップショットとアプリケーションバックアップを自動化。
Infrastructure as Code (IaC)： Terraform、Pulumi、AWS CDKを使用して、クラスターの構成、ノードグループ、アドオンを完全に管理。 ArgoCDやFluxなどのGitOpsパイプラインを使用して、アップグレード中のアプリケーションデプロイメントを管理。
戦略的ロールアウト：自動化されたカナリアデプロイメント、ブルー/グリーンクラスター、ローリングアップデートをスクリプトとCI/CDワークフローで実施。
テストフレームワーク：各アップグレードフェーズ後に、アップグレード前と後の検証ジョブを自動的にデプロイ。 CI/CDパイプラインにスモークテストとワークロード固有のヘルスチェックを組み込む。
モニタリングと可視化：アラートとGrafanaダッシュボードを連携し、アップグレードフェーズごとに健康状態を自動で監視。
ガバナンスの統合：アップグレードプロセスの一環として、サービスリクエスト（例：ServiceNow）を自動生成し、ITSMチケットを更新。

結論

Kubernetesのアップグレードを一度限りのプロジェクトとしてではなく、継続的で自動化されたプロセスとして取り扱うことによって、プラットフォームチームはリスクを劇的に削減し、クラスターの健康状態を改善し、革新サイクルを加速できます。今すぐ実施できる強力なアップグレード戦略は、明日の運用の優秀さへの基盤となります。小さく始めて、すべてを自動化し、アップグレードを退屈にする — それが目標です。

コミュニティとサポートリソース

成功するKubernetes戦略は、継続的な学習とコミュニティとの連携に依存しています。プラットフォームエンジニアリングチームのための重要なリソースは以下の通りです：

クラウドプロバイダのドキュメント(英語）

EKSドキュメント - AWS EKSに関する包括的なガイド
AKSドキュメント - MicrosoftのAKSリソース
GKEドキュメント - GoogleのGKEガイド

コミュニティリソース

Kubernetes Slack - #eks、#aks、#gke、技術的なSIGチャネルに参加
CNCFウェビナー - 定期的な技術的なディープダイブ
KubeCon録画 - 過去のカンファレンスのセッション

技術的な学習リソース

EKSワークショップ - 実践的なEKSの演習
AKSワークショップ - MicrosoftのAKSチュートリアル
Kubernetes学習パス - 公式の学習リソース

Part 1「戦略ガイド」もぜひご覧ください。アップグレード成功の全体像がつかめます。

Kubernetesアップグレードをもっとシンプルにしませんか？
Aokumoが自動化と効率化をどのように支援できるか、デモ予約またはお問い合わせでご確認ください。

Kubernetesのアップグレード（パート2）：成功するための技術ガイド

Introduction

Kubernetesアップグレードを定常運用にするためのツール

エンタープライズクラスのKubernetesアップグレード用ツールカテゴリ

インテグレーションおよびワークフロー用ツール

なぜインフラストラクチャー・アズ・コード（IaC）がアップグレードにとって重要か

EKS用Terraform実装

IaC（Infrastructure as Code）ベストプラクティス

ゼロダウンタイムアップグレード戦略

1. Canaryデプロイメント（EKSに最適）

実装手順:

2. Blue/Green クラスター展開

実装手順:

3. Pod Disruption Budgets（PDB）を使用したローリングアップデート

自動化された検証フレームワーク

アップグレード前の検証

アップグレード後の検証

バージョン管理

1. 互換性マトリクス

2. バージョンのずれを管理

3. 最大バージョンスキュー制限

4. サポート終了日（EOL）の確認

5. CNIプラグインとネットワーキングの互換性

一般的なアップグレードの問題のトラブルシューティング

クラスタ内で発生する一般的なアップグレードの問題

クロスクラウドのKubernetesアップグレードの問題

積極的な予防措置

Kubernetes戦略の未来への備え

1. 外部クラウドプロバイダへの移行

2. 非推奨フラグの削除

3. Container Storage Interface (CSI) への移行

包括的なアップグレード戦略の実装

1. 定期的なアップグレードスケジュールを確立

2. ロールアウト戦略を定義

3. 自動化を徹底する

結論

コミュニティとサポートリソース

クラウドプロバイダのドキュメント(英語）

コミュニティリソース

技術的な学習リソース

related

Kubernetesアップグレード完全攻略：スピーディで安全に再現性を可能にする方法

2025年版Kubernetesリソース管理の極意：デフォルト制限とHPAの先を行く

2025年版 Kubernetesツール：エンタープライズの課題解決法