Amazon Web Services ブログ

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

この記事は Amazon EKS now supports Kubernetes version 1.28 (記事公開日: 2023 年 9 月 26 日) を翻訳したものです。

はじめに

Amazon Elastic Kubernetes Service (Amazon EKS) チームは、Amazon EKS および Amazon EKS Distro の Kubernetes バージョン 1.28 のサポートを発表できることを嬉しく思います。Amazon EKS Anywhere (リリース 0.18.0) も Kubernetes 1.28 をサポートします。このバージョンのリリース名は「Planternetes」です。このテーマは、植物 (Plant) と Kubernetes を組み合わせて庭園をイメージさせる言葉遊びです。 Kubernetes リリースチームは、公式リリース発表の中で、このリリースについて「このリリースを支えているのは、さまざまなバックグラウンドを持つ人々です。」と述べています。

Kubernetes 1.28 のハイライト

この記事では、Kubernetes バージョン 1.28 リリースの注目すべき機能強化、および削除と非推奨の一部について説明します。まず、このリリースでは、コントロールプレーンとノードコンポーネントの間でサポートされるバージョンスキューの拡張を含む、いくつかの重要な変更が加えられていることに注意してください。v1.28 には、高度なステートフルワークロード管理のサポートなど、私たち全員が興奮している素晴らしい機能強化もあります。

以下は、1.28 リリースに関して技術コミュニティが興奮した機能強化の一部です。Kubernetes バージョン 1.28 の変更とアップデートの完全なリストについては、Kubernetes リリースブログを確認してください。

コントロールプレーンとノードのバージョン間でサポートされるスキューの変更

  • Kubernetes v1.28 では、コアコンポーネントに対してより寛容なバージョン互換性ポリシーが導入され、Kubernetes API サーバーと kubelet の間でサポートされるスキュー (ずれ、不均衡) が n-2 から n-3 に 1 マイナーバージョン分拡大されます。これは、サポートされている最も古いマイナーバージョンのノードコンポーネントが、サポートされている最新のマイナーバージョンの Amazon EKS コントロールプレーンコンポーネントと連携できることを意味します。例えば、Amazon EKS のバージョンが 1.26 の場合、使用できる最も古い kubelet のバージョンは 1.23 です。この変更は、AWS Fargateマネージド型ノードグループセルフマネージド型ノードでサポートされます。結局のところ、この変更により、データプレーン上の kubelet を更新するための猶予期間が少し長くなります。この変更により、データプレーン上で kubelet のマイナーバージョンを更新するための猶予期間が追加されますが、セキュリティ上の理由、特に潜在的な共通脆弱性識別子 (CVE) を考慮して、より新しい AMI (Amazon Machine Image) バージョンを維持することの重要性が否定されるわけではないことに注意してください。この n-3 スキューの変更は、現在サポートされているバージョンにのみ適用されます。あるバージョンがサポート終了となった場合、現在サポートされているバージョンのみの使用に制限されます。
  • 詳細については、Changes to supported skew between control plane and node versions を参照してください。

