Amazon EKS が Kubernetes 1.22 のサポートを開始

この記事は Amazon EKS now supports Kubernetes 1.22 (記事公開日: 2022 年 4 月 4 日) を翻訳したものです。

Amazon Elastic Kubernetes Service (Amazon EKS) チームは、Kubernetes 1.22 のサポートを発表できることを嬉しく思います。 Amazon EKS、Amazon EKS Distro、そして Amazon EKS Anywhere は、Kubernetes バージョン 1.22 を実行できるようになりました。アップストリームプロジェクトのこのリリースのテーマは、 “Reaching New Peaks” です。リリースリードの Savitha Raghunathan によると、このリリースのテーマは彼女が次のように説明したことによります。「パンデミックとバーンアウトにもかかわらず、Kubernetes 1.22 はあらゆるリリースの中で最も多くの機能拡張が行われました。」このリリースでは、かなりの数の API の変更、Kubernetes のリリース頻度の変更、その他多くのアップデートが行われています。このリリースをより優れたクラウドネイティブエコシステムにもたらすために、アップストリームの Kubernetes 1.22 リリースチームが行ってきたすべての作業に感謝します。

Kubernetes 1.22: Reaching New Peaks ロゴ

AWS のお客様やオープンソースソフトウェアへのコミットメント

セキュリティと信頼性は、Amazon EKS がエンタープライズのお客様が Kubernetes を開始、実行、スケールするための最も信頼できる方法であることを示す特徴です。Amazon EKS 1.22 のリリースプロセスでは、etcd の最新かつ最高のバージョンである3.5.2 (Kubernetes 1.22 で推奨) を同梱する予定でした。ご存じのように、etcd はすべてのクラスターデータのバッキングストアであり、Kubernetes クラスターの頭脳と言えます。etcd 3.5 では、コミュニティは多くのパフォーマンスと信頼性の改善を行いました。しかし、2 つのデータ不整合の問題が発生したため、Amazon EKS チームはこれらの問題の検証と一貫した再現を支援しました。Amazon EKS チームは、アップストリームの etcd チームと密接に連携し、クラスターデータを不整合状態にする可能性のあるこれら 2 つの深刻度の高い問題 (1, 2) を軽減するための支援を行っています。Amazon EKS チームは、修正に向けて etcd コミュニティと引き続き協力しています。Amazon EKS チームは、すべてのクラスターコンポーネントの最新バージョンをデフォルトで使用することよりも、広範なテストを優先しています。AWS は、このような厳格なテストとコラボレーションへのコミットメントが、etcd というオープンソースプロジェクト、さらに Kubernetes 全体にとって本当の意味で良い影響を与えると考えています。

etcd コミュニティは、etcd 3.5.3 で修正が行われるまで、etcd 3.5.1 および 3.5.2 の使用を延期することを発表しました。Amazon EKS チームは、etcd コミュニティと協力して修正に貢献するとともに、お客様が期待するのと同じ厳密さと優先度で、今後の etcd のリリースをテストします。オープンソースへの協力と貢献は、あらゆる Kubernetes サービスを大規模に実行するための鍵です。etcd 開発者との継続的な作業の結果、AWS は Amazon EKS 1.22 を etcd v3.4 とともに提供しており、安定した時点で etcd 3.5.3 (またはそれ以降) へアップグレードする予定です。

Kubernetes 1.22 のハイライト

重要な新機能をすべて確認したい場合は、Kubernetes 公式ブログのリリースに関する記事とリリースノート全体をお読みください。ここでは、注目すべきアップデートのいくつかにスポットを当てます。Kubernetes 1.22 の完全な変更ログについてはこちらをご参照ください: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.22.md

1.22 での Kubernetes API と機能の削除

Kubernetes 1.22 では、多くの非推奨 API が削除されました。Kubernetes 1.22 にアップグレードする前に、削除された API を現在一般利用可能な同等の API にアップグレードしてください。Kubernetes 公式ブログの記事 “Kubernetes API and Feature Removals In 1.22: Here’s What You Need To Know” では、これらの API が一般利用可能になったことで、何が削除され、何を代わりに配置するべきかが詳細に説明されています。Amazon EKS のお客様がアップグレード前に行うべきことの詳細については、最新の Amazon EKS ドキュメントの “Updating a cluster” を参照してください。安定版へ移行した便利な機能の 1 つは、非推奨の API の使用に対する警告メカニズムです。

