Amazon EKS Kubernetes バージョン - Amazon EKS

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

Amazon EKS Kubernetes バージョン

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

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

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

  • 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.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 月 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.16 ノードは1.18、コントロールプレーンによってオーケストレーションされたときにも動作し続けます。ただし、コントロールプレーンの背後に 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バージョンでデプロイされます。