標準サポートバージョンのリリースノート - Amazon EKS

標準サポートバージョンのリリースノート

このトピックでは、標準サポートの各 Kubernetes バージョンで注意すべき重要な変更点を説明します。アップグレードするときは、クラスターの古いバージョンと新しいバージョン間で発生した変更を注意深く確認してください。

注記

1.24 以降のクラスターでは、公式に公開された Amazon EKS AMI には、唯一のランタイムとして containerd が含まれています。1.24 よりも前の Kubernetes バージョンは、デフォルトのランタイムとして Docker を使用します。これらのバージョンには、containerd を使用してサポートされているクラスターでワークロードをテストできるブートストラップフラグオプションがあります。詳細については、「Amazon EKS は Dockershim のサポートを終了しました」を参照してください。

Kubernetes 1.29

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

重要
  • 非推奨の FlowSchemaflowcontrol.apiserver.k8s.io/v1beta2 API バージョンと PriorityLevelConfiguration は、Kubernetes v1.29 で現在は提供されていません。非推奨のベータ API グループを使用するマニフェストまたはクライアントソフトウェアがある場合は、v1.29 にアップグレードする前にこれらを変更する必要があります。

  • Node オブジェクトの .status.kubeProxyVersion フィールドは非推奨となり、Kubernetes プロジェクトでは今後のリリースでそのフィールドを削除することが提案されています。非推奨のフィールドは正確ではなく、従来は kubelet によって管理されていましたが、実際には kube-proxy バージョンを認識できず、kube-proxy が実行されているかどうかも判別できませんでした。クライアントソフトウェアでこのフィールドを使用している場合は、停止してください。かかるフィールドの情報に信頼性はなく、現在は非推奨です。

  • Kubernetes 1.29 で潜在的なアタックサーフェスを減らすため、LegacyServiceAccountTokenCleanUp 機能は、レガシーの自動生成されたシークレットベースのトークンを長期間 (デフォルトでは 1 年) 使用されていない場合は無効としてラベル付けし、無効としてマークされた後に長期間使用が試みられなかった場合は自動的に削除します (デフォルトではその後 1 年)。このようなトークンを識別するには、以下を実行してください。

    kubectl get cm kube-apiserver-legacy-service-account-token-tracking -nkube-system

Kubernetes 1.29 変更履歴の全文については、「https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md#changelog-since-v1280」を参照してください。

Kubernetes 1.28

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

  • Kubernetes v1.28 により、n-2 から n-3 へ、1 つのマイナーバージョンごとのコアノードとコントロールプレーンコンポーネントの間でサポートされるスキューが拡張されました。これにより、サポートされている最も古いマイナーバージョンのノードコンポーネント (kubelet および kube-proxy) が、サポートされている最新のマイナーバージョンのコントロールプレーンコンポーネント (kube-apiserverkube-schedulerkube-controller-managercloud-controller-manager) と連携できるようになりました。

  • Pod GC Controller にあるメトリクス force_delete_pods_total および force_delete_pod_errors_total は、ポッドの強制削除をすべて考慮するよう拡張されました。ポッドが強制的に削除される理由が、ポッドが終了しているのか、孤立しているのか、サービス外テイントで終了しているのか、あるいは終了してスケジュールされていないのかを示す理由がメトリックに追加されます。

  • PersistentVolume (PV) コントローラーは、storageClassName が設定されておらずバインドされていない PersistentVolumeClaim にデフォルトの StorageClass を自動的に割り当てるように変更されました。さらに、API サーバー内の PersistentVolumeClaim アドミッション検証メカニズムが調整され、値が未設定の状態から実際の StorageClass 名に変更できるようになりました。

Kubernetes 1.28 変更履歴の全文については、「https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.28.md#changelog-since-v1270」を参照してください。

Kubernetes 1.27

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

