Kubernetes コミュニティは、約 4 ヶ月ごとに新しいマイナーバージョンをリリースします。Container Service for Kubernetes (ACK) はこのリリース周期に準拠し、作成、メンテナンス、およびサポート終了 (EOL) を含む Kubernetes バージョンのライフサイクルを管理します。このドキュメントでは、Kubernetes バージョンのリリース、ライフサイクル、およびサポートに関する ACK のサポートポリシーの概要を説明します。
リリース履歴
以下の表では、ACK マネージドクラスターでサポートされている Kubernetes バージョンを一覧表示します。
v1.31 以降、ACK はすべてのマイナーバージョンをサポートするようになります。これは、以前の偶数番号のマイナーバージョン (1.28 や 1.30 など) のみをサポートするというポリシーを拡張したものです。これらのバージョンのサポート期間は 1 年間です。
バージョン | ステータス | ACK リリース日 | ACK サポート終了日 |
計画中 | 2026年5月 | 2027年5月30日 | |
計画中 | 2026年2月 | 2027年2月28日 | |
計画中 | 2025年9月 | 2026年9月30日 | |
リリース済み | 2024年6月 | 2026年6月30日 |
バージョン形式
ACK は、x.y.z-aliyun.n というバージョニングスキームを使用します。ここで、x.y.z はコミュニティの Kubernetes バージョン (メジャー.マイナー.パッチ) で、n は ACK のパッチバージョンです。
バージョンのライフサイクル
Kubernetes コミュニティが新しいマイナーバージョンをリリースした後、ACK はリスク評価と整合性テストを実施します。通常、コミュニティが最初のパッチをリリースしてから 2 週間以内に、新しいバージョンでのクラスター作成やアップグレードが可能になります。
Kubernetes コミュニティがマイナーバージョンの新しいパッチバージョンをリリースすると、ACK は修正された問題のリスクレベルを評価し、アップデートをリリースするかどうかを決定します。重大なセキュリティ脆弱性に対処するパッチバージョンについては、ACK は通常 24 時間以内に評価を完了し、新しいバージョンをリリースします。
サポートポリシー
[クラスターの作成]
ACK は、直近 3 つの Kubernetes マイナーバージョンのいずれかを使用するクラスターの作成をサポートします。たとえば、最新の 3 つのマイナーバージョンが 1.35、1.34、1.33 である場合、ACK がバージョン 1.35 のサポートを開始すると、バージョン 1.32 のクラスター作成は利用できなくなります。古いパッチバージョンでのクラスター作成も利用できません。
マイナーバージョンの新しいパッチバージョンがリリースされると、それ以前のパッチバージョンでのクラスター作成は利用できなくなります。たとえば、バージョン 1.30.7 がリリースされると、バージョン 1.30.1 のクラスターは作成できなくなります。
[クラスターアップグレード]
クラスターは一度に 1 つのマイナーバージョンしかアップグレードできません。ダウングレードやマイナーバージョンをスキップしたアップグレードはサポートされていません。
パッチバージョンについては、利用可能な最新のパッチバージョンにのみアップグレードできます。古いパッチバージョンへのアップグレードはサポートされていません。
[テクニカルサポート]
ACK は、サポート期間中のすべての Kubernetes バージョンに対して、質疑応答、オンラインガイダンス、トラブルシューティングを含むテクニカルサポートを提供します。
古いバージョンのリスク
古いバージョンを使用すると、セキュリティと安定性のリスクが生じます。バージョンのサポートが終了すると、クラスターは新しい機能、バグ修正、タイムリーなテクニカルサポートを受けられなくなり、パッチが適用されていないセキュリティ上の欠陥に対して脆弱になります。
クラスターを安全で安定したバージョンにアップグレードする必要があります。
クラスターの手動アップグレード：クラスターを一度に 1 マイナーバージョンずつ最新バージョンにアップグレードします。アップグレードするノードの指定、アップグレードバッチの最大同時実行ノード数の設定、アップグレード間隔と一時停止ポリシーの構成により、アップグレードのペースを制御できます。
クラスターの自動アップグレード：クラスターの自動アップグレードを有効にし、適切なアップグレード頻度を選択して、クラスターが定期的にアップグレードされるようにします。
古いバージョンの強制更新
アップストリームのサポート期間を過ぎた Kubernetes バージョンについては、Kubernetes コミュニティは CVE リスクを開示したり、パッチを提供したりしません。古いバージョンに存在する潜在的なセキュリティリスクは、タイムリーに発見または修正されない可能性があります。ACK クラスターはマネージドアーキテクチャを使用しているため、これらのセキュリティリスクはクラスターだけでなく、Alibaba Cloud 全体のセキュリティにも影響を与える可能性があります。そのため、ACK はクラスターが古いバージョンを長期間使用することを許可せず、安全で安定したバージョンへの強制更新を実行します。
ACK は、クラスターのバージョンが古くなった直後に強制更新を実行するわけではありません。サポートされているバージョンに手動でクラスターをアップグレードすることを推奨します。強制更新が実行される前に、ACK は少なくとも 1 か月前までに SMS、メール、および内部メッセージで通知をお送りします。
強制更新には、以下のアクションが含まれます：
クラスターコンポーネントのアップグレード。新しいクラスターバージョンと互換性のないコンポーネントのみがアップグレードされます。
クラスターコントロールプレーンのアップグレード。
ノードプールとノードのアップグレード。
以下の場合、強制更新は実行されません。手動でアップグレードを実行する必要があります：
このクラスターはACK 専用クラスターであるため、ACK Pro クラスターへの移行を推奨します。詳細については、「ACK 専用クラスターを ACK Pro クラスターにホットマイグレーションする」をご参照ください。
クラスターが Kubernetes 1.22 を使用し、コンテナランタイムとして Docker を使用している場合は、containerd ランタイムに移行する必要があります。詳細については、「ノードコンテナランタイムの Docker から containerd への移行」をご参照ください。
インストールされている NGINX Ingress コントローラーが、ターゲットの ACK バージョンと互換性のない古いバージョンである場合。コンポーネントの詳細については、NGINX Ingress コントローラーの変更ログをご参照ください。
よくある質問
固定バージョンを使い続けることはできますか？
いいえ。古いバージョンに存在する潜在的なセキュリティリスクは、クラスターだけでなく、Alibaba Cloud 全体のセキュリティにも影響を与える可能性があります。ACK はクラスターが古いバージョンを長期間使用することを許可せず、安全で安定したバージョンへの強制更新を実行します。
ACK の最新の機能とテクニカルサポートを活用するために、速やかにクラスターのバージョンをアップグレード (クラスターの手動アップグレード) してください。アップグレードする前に、ACK がサポートする Kubernetes バージョンのリリースノートを確認して、各バージョンの機能変更と重要な注意事項をご確認ください。クラスターが定期的にアップグレードされるように、クラスターの自動アップグレードを有効にすることを推奨します。
古いクラスターを迅速にアップグレードする方法
以下の 2 つの解決策のいずれかを選択できます：
解決策 1：一度に 1 バージョンずつアップグレードします。各アップグレード後、アプリケーションが安定して稼働していることを確認するためにクラスターを監視してから、次のアップグレードに進みます。詳細については、「クラスターの手動アップグレード」をご参照ください。
解決策 2：最新バージョンの新しいクラスターを作成し、アプリケーションを徐々に新しいクラスターに移行してから、古いクラスターを廃止します。クラスターの作成と設定方法については、「ACK マネージドクラスターの作成」をご参照ください。
アップグレード時にマイナーバージョンをスキップできますか？
いいえ。ACK はアップグレード時にマイナーバージョンをスキップすることをサポートしていません。クラスターを一度に 1 バージョンずつアップグレードする必要があります。さらに、クラスターのコントロールプレーンをアップグレードする前に、ノードがコントロールプレーンと同じ Kubernetes バージョンを使用していることを確認してください。
Docker から containerd に切り替える方法
ACK は、Kubernetes v1.24 以降では、組み込みのコンテナランタイムとして Docker をサポートしなくなりました。ノードのコンテナランタイムを Docker から containerd に移行する必要があります。
ノードプールのアップグレード機能を使用して元のノードプールでランタイムの切り替えを行うか、新しい containerd ノードプールを作成してローリング移行を実行できます。詳細については、「ノードコンテナランタイムの Docker から containerd への移行」をご参照ください。
ACK はどのようにアップグレードの安定性を確保していますか？
ACK クラスターは、コントロールプレーンと 1 つ以上のノードプールで構成されます。
コントロールプレーンのアップグレード：ACK は、非推奨 API、コンポーネントの互換性、機能設定の互換性、およびコントロールプレーンコンポーネントの問題を検査するためのアップグレード前チェックを提供します。このチェックを実行しても、アプリケーションの通常運用には影響しません。チェックで問題が報告された場合は、コンソールに表示される修正アドバイスに従ってください。詳細については、「クラスターの手動アップグレード」をご参照ください。
ノードプールのアップグレード：ノードプールのアップグレードには、kubelet と containerd のアップグレードが含まれます。ACK は、ノードのステータス、システムリソース、ディスクステータス、およびネットワーク環境を検査するためのアップグレード前チェックを提供します。このチェックを実行しても、アプリケーションの通常運用には影響しません。チェックで問題が報告された場合は、コンソールに表示される修正アドバイスに従ってください。
カスタムのアップグレードポリシーを設定することもできます。たとえば、アップグレードするノードを指定したり、アップグレードバッチの最大同時実行ノード数を設定したり、一時停止ポリシーを設定したりすることで、アップグレードのペースを制御できます。ノードのシステムディスクに重要なアプリケーションデータが含まれている場合は、ノードプールをアップグレードする前にノードのシステムディスクのスナップショットを作成することもできます。詳細については、「ノードプールのアップグレード」をご参照ください。
アップグレードの注意事項
クラスターのアップグレードはロールバックできません。まずテスト環境をアップグレードし、検証が成功した後に本番環境をアップグレードすることを推奨します。アップグレードプロセス中に、検証のために一部のノードを先にアップグレードすることもできます。
サポートされているコンポーネントのバージョン、機能、および非推奨の API は、Kubernetes のバージョンによって異なります。詳細については、各バージョンの「ACK がサポートする Kubernetes バージョンのリリースノート」をご参照ください。
コントロールプレーンのアップグレードに関する注意事項に従ってください。
ノードプールのアップグレードに関する注意事項に従ってください。
関連ドキュメント
クラスターのアップグレードに関する影響、手順、注意事項、およびアップグレード方法については、「クラスターのアップグレード」をご参照ください。
ACK がサポートする OS タイプとイメージバージョンについては、「OS イメージのリリースノート」をご参照ください。
ACK が提供する CVE の修正と対応する解決策については、「CVE の修正」をご参照ください。
アップグレード前のチェックと非推奨 API については、「クラスターのチェック項目と修正方法」をご参照ください。
ACK Pro クラスターは、大規模なエンタープライズ本番環境向けに、より高い信頼性とセキュリティでベーシッククラスターを強化し、SLA の補償対象となります。 移行が必要な場合は、「ACK マネージドベーシッククラスターを ACK Pro クラスターにホット移行する」をご参照ください。