Amazon EKS での利用可能な Kubernetes のバージョン Kubernetes 1.21 Kubernetes 1.20 Kubernetes 1.19 Kubernetes 1.18 Kubernetes 1.17 Amazon EKS Kubernetes リリースカレンダー Amazon EKS バージョンのサポートとよくある質問

Amazon EKS での Kubernetes のバージョン

Kubernetes プロジェクトは、、新機能、設計の更新、バグ修正を継続的に統合しています。コミュニティでは、Kubernetes の新しいマイナーバージョン (例:1.21) をリリースしています。これは、およそ 3 か月ごとにリリースされています。各マイナーバージョンは、最初にリリースされてから約 12 か月間サポートされます。

Amazon EKS での利用可能な Kubernetes のバージョン

現在、次の Kubernetes バージョンが、新しい Amazon EKS クラスターで利用可能です。

1.21.5
1.20.7
1.19.15
1.18.16

アプリケーションが特定のバージョンの Kubernetes を必要とする場合を除き、Amazon EKS がクラスター用にサポートしている、利用可能な最新の Kubernetes バージョンを選択することをお勧めします。新しい Kubernetes バージョンが Amazon EKS で利用可能になったら、利用可能な最新のバージョンが使用できるように、クラスターをタイムリーに更新することをお勧めします。クラスターを更新する手順については、「クラスターの更新」を参照してください。。Kubernetes リリースの詳細については、「Amazon EKS Kubernetes リリースカレンダーおよびAmazon EKS バージョンのサポートとよくある質問」を参照してください。。

注記

Kubernetes バージョン 1.23 のリリース以降、公式に公開された Amazon EKS AMI に含まれるランタイムは containerd のみとなります。Kurbernetes バージョン 1.17 から 1.21 では、デフォルトのランタイムとして Docker を使用しますが、現在サポートされているすべてのクラスターで、containerd を使用してワークロードをテストできるブートストラップフラグオプションがあります。詳細については、「Dockershim の廃止」を参照してください。

Kubernetes 1.21

Amazon EKS で Kubernetes 1.21 が利用可能になりました。Kubernetes 1.21 の詳細については、公式リリースのお知らせを参照してください。

重要

