このページの改善にご協力ください
本ユーザーガイドの改善にご協力いただけませんか? このページの下部までスクロールし、[GitHub でこのページの編集] を選択します。皆さまにご協力いただくことで、あらゆる人々に使いやすいユーザーガイドになります。
延長サポートバージョンのリリースノート
このトピックでは、延長サポートにおいて各 Kubernetes バージョンで注意すべき重要な変更点を説明します。アップグレードするときは、クラスターの古いバージョンと新しいバージョン間で発生した変更を注意深く確認してください。
Kubernetes 1.25
Kubernetes 1.25
が Amazon EKS で利用可能になりました。Kubernetes 1.25
の詳細については、「公式リリースのお知らせ
重要
-
Kubernetes バージョン
1.25
以降、Amazon EC2P2
インスタンスを Amazon EKS に最適化された高速 Amazon Linux AMI で使用するには、追加設定が必要です。これらの Kubernetes バージョン1.25
以降向けの AMI はNVIDIA 525
シリーズまたはそれ以降のドライバーに対応しており、P2
インスタンスとの互換性がありません。NVIDIA 525
シリーズおよびそれ以降のドライバーはP3
、P4
、P5
インスタンスとの互換性があるため、これらのインスタンスを Kubernetes バージョン1.25
またはそれ以降の AMI で使用することができます。Amazon EKS クラスターをバージョン1.25
にアップグレードする前に、P2
インスタンスをP3
、P4
、P5
インスタンスに移行します。また、NVIDIA 525
シリーズまたはそれ以降と連携するように、アプリケーションを自発的にアップグレードする必要があります。新しいNVIDIA 525
シリーズ以降のドライバーは、2024 年 1 月後半に Kubernetes バージョン1.23
および1.24
にバックポートする予定です。 -
PodSecurityPolicy
(PSP) は Kubernetes1.25
で削除されます。PSPs は、Pod Security Admission (PSA)および Pod Security Standards (PSS) に置き換えられます。PSA は、PSS で概説されているセキュリティコントロールを実装する組み込みのアドミッションコントローラーです。PSA および PSS は Kubernetes 1.25
で安定状態に移行し、Amazon EKS ではデフォルトで有効になります。クラスター内に PSPs がある場合は、クラスターをバージョン1.25
にアップグレードする前に、PSP から組み込みの Kubernetes PSS または Policy as Code ソリューションに移行してください。PSP から移行しない場合、ワークロードが中断される可能性があります。詳細については、「ポッドセキュリティポリシー (PSP) の削除に関するよくある質問」を参照してください。 -
Kubernetes バージョン
1.25
には、API の優先度と公平性 (APF) として知られる、既存の機能の動作が変わる変更が含まれています。APF は、リクエスト量が増加しているときに発生する可能性のある過負荷から API サーバーを保護する役割を果たします。保護は、所定の時点で処理できる同時リクエストの数に制限を設けることで行なわれます。この処理は、さまざまなワークロードやユーザーからのリクエストに明確な優先レベルや制限を適用することで実施されます。このアプローチにより、重要なアプリケーションや優先度の高いリクエストを優先的に扱いながら、優先度の低いリクエストが API サーバーを圧迫するのを防ぐことができます。詳しくは、Kubernetes ドキュメントの「API の優先順位と公平性」または EKS ベストプラクティスガイドの「API の優先順位と公平性 」を参照してください。 これらのアップデートは PR #10352
および PR #118601 で導入されました。以前は、APF はすべてのタイプのリクエストを一様に処理し、各リクエストが同時リクエスト制限の 1 単位を消費していました。APF の動作が変更されたことで、API サーバーに非常に大きな負荷がかかる要因となる LIST
リクエストにより多くの同時実行単位が割り当てられるようになりました。API サーバーは、LIST
リクエストによって返されるオブジェクトの数を推定します。返されるオブジェクトの数に比例した同時実行単位を割り当てます。Amazon EKS バージョン
1.25
以降にアップグレードすると、このアップデートされた動作により、多量のLIST
リクエストを持つ (以前は問題なく機能していた) ワークロードに、レート制限が発生する可能性があります。これは HTTP 429 のレスポンスコードとして表示されます。LIST
リクエストへのレート制限により、ワークロードの中断が発生する可能性を回避するため、ワークロードを再構築してこれらのリクエストのレートを減らすことを強くお勧めします。または、APF 設定を調整して、重要なリクエストにより多くの容量を割り当てて、重要でないリクエストに割り当てる容量を減らすことで、この問題を解決することもできます。これらの緩和方法の詳細については、EKS ベストプラクティスガイドの「リクエストがドロップされるのを防ぐには」を参照してください。 -
Amazon EKS
1.25
には、更新された YAML ライブラリを含むクラスター認証の機能強化が含まれています。kube-system
名前空間で見つかったaws-auth
ConfigMap
の YAML の値がマクロで始まり、最初の文字が中括弧である場合、中括弧 ({ }
) の前後に引用符 (“ ”
) を追加する必要があります。これは、aws-iam-authenticator
バージョンv0.6.3
によって Amazon EKS1.25
でaws-auth
ConfigMap
が正確に解析されるようにするために必要です。 -
EndpointSlice
のベータ API バージョン (discovery.k8s.io/v1beta1
) は Kubernetes1.21
で非推奨となっており、Kubernetes1.25
現在は提供されていません。この API はdiscovery.k8s.io/v1
に更新されました。詳細については、Kubernetes ドキュメントの「EndpointSlice
」を参照してください。AWS Load Balancer Controller v2.4.6
以前は、v1beta1
エンドポイントを使用してEndpointSlices
と通信していました。AWS Load Balancer Controller のためにEndpointSlices
の設定を使用している場合は、Amazon EKS クラスターを1.25
にアップグレードする前に AWS Load Balancer Controllerv2.4.7
にアップグレードする必要があります。AWS Load Balancer Controller のためにEndpointSlices
の設定を使用しているときに1.25
にアップグレードすると、コントローラーがクラッシュし、ワークロードが中断されます。コントローラーをアップグレードするには、「AWS Load Balancer Controller とは」を参照してください。
-
SeccompDefault
は、Kubernetes1.25
でベータ版に昇格しました。kubelet
を設定するときに--seccomp-default
フラグを設定すると、コンテナランタイムは unconfined (seccomp disabled
) モードではなく、そのRuntimeDefault
seccomp
プロファイルを使用します。デフォルトプロファイルは、ワークロードの機能を維持しながら、セキュリティデフォルトの強力なセットを提供します。このフラグは利用可能ですが、Amazon EKS はデフォルトでこのフラグを有効にしないため、Amazon EKS の動作は事実上変更されていません。必要に応じて、ノードでこれを有効にすることができます。詳細については、Kubernetes ドキュメントのチュートリアル「seccomp を使用してコンテナの Syscall を制限する」を参照してください。 -
Docker (
Dockershim
とも呼ばれる) のコンテナランタイムインターフェイス (CRI) のサポートは、Kubernetes1.24
以降から削除されました。Kubernetes1.24
以降のクラスター用の Amazon EKS の公式 AMIs における唯一のコンテナランタイムはcontainerd
です。Amazon EKS1.24
以降に更新する前に、サポートされなくなったブートストラップスクリプトフラグへの参照をすべて削除する必要があります。詳細については、「Amazon EKS は Dockershim のサポートを終了しました」を参照してください。 -
ワイルドカードクエリのサポートは CoreDNS
1.8.7
で非推奨となり、CoreDNS1.9
で削除されました。これはセキュリティ対策として行われました。ワイルドカードクエリは機能しなくなり、IP アドレスの代わりにNXDOMAIN
を返します。 -
Kubernetes API サーバーの
goaway-chance
オプションを使用すると、接続がランダムに閉じることで、 HTTP/2
クライアント接続が単一の API サーバーインスタンスでスタックされることを防ぐことができます。接続が閉じると、クライアントは再接続を試み、負荷分散の結果として別の API サーバーにアクセスする可能性があります。Amazon EKS バージョン1.25
では、goaway-chance
フラグが有効になっています。Amazon EKS クラスターで実行されているワークロードでHTTP GOAWAY
と互換性のないクライアントが使用されている場合は、接続終了時に再接続することで GOAWAY
を処理できるようにクライアントを更新することをお勧めします。
Kubernetes 1.25
変更履歴の全文については、「https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.25.md#changelog-since-v1240
Kubernetes 1.24
Kubernetes 1.24
が Amazon EKS で利用可能になりました。Kubernetes 1.24
の詳細については、「公式リリースのお知らせ
重要
-
Kubernetes
1.24
以降、新しいベータ版 API はデフォルトではクラスターで有効になっていません。デフォルトでは、既存のベータ API と既存のベータ API の新しいバージョンは引き続き有効になっています。Amazon EKS はアップストリーム Kubernetes1.24
と同じ動作をします。新規および既存の両方の API 操作の新機能を制御する機能ゲートは、デフォルトで有効になっています。これはアップストリーム Kubernetes と一致しています。詳細については、「GitHub」の「KEP-3136: ベータ API はデフォルトでオフになっている」を参照してください。 -
Docker (Dockershim とも呼ばれる) のコンテナランタイムインターフェイス (CRI) のサポートは、Kubernetes
1.24
から削除されました。Amazon EKS 公式 AMI には唯一のランタイムとして containerd があります。Amazon EKS1.24
以降に移行する前に、サポートされなくなったブートストラップスクリプトフラグへの参照をすべて削除する必要があります。また、ワーカーノードで IP 転送が有効になっていることを確認してください。詳細については、「Amazon EKS は Dockershim のサポートを終了しました」を参照してください。 -
Fluentd をすでに Container Insights 用に構成している場合、クラスターを更新する前に Fluentd を Fluent Bit に移行する必要があります。Fluentd パーサーは JSON 形式のログメッセージのみを解析するように構成されています。
dockerd
とは異なり、containerd
コンテナランタイムには JSON 形式ではないログメッセージがあります。Fluent Bit に移行しないと、構成された Fluentd's パーサーの一部が Fluentd コンテナー内で大量のエラーを生成します。移行の詳細については、「CloudWatch Logs へログを送信する DaemonSet として Fluent Bit を設定する」を参照してください。 -
Kubernetes
1.23
以前のバージョンでは、検証不能な IP と DNS サブジェクト代替名 (SAN) を含むkubelet
サービング証明書は、検証不能な SAN とともに自動的に発行されます。これらの検証不能な SAN は、プロビジョニングされた証明書から除外されます。バージョン1.24
以降のクラスターでは、SAN を検証できない場合、kubelet
サービング証明書は発行されません。これにより、kubectl
exec コマンドとkubectl
ログコマンドが機能しなくなります。詳細については、「クラスターをKubernetes 1.24 にアップグレードする前の証明書署名に関する考慮事項」を参照してください。 -
Fluent Bit を使用する Amazon EKS
1.23
クラスターをアップグレードする場合は、k8s/1.3.12
以降のものが実行中であることを確認する必要があります。これを行うには、GitHub から最新の該当する Fluent Bit YAML ファイルを再適用します。詳細については、「Amazon CloudWatch ユーザーガイド」の「Fluent Bit のセットアップ」を参照してください。
-
Topology Aware Hints を使用すると、クラスターワーカーノードが複数のアベイラビリティーゾーンにデプロイされている場合に、トラフィックをゾーン内に保持する設定を指定できます。ゾーン内でトラフィックをルーティングすると、コストを削減し、ネットワークパフォーマンスを向上させることができます。デフォルトでは、Topology Aware Hints は Amazon EKS
1.24
で有効になっています。詳細については、「Kubernetes ドキュメント」の「トポロジー対応のヒント」を参照してください。 -
PodSecurityPolicy
(PSP) は、Kubernetes1.25
で削除される予定です。PSPs は、ポッドセキュリティアドミッション (PSA)に置き換えられています。PSA は、ポッドセキュリティ標準 (PSS) で概説されているセキュリティコントロールを使用するビルトインのアドミッションコントローラーです。PSA と PSS はどちらもベータ機能であり、Amazon EKS ではデフォルトで有効になっています。バージョン 1.25
での PSP の削除に対処するには、Amazon EKS に PSS を実装することをお勧めします。詳細については、「AWS ブログ」の「Amazon EKS でのポッドセキュリティ標準の実装」を参照してください。 -
client.authentication.k8s.io/v1alpha1
ExecCredential は、Kubernetes1.24
で削除されます。ExecCredential API は、Kubernetes1.22
で一般に利用できるようになりました。v1alpha1
API に依存する client-go 認証情報プラグインを使用する場合は、v1
API への移行方法について、プラグインのディストリビューターにお問い合わせください。 -
Kubernetes
1.24
については、アップストリームの Cluster Autoscaler プロジェクトに機能を提供しました。この機能は、Amazon EKS のマネージド型ノードグループのゼロノードへのスケーリングとノードからのスケーリングを簡素化します。以前は、Cluster Autoscaler がゼロノードにスケーリングされたマネージド型ノードグループのリソース、ラベル、テイントを理解するには、基盤となる Amazon EC2 Auto Scaling グループに、それが担当するノードの詳細情報をタグ付けする必要がありました。現在、マネージド型ノードグループに実行中のノードがない場合、Cluster Autoscaler は Amazon EKSDescribeNodegroup
API 操作を呼び出します。この API オペレーションは、Cluster Autoscaler がマネージド型ノードグループのリソース、ラベル、テイントについて必要とする情報を提供します。この機能を使用するには、Cluster Autoscaler サービスアカウントの IAM ポリシーにeks:DescribeNodegroup
アクセス許可を追加する必要があります。Amazon EKS マネージド型ノードグループを強化する Auto Scaling グループの Cluster Autoscaler タグの値がノードグループ自体と競合する場合、Cluster Autoscaler は Auto Scaling グループタグの値を使用します。これは、必要に応じて値をオーバーライドできるようにするためです。詳細については、「Autoscaling」を参照してください。 -
Amazon EKS
1.24
で Inferentia または Trainium インスタンスタイプを使用する場合は、AWS Neuron デバイスプラグインバージョン 1.9.3.0 以降にアップグレードする必要があります。詳細については、「AWS Neuron ドキュメント」の「Neuron K8 リリース [1.9.3.0]」を参照してください。 -
Containerd
では、IPv6
が Pods 用にデフォルトで有効になっています。これは、ノードのカーネル設定を Pod ネットワークの名前空間に適用します。このため、Pod 内のコンテナはIPv4
(127.0.0.1
) とIPv6
(::1
) の両方のループバックアドレスにバインドされます。IPv6
はデフォルトの通信用プロトコルです。クラスターをバージョン1.24
に更新する前に、マルチコンテナ Pods をテストすることをお勧めします。ループバックインターフェイスのすべての IP アドレスにバインドできるようにアプリを変更します。ライブラリの大部分はIPv6
バインディングを有効にします。これはIPv4
との下位互換性を備えています。アプリケーションコードを変更できない場合、次の 2 つのオプションがあります。-
init
コンテナを実行し、disable ipv6
をtrue
(sysctl -w net.ipv6.conf.all.disable_ipv6=1
) に設定します。 -
アプリケーション Pods と一緒に
init
コンテナを挿入するように MutatingAdmissionWebhookを設定します。
すべてのノードですべての Pods 用に
IPv6
をブロックする必要がある場合、インスタンスでIPv6
を無効にしなければならない場合があります。 -
-
Kubernetes API サーバーの
goaway-chance
オプションを使用すると、接続がランダムに閉じることで、 HTTP/2
クライアント接続が単一の API サーバーインスタンスでスタックされることを防ぐことができます。接続が閉じると、クライアントは再接続を試み、負荷分散の結果として別の API サーバーにアクセスする可能性があります。Amazon EKS バージョン1.24
では、goaway-chance
フラグが有効になっています。Amazon EKS クラスターで実行されているワークロードでHTTP GOAWAY
と互換性のないクライアントが使用されている場合は、接続終了時に再接続することで GOAWAY
を処理できるようにクライアントを更新することをお勧めします。
Kubernetes 1.24
変更履歴の全文については、「https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#changelog-since-v1230
Kubernetes 1.23
Kubernetes 1.23
が Amazon EKS で利用可能になりました。Kubernetes 1.23
の詳細については、「公式リリースのお知らせ
重要
-
Kubernetes ツリー内からコンテナストレージインターフェイス (CSI) ボリュームへの移行機能が有効になっています。この機能により、Amazon EBS の既存の Kubernetes ツリー内ストレージプラグインを、対応する Amazon EBS CSI ドライバーに置き換えることができます。詳細については、Kubernetes ブログの「Kubernetes 1.17 機能: Kubernetes ツリー内から CSI ボリュームへの移行機能がベータ版に移行
」を参照してください。 この機能は、ツリー内 API を同等の CSI API に変換し、代替 CSI ドライバーにオペレーションを委任します。この機能を使用すると、これらのワークロードに属する既存の
StorageClass
、PersistentVolume
、およびPersistentVolumeClaim
オブジェクトを使用する場合、顕著な変化はほとんどない可能性が高いです。この機能により、Kubernetes は、すべてのストレージ管理オペレーションをツリー内プラグインから CSI ドライバーに委任できます。既存のクラスターで Amazon EBS ボリュームを使用する場合は、クラスターをバージョン1.23
に更新する前に、クラスターで Amazon EBS CSI ドライバーをインストールします。既存のクラスターを更新する前にドライバーをインストールしないと、ワークロードが中断される可能性があります。Amazon EBS ボリュームを使用するワークロードを新しい1.23
クラスターでデプロイする場合は、クラスターにワークロードをデプロイする前に、クラスターに Amazon EBS CSI ドライバーをインストールします。クラスターに Amazon EBS CSI ドライバーをインストールする方法については、「Amazon EBS CSI ドライバー」を参照してください。移行機能に関するよくある質問については、「Amazon EBS CSI 移行に関するよくある質問」を参照してください。 -
AWS によって公開されている Amazon EKS 最適化 Windows AMI の延長サポートは、Kubernetes バージョン
1.23
では利用できませんが、Kubernetes バージョン1.24
以降では利用できます。
-
Kubernetes はバージョン
1.20
でのdockershim
のサポートを停止し、バージョン1.24
でdockershim
を削除しました。詳細については、Kubernetes ブログの「Kubernetes は Dockershim から以降: コミットメントと次のステップ」を参照してください。Amazon EKS は、Amazon EKS バージョン 1.24
以降、dockershim
のサポートを終了します。Amazon EKS バージョン1.24
から、Amazon EKS 公式 AMI は唯一のランタイムとしてcontainerd
を備えることになります。Amazon EKS バージョン
1.23
は引き続きdockershim
をサポートしますが、今すぐアプリケーションのテストを開始して、Docker 依存関係を特定して削除することをお勧めします。これにより、クラスターをバージョン1.24
に更新する準備が整います。dockershim
の削除の詳細については、「Amazon EKS は Dockershim のサポートを終了しました」を参照してください。 -
Kubernetes は、Pods、サービス、およびノード向けに
IPv4
/IPv6
デュアルスタックネットワーキングの一般提供を開始しました。ただし、Amazon EKS と Amazon VPC CNI plugin for Kubernetes では、デュアルスタックネットワークをサポートしていません。クラスターはIPv4
またはIPv6
アドレスを Pods およびサービスに割り当てることができますが、両方のアドレスタイプを割り当てることはできません。 -
Kubernetes は、ポッドセキュリティアドミッション (PSA) 機能のベータ版の提供を開始しました。この機能は、デフォルトで有効になっています。詳細については、Kubernetes のドキュメントの「Pod Security Admission
」を参照してください。PSA は、ポッドセキュリティポリシー (PSP) アドミッションコントローラーを置き換えます。PSP アドミッションコントローラーはサポートされておらず、Kubernetes バージョン 1.25
で削除される予定です。PSP アドミッションコントローラーは、適用レベルを設定する特定の名前空間ラベルに基づいて、名前空間の Pods に対して Pod セキュリティ標準を適用します。詳細については、「Amazon EKS のベストプラクティスガイド」の「Pod Security Standards (PSS) and Pod Security Admission (PSA)
」(Pod Security Standards (PSS) および Pod Security Admission (PSA)) を参照してください。 -
クラスターでデプロイされる
kube-proxy
イメージは、Amazon EKS Distro (EKS-D) によって維持される最小基本イメージとなりました。イメージには最小限のパッケージが含まれており、シェルやパッケージマネージャーは含まれていません。 -
Kubernetes は、エフェメラルコンテナのベータ版の提供を開始しました。エフェメラルコンテナは、既存の Pod と同じ名前空間で実行される一時的なコンテナです。これらを使用して、トラブルシューティングやデバッグの目的で Pods およびコンテナの状態を観察できます。これは、コンテナがクラッシュしたか、コンテナイメージにデバッグユーティリティが含まれていないことを理由として
kubectl exec
が不十分である場合に、インタラクティブなトラブルシューティングに特に役立ちます。デバッグユーティリティを含むコンテナの例は、distroless イメージです。詳細については、Kubernetes ドキュメントの「Debugging with an ephemeral debug container 」(エフェメラルデバッグコンテナを使用したデバッグ) を参照してください。 -
Kubernetes は、
HorizontalPodAutoscaler
autoscaling/v2
の安定した API の一般提供を開始しました。HorizontalPodAutoscaler
autoscaling/v2beta2
API は非推奨です。1.26
ではご利用いただけなくなります。 -
Kubernetes API サーバーの
goaway-chance
オプションを使用すると、接続がランダムに閉じることで、 HTTP/2
クライアント接続が単一の API サーバーインスタンスでスタックされることを防ぐことができます。接続が閉じると、クライアントは再接続を試み、負荷分散の結果として別の API サーバーにアクセスする可能性があります。Amazon EKS バージョン1.23
では、goaway-chance
フラグが有効になっています。Amazon EKS クラスターで実行されているワークロードでHTTP GOAWAY
と互換性のないクライアントが使用されている場合は、接続終了時に再接続することで GOAWAY
を処理できるようにクライアントを更新することをお勧めします。
Kubernetes 1.23
変更履歴の全文については、「https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md#changelog-since-v1220