また、kubectl-convert コマンドは、マニフェストやアプリケーションに必要な変更の一部に対処するのに役立ちます。kubectl-convert は、異なる API バージョン間で設定ファイルファイルを変換するのに役立ちます。 YAML と JSON の両方の形式が利用できます。API バージョンの移行に関する推奨事項については、ブログ記事 “Here’s What You Need To Know” の “What to do” セクションを確認してください。Kubernetes 1.22 で安定版に移行するいくつかのベータ Kubernetes API のうち、最も注目すべきものをいくつか紹介します。

Ingress
- Kubernetes 1.22 では、Ingress の extensions/v1beta1 および networking.k8s.io/v1beta1 API バージョンは使用できなくなりました。
- Kubernetes v1.19 以降を実行しているクラスターでは、古い API バージョンを使用して作成された場合でも、v1 API を使用して既存の Ingress オブジェクトを取得または更新することができます。
- aws-load-balancer-controller のバージョン 2.4.0 を実行している場合は、Ingress の最新 API に既に対応しています。
- aws-load-balancer-controller をアップグレードする必要がある場合、その手順はインストールガイドに記載されています。
Webhook リソース
- ValidatingWebhookConfiguration と MutatingWebhookConfiguration は admissionregistration.k8s.io/v1 API バージョンを使用するように移行してください。
- v1 API を使用して、古い API バージョンを使用して作成された既存のオブジェクトを取得または更新することができます。
CustomResourceDefinition
- CustomResourceDefinition (CRD) は、かなり以前から多くの業界で使用されてきました。それらが安定版に移行するのは良いことです。CRD の作成者にとっては、API が今後より安定することが保証されています。
- ベータから安定版への移行に伴い、CRD には非常に多くの変更が加えられたため、Kubernetes コミュニティでは、CRD をアップグレードしてテストし、意図した通りに動作することを確認するようユーザーに推奨しています。

Kubernetes のリリース頻度の変更

Kubernetes のアップストリームプロジェクトは、多くのオープンソースプロジェクトと同様に、人によって運営されています。リリースが年 3 回になったことは、プロジェクトにとって大きな変化であり、機能セットが成熟してきたことの表れでもあります。また、この頻度の変更は、それ自体をブログ記事とするに値するほど重要なものです: “Kubernetes Release Cadence Change: Here’s What You Need To Know”

“この変更以前は、機能拡張は 9ヶ月でアルファから安定版へ移行する可能性がありました。今回の変更で、この期間は 12 ヶ月に延長されます。” この変更により、定期リリースチームのメンバー (SIG Release) は、リリースとリリースの間に必要な休暇を取ることができ、アフターコロナの生活にも対応できるようになります。技術的なメリットとしては、既存の Kubernetes のバージョンにセキュリティアップデートやバグフィックスを適用できる期間が “若干長くなる” ことが挙げられます。(これは、アップストリームプロジェクトの長期的なサポートコミットメントではないことに注意してください) 。また、コードフリーズの前に機能に取り組む時間が増えるため、あるリリースではより多くのアップデートが行われる可能性があります。いつものように、AWS はコントロールプレーンにセキュリティパッチとアップデートを自動的に適用することに熱心に取り組んでいます。同様に、マネージド型ノードグループは、必要なときにワーカーノードをリサイクルするメカニズムを提供します。Amazon EKS は、常に少なくとも 4 つの本番環境対応バージョンの Kubernetes をサポートすることをコミットしています。

現在、Kubernetes コミュニティでは、リリース頻度に関するアンケートを実施しています。Kubernetes プロジェクトのコントリビューター、Kubernetes のユーザー、Kubernetes を使用、再販、またはホストする企業の社員である場合は、アンケートへの参加を検討してください。

Server-Side Apply が GA

“Server-Side Apply は、Kubernetes API サーバー上で実行される、新しいオブジェクトマージアルゴリズムであり、フィールドの所有権を追跡します。” これはどういう意味でしょうか？Server-Side Apply によって、ユーザーだけでなくコントローラーでさえも、リソースを宣言的に管理することができるようになります。Server-Side Apply は、オリジナルの kubectl apply の代わりとして、およびコントローラーが変更を実行するための、よりシンプルなメカニズムとしての両方を提供します。念のため補足すると、Amazon EKS アドオンは Kubernetes Server-Side Apply の機能を使用します。Amazon EKS API を通じて、Amazon EKS アドオンの特定の Amazon EKS が管理する設定フィールドを変更することができます。また、アドオンが起動すると、Amazon EKS によって管理されていない設定フィールドを Kubernetes クラスター内で直接変更することも可能です。これには、該当する場合、アドオンの特定の設定フィールドを定義することが含まれます。

Pod Security Admission