ステートフルワークロードの機能強化が安定版に移行

  • Kubernetes 1.28 では、特にステートフルワークロードの処理を強化する、高度なストレージ機能スイートが発表されました。Kubernetes Enhancement Proposal (KEP) (#2268, #3333) で説明されているこれらの機能強化は、安定版への移行が完了したため、すぐに利用可能です。これらの機能は、ステートフルワークロードをクラスター内でより効率的に管理できるようにする VolumeAttachment や PersistentVolumeClaim (PVC) などの強力なツールセットを提供します。StorageClass が定義されていないストレージを処理する場合でも、PersistentVolume (PV) を作成するオプションがあります。StorageClass を参照せずとも、NFS マウント用の PV を作成し、NFS サーバーの詳細とともに PV を定義するなど、PV を直接手動でプロビジョニングして作成することができます。その後、PV を PVC 経由で要求し、ステートフルワークロード用のストレージをプロビジョニングできます。
  • #2268 は安定版に移行し、NodeOutOfServiceVolumeDetach フィーチャーゲートはデフォルトで有効になりました。この機能は、グレースフルではないノードシャットダウンからの復旧を可能にし、ステートフルワークロードを別のノードに正常にフェイルオーバーできるようにします。これは、さまざまなプラットフォームでノードのシャットダウンを処理する際の以前の制限に対処します。既存の VolumeAttachment がシャットダウンされた元のノードから切り離されることを確実にすることで、ステートフルなアプリケーションのシームレスな移行を可能にします。
  • #3333 は安定版に移行し、RetroactiveDefaultStorageClass フィーチャーゲートはデフォルトで有効になりました。この機能により、PVC に対するデフォルトの StorageClass の自動的かつ遡及的な割り当てが安定に移行しました。PVC に StorageClassName が定義されていない場合、Kubernetes は自動的に StorageClassName を設定します。この機能により、ステートフルワークロードのストレージ管理の堅牢性が強化され、Kubernetes クラスター内でのストレージリソースの一貫した処理が保証されます。
  • 詳細については、Kubernetes 1.28: Non-Graceful Node Shutdown Moves to GA および Kubernetes v1.28: Retroactive Default StorageClass move to GA を参照してください。

高度なトポロジー管理ときめ細やかな Pod 配置がベータ版に到達

  • Kubernetes v1.28 では、洗練された多様なトポロジー管理機能が導入されました。KEP (#3545) で詳しく説明されているこれらの機能は、デフォルトで有効になっており、ベータ版で利用可能です。これらを組み合わせることで、リソース効率を最大化し、パフォーマンスを向上させ、耐障害性を強化する方法で Pod の配置を調整するという課題に対処する、堅牢な強力なツールを形成します。両方のオプションを使用することで、Pod を互いに近くに配置してパフォーマンスを向上させるだけでなく、アベイラビリティゾーンなどの他の制約にも従い、クラスターリソースを効率的に使用できます。
  • TopologyManagerPolicyBetaOptions は、ノードのトポロジーやリソースのアベイラビリティなどの要素に基づいて Pod の配置を微調整するための高度な設定を提供します。主要な設定の 1 つは、prefer-closest-numa-nodes ポリシーです。 NUMA (Non-Uniform Memory Access) ノードは、CPU とメモリのグループです。通常、Topology Manager は利用可能な NUMA ノードに Pod を分散させますが、この設定は Topology Manager に近くの NUMA ノードを優先するように指示します。このオプションを有効にすると、Topology Manager は Pod の配置についてより多くの情報に基づいた決定を下せるようになり、NUMA ノード間の距離を考慮するように指示されます。これは、レイテンシーの影響を受けやすいアプリケーションや高スループットを必要とするアプリケーションにとって重要です。
  • TopologyManagerPolicyOptions は、独自のクラスタートポロジーに従って Pod の配置を調整する際の、追加のきめ細やかなレイヤーを提供します。この機能を使用すると、ノードラベル、アフィニティルール、およびリソース制約に基づいて制約を定義できるため、Pod の配置を細かく制御できます。これにより、ノードラベル、アフィニティルール、およびリソース制約を使用して制約を定義できます。たとえば、リソース使用率を最適化するために、Pod を特定のアベイラビリティゾーンに制限するように指定できます。
  • これらは強力な機能ですが、既存の Pod の仕様やノードの設定を調整する必要があることに注意してください。その影響を総合的にテストし、問題が発生した場合のロールバック計画を立てておくことをお勧めします。何らかの問題が発生した場合は、機能を無効にして kubelet を再起動することをお勧めします。
  • 詳細については、Control Topology Management Policies on a node を参照してください。

非推奨とその他のアップデート

Kubernetes バージョン 1.28 のリリースに伴い、Amazon EKS は Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの互換性に直接影響する非推奨事項を含む、いくつかの重要な変更を導入しています。Kubernetes 1.28 に移行する前に、これらのアップデートを確認し、それに応じて Amazon EKS クラスターとアプリケーションを適応させることが重要です。この文脈における主な変更点は以下のとおりです。

Amazon EC2 P2 インスタンスの廃止

  • Kubernetes バージョン 1.28 以降では、Amazon EKS optimized accelerated Amazon Linux AMI で Amazon EC2 P2 インスタンスを使用することができなくなりました。 Kubernetes バージョン 1.28 以降向けのこれらの AMI は、P2 インスタンスと互換性のない NVIDIA 525 シリーズ以降のドライバーをサポートします。ただし、NVIDIA 525 シリーズ以降のドライバーは、P3、P4、および P5 インスタンスと互換性があるため、Kubernetes バージョン 1.28 以降の AMI でこれらのインスタンスを使用できます。Amazon EKS クラスターをバージョン 1.28 にアップグレードする前に、P2 インスタンスを P3、P4、P5 インスタンスに移行してください。また、NVIDIA 525 シリーズ以降で動作するように、アプリケーションを積極的にアップグレードすることをお勧めします。

サポートの終了

Amazon EKS は、常に少なくとも 4 つの Kubernetes バージョンをサポートしています。Kubernetes のリリースサイクルの性質を考えると、すべてのお客様にとって、継続的なアップグレード計画を持つことは非常に重要です。1.23 や 1.24 などの古いバージョンの Kubernetes をまだ実行している場合は、より新しいサポートされているバージョンのいずれかにアップグレードすることを検討してください。1.23 クラスターのサポート終了は 2023 年 10 月 11 日、1.24 クラスターのサポート終了は 2024 年 1 月を予定しています。Amazon EKS のバージョンサポートに関してさらに質問がある場合は、FAQ を参照してください。

まとめ

この記事では、Kubernetes バージョン 1.28 の注目すべき変更点を紹介し、利用可能となった最もエキサイティングな機能のいくつかをハイライトしました。Kubernetes v1.28 のリリースノートに記載されているその他の改善点もぜひチェックしてみてください。クラスターを最新の Amazon EKS バージョンにアップグレードする際にサポートが必要な場合は、こちらのドキュメントを参照してください。

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