Amazon Web Services ブログ
Amazon EKS が Kubernetes 1.26 のサポートを開始
この記事は Amazon EKS now supports Kubernetes version 1.26 (記事公開日: 2023 年 4 月 12 日) を翻訳したものです。
はじめに
Amazon Elastic Kubernetes Service (Amazon EKS) チームは、Amazon EKS および Amazon EKS Distro の Kubernetes バージョン 1.26 のサポートを発表できることを嬉しく思います。Amazon EKS Anywhere (リリース 0.15.1) も Kubernetes 1.26 をサポートします。このバージョンのリリース名は「Electrifying」です。このテーマは、プロジェクトが構成する多様なコンポーネントと、プロジェクトに貢献した個人の両方をたたえるために選ばれました。Kubernetes リリースチームは、公式リリース発表の中で、このリリースは「リリースフローに組み込まれ、これらすべての実現に寄与したすべての人々に捧げます。」と述べています。クラスターをアップグレードするには、Updating an Amazon EKS cluster Kubernetes version を参照してください。
Kubernetes v1.26 のハイライト
この記事では、Kubernetes バージョン 1.26 リリースにおける重要な削除、非推奨、および機能強化のいくつかを取り上げます。まず、新しく、より高速で安価な、一般利用可能 (GA) なレジストリである registry.k8s.io のニュースや、2023 年 3 月 20 日より開始されたこのレジストリへのリダイレクトを見逃すことはできません。なお、Kubernetes 1.26 のイメージはすでに k8s.gcr.io で利用可能であり、今後も引き続き利用可能です。しかし、今後、Kubernetes の新しいバージョンはすべて registry.k8s.io にのみ公開され、これが Kubernetes イメージの推奨される唯一のソースとなります。なお、以前のレジストリ である k8s.gcr.io には、v1.26 のコンテナイメージタグはこれ以上リリースされないため、ユーザーは最新の Kubernetes イメージを入手するために registry.k8s.io を使用する必要があります。まだ新しいレジストリに変更していない場合は、AWS のデベロッパーアドボケイトの 1 人である Justin Garrison による短い YouTube 動画をチェックしてください。
Kubernetes バージョン 1.26 のすべての非推奨と削除に注意してください。以下は、最も注目すべき変更点のリストです。完全なリストについては、Kubernetes の変更ログを参照してください。
アップグレードの前提条件
Amazon EKS では、Kubernetes v1.26 にアップグレードする前に、完了する必要がある重要なタスクがいくつかあります。次のセクションでは、アップグレード前に対処する必要がある 2 つの重要な変更点の概要を説明します。
- VPC (Virtual Private Cloud) CNI (Container Network Interface) プラグイン: VPC CNI プラグインのバージョンを 1.12 以降にアップグレードする必要があります。以前のバージョンの VPC CNI は、Kubernetes v1.26 から削除された CRI v1alpha2API に依存しているため、CNI がクラッシュする原因になります。クラスターの VPC CNI をアップグレードするためのステップバイステップの手順については、Working with the Amazon VPC CNI plugin for Kubernetes Amazon EKS add-on を参照してください。
- containerd ランタイム: containerd バージョン 1.6.0 以降にアップグレードする必要があります。Kubernetes v1.26 では、CRI v1alpha2 のサポートが終了しました。このため、コンテナランタイムが CRI v1 をサポートしていない場合、kubelet はノードを登録しません。これは、containerd のマイナーバージョン 1.5 以下に影響し、Kubernetes 1.26 ではサポートされません。同様に、v1alpha2 のみをサポートする他のコンテナランタイムも更新する必要があります。Amazon EKS 最適化 AMI を使用している場合は、それがどのバージョンの containerd を使用しているか確認してください。カスタム AMI に含まれる containerd のバージョンはさまざまで、一部の古いバージョンは Kubernetes v1.26 と互換性がない場合があることに注意してください。互換性を確保するために、containerd バージョン 1.6.19 を含む最新の Amazon EKS 最適化 AMI にアップグレードしてください。
注意事項: EKS 1.26 では、kubelet の AWS 特有のロジックが無効化されました。1.26 より前の EKS 最適化 AMI を使用した場合、kubelet は in-tree クラウド プロバイダーを使用するように構成されていました。これは、--cloudprovider=aws フラグを kubelet の extra-args に渡すことで設定されていました。これにより、kubelet は インスタンスの PrivateDnsName を返す EC2 DescribeInstance API を呼び出していました。1.26 以降、kubelet はデフォルトで --cloud-provider=external または --cloud-provider="" を使用するように設定されています。カスタム AMI を使用している場合や、example.com などのカスタムドメインサフィックスを含む DHCP オプションセットを使用して VPC を構成している場合、これにより問題が発生する可能性があります。--hostname-override=$PRIVATE_DNS_NAME フラグを kubelet の extra-args に渡さない限り、kubelet はオペレーティングシステムのホスト名をノード名として使用します (例: i-0c9e5eff964fb6eea.example.com や ip-192-168-52.example.com) 。このような名前のノードはクラスターへの登録に失敗します。これは、aws-iam-authenticator がノードの名前が常にノードの PrivateDnsName と一致することを期待しているためです。この問題の詳細については、Override hostname to match EC2’s PrivateDnsName を参照してください。EKS 最適化 AMI の最新バージョン v20230501 は、--hostname-override フラグを含むように更新されました。 1.26 にアップグレードした後、ノードがクラスターに参加する際に問題が発生する場合は、v20230501 以降を使用していることを確認してください。Retrieving Amazon EKS optimized Amazon Linux AMI IDs で説明されているように、パラメータストアにクエリを実行することで、リージョン内の最新の EKS 最適化 AMI を見つけることができます。awslabs/amazon-eks-ami で入手可能な Packer スクリプトから構築されたカスタム AMI は、最新バージョンの AMI リリース v20230501 を使用して再構築する必要があります。
削除された API バージョンや機能
昨今、Kubernetes の新バージョンがリリースされると、API (Application Programming Interface) バージョンが削除されることが少なくありません。このような場合、バージョン 1.26 にアップグレードする前に、すべてのマニフェストとコントローラーをこのセクションに記載されている新しいバージョンと機能に更新することが必要不可欠です。
- apiserver.k8s.io/v1beta1 API バージョン: 1.26 で削除された API バージョンには、v1.23 で非推奨とされた flowcontrol.apiserver.k8s.io/v1beta1 API があります。この API バージョンは、Kubernetes の API Priority and Fairness (APF) 機能に関連しています。v1beta1 API バージョンの FlowSchema および PriorityLevelConfiguration リソースを使用している場合は、代わりに新しい flowcontrol.apiserver.k8s.io/v1beta2 API バージョンを使用するように Kubernetes マニフェストと API クライアントを更新してください。APF のデフォルト設定を変更していない場合は、おそらく削除の影響を受けず、追加の措置を講じる必要はありません。 削除されるバージョンを使用しているかどうか不明な場合は、次のコマンドを実行してください。
- autoscaling/v2beta2 API バージョン: Kubernetes v1.26 で削除された API バージョンには、v1.23 で非推奨とされた autoscaling/v2beta2 API があります。現在、HorizontalPodAutoscaler の autoscaling/v2beta2 API バージョンを使用している場合、代わりに autoscaling/v2 API バージョンを使用するようにアプリケーションを更新してください。削除されるバージョンを使用しているかどうか不明な場合は、次のコマンドを実行してください。
- Dynamic kubelet configuration: Dynamic kubelet configuration は、安定性とセキュリティ上の懸念から v1.26 で削除されました。以前は、この設定を使用して、各ノードで kubelet が使用すべき設定データを含む ConfigMap を指定することで、Kubernetes API を介して新しい kubelet 設定を展開できました。Puppet、Chef、Ansible などの構成管理ツールを使用するか、
--configを使用して kubelet に設定を渡すことで静的な kubelet 設定に切り替えることをお勧めします。 詳細については、Set Kubelet parameters via a config file を参照してください。 - Bottlerocket の cgroup v1 から cgroup v2 への移行: Bottlerocket は、バージョン 1.26 で cgroup v1 から cgroup v2 へ移行します。現在の cgroup v1 の実装がデフォルトのオプションではなくなるため、この変更は Amazon EKS クラスターで Bottlerocket AMI を使用しているユーザーに影響します。Bottlerocket は新しい cgroup v2 を使用します。cgroup v2 は、メモリ、CPU、I/O、およびネットワークの制御を強化することで、Linux のリソース管理における以前の制限に対処するように設計されています。この改善により、リソース割り当てのより効率的な自動化が可能になり、I/O 使用やその他のリソースを集中的に使用するアクティビティをより安全に制限できます。 なお、Bottlerocket は、Bottlerocket インスタンスを自動的に更新するためのツールと、更新を直接制御するための API を提供しています。詳しくは、Bottlerocket ドキュメントの更新方法を参照してください。
- klog ロギングフラグ: v1.26 では、klog ロギングライブラリを使用したイベントストリームのロギングを拡張する多数の klog フラグが削除され、ロギングの設定とメンテナンスが簡素化されました。これには、
--logtostderrの削除が含まれます。 設定ファイルとスクリプトを更新して、別のログオプションを使用することをお勧めします。削除されたフラグの完全なリストについては、Removed klog flags を参照してください。
Kubernetes プロジェクトのコンテキストでは、機能やフラグを非推奨にするということは、徐々に段階的に廃止され、最終的に将来のバージョンで削除されることを意味します。Kubernetes バージョン 1.26 では多くの非推奨があります。完全なリストは、Deprecations and removals in Kubernetes v1.26 を参照してください。
安定版への移行のハイライト
このリリースでは、多くのクールな機能が安定版に移行されており、私たちの技術コミュニティは大いに興奮しています。ここでは、その中でも特に注目される機能を、彼らの言葉でご紹介します。
JobTrackingWithFinalizers が GA
Justin Garrison — Sr. Developer Advocate at AWS
- #2307 これは素晴らしい機能です。なぜなら、たくさんの Job を実行すると、Pod が削除された後に Job の完了に関する情報が失われるという歴史的な問題があったからです。Pod の削除は重要です。Pod は (実行されていないときでも) ノードのリソースを消費し、Secret をウォッチするために API サーバーにさらに負荷をかける可能性があるからです。
- このアップデートにより、Pod を削除しても、Job に関するデータが失われないようになります。これは、AWS Fargate を使用して Job を実行しているお客様にとって特に重要です。Job 完了後に Pod を削除しない場合、AWS Fargate のノードは削除されません。これは、使用されていないコンピュートに対してまだ料金を払っていることを意味します。推奨はガベージコレクションですが、歴史的にこれは、削除された Pod のジョブステータスをクエリできないことを意味しています。
- 詳細については、Job Tracking, to Support Massively Parallel Batch Workloads, Is Generally Available を参照してください。
Kubelet Credential Provider の GA サポート
Justin Garrison — Sr. Developer Advocate at AWS
- #2133 これにより、さまざまなコンテナレジストリへの認証が簡素化され、Kubernetes リソースとして認証情報を保持する必要がなくなります。これにより、レジストリへの認証時の柔軟性が増し、Kubernetes リソース管理とノード/レジストリ/セキュリティ管理の間でオーナーシップを分離できます。
- 詳細については、GA Support for Kubelet Credential Providers を参照してください。
CPU Manager が GA
Justin Garrison — Sr. Developer Advocate at AWS
- CPU Manager は、ワークロードが CPU とパフォーマンスの要件をより詳細に制御できるようにします。これは、アベイラビリティに基づいてワークロードを CPU 間でスケジューリングまたは移動させることができるマルチソケットサーバーにとって重要です。一部のワークロードでは、キャッシュミスを避けるためや、メインメモリとのより高い帯域幅を持ち、NUMA と同じバスでスケジュールされるように、CPU スケジューリングを厳密に制御する必要があります。
- 画像レンダリングなどのハイパフォーマンス コンピューティング (HPC) ワークロードは、実行中に別の CPU に再スケジュールされなければ、より高速に実行できます。
- 詳細については、CPUManager goes GA を参照してください。
type=LoadBalancer の Service でプロトコルの混在をサポート
Jeremy Cowan — Sr. Manager, Developer Advocacy at AWS
- #1435 この機能により、異なるプロトコルで異なるポート定義を持つ LoadBalancer Service を作成できます。 AWS Load Balancer Controller では、ポートが異なる限り、TCP (Transmission Control Protocol) と UDP (User Datagram Protocol) を公開する Service を作成することができます。同じポートとプロトコルを公開する Service、例えば、TCP と UDP で 53 番ポートを開く DNS (Domain Name System) は、現時点では作成できません。
- 詳細については、mixed-protocol-lb を参照してください。
Service Internal Traffic Policy
Jeremy Cowan — Sr. Manager, Developer Advocacy at AWS
- #2086 により、Service のトラフィックに対してノードローカルやトポロジーを考慮したルーティングが可能になりました。これまで、Service にルーティングされた内部トラフィックは、すべてのエンドポイントにランダムに分散されていました。Service Internal Traffic Policy を使用すると、同じノード上で実行されている Service のインスタンスに常にトラフィックを送信する Service を作成することができます。トラフィックをノード/アベイラビリティゾーン (AZ) のローカルに保つことで、パフォーマンスを向上させながら、AZ をまたぐネットワークコストを削減することができます。
- 詳細については、Service Internal Traffic Policy を参照してください。
これは、Kubernetes v1.26 で安定版に移行した最もクールな機能の完全なリストではありません。完全なリストについては、Graduations to stable を参照してください。
Kubernetes のヒントとテクニック
Kubernetes v1.26 へのアップグレードをより簡単にするために、私たちの技術コミュニティからいくつかのヒントとテクミックを紹介します。
kubelet 設定をすべて抽出する
Jeremy Cowan — Sr. Manager, Developer Advocacy at AWS
- kubelet の設定は、複数のファイルにまたがっていることがあるため、これは、kubelet の設定を一度に抽出するのに便利な方法です。
- proxy コマンドは、プロキシサーバーを起動します。バックグラウンドで動作させます。続くコマンドでは、シェル変数を再設定中のノードの名前に設定し、ポート 8001 で動作するプロキシサーバーを使用して、curl を使用して Kubernetes API サーバーからそのノードの kubelet 設定を取得します。出力は次に jq にパイプされ、jq は kind と apiVersion を設定して kubelet 設定を変更します。この更新された設定を使用して、指定したノードの kubelet 設定を更新できます。
サポートの終了
もしまだ 1.22 や 1.23 といった古いバージョンの Kubernetes を実行している場合は、より新しいサポートされているバージョンにアップグレードすることを検討してください。1.22 クラスターは 2023 年 6 月 4 日にサポートが終了し、1.23 クラスターの 2023 年 10 月にサポートが終了します。Amazon EKS のバージョンサポートに関してさらに質問がある場合は、FAQ を参照してください。
まとめ
この記事では、Kubernetes バージョン 1.26 の主な変更点について説明し、AWS コミュニティが注目するいくつかのエキサイティングな機能について紹介しました。Kubernetes v1.26 リリースノートに記載されている他の改善点もぜひチェックしてみてください。現在、VPC CNI プラグイン、containerd、または削除された API バージョンを実行している場合は、移行計画を開始することを強くお勧めします。クラスターを最新の Amazon EKS バージョンにアップグレードする際にサポートが必要な場合は、こちらのドキュメントを参照してください。
翻訳はプロフェッショナルサービスの杉田が担当しました。原文はこちらです。