ポッド、サービス、およびノードでのデュアルスタックネットワーク (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 がノードのシャットダウンを認識して、そのノードのポッドを十分な時間をかけて適切に終了させることができます。今回の更新以前は、ノードのシャットダウンが行われる際に、ポッドが想定される終了ライフサイクルに従わなかったことが原因でした。これにより、ワークロードの問題が発生しました。systemd 経由で 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 の詳細については、公式リリースのお知らせを参照してください。

重要

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 のランタイムとして containerd に移行されます。さらなる詳細については、コンテナのロードマップでの問題を参照してください。
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 の詳細については、公式リリースのお知らせを参照してください。

重要

1.19 以降の Amazon EKS では、kubernetes.io/cluster/<cluster-name> タグが、クラスターの作成中に渡されたサブネットに追加されなくなります。このサブネットタグは、Kubernetes サービスコントローラーまたは AWS Load Balancer Controller により Elastic Load Balancer が配置される場所を、ユーザーが決定したい場合にのみ必要となります。クラスターの作成中に Amazon EKS に渡されるサブネットの要件については、更新された「クラスターー VPC とサブネットに関する考慮事項」を参照してください。
- 既存のクラスターを 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/v1 API を使用して、kubernetes.io/legacy-unknown リクエストを作成することはできません。
- 依然として、certificates.k8s.io/v1beta1 API で kubernetes.io/legacy-unknown 署名者名を使用しながら CSR を作成することは可能です
- また現在も、ノード以外のサーバー証明書や Webhook のために CSR が署名されるように、(certificates.k8s.io/v1beta1 API などから) リクエストできます。これらの 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> を追加する必要はなくなります。以前のバージョンを使用する場合は、すべてのポッドにこの変数を含める必要があります。
新しいクラスターには、externalTrafficPolicy で更新されたデフォルト値が含まれています。HealthyThresholdCount および UnhealthyThresholdCount は 2 つずつで、HealthCheckIntervalSeconds は 10 秒に短縮されます。古いバージョンで作成されアップグレードされたクラスターは、古い値を保持します。

完全な 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 のブログを参照してください。

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 を参照してください。

Amazon EKS Kubernetes リリースカレンダー

注記

月と年のみの日付はおおよその日付であり、確定後に正確な日付で更新されます。

Kubernetes バージョン	アップストリームのリリース	Amazon EKS リリース	Amazon EKS のサポート終了
1.17	2019 年 12 月 9 日	2020 年 7 月 10 日	2021 年 11 月 2 日
1.18	2020 年 3 月 23 日	2020 年 10 月 13 日	2022 年 3 月 31 日
1.19	2020 年 8 月 26 日	2021 年 2 月 16 日	2022年6月
1.20	2020 年 12 月 8 日	2021年5月18日	2022 年 9 月
1.21	2021 年 4 月 8 日	2021 年 7 月 19 日	2023 年 2 月
1.22	2021 年 8 月 4 日	2022 年 3 月	2023 年 5 月

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 で終了する際には通知が届きますか?

お客様のアカウント内のいずれかのクラスターが、 Amazon EKS でリリースされてから約 12 か月が経過しサポート終了に近いKubernetes バージョンを実行している場合、Amazon EKS は、AWS Health Dashboard を通じて通知を送信します。通知にはサポート終了日が含まれます。これは、通知の日から 60 日以上後です。

Q: サポート終了日にはどうなりますか?

A: サポート終了日には、終了の対象となっているバージョンで新しい Amazon EKS クラスターを作成できなくなります。既存のコントロールプレーンは、Amazon EKS の段階的なデプロイプロセスを通じて、サポートされている最も古いバージョンに自動的に更新されます。コントロールプレーンの自動更新後は、クラスターアドオンと Amazon EC2 ノードを手動で更新する必要があります。詳細については、「Amazon EKS クラスターに必要な Kubernetes バージョンの更新方法」を参照してください。

Q: サポート終了後にコントロールプレーンが自動的に更新されるのは、正確にはいつですか?

A: Amazon EKS での具体的なスケジュールは決まっていません。自動更新は、サポート終了日以降に任意のタイミングで実行される可能性があります。Amazon EKS の自動更新プロセスに頼ることなく、事前の対応により、コントロールプレーンを更新することをお勧めします。詳細については、「」を参照してくださいクラスターの更新

Q: コントロールプレーンを 1 つのKubernetes バージョンに恒久的に維持することはできますか?

いいえ。AWS では、クラウドのセキュリティを最優先事項ととらえています。特定の時点 (通常は 1 年) を過ぎると、Kubernetes コミュニティは CVE パッチのリリースを停止し、非推奨バージョンに対する CVE の提出を推奨しなくなります。つまり、古いバージョンの Kubernetes 固有の脆弱性が報告されない可能性があり、クラスターに脆弱性が発生した場合の通知や修復オプションがない状態で公開され続けることになります。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 のバージョンおよびバージョンスキューのサポートポリシー」を参照してください。コントロールプレーンとノードでは、同一の Kubernetes バージョンを維持することをお勧めします。

Q: クラスターコントロールプレーンのバージョンに対する自動アップグレードによって、Fargate で実行中のポッドも自動的にアップグレードされますか?

Fargate ポッドは、AWS が所有するアカウントのインフラストラクチャで、Amazon EKS 側の責任共有モデルに基づき実行されています。Amazon EKS は Kubernetes の削除 API を使用して、Fargate で実行されているポッドを正常に廃止しようとします。詳細については、Kubernetes ドキュメントの「The Eviction API 」を参照してください。削除できないポッドがある場合、Amazon EKS は Kubernetes の delete pod コマンドを発行します。削除後にポッドが自動的に再スケジュールされるように、Fargateポッドは、Kubernetes デプロイなどのレプリケーションコントローラーの一部として実行することを強くお勧めします。詳細については、Kubernetes ドキュメントの「Deployments」を参照してください。Fargate ポッドの新しいバージョンは、クラスターの更新されたコントロールプレーンバージョンと同じ kubelet バージョンでデプロイされます。

重要

コントロールプレーンを更新する場合は、Fargate ノードを自分で更新する必要があります。Fargate ノードを更新するには、ノードと対応した Fargate ポッドを削除した上で、ポッドを再デプロイします。新しいポッドは、クラスターと同じ kubelet バージョンでデプロイされます。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

コントロールプレーンのログ記録

プラットフォームのバージョン