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

「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」

Amazon EKS Kubernetes バージョン

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

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

現在、次の Kubernetes バージョンは、 の新しいクラスターで利用することができます。Amazon EKS:

  • 1.19.6

  • 1.18.9

  • 1.17.12

  • 1.16.15

  • 1.15.12

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

Kubernetes 1.19

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

Important

  • 1.19 以降、 はクラスターの作成時に渡されたサブネットに Amazon EKS タグを追加kubernetes.io/cluster/<cluster-name>しなくなりました。このサブネットタグは、Kubernetes サービスコントローラーまたは AWS Load Balancer コントローラーが 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 コントローラー、「」を参照してください。ロードバランサーを使用する場合のサブネットのタグ付けの詳細については、「」でのアプリケーションの負荷分散 Amazon EKSおよび「」を参照してくださいにおけるネットワーク負荷分散 Amazon EKS。

  • サービスアカウントの IAM ロールで使用するためにウェブ ID トークンファイルにアクセスする必要のある非ルートコンテナのセキュリティコンテキストを指定する必要がなくなりました。詳細についてはIAMサービスアカウントの ロール、「」および「」で射影されたサービスアカウントボリュームでのファイルアクセス許可処理の proposal を参照してくださいGitHub。

  • ポッド ID のウェブフックが更新され、不足しているスタートアッププローブGitHubの問題に対処しました。Webhook では、トークンの有効期限を制御する注釈もサポートされるようになりました。詳細については、GitHubプルリクエストを参照してください。

  • CoreDNS バージョン 1.8.0 は、 Amazon EKS 1.19 クラスターに推奨されるバージョンです。このバージョンは、新しい Amazon EKS 1.19 クラスターにデフォルトでインストールされます。詳細については、「 」を参照してください。 のインストールまたはアップグレードCoreDNS.

  • Amazon EKS 最適化には、Linux カーネルバージョン 5.4 for Kubernetes バージョン 1.19 Amazon Linux 2 AMIs が含まれます。詳細については、「 」を参照してください。Amazon EKS 最適化された Amazon Linux AMI.

  • CertificateSigningRequest API は、以下の変更certificates.k8s.io/v1により安定して昇格されました。

    • spec.signerName が必須になりました。kubernetes.io/legacy-unknown API certificates.k8s.io/v1 で の リクエストを作成することはできません。

    • CSRs API kubernetes.io/legacy-unknown を使用してcertificates.k8s.io/v1beta1、署名者名で を作成し続けることができます。

    • たとえば、 certificates.k8s.io/v1beta1 API を使用して、非ノードサーバー証明書 (ウェブフック) に対する への CSR の署名を引き続きリクエストできます。これらは自動承認CSRsされません。

    • 証明書を承認するには、権限のあるユーザーには kubectl 1.18.8 以降が必要です。

    証明書 v1 API の詳細については、Kubernetes ドキュメントの「Certificate Signing Requests」を参照してください。

Amazon EKS 以下の Kubernetes リソースは、Kubernetes コントロールプレーンが機能するために重要です。削除または編集しないことをお勧めします。

アクセス許可 Kind 名前空間 Reason
eks:certificate-controller Rolebinding kube-system コントロールプレーンの署名者および承認者機能に影響を与えます。
eks:certificate-controller Role kube-system コントロールプレーンの署名者および承認者機能に影響を与えます。
eks:certificate-controller ClusterRolebinding すべて kubelet が kubectl exec や などの特定のクラスター機能に影響するサーバー証明書をリクエストする機能に影響を与えkubectl logsます。