重要
  • アルファ seccomp アノテーション seccomp.security.alpha.kubernetes.io/pod と container.seccomp.security.alpha.kubernetes.io アノテーションのサポートは削除されました。アルファ seccomp アノテーションは 1.19 で非推奨となり、1.27 で削除されたことで、seccomp アノテーションを持つ Pods に seccomp フィールドが自動的に入力されなくなります。代わりに、Pods またはコンテナの securityContext.seccompProfile フィールドを使用して seccomp プロファイルを構成してください。クラスターで非推奨のアルファ seccomp アノテーションを使用しているかどうかを確認するには、次のコマンドを実行します。

    kubectl get pods --all-namespaces -o json | grep -E 'seccomp.security.alpha.kubernetes.io/pod|container.seccomp.security.alpha.kubernetes.io'
  • kubelet の --container-runtime コマンドライン引数が削除されました。1.24 以降、Amazon EKS のデフォルトのコンテナランタイムが containerd となっており、これによりコンテナランタイムを指定する必要がなくなりました。1.27 以降、Amazon EKS は、ブートストラップスクリプトに渡された --container-runtime 引数を無視します。ノードのブートストラッププロセス中のエラーを防ぐために、この引数を --kubelet-extra-args に渡さないことが重要です。すべてのノード作成ワークフローとビルドスクリプトから --container-runtime 引数を削除する必要があります。

  • Kubernetes 1.27 の kubelet は、デフォルトの kubeAPIQPS を 50 に、kubeAPIBurst を 100 に増やしました。これらの機能強化により、kubelet がより大量の API クエリを処理できるようになり、応答時間とパフォーマンスが向上します。  スケーリング要件により、Pods に対する需要が増加した場合、修正されたデフォルト値により、kubelet は増加したワークロードを効率的に管理できるようになります。その結果、Pod の起動が速くなり、クラスター操作がより効率的になります。

  • よりきめ細かい Pod トポロジを使用して、minDomain などのポリシーを分散できます。このパラメータにより、Pods を分散させる必要のあるドメインの最小数を指定できます。nodeAffinityPolicy および nodeTaintPolicy を使用することで、Pod の分散を管理する際の粒度をさらに細かくすることができます。これは、ノードのアフィニティ、テイント、Pod's 仕様の topologySpreadConstraints の matchLabelKeys フィールドによって異なります。これにより、ローリングアップグレード後の分散計算のために Pods を選択できます。

  • Kubernetes1.27 は PersistentVolumeClaims (PVCs) の存続期間を制御する StatefulSets の新しいポリシーメカニズムをベータ版に昇格しました。新しい PVC リテンションポリシーでは、StatefulSet が削除されたとき、または StatefulSet 内のレプリカがスケールダウンされたときに、StatefulSet スペックテンプレートから生成された PVCs を自動的に削除するか、保持するかを指定できます。

  • Kubernetes API サーバーの goaway-chance オプションを使用すると、接続がランダムに閉じることで、HTTP/2 クライアント接続が単一の API サーバーインスタンスでスタックされることを防ぐことができます。接続が閉じると、クライアントは再接続を試み、負荷分散の結果として別の API サーバーにアクセスする可能性があります。Amazon EKS バージョン 1.27 では、goaway-chance フラグが有効になっています。Amazon EKS クラスターで実行されているワークロードで HTTP GOAWAY と互換性のないクライアントが使用されている場合は、接続終了時に再接続することで GOAWAY を処理できるようにクライアントを更新することをお勧めします。

Kubernetes 1.27 変更履歴の全文については、「https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.27.md#changelog-since-v1260」を参照してください。

Kubernetes 1.26

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

重要

Kubernetes 1.26 では、CRI v1alpha2 のサポートは終了しています。この結果、コンテナランタイムが CRI v1 をサポートしていない場合、kubelet はノードを登録しなくなります。これは、Kubernetes 1.26 は containerd のマイナーバージョン 1.5 以前のバージョンをサポートされていないことも意味します。containerd を使用している場合は、ノードを Kubernetes 1.26 にアップグレードする前に containerd バージョン 1.6.0 以降にアップグレードする必要があります。また、v1alpha2 のみをサポートする他のコンテナランタイムもアップグレードする必要があります。詳細については、コンテナランタイムベンダーにお問い合わせください。デフォルトでは、Amazon Linux および Bottlerocket AMI には containerd バージョン 1.6.6 が含まれます。

  • Kubernetes 1.26 にアップグレードする前に、Amazon VPC CNI plugin for Kubernetes をバージョン 1.12 以降にアップグレードしてください。Amazon VPC CNI plugin for Kubernetes バージョン 1.12 またはそれ以降にアップグレードしていない場合、Amazon VPC CNI plugin for Kubernetes はクラッシュします。詳細については、「Amazon VPC CNI plugin for Kubernetes Amazon EKS アドオンの使用」を参照してください。

  • Kubernetes API サーバーの goaway-chance オプションを使用すると、接続がランダムに閉じることで、HTTP/2 クライアント接続が単一の API サーバーインスタンスでスタックされることを防ぐことができます。接続が閉じると、クライアントは再接続を試み、負荷分散の結果として別の API サーバーにアクセスする可能性があります。Amazon EKS バージョン 1.26 では、goaway-chance フラグが有効になっています。Amazon EKS クラスターで実行されているワークロードで HTTP GOAWAY と互換性のないクライアントが使用されている場合は、接続終了時に再接続することで GOAWAY を処理できるようにクライアントを更新することをお勧めします。

