「翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。」
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 に変更されません。
-
VPC タグ付けの詳細については、「」を参照してください。VPC のタグ付け要件.
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 バージョンとバージョンスキューのサポート
Q: ポッドは、自動クラスターコントロールプレーンバージョンアップグレードでFargate自動的にアップグレードされますか?
はい。 Fargate ポッドは、責任AWS共有モデルAmazon EKS側の 所有アカウントのインフラストラクチャで実行されます。 Amazon EKS は、Kubernetes 削除 API を使用して、 で実行されているポッドを正常にドレーンしようとFargateします。詳細については、Kubernetes
ドキュメントの「Evictiondelete pod
を発行します。Fargate ポッドは削除後に自動的に再スケジュールされるように、Kubernetes などのレプリケーションコントローラーの一部としてポッドを実行することを強くお勧めします。詳細については、Kubernetes ドキュメントのkubelet
バージョンと同じバージョンでデプロイされます。
コントロールプレーンを更新する場合は、Fargateノードを自分で更新する必要があります。Fargate ノードを更新するには、ノードで表される Fargate ポッドを削除し、
ポッドを再デプロイします。新しいポッドは、クラスターと同じkubelet
バージョンでデプロイされます。