Kubernetes の以下の機能が Kubernetes 1.19 Amazon EKS クラスターでサポートされるようになりました。

  • ExtendedResourceToleration アドミッションコントローラーが有効になっています。このアドミッションコントローラーは、 などの拡張リソースをリクエストするポッドに taint の許容を自動的に追加するのでGPUs、手動で許容を追加する必要はありません。詳細については、Kubernetes ExtendedResourceToleration ドキュメントの「」を参照してください。

  • インツリー Kubernetes サービスコントローラーによってプロビジョニングされた Elastic Load Balancer (CLB および NLB) は、インスタンスターゲットとして含められたノードのフィルタリングをサポートします。これにより、大規模なクラスターでターゲットグループの制限に達するのを防ぐことができます。詳細については、Kubernetes ドキュメントの「Other ELB GitHub annotations」で関連するservice.beta.kubernetes.io/aws-load-balancer-target-node-labels問題と注釈を参照してください。

  • Pod Topology Spread が安定したステータスに達しました。トポロジ分散制約を使用して、リージョン、ゾーン、ノード、その他のユーザー定義トポロジドメインなどの障害ドメイン間でポッドをクラスター全体に分散する方法を制御できます。これにより、高可用性と効率的なリソース使用率を実現できます。詳細については、Kubernetes ドキュメントの「Pod Topology Spread Constraints」を参照してください。

  • Ingress API が一般公開されました。詳細については、Kubernetes ドキュメントの Ingress を参照してください。

  • EndpointSlices はデフォルトで有効になっています。EndpointSlices は、エンドポイント API の代わりに、サービスにバックアップする Pod の IP アドレス、ポート、準備状態、トポロジ情報を追跡するための、よりスケーラブルで拡張可能な新しい API です。詳細については、Kubernetes ブログEndpointSlicesの「Scaling Kubernetes Networking With」を参照してください。

  • シークレットと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 が で利用可能になりました。Amazon EKS. 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 クラスターでは、変更ウェブフックを使用するか、環境変数を手動で設定するかに関係なく、中国リージョンのサービスアカウントのAWS_DEFAULT_REGION=<region-code>ロールを使用するときに IAM 環境変数をポッドに含める必要がなくなりました。以前のバージョンのすべてのポッドに対して 変数を含める必要があります。

完全な Kubernetes 1.18 変更ログについては、https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md. を参照してください。

Kubernetes 1.17

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

重要

  • EKS で CSIMigrationAWS 機能フラグを有効にしていません。これは、詳細な移行手順とともに、将来のリリースで有効になる予定です。CSI 移行の詳細については、Kubernetes のブログ.を参照してください。

  • いずれかのAWS Fargateポッドに 1.16 より前のkubeletマイナーバージョンがある場合、1.16 から 1.17 へのクラスターの更新は失敗します。クラスターを 1.16 から 1.17 に更新する前にFargate、ポッドをリサイクルして、クラスターを 1.17 に更新する前にポッド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は正式リリースされました。この機能により、関連するロードバランサーも削除されるまで、サービスリソースは完全に削除されません。

  • カスタムリソースがデフォルト値をサポートするようになりました。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 が で利用可能になりました。Amazon EKS. Kubernetes 1.16 の詳細については、公式リリースのお知らせ.を参照してください。

重要

  • Kubernetes 1.16 は、多数の中止された を削除しますAPIs。 クラスターを 1.16 に更新する前に、アプリケーションの変更が必要になる場合があります。更新する前に、1.16 の更新の前提条件に慎重に従ってください。

  • 1.16 以降Amazon EKS、認証機関は SAN X.509 拡張機能を使用した証明書署名リクエストを優先します。これにより、EKS CA は からの SAN x509 拡張機能リクエストを優先しますGitHub。

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

  • 新しい注釈: service.beta.kubernetes.io/aws-load-balancer-eip-allocations は、Elastic IP アドレスを Network Load Balancer に割り当てるためにサービスタイプ LoadBalancer で利用可能です。詳細については、「AWS NLB による EIP 割り当てのサポートGitHub」を参照してください。

  • サービスロードバランサーのファイナライザー保護がベータ版になり、デフォルトで有効になりました。Service Load Balancer のファイナライザー保護により、AWS Network Load Balancer など、Kubernetes Service オブジェクトに割り当てられたロードバランサーリソースは、サービスが削除されたときに破棄または解放されます。詳細については、Kubernetes ドキュメントの「Garbage Collecting Load Balancers」を参照してください。

  • Kubernetes カスタムリソース定義とアドミッション Webhook 拡張メカニズムは、両方とも一般公開されています。詳細については、Kubernetes ドキュメントの「カスタムリソースと動的アドミッションコントロール」を参照してください。

  • サーバー側の適用機能がベータステータスになり、デフォルトで有効になっています。詳細については、Kubernetes ドキュメントの「Server Side Apply」を参照してください。

  • CustomResourceDefaulting 機能はベータ版に昇格され、デフォルトで有効になります。デフォルトは、apiextensions.k8s.io/v1 API を介して構造スキーマで指定することができます。詳細については、Kubernetes ドキュメントの「構造スキーマhttps://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schemaの指定」を参照してください。