Kubernetes 1.26 変更履歴の全文については、「https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.26.md#changelog-since-v1250」を参照してください。

Kubernetes 1.25

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

重要
  • Kubernetes バージョン 1.25 以降、Amazon EC2 P2 インスタンスを Amazon EKS に最適化された高速 Amazon Linux AMI で使用するには、追加設定が必要です。これらの Kubernetes バージョン 1.25 以降向けの AMI は  NVIDIA 525 シリーズまたはそれ以降のドライバーに対応しており、P2 インスタンスとの互換性がありません。NVIDIA 525 シリーズおよびそれ以降のドライバーは P3P4P5 インスタンスとの互換性があるため、これらのインスタンスを Kubernetes バージョン 1.25 またはそれ以降の AMI で使用することができます。Amazon EKS クラスターをバージョン 1.25 にアップグレードする前に、P2 インスタンスを P3P4P5 インスタンスに移行します。また、NVIDIA 525 シリーズまたはそれ以降と連携するように、アプリケーションを自発的にアップグレードする必要があります。新しい NVIDIA 525 シリーズ以降のドライバーは、2024 年 1 月後半に Kubernetes バージョン 1.23 および 1.24 にバックポートする予定です。

  • PodSecurityPolicy (PSP) は Kubernetes 1.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 EKS 1.25aws-auth ConfigMap が正確に解析されるようにするために必要です。

  • EndpointSlice のベータ API バージョン (discovery.k8s.io/v1beta1) は Kubernetes 1.21 で非推奨となっており、Kubernetes 1.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 Controller v2.4.7 にアップグレードする必要があります。AWS Load Balancer Controller のために EndpointSlices の設定を使用しているときに 1.25 にアップグレードすると、コントローラーがクラッシュし、ワークロードが中断されます。コントローラーをアップグレードするには、「AWS Load Balancer Controller とは」を参照してください。

  • SeccompDefault は、Kubernetes 1.25 でベータ版に昇格しました。kubelet を設定するときに --seccomp-default フラグを設定すると、コンテナランタイムは unconfined (seccomp disabled) モードではなく、その RuntimeDefaultseccomp プロファイルを使用します。デフォルトプロファイルは、ワークロードの機能を維持しながら、セキュリティデフォルトの強力なセットを提供します。このフラグは利用可能ですが、Amazon EKS はデフォルトでこのフラグを有効にしないため、Amazon EKS の動作は事実上変更されていません。必要に応じて、ノードでこれを有効にすることができます。詳細については、Kubernetes ドキュメントのチュートリアル「seccomp を使用してコンテナの Syscall を制限する」を参照してください。

  • Docker (Dockershim とも呼ばれる) のコンテナランタイムインターフェイス (CRI) のサポートは、Kubernetes 1.24 以降から削除されました。Kubernetes 1.24 以降のクラスター用の Amazon EKS の公式 AMIs における唯一のコンテナランタイムは containerd です。Amazon EKS 1.24 以降に更新する前に、サポートされなくなったブートストラップスクリプトフラグへの参照をすべて削除する必要があります。詳細については、「Amazon EKS は Dockershim のサポートを終了しました」を参照してください。

  • ワイルドカードクエリのサポートは CoreDNS 1.8.7 で非推奨となり、CoreDNS 1.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」を参照してください。