Amazon EKS Kubernetes のバージョン

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

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

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

• 1.23

• 1.22

• 1.21

• 1.20

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

注記

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

Kubernetes 1.23

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

• 重要

  Kubernetes ツリー内から Container Storage Interface (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 移行に関するよくある質問」を参照してください。

• Kubernetes はバージョン 1.20 での dockershim のサポートを停止し、バージョン 1.24 で dockershim を削除しました。詳細については、Kubernetes のブログの「Kubernetes is Moving on From Dockershim: Commitments and Next Steps」(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 は、Pod Security Admission 機能のベータ版の提供を開始しました。この機能は、デフォルトで有効になっています。詳細については、Kubernetes のドキュメントの「Pod Security Admission」を参照してください。Pod Security Admission は、Pod Security Policy (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 1.23 の変更ログについては、「https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.23.md#changelog-since-v1220」を参照してください。

Kubernetes 1.22

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

• Kubernetes 1.22 では、使用できなくなった複数の API が削除されます。Amazon EKS バージョン 1.22 にアップグレードする前に、アプリケーションを変更する必要がある場合もあります。クラスターを更新する前に、必ず「Kubernetes バージョン 1.22 の前提条件」を確認してください。

• 重要

  Kubernetes バージョン 1.22 では、BoundServiceAccountTokenVolume は段階的に安定しており、デフォルトで有効になっています。この機能により、サービスアカウントトークンのセキュリティが向上します。また、Kubernetes で実行中のワークロードで、オーディエンス、時間、およびキーバインド化された JSON ウェブトークンのリクエストが可能になります。また、サービスアカウントトークンの有効期限が 1 時間になりました。以前の Kubernetes バージョンでは、有効期限はありませんでした。つまり、これらのトークンに依存するクライアントは 1 時間以内にトークンを更新する必要があります。次の Kubernetes クライアント SDK では、必要な時間内にトークンを自動的に更新します。

  • Go - バージョン 0.15.7 以降

  • Python - バージョン 12.0.0 以降

  • Java バージョン 9.0.0 以降

  • JavaScript バージョン 0.10.3 以降

  • Ruby master ブランチ

  • Haskell バージョン0.3.0.0

  • C# バージョン 7.0.5 以降

  ワークロードで古いバージョンのクライアントを使用している場合は、更新する必要があります。有効期限付きの新しいサービスアカウントトークンにクライアントがスムーズに移行できるようにするには、Kubernetes バージョン 1.22 でデフォルトの 1 時間を超えてサービスアカウントトークンの有効期限を延長します。Amazon EKS クラスターの場合、延長できる有効期限は 90 日です。Amazon EKS クラスターの Kubernetes API サーバーでは、90 日を超えるトークンのリクエストは拒否されます。アプリケーションとその依存関係を確認し、Kubernetes クライアント SDK が前記のバージョンと同じかそれ以降であることを確認することをお勧めします。以前のトークンを使用している pods を特定する方法については、「Kubernetes service accounts」(Kubernetes のサービスアカウント) を参照してください。

• Kubernetes 1.22 では、Ingress API のバージョン extensions/v1beta1 および networking.k8s.io/v1beta1 が削除されました。AWS Load Balancer Controller を使用している場合、Amazon EKS クラスターをバージョン 1.22 にアップグレードする前に、バージョン 2.4.1 以上にアップグレードする必要があります。さらに、apiVersion networking.k8s.io/v1 を使用するため、Ingress マニフェストを変更する必要があります。これは、Kubernetes バージョン 1.19 から利用可能です。Ingress v1beta1 および v1 間の変更についての詳細は、「Kubernetes ドキュメント」を参照してください。AWS Load Balancer Controller のコントローラーサンプルマニフェストでは、v1 仕様を使用します。

• Amazon EKS レガシーの Windows サポートコントローラー では、Kubernetes 1.22 で削除された admissionregistration.k8s.io/v1beta1 API を使用します。Windows ワークロードを実行している場合は、Amazon EKS バージョン 1.22 にアップグレードする前に、レガシー Windows サポート を削除して、Windows サポート を有効にする必要があります。

• Kubernetes バージョン 1.22 では、CertificateSigningRequest (CSR) API バージョン certificates.k8s.io/v1beta1 が削除されました。certificates.k8s.io/v1 CSR API を使用するには、マニフェストと API クライアントを移行する必要があります。この API は、バージョン 1.19 から利用可能です。Amazon EKS での CSR の使用方法については、「証明書への署名」を参照してください。

• Kubernetes 1.22 では、CustomResourceDefinition API バージョン apiextensions.k8s.io/v1beta1 が削除されました。クラスター内のすべてのカスタムリソース定義が v1 にアップデートされていることを確認してください。API バージョン v1 のカスタムリソース定義では、Open API v3 スキーマの検証が定義されている必要があります。詳細については、Kubernetesドキュメントを参照してください。

• App Mesh を使用している場合は、Amazon EKS バージョン 1.22 にアップグレードする前に、App Mesh コントローラー v1.4.3 かそれ以降にアップグレードする必要があります。古いバージョンの App Mesh コントローラーでは v1beta1 CustomResourceDefinition API バージョンを使用しており、Kubernetes バージョン 1.22 およびそれ以降とは互換性がありません。

• Amazon EKS バージョン 1.22 では、デフォルトで EndpointSliceTerminatingCondition 機能が有効です。これは、終了状態の pods を EndpointSlices 内に含みます。AWS Load Balancer Controller で、enableEndpointSlices を True に設定した場合 (デフォルトでは無効です)、Amazon EKS バージョン 1.22 にアップグレードする前に、AWS Load Balancer Controller バージョン 2.4.1+ 以降にアップグレードする必要があります。

• Amazon EKS バージョン 1.22 以降、kube-proxy ではデフォルトで、Prometheus メトリクスが pod 外に公開されるように設定されています。この動作の変更により、コンテナロードマップで行われたリクエストの問題 #657 が解決されます。

• Amazon EKS バージョン 1.22 の初回起動では、バックエンドとして etcd バージョン 3.4 を使用します。これが、etcd バージョン 3.5 に存在するデータ破損の可能性による影響を受けることはありません。

• Amazon EKS 1.22 以降、Amazon EKS では、コアコントロールプレーンのコードから、ツリー外の AWS Kubernetes Cloud Controller Manager に AWS クラウドに固有の制御ロジックをデカップリングしています。これは、アップストリームの Kubernetes における推奨事項に沿ったものです。相互運用性のロジックを Kubernetes および基盤となるクラウドインフラストラクチャ間でデカップリングすることで、cloud-controller-manager コンポーネントを使用して、クラウドプロバイダーがメインの Kubernetes プロジェクトとは異なるペースで機能をリリースすることを可能します。この変更は透過的であり、アクションは必要ありません。ただし、cloud-controller-manager という名前の新しいログストリームが、ControllerManager のログタイプの下に表示されます。詳細については、「Amazon EKS コントロールプレーンのログ記録」を参照してください。

• Amazon EKS 1.22 以降、Amazon EKS は、サービスアカウント (IRSA) 用に IAM ロールで使用されるデフォルトの AWS Security Token Service エンドポイントを変更しています。これによりグローバルエンドポイントではなくリージョンのエンドポイントとなり、レイテンシーを削減して信頼性を向上させることができます。必要に応じて、サービスアカウントの AWS Security Token Service エンドポイントの設定 でグローバルエンドポイントを使用するように IRSA を設定できます。

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

• Server-side Apply を GA に移行する - Server-side Apply は、ユーザーとコントローラーが宣言的な設定を通じてリソースを管理するのに役立ちます。これにより、完全に指定されたインテントを送信することで、宣言的にオブジェクトを作成または変更できます。いくつかのリリースでベータ版になり、今回、Server-side Apply は正式にリリースされました。

• サポートされていない API の使用に関する警告メカニズム - サポートされていない API を使用すると、API コンシューマーに表示される警告と、クラスター管理者に表示されるメトリクスが生成されます。

完全な Kubernetes 1.22 の変更ログについては、「https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md#changelog-since-v1210」を参照してください。

Kubernetes 1.21

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

• 重要

  Kubernetes バージョン 1.21 では、BoundServiceAccountTokenVolume がベータ版に移行し、デフォルトで有効になっています。この機能により Kubernetes で実行しているワークロードがオーディエンス、時間、およびキーバインド化された JSON Web トークンをリクエストできるようにすることで、サービスアカウントトークンのセキュリティが向上します。また、サービスアカウントトークンの有効期限が 1 時間になりました。以前の Kubernetes バージョンでは、有効期限はありませんでした。つまり、これらのトークンに依存するクライアントは 1 時間以内にトークンを更新する必要があります。次の Kubernetes クライアント SDK では、必要な時間内にトークンを自動的に更新します。

  • Go - バージョン 0.15.7 以降

  • Python - バージョン 12.0.0 以降

  • Java バージョン 9.0.0 以降

  • JavaScript バージョン 0.10.3 以降

  • Ruby master ブランチ

  • Haskell バージョン0.3.0.0

  • C# バージョン 7.0.5 以降

  ワークロードで古いバージョンのクライアントを使用している場合は、更新する必要があります。有効期限付きの新しいサービスアカウントトークンにクライアントがスムーズに移行できるようにするには、Kubernetes バージョン 1.21 でデフォルトの 1 時間を超えてサービスアカウントトークンの有効期限を延長します。Amazon EKS クラスターの場合、延長できる有効期限は 90 日です。Amazon EKS クラスターの Kubernetes API サーバーでは、90 日を超えるトークンのリクエストは拒否されます。アプリケーションとその依存関係を確認し、Kubernetes クライアント SDK が前記のバージョンと同じかそれ以降であることを確認することをお勧めします。古いトークンを使用している pods を特定する方法については、「Kubernetes service accounts」(Kubernetes のサービスアカウント) を参照してください。

• pods、サービス、およびノードでの デュアルスタックネットワーク サポート (IPv4 および IPv6 アドレス) がベータ版になりました。ただし現在、Amazon EKS と Amazon VPC CNI plugin for Kubernetes では、デュアルスタックネットワークをサポートしていません。

• Amazon EKS 最適化 Amazon Linux 2 AMI に、 containerd ランタイムを Docker の代替として使用するためのブートストラップフラグが含まれるようになりました。このフラグは、次の Kubernetes のリリースで サポートされるランタイムとして Docker を削除 するための事前措置です。詳細については、「containerd ランタイムブートストラップフラグを有効にする」を参照してください。これは、GitHub のコンテナ化ロードマップでご確認いただけます。

• マネージド型ノードグループによる、Cluster Autoscaler の優先度エクスパンダーのサポート。

  Amazon EKS バージョン 1.21 クラスターで新しく作成されたマネージド型ノードグループでは、基盤となる Auto Scaling グループ名に次の形式を使用します。

  eks-managed-node-group-name-uuid

  これにより、Cluster Autoscaler の優先度エクスパンダ機能を使用して、ユーザー定義の優先順位に基づいてノードグループをスケーリングできるようになります。一般的なユースケースとしては、オンデマンドグループよりもスポットノードグループのスケーリングを優先させる場合などがあります。この動作の変更により、コンテナーロードマップに挙げられている問題 #1304 が解決されます。

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

• CronJobs (従来の ScheduledJobs) が安定版に移行しました。この変更より、バックアップやレポートの生成など、定期的にスケジュールされたアクションを実行できます。

• イミュータブルなシークレットと ConfigMaps が安定版に移行しました。新しいイミュータブルなフィールドがこれらのオブジェクトに追加され、変更を拒否できるようになりました。この変更の拒否により、意図せずアプリケーションを破壊する更新からクラスターを保護できます。これらのリソースはイミュータブルであるため、kubelet では変更の監視やポーリングを行いません。これは、kube-apiserver のロードが軽減されとスケーラビリティとパフォーマンスの向上を実現できます。

• ノードの適切なシャットダウンがベータ版に移行しました。この更新により、kubelet がノードのシャットダウンを認識して、そのノードの pods を十分な時間をかけて適切に終了させることができます。この更新の前は、ノードがシャットダウンしたときに、その pods が予想される終了ライフサイクルに従わなかった。これにより、ワークロードの問題が発生しました。systemd 経由で kubelet が差し迫ったシステムシャットダウンを検出し、その情報を実行中の pods に伝えるため、十分な時間をかけて適切に終了するようになりました。

• 複数のコンテナを持つポッドは、kubectl.kubernetes.io/default-container アノテーションを使用して、kubectl コマンド用にコンテナを事前に選択することができます。

• PodSecurityPolicy は段階的に非推奨とされています。PodSecurityPolicy は、Kubernetes の非推奨化のガイドラインに従って、さらにいくつかのリリースで引き続き機能します。詳細については、PodSecurityPolicy Deprecation: Past, Present, and Future ならびに AWSブログを参照してください。

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

Kubernetes 1.20

Kubernetes 1.20 の詳細については、「official release announcement」(公式リリースのお知らせ) を参照してください。

• 1.20 では、新しいデフォルトのロールとユーザーが提供されます。詳細については、「デフォルトの Amazon EKS Kubernetes ロールとユーザー」を参照してください。サポートされている証明書マネージャのバージョン、を使用していることを確認します。

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

• APIの優先順位と公平性がベータステータスになり、デフォルトで有効になっています。これにより kube-apiserver を使用して、受信リクエストを優先度レベルで分類します。

• ランタイムクラスが安定状態に達しました。RuntimeClass リソースは、クラスタ内の複数のランタイムをサポートするためのメカニズムを提供し、コンテナランタイムに関する情報をコントロールプレーンに表面化させます。

• プロセス ID の制限がなくなりました。

• kubectl デバッグがベータステータスになりました。kubectl debug は、一般的なデバッグワークフローを kubectl から直接サポートします。

• Docker コンテナのランタイムは段階的に廃止されました。これに関しては、Kubernetes コミュニティのブログ投稿で詳細に触れているほか、よくある質問ページでも取り上げられています。Docker が作成した画像は、今後も引き続き使用できます。kubelet 起動ログに出力される dockershim 廃止警告メッセージを無視しても問題ありません。Amazon EKS は、最終的に Amazon EKS 最適化 Amazon Linux 2 AMI のランタイムとして containerd に移行します。さらなる詳細については、コンテナのロードマップでの問題を参照してください。

• FQDN としての Pod Hostname はベータステータスに移行しました。この機能により、pod のホスト名を完全修飾ドメイン名 (FQDN) に設定できるようになり、カーネルのホスト名フィールドを pod の FQDN に設定できるようになりました。

• client-go の資格情報プラグインは、KUBERNETES_EXEC_INFO 環境変数を通じて現在のクラスター情報に送られます。この機能強化により、Go クライアントは、キー管理システム (KMS) などの外部認証情報プロバイダーを使用して認証できます。

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

Kubernetes 1.19

Kubernetes 1.19 の詳細については、「official release announcement」(公式リリースのお知らせ) を参照してください。

• 1.19 以降の Amazon EKS では、クラスターの作成時に渡されるサブネットに、kubernetes.io/cluster/my-cluster タグが追加されなくなります。このサブネットタグは、Kubernetes サービスコントローラーまたは AWS Load Balancer Controller により Elastic Load Balancer が配置される場所をユーザーが決定したい場合にのみ必要となります。クラスターの作成中に Amazon EKS に渡されるサブネットの要件については、更新された「Amazon EKS VPC およびサブネットの要件と考慮事項」を参照してください。

  • 既存のクラスターを 1.19 に更新した場合は、サブネットタグは変更されません。

  • AWS Load Balancer Controller のバージョン 2.1.1 以前には、サブネットタグ my-cluster が必要です。バージョン 2.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」(予測されるサービスアカウントボリュームでのファイル権限処理の提案)」を参照してください。

• pod アイデンティティウェブフックが更新され、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 が含まれています。詳細については、GitHub の「Changelog」を参照してください。

• 以下の変更が行われ、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	すべて	kubelet が、kubectl exec や kubectl logs などの所定のクラスター機能に影響を与えるサーバー証明書をリクエストできるかどうかに影響を与えるため。

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

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

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

• Pod Topology Spread が安定版になりました。Topology Spread によるコントロールを使用すると、リージョン、ゾーン、ノード、その他のユーザー定義トポロジードメインなどで障害を起こしたドメイン間で、pods がクラスター全体に分散される方法をコントロールできます。これにより、高可用性を実現し、リソースの利用効率を向上できます。詳細については、「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」(シークレット) を参照してください。

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

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

注記

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

Kubernetes バージョン	アップストリームのリリース	Amazon EKS リリース	Amazon EKS のサポート終了
1.24	2022 年 5 月 3 日	2022 年 11 月	2024 年 1 月
1.23	2021 年 12 月 7 日	2022 年 8 月 11 日	2023 年 10 月
1.22	2021 年 8 月 4 日	2022 年 4 月 4 日	2023 年 5 月
1.21	2021 年 4 月 8 日	2021 年 7 月 19 日	2023 年 2 月
1.20	2020 年 12 月 8 日	2021年5月18日	2022 年 11 月 1 日
1.19	2020 年 8 月 26 日	2021 年 2 月 16 日	2022 年 8 月 1 日

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: Amazon EKS で Kubernetes バージョンのサポートが終了する際には通知が届きますか?

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

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

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

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

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

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 バージョンを実行しているインスタンスが含まれているとします。そうすると、コンソールで、クラスターの [Compute] (コンピューティング) タブの [Node Groups] (ノードグループ) セクションに、ノードグループのヘルスに関する問題が表示されます。最後に、ノードグループでバージョンの更新が可能な場合は、コンソールのノードグループの横に、[Update now] (今すぐ更新) が表示されます。詳細については、「マネージド型ノードグループの更新」を参照してください。コントロールプレーンとノードで、同じ Kubernetes バージョンを保持することをお勧めします。

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

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

Kubernetes プロジェクトでは、最大 2 つのマイナーバージョンに対して、コントロールプレーンとノード間の互換性がテストされます。例えば、1.21 ノードは、1.23 コントロールプレーンによってオーケストレーションされた場合も動作し続けます。しかし、コントロールプレーンの背後で 2 つのマイナーバージョンのノードを使用し続けながら、クラスターを実行することはお勧めしません。詳細については、「Kubernetes ドキュメント」の「Kubernetes version and version skew support policy」(Kubernetes のバージョンおよびバージョンスキューのサポートポリシー) を参照してください。コントロールプレーンとノードで、同じ Kubernetes バージョンを保持することをお勧めします。

質問: 自動クラスターコントロールプレーンのバージョンに自動アップグレードされた Fargate で実行中の pods も、アップグレードされますか?

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

重要

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