完全な Kubernetes 1.16 変更ログについては、https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.16.md. を参照してください。

Kubernetes 1.15

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

重要

1.15 以降では、Amazon EKS により、クラスターが含まれている VPC にタグ付けされなくなりました。

  • クラスターの VPC 内のサブネットは、引き続きタグ付けされます。

  • VPC タグは、既存のクラスターの更新では 1.15 に変更されません。

重要

Amazon EKS は Pod Identity Webhook の再呼び出しポリシーを に設定IfNeededしています。 これによりApp Mesh、サイドカーインジェクターのような他の変更アドミッション Webhook によってオブジェクトが変更された場合、Webhook の再呼び出しが可能になります。App Mesh サイドカーインジェクターの詳細については、「サイドカーインジェクターのインストール.」を参照してください。

以下の機能が Kubernetes 1.15 Amazon EKS クラスターでサポートされるようになりました。

  • EKS では、Network Load Balancer の Transport Layer Security (TLS) 終了、アクセスログ、およびソース範囲の設定がサポートされるようになりました。詳細については、「 での AWS での Network Load Balancer のサポート」を参照してくださいGitHub。

  • オンザフライでバージョンを変換する機能など、カスタムリソース定義 (CRD) の柔軟性が向上しました。詳細については、「 CustomResourceDefinitions で を使用して Kubernetes API を拡張する」を参照してくださいGitHub。

  • NodeLocal DNSCache は、Kubernetes バージョン 1.15 クラスターのベータ版です。この機能は、クラスターノードで として DNS キャッシュエージェントを実行することで、クラスター DNS パフォーマンスを向上させるのに役立ちますDaemonSet。 詳細については、「 NodeLocal の KubernetesDNSCache クラスターでの の使用」を参照してくださいGitHub。

    注記

    CoreDNS で実行する場合はAmazon EC2、 設定force_tcpで を使用しないことをお勧めします。また、 options use-vc が で設定されていないことを確認してください/etc/resolv.conf。

完全な Kubernetes 1.15 変更ログについては、https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.15.md. を参照してください。

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

注記

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

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

Amazon EKS バージョンのサポートとよくある質問

Kubernetes バージョンに対する Kubernetes コミュニティのサポートに沿って、Amazon EKS は Kubernetes の少なくとも 4 つの本番稼働対応バージョンをいつでもサポートするよう努めています。Kubernetes の特定のマイナーバージョンのサポート終了日については、サポート終了日の最低 60 日前に発表します。Kubernetes の新しいバージョンの Amazon EKS の認定およびリリースプロセスにより、Amazon EKS の Kubernetes バージョンのサポート終了日は、Kubernetes プロジェクトがバージョンアップストリームのサポートを停止した日以降になります。

よくある質問

Q: Kubernetes のバージョンが でサポートされる期間はどのくらいですか?Amazon EKS?

