Amazon EKS での Kubernetes のバージョン
Kubernetes プロジェクトは、新機能、設計の更新、およびバグ修正とともに急速に進化しています。コミュニティでは、Kubernetes の新しいマイナーバージョン (例えば 1.21 など) を、通常、約 3 か月ごとにリリースしています。各マイナーバージョンのサポートは、最初のリリースから約 12 か月間は継続されます。
Amazon EKS での利用可能な Kubernetes のバージョン
現在、次の Kubernetes バージョンが、新しい Amazon EKS クラスターで利用可能です。
-
1.21.2
-
1.20.7
-
1.19.8
-
1.18.16
-
1.17.17
-
1.16.15
アプリケーションが特定のバージョンの Kubernetes を必要とする場合を除き、Amazon EKS がクラスター用にサポートしている、利用可能な最新の Kubernetes バージョンを選択することをお勧めします。新しい Kubernetes バージョンが Amazon EKS で利用可能になったら、利用可能な最新のバージョンが使用できるように、クラスターをタイムリーに更新することをお勧めします。詳細については、「クラスターの更新」を参照してください。詳細については、「Amazon EKS Kubernetes リリースカレンダー」および「Amazon EKS バージョンのサポートとよくある質問」を参照してください。
Kubernetes 1.21
Amazon EKS で Kubernetes 1.21 が利用可能になりました。Kubernetes 1.21 の詳細については、公式リリースのお知らせ
Important
-
ポッド、サービス、およびノードでのデュアルスタックネットワーク
(IPv4 および IPv6 アドレス) サポートがベータ版になりました。ただし、Amazon EKS と Amazon VPC CNI は現在、デュアルスタックネットワーキングをサポートしていません。 -
Amazon EKS 最適化 Amazon Linux 2 AMI に、
containerdランタイムをDocker の代替として使用するためのブートストラップフラグが含まれるようになりました。このフラグの追加は、次の Kubernetes リリースで サポートされているランタイムとしての Docker を削除するための事前措置です。詳細については、「containerd ランタイムブートストラップフラグを有効にする」を参照してください。これは、GitHub のコンテナ化ロードマップ でご確認いただけます。 -
マネージド型ノードグループによる、Cluster Autoscaler の優先度エクスパンダーのサポート。
Amazon EKS v1.21 クラスターで新しく作成されたマネージド型ノードグループは、基盤となる Auto Scaling グループ名に次の形式を使用します。
eks-<managed-node-group-name>-<uuid>これにより、Cluster Autoscaler の優先度エクスパンダ
機能を使用して、ユーザー定義の優先順位に基づいてノードグループをスケーリングできるようになります。一般的なユースケースとしては、オンデマンドよりもスポットノードグループのスケーリングを優先させる場合などがあります。この動作の変更により、コンテナーロードマップに挙げられている問題 #1304 が解決されます。
Kubernetes の以下の機能が Kubernetes 1.21 Amazon EKS クラスターでサポートされるようになりました。
-
CronJobs
(従来の ScheduledJobs) が安定版に移行しました。これにより、バックアップやレポートの生成など、定期的にスケジュールされたアクションを実行できます。 -
イミュータブルなシークレットと ConfigMaps
が安定版に移行しました。新しいイミュータブルなフィールドがこれらのオブジェクトに追加され、変更を防止できるようになりました。この変更の防止により、意図せずアプリケーションを破壊する更新からクラスターを保護します。これらのリソースは不変であるため、kubelet による変更の監視またはポーリングの必要がなくなり、 kube-apiserverの負荷を軽減すると同時に、スケーラビリティとパフォーマンスの向上を実現できます。 -
ノードの適切なシャットダウン
がベータ版に移行しました。これにより、kubelet によるノードのシャットダウンの認識を可能にし、そのノードのポッドをスムーズに終了させることができます。この機能以前は、ノードのシャットダウンが行われる際に、ポッドが想定される終了ライフサイクルに従わなかったことが原因で、ワークロードの問題が発生していました。今後は、kubelet が差し迫ったシステムシャットダウンを検出し、その情報を実行中のポッドに伝えることで、適切な終了が行われます。 -
複数のコンテナを持つポッドは、
kubectl.kubernetes.io/default-containerアノテーションを使用して、kubectl コマンド用にコンテナを事前に選択することができます。 -
PodSecurityPolicy は非推奨化されました。PodSecurityPolicy では、Kubernetes の非推奨化ガイドラインに従い、いくつかのリリースの機能が継続されます。詳細については、PodSecurityPolicy Deprecation: Past, Present, and Future
ならびに AWS ブログ を参照してください。
完全な Kubernetes 1.21 変更ログについては、https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.21.md
Kubernetes 1.20
Kubernetes 1.20 の詳細については、公式リリースのお知らせ
Important
-
1.20 では、ロールとユーザーの新デフォルトが提供されます。詳細については、「EKS Kubernetes のロールとユーザのデフォルト」を参照してください。
Kubernetes の以下の機能が Kubernetes 1.20 Amazon EKS クラスターでサポートされるようになりました。
-
APIの優先順位と公平性
がベータステータスになり、デフォルトで有効になっています。これにより kube-apiserverを使用して、受信リクエストを優先度レベルで分類します。 -
ランタイムクラス
が安定状態に達しました。 RuntimeClassリソースは、クラスタ内の複数のランタイムをサポートするためのメカニズムを提供し、コンテナランタイムに関する情報をコントロールプレーンに表面化させます。 -
プロセス ID の制限
がなくなりました。 -
kubectl デバッグ
がベータステータスになりました。 kubectl debugは、一般的なデバッグワークフローをkubectlから直接サポートします。 -
Docker コンテナのランタイムは廃止されました。これに関しては、Kubernetes コミュニティのブログ投稿
で詳細に触れているほか、よくある質問ページ でも取り上げています。Docker が作成した画像は、今後も引き続き使用できます。kubelet 起動ログに出力される dockershim 廃止警告メッセージを無視しても問題ありません。EKS は、最終的に EKS に最適化された Amazon Linux 2 AMI のランタイムとしてコンテナードに移行されます。さらなる詳細については、コンテナのロードマップでの問題 を参照してください。 -
FQDN としてのポッドホスト名はベータステータスに卒業しました。この機能により、ポッドのホスト名を完全修飾ドメイン名 (FQDN) に設定できるようになり、カーネルのホスト名フィールドをポッドの FQDN に設定できるようになりました。
-
client-go の資格情報プラグインは、
KUBERNETES_EXEC_INFO環境変数を通じて現在のクラスター情報に送られます。この機能強化により、Go クライアントは、キー管理システム (KMS) などの外部資格情報プロバイダーを使用して認証できます。
完全な Kubernetes 1.20 変更ログについては、https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md
Kubernetes 1.19
Kubernetes 1.19 の詳細については、公式リリースのお知らせ
Important
-
1.19 以降の Amazon EKS では、
kubernetes.io/cluster/タグが、クラスターの作成中に渡されたサブネットに追加されなくなります。このサブネットタグは、Kubernetes サービスコントローラーまたは AWS Load Balancer Controller により Elastic Load Balancer が配置される場所を、ユーザーが決定したい場合にのみ必要となります。クラスターの作成中に Amazon EKS に渡されるサブネットの要件については、更新された「クラスター VPC に関する考慮事項」を参照してください。<cluster-name>-
既存のクラスターを 1.19 に更新した場合は、サブネットタグは変更されません。
-
AWS Load Balancer Controller のバージョン
v2.1.1以前には、サブネットタグ<cluster-name>v2.1.2以降では、タグを指定してサブネット検出を調整できますが、必須ではありません。AWS Load Balancer Controller の詳細については、「AWS Load Balancer Controller」を参照してください。ロードバランサーを使用する場合のサブネットのタグ付けの詳細については、「Amazon EKS でのアプリケーション負荷分散」および「Amazon EKS でのネットワーク負荷分散」を参照してください。
-
-
今後は、非ルートコンテナ (これは、サービスアカウントの IAM ロールで使用するためのウェブ ID トークンファイルにアクセスします) に、セキュリティコンテキストを提供する必要がなくなりました。詳細については、GitHub の「サービスアカウントの IAM ロール」、および「proposal for file permission handling in projected service account volume (射影されたサービスアカウントボリュームでのファイル権限処理の提案)
」を参照してください。 -
ポッド ID Webhook が更新され、GitHub でのスタートアッププローブが欠落する
問題に対応しました。また、Webhook では、トークンの有効期限を制御するアノテーションもサポートされています。詳細については、「GitHub pull request (GitHub のプルリクエスト) 」を参照してください。 -
Amazon EKS 1.19 クラスターの推奨バージョンは、CoreDNS バージョン 1.8.0 です。このバージョンは、新しい Amazon EKS 1.19 クラスターにデフォルトでインストールされます。詳細については、「CoreDNS アドオンの管理」を参照してください。
-
Amazon EKS に最適化された Amazon Linux 2 AMI には、Kubernetes バージョン 1.19 用の Linux カーネルバージョン 5.4 が搭載されています。詳細については、「Amazon EKS 最適化 Amazon Linux AMI」を参照してください。
-
以下の変更が行われ、
CertificateSigningRequest APIが安定版のcertificates.k8s.io/v1に昇格しました。-
spec.signerNameが必須になりました。certificates.k8s.io/v1API を使用して、kubernetes.io/legacy-unknownリクエストを作成することはできません。 -
依然として、
certificates.k8s.io/v1beta1API でkubernetes.io/legacy-unknown署名者名を使用しながら CSR を作成することは可能です -
また現在も、ノード以外のサーバー証明書や Webhook のために CSR が署名されるように、(
certificates.k8s.io/v1beta1API などから) リクエストできます。これらの CSR は自動承認されません。 -
証明書を承認する特権ユーザーには、
kubectlの 1.18.8以降が必要です。
証明書 v1 API の詳細については、Kubernetes ドキュメントの「Certificate Signing Requests (証明書署名リクエスト)
」を参照してください。 -
以下の Amazon EKS Kubernetes リソースは、Kubernetes コントロールプレーンが機能するために重要です。これらは削除や編集しないことをお勧めします。
| アクセス許可 | Kind | 名前空間 | 理由 |
|---|---|---|---|
eks:certificate-controller |
Rolebinding |
kube-system |
コントロールプレーンの署名者と承認者の機能に影響を与えます。 |
eks:certificate-controller |
Role |
kube-system |
コントロールプレーンの署名者と承認者の機能に影響を与えます。 |
eks:certificate-controller |
ClusterRolebinding |
すべて | kubectl exec や kubectl logs など一定のクラスター機能に影響を与えるサーバー証明書を、リクエストするための kubelet の能力に影響します。
|
Kubernetes の以下の機能が Kubernetes 1.19 Amazon EKS クラスターでサポートされるようになりました。
-
ExtendedResourceTolerationアドミッションコントローラーが有効になりました。このアドミッションコントローラーは、GPU などの拡張リソースを要求するポッドにテイントの許容範囲を自動的に追加するため、許容範囲を手動で追加する必要はありません。詳細については、Kubernetes ドキュメントの「ExtendedResourceToleration」を参照してください。 -
ツリー内の Kubernetes サービスコントローラーによってプロビジョニングされた Elastic Load Balancer (CLB および NLB) は、インスタンスターゲットとして含まれるノードをフィルタリングすることができます。これにより、大規模なクラスターが、ターゲットグループの上限に達するのを回避できます。詳細については、Kubernetes ドキュメントで、関連するGitHub での問題
と、「他の ELB アノテーション 」にある service.beta.kubernetes.io/aws-load-balancer-target-node-labelsを参照してください。 -
Pod Topology Spread が安定版になりました。Topology Spread による制約を使用すると、リージョン、ゾーン、ノード、その他のユーザー定義トポロジードメインなどで障害を起こしたドメイン間で、ポッドがクラスター全体に分散される方法を制御できます。これにより、高可用性を実現し、リソースの利用効率を向上できます。詳細については、Kubernetes ドキュメントの「Pod Topology Spread Constraints
」を参照してください。 -
Ingress API の一般提供を開始しました。詳細については、Kubernetes ドキュメントの「Ingress
」を参照してください。 -
EndpointSlices は、デフォルトで有効になっています。EndpointSlices は、エンドポイント API に代わるスケーラブルで拡張可能な新しい API です。この API により、サービスをバックアップするポッドの IP アドレス、ポート、準備状況、およびトポロジ情報を追跡することができます。詳細については、Kubernetesのブログで「Scaling Kubernetes Networking With EndpointSlices (EndpointSlices を使用した Kubernetes ネットワークのスケーリング
」を参照してください。 -
シークレットボリュームと ConfigMap ボリュームをイミュータブルとしてマークできるようになりました。これにより、クラスター内に多くの シークレットボリュームと ConfigMap ボリュームがある場合の、API サーバーに対する負荷が大幅に軽減されます。詳細については、Kubernetes ドキュメントの「ConfigMap
」、ならびに「Secret 」を参照してください。
完全な Kubernetes 1.19 変更ログについては、https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.19.md
Kubernetes 1.18
Kubernetes 1.18 の詳細については、公式リリースのお知らせ
Kubernetes の以下の機能が Kubernetes 1.18 Amazon EKS クラスターでサポートされるようになりました。
-
トポロジマネージャーがベータになりました。この機能により、CPU とデバイスマネージャはリソース割り当ての決定を調整し、機械学習と分析のワークロードで低レイテンシーに最適化できます。詳細については、Kubernetes ドキュメントの「Control Topology Management Policies on a node
」を参照してください。 -
サーバー側の適用機能は、新しいベータバージョンで更新されます。この機能では、すべての新しい Kubernetes オブジェクトのフィールドに対する変更を追跡および管理し、リソースがいつ何によって変更されたかを把握できます。詳細については、Kubernetes ドキュメントの「What is Server-side Apply?
」を参照してください。 -
Ingress 仕様に新しい
pathTypeフィールドと新しいIngressClassリソースが追加されました。これらの機能により、Ingress 設定のカスタマイズが簡単になります。これらの機能は、AWS Load Balancer Controller (旧 ALB Ingress Controller) でサポートされます。詳細については、Kubernetes ドキュメントの「Improvements to the Ingress API in Kubernetes 1.18 in the Kubernetes documentation」を参照してください。 -
設定可能な水平方向のポッドの Auto Scaling 動作。詳細については、Kubernetes ドキュメントの「Support for configurable scaling behavior
」を参照してください。 -
1.18 のクラスターでは、変更 Webhook を使用しているか、環境変数を手動で設定しているかに関係なく、中国リージョンでサービスアカウントの IAM ロールを使用するポッドに対し、環境変数
AWS_DEFAULT_REGION=<region-code>を追加する必要はなくなります。以前のバージョンを使用する場合は、すべてのポッドにこの変数を含める必要があります。
完全な Kubernetes 1.18 変更ログについては、https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md
Kubernetes 1.17
Kubernetes 1.17 の詳細については、公式リリースのお知らせ
-
EKS で
CSIMigrationAWS機能フラグを有効にしていません。これは、詳細な移行手順とともに、将来のリリースで有効になる予定です。CSI 移行の詳細については、Kubernetes のブログを参照してください。 -
いずれかの AWS Fargate ポッドに 1.16 より前の
kubeletマイナーバージョンがある場合、1.16 から 1.17 へのクラスターの更新は失敗します。クラスターで 1.16 から 1.17 への更新を試みる前に、Fargate ポッドをリサイクルし、kubelet を 1.16 にしておく必要があります。1.15 以降のクラスターで Kubernetes デプロイをリサイクルするには、次のコマンドを使用します。kubectl rollout restart deployment<deployment-name>
Kubernetes の以下の機能が Kubernetes 1.17 Amazon EKS クラスターでサポートされるようになりました。
-
Cloud Provider Labels
の一般提供が開始されました。ノードアフィニティやカスタムコントローラーなどの機能に対してポッド仕様でベータラベルを使用している場合は、新しい GA ラベルへの移行を開始することをお勧めします。新しいラベルの詳細については、次の Kubernetes のドキュメントを参照してください。 -
ResourceQuotaScopeSelectors
機能が正式リリースされました。この機能を使用すると、クォータがサポートするリソースの数を、スコープに関連するリソースのみに制限できます。 -
TaintNodesByCondition
機能が正式リリースされました。この機能を使用すると、ディスクやメモリに高い負荷がかかっているような状態のノードを taint に設定できます。 -
CSI トポロジ
機能は正式リリースされ、EBS CSI ドライバー によって完全にサポートされました。トポロジを使用して、ボリュームのプロビジョニング先のアベイラビリティーゾーンを制限できます。 -
LoadBalancerタイプのサービス用に、Finalizer protectionの一般提供を開始しました。この機能により、関連するロードバランサーも削除されるまで、サービスリソースは完全に削除されません。 -
カスタムリソースがデフォルト値
をサポートするようになりました。OpenAPI v3 検証スキーマ で値を指定します。 -
Windows コンテナの RunAsUsername
機能がベータ版となり、コンテナ内の Windows アプリケーションを、デフォルトとは異なるユーザー名で実行できるようになりました。
完全な Kubernetes 1.17 変更ログについては、https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.17.md
Kubernetes 1.16
Kubernetes 1.16 の詳細については、公式リリースのお知らせ
-
Kubernetes 1.16 では、いくつかの非推奨の API が削除されます。クラスターを 1.16 に更新する前に、アプリケーションを変更する必要が生じる場合があります。更新を行う前に、1.16 へのアップグレードの前提条件に従ってください。
-
1.16 以降、Amazon EKS の認証権限は SAN X.509 拡張による証明書署名リクエストに従います。これにより、GitHub からリクエストされる、SAN x509 拡張に従う必要がある EKS CA の機能
が解決されます。
Kubernetes の以下の機能が Kubernetes 1.16 Amazon EKS クラスターでサポートされるようになりました。
-
CSI 仕様のボリューム拡張がベータ版に移行されました。これにより、CSI 仕様のボリュームプラグインのサイズ変更が可能になりました。詳細については、Kubernetes CSI ドキュメントの「Volume Expansion
」を参照してください。最新バージョンの EBS CSI ドライバー では、Amazon EKS 1.16 のクラスターで実行時の、ボリューム拡張がサポートされます。 -
Windows GMSA のサポートはアルファ版からベータ版に昇格し、Amazon EKS によるサポートも開始されました。詳細については、Kubernetes ドキュメントの「Configure GMSA for Windows Pods and containers
」を参照してください。 -
新しい注釈:
service.beta.kubernetes.io/aws-load-balancer-eip-allocationsは、Elastic IP アドレスを Network Load Balancer に割り当てるためにサービスタイプLoadBalancerで利用可能です。詳細については、GitHub の問題「Support EIP Allocations with AWS NLB」を参照してください。 -
サービスロードバランサーのファイナライザー保護がベータ版になり、デフォルトで有効になりました。サービスロードバランサーのファイナライザー保護により、ネットワークロードバランサー など、Kubernetes Service オブジェクトに割り当てられたロードバランサーリソースは、サービスの削除時に破棄または解放されます。詳細については、Kubernetes ドキュメントの「Garbage Collecting Load Balancers
」を参照してください。 -
Kubernetes カスタムリソース定義とアドミッション Webhook 拡張メカニズムは、両方とも一般公開されています。詳細については、Kubernetes ドキュメントの「Custom Resources
」と「Dynamic Admission Control 」を参照してください。 -
サーバー側の適用機能がベータステータスになり、デフォルトで有効になっています。詳細については、Kubernetes ドキュメントの「Server Side Apply
」を参照してください。 -
CustomResourceDefaulting機能はベータ版に昇格され、デフォルトで有効になります。デフォルトは、apiextensions.k8s.io/v1API を介して構造スキーマで指定することができます。詳細については、Kubernetes ドキュメントの Specifying a structural schemaを参照してください。
完全な Kubernetes 1.16 変更ログについては、https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.16.md
Amazon EKS Kubernetes リリースカレンダー
月と年のみの日付はおおよその日付であり、確定後に正確な日付で更新されます。
| Kubernetes バージョン | アップストリームのリリース | Amazon EKS リリース | Amazon EKS のサポート終了 |
|---|---|---|---|
| 1.16 | 2019 年 9 月 8 日 | 2020 年 4 月 30 日 | 2021 年 9 月 27 日 |
| 1.17 | 2019 年 12 月 9 日 | 2020 年 7 月 10 日 | 2021 年 11 月 2 日 |
| 1.18 | 2020 年 3 月 23 日 | 2020 年 10 月 13 日 | 2022 年 2 月 18 日 |
| 1.19 | 2020 年 8 月 26 日 | 2021 年 2 月 16 日 | 2022 年 4 月 |
| 1.20 | 2020 年 12 月 8 日 | 2021 年 5 月 18 日 | 2022年6月 |
| 1.21 | 2021 年 4 月 8 日 | 2017 年 7 月 19 日 | 2022 年 9 月 |
Amazon EKS バージョンのサポートとよくある質問
Kubernetes の各バージョンに Kubernetes コミュニティが提供するサポートに沿って、Amazon EKS は Kubernetes の少なくとも 4 つの実稼働対応バージョンをいつでもサポートするよう努めています。Kubernetes の特定のマイナーバージョンのサポート終了日については、サポート終了日の最低 60 日前に発表します。Kubernetes の新しいバージョンの Amazon EKS における認定およびリリースプロセスにより、Amazon EKS での Kubernetes バージョンのサポート終了日は、Kubernetes プロジェクトがそのバージョンでアップストリームを停止した日以降になります。
よくある質問
Q: 1 つの Kubernetes のバージョンが Amazon EKS でサポートされる期間はどのくらいですか?
A: Kubernetes バージョンは、Amazon EKS で最初に利用可能になってから 14 か月間は完全にサポートされます。これは、Amazon EKS で利用可能なバージョンが、Kubernetes のアップストリームでサポートされなくなった場合でも当てはまります。当社では、Amazon EKS でサポートされている Kubernetes の各バージョンに適用されるセキュリティパッチをバックポートしています。
Q: Kubernetes バージョンのサポートが Amazon EKS で終了する際には通知が届きますか?
A: はい。お客様のアカウント内のいずれかのクラスターが、 Amazon EKS でリリースされてから約 12 か月が経過しサポート終了に近いKubernetes バージョンを実行している場合、Amazon EKS は 、AWS Personal Health Dashboard を通じて通知を送信します。通知にはサポート終了日が含まれます。通知は、サポート終了の日から 60 日以上前に送信されます。
Q: サポート終了日にはどうなりますか?
A: サポート終了日には、終了の対象となっているバージョンで新しい Amazon EKS クラスターを作成できなくなります。既存のコントロールプレーンは、Amazon EKS の段階的なデプロイプロセスを通じて、サポートされている最も古いバージョンに自動的に更新されます。コントロールプレーンの自動更新後は、クラスターアドオンと Amazon EC2 ノードを手動で更新する必要があります。詳細については、「Amazon EKS クラスターに必要な Kubernetes バージョンの更新方法 」を参照してください。
Q: サポート終了後にコントロールプレーンが自動的に更新されるのは、正確にはいつですか?
A: Amazon EKS での具体的なスケジュールは決まっていません。自動更新は、サポート終了日以降に任意のタイミングで実行される可能性があります。Amazon EKS の自動更新プロセスに頼ることなく、事前の対応により、コントロールプレーンを更新することをお勧めします。詳細については、「クラスターの更新」を参照してください。
Q: コントロールプレーンを 1 つのKubernetes バージョンに恒久的に維持することはできますか?
いいえ。AWS では、クラウドのセキュリティを最優先事項ととらえています。Amazon EKS では、サポート終了に達したバージョンで、コントロールプレーンを維持することはできません。
Q: Amazon EKS では、どの Kubernetes 機能がサポートされてますか?
A: Amazon EKS は、Kubernetes API で一般提供されているすべての機能と、デフォルトで有効になっているベータ機能をサポートしています。アルファ機能はサポートされません。
Q: Amazon EKS のマネージド型ノードグループは、クラスターのコントロールプレーンのバージョンとともに自動的に更新されますか?
A: いいえ。マネージドノード型グループでは、アカウントに Amazon EC2 インスタンスを作成しています。これらのインスタンスは、お客様または Amazon EKS がコントロールプレーンを更新しても、自動的にはアップグレードされません。Amazon EKS によってコントロールプレーンが自動更新された時点で、マネージド型ノードグループの Kubernetes バージョンは、コントロールプレーンより 1 つ以上前のバージョンになる可能性があります。マネージド型ノードグループに、コントロールプレーンより 1 つ以上前のバージョンである Kubernetes を実行しているインスタンスが含まれている場合、コンソール上のクラスターの [Configuration (設定)] タブにある、[Compute (コンピューティング)] タブの [Node Groups (ノードグループ)] セクションに、ノードグループの正常性に関する問題として表示されます。ノードグループで利用可能なバージョン更新がある場合は、コンソールのノードグループの横に、[Update now (今すぐ更新)] が表示されます。詳細については、「マネージド型ノードグループの更新」を参照してください。コントロールプレーンとノードでは、Kubernetes バージョンを同じに維持することをお勧めします。
Q: セルフマネージド型ノードグループは、クラスタコントーロールプレーンのバージョンとともに自動的に更新されますか?
A: いいえ。 セルフマネージド型ノードグループには、アカウント内の Amazon EC2 インスタンスが含まれています。これらのインスタンスは、お客様または Amazon
EKS がコントロールプレーンのバージョンを更新しても、自動的にはアップグレードされません。セルフマネージド型ノードグループは、更新が必要であることをコンソールに表示しません。更新が必要なノードを確認するには、クラスターの
[Overview (概要)] タブにある [Nodes (ノード)]1 のリストからノードを選択して、そこにインストールされている kubelet バージョンを表示します。ノードは手動で更新する必要があります。詳細については、「セルフマネージド型ノードの更新」を参照してください。
Kubernetes では、最大 2 つ前のマイナーバージョンに対して、コントロールプレーンとノード間の互換性が確認されています。例えば、1.19 ノードは、1.21
のコントロールプレーンによってオーケストレーションされた場合でも動作を継続します。ただし、コントロールプレーンの背後で、永続的に 2 つ前のマイナーバージョンであるノードを使用しながら、クラスターを実行することはお勧めしません。詳細については、Kubernetes
ドキュメントの「Kubernetes のバージョンおよびバージョンスキューのサポートポリシー
Q: クラスターコントロールプレーンのバージョンに対する自動アップグレードによって、Fargate で実行中のポッドも自動的にアップグレードされますか?
はい。Fargate ポッドは、AWS が所有するアカウントのインフラストラクチャで、Amazon EKS 側の 責任共有モデルに基づき実行されています。Amazon EKS は Kubernetes の削除 API を使用して、Fargate で実行されているポッドを正常に廃止しようとします。詳細については、Kubernetes
ドキュメントの「The Eviction API delete pod コマンドを発行します。削除後にポッドが自動的に再スケジュールされるように、Fargateポッドは、Kubernetes デプロイなどのレプリケーションコントローラーの一部として実行することを強くお勧めします。詳細については、Kubernetes
ドキュメントの「Deploymentskubelet バージョンでデプロイされます。
コントロールプレーンを更新する場合は、Fargate ノードを自分で更新する必要があります。Fargate ノードを更新するには、ノードと対応した Fargate
ポッドを削除した上で、ポッドを再デプロイします。新しいポッドは、クラスターと同じ kubelet バージョンでデプロイされます。