Kubernetes 1.25 では、PodSecurityPolicy が Pod Security Standards (PSS) とPod Security Admission (PSA) に置き換えられます。Kubernetes Pod Security Standards は、Pod の異なる隔離レベルを定義します。これらのスタンダードによって、Pod の動作をどのように制限したいかを明確かつ一貫した方法で定義できます。PSA の取り組みには、PSS で定義された制御を実装するアドミッションコントローラー Webhook プロジェクトが含まれます。AWS は、お客様がこれらの新しいスタンダードのテストを開始できるように、それに応じて Amazon EKS ベストプラクティスガイドを更新しています。

自動ラベリング

NamespaceDefaultLabelName フィーチャーゲートが有効になっている場合、Kubernetes コントロールプレーンはすべての Namespace にイミュータブルなラベル kubernetes.io/metadata.name を設定します。ラベルの値は、Namespace 名です。これはベータ機能です。

DaemonSet の maxSurge

このベータ機能により、お客様は、アップデート中に DaemonSet の Pod をアップデートできる最大ノード数を指定することができます。これらのノードでは、新しい Pod が作成されてから古い Pod が削除されます。この値は、希望する Pod の絶対数またはパーセンテージにすることができます。これにより、DaemonSet のアップデートによる停止を最小限に抑えることができます。

NetworkPolicy でポートの範囲を対象として指定可能に

NetworkPolicy を記述する際に、単一のポートではなく、ポートの範囲を対象とすることができます。これは、次の例のように endPort フィールドを使用することで実現できます。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: port-range-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: web
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 32000
      endPort: 32768

Amazon EKS は Dockershim のサポート終了を予定しています

Dockershim は Kubernetes がコンテナランタイムとして Docker を使用できるようにします。バージョン 1.20 で、Kubernetes は Dockershim を非推奨としました。Docker はまだ完全に機能しますが、次の Amazon EKS のメジャーリリース (1.23) でサポートが削除される前に、ユーザーは別のコンテナランタイムに移行する必要があります。Amazon EKS はバージョン 1.24 で Dockershim のサポートを削除します。Dockershim は引き続き使用できますが、そのための AMI を構築する必要があります。Dockershim は Amazon EKS が提供する最適化 AMI には含まれなくなります。containerd を使用してクラスターをインストールおよび管理する方法については、このトピックに関する以前のリリースのブログ記事 (日本語訳) を参照してください。containerd は CNCF の Graduated プロジェクトであり、Fargate、Bottlerocket、Windows ワーカーノードで既に使用されています。

Detector for Docker Socket (DDS)

Dockershim がお客様の環境のどこで使用されているかを判断しようとするとき、Amazon EKS チームはこれが難しい場合があることを認識しています。私たちのお客様やより大きな Kubernetes エコシステムを支援するために、私たちはこれを支援するツールを開発しました: Detector for Docker Socket (DDS)

この検出ツールは、ワークロードまたはマニフェストファイルのいずれかが docker.sock ボリュームをマウントしているかどうかを検出することができる kubectl プラグインです。DDS は、Kubernetes クラスター内のすべての Pod を検査します。Pod　がワークロード (Deployment、StatefulSet など) の一部である場合、Pod を直接検査するのではなく、ワークロードタイプを検査します。また、このツールは、ディスク上の Kubernetes マニフェストファイルを調べるためにも使用できます。詳細については、プロジェクトの README をご覧ください。

EKS のアップグレード

EKS バージョンをアップグレードする方法については、ブログ記事 “Planning Kubernetes Upgrades with Amazon EKS” (日本語訳: “Amazon EKS での Kubernetes アップグレードの計画“) を参照してください。

まとめ

改めて補足すると、Amazon EKS は、常に少なくとも 4 つの Kubernetes のバージョンをサポートしています。Kubernetes の定期的なリリースサイクルを考慮すると、すべてのお客様は継続的なアップグレード計画を立てることが非常に重要です。Amazon EKS のバージョン 1.18 は、2022 年 3 月 31 日にサポート終了を迎えました。1.18 クラスターを新規に作成することはできなくなりました。詳細については、Amazon EKS Kubernetes リリースカレンダーを参照してください。

このことを念頭に置き、お客様が Kubernetes 1.22 のさまざまな機能強化や一般利用可能な新しい API を活用し始められることを楽しみにしています。繰り返しになりますが、パンデミックの中、このリリースに取り組んでくれた Kubernetes 1.22 のリリースチームに大いに感謝します。containerd を使用してワークロードをテストし、Dockershim の削除に対するが準備できていることを確認してください。また、新しいアップストリームリリース頻度 (年 4 回から 3 回へ) は、将来の Kubernetes のリリースは、回数は少なくなるがより大きなリリースになる可能性があることに注意して下さい。

翻訳はプロフェッショナルサービスの杉田が担当しました。原文はこちらです。

Amazon Web Services ブログ