A: Kubernetes バージョンは、 で最初に利用可能になってから 14 か月間は完全にサポートされます。Amazon EKS. これは、 で利用可能なバージョンがアップストリーム Kubernetes によってサポートされなくなった場合でも当てはまります。Amazon EKS. でサポートされている Kubernetes のバージョンに適用可能なセキュリティパッチはバックポートされています。Amazon EKS.

Q: で Kubernetes バージョンのサポートが終了したときに通知されますAmazon EKSか?

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

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

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

Q: サポート終了後にコントロールプレーンは自動的にいつ更新されますか?

A: Amazon EKS での具体的なスケジュールは決まっていません。自動更新は、サポート終了後いつでも行うことができます。Amazon EKS 自動更新プロセスに依存せずに、コントロールプレーンを更新してプロアクティブに対応することをお勧めします。詳細については、「 」を参照してください。クラスターの更新.

Q: コントロールプレーンを Kubernetes バージョンに無期限に残すことはできますか?

A: いいえ。 のクラウドセキュリティは最優先事項AWSです。 Amazon EKS では、サポート終了に達したバージョンでコントロールプレーンを維持することはできません。

Q: でサポートされている Kubernetes 機能Amazon EKSはどれですか?

A: は、Kubernetes API のすべての一般可用性機能およびデフォルトで有効になっているベータ機能Amazon EKSをサポートしています。アルファ機能はサポートされていません。

Q: Amazon EKS マネージド型ノードグループは、クラスターコントロールプレーンのバージョンに従って自動的に更新されますか?

A: いいえ。マネージド型ノードグループは、アカウントに Amazon EC2 インスタンスを作成します。これらのインスタンスは、お客様がコントロールプレーンを更新したとき、またはお客様がコントロールプレーンAmazon EKSを更新したときに自動的にアップグレードされません。でコントロールプレーンAmazon EKSを自動的に更新する場合、マネージド型ノードグループの Kubernetes バージョンは、コントロールプレーンよりも複数のバージョンになる場合があります。マネージド型ノードグループに、コントロールプレーンよりも複数のバージョン以前に Kubernetes のバージョンを実行しているインスタンスが含まれている場合、ノードグループには、 コンソールのクラスターの [設定] タブの [コンピューティング] タブの [ノードグループ] セクションにヘルスの問題があります。ノードグループに利用可能なバージョンの更新がある場合、[Update (更新)] がコンソールのノードグループの横に表示されます。詳細については、「 」を参照してください。マネージド型ノードグループの更新. コントロールプレーンとノードで同じ Kubernetes バージョンを維持することをお勧めします。

Q: 自己管理型ノードグループは、クラスターコントロールプレーンバージョンとともに自動的に更新されますか?

A: いいえ。セルフマネージド型ノードグループには、アカウントの Amazon EC2 インスタンスが含まれます。これらのインスタンスは、ユーザーまたはコントロールプレーンのバージョンAmazon EKSを更新しても、自動的にアップグレードされません。セルフマネージド型ノードグループには、更新が必要であることがコンソールに一切表示されません。ノードにインストールされているkubeletバージョンを表示するには、クラスターの [Overview (概要)] タブの [Nodes (ノード)] リストでノードを選択して、どのノードを更新する必要があるかを判断します。ノードを手動で更新する必要があります。詳細については、「 」を参照してください。セルフマネージド型ノードの更新.

Kubernetes プロジェクトは、最大 2 つのマイナーバージョンについて、コントロールプレーンとノード間の互換性をテストします。たとえば、 1.17 ノードは1.19、コントロールプレーンによってオーケストレーションされたときにも動作し続けます。ただし、コントロールプレーンの背後にある 2 つのマイナーバージョンのノードでクラスターを実行することはお勧めしません。詳細については、Kubernetes ドキュメントの「Kubernetes バージョンとバージョンスキューのサポートポリシー」を参照してください。コントロールプレーンとノードで同じ Kubernetes バージョンを維持することをお勧めします。

Q: ポッドは、自動クラスターコントロールプレーンバージョンアップグレードでFargate自動的にアップグレードされますか?

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

重要

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