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

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

はじめに

Amazon Elastic Kubernetes Service (Amazon EKS) チームは、Amazon EKS および Amazon EKS Distro の Kubernetes バージョン 1.27 のサポートを発表できることを嬉しく思います。Amazon EKS Anywhere (リリース 0.16.0) も Kubernetes 1.27 をサポートします。このバージョンのリリース名は「Chill Vibes」 (リラックスした雰囲気) です。このテーマは、リリースが非常にスムーズであった事実をたたえるために選ばれました。Kubernetes リリースチームは、公式のリリース発表の中で、このリリースについて「機能拡張の凍結後に例外リクエストが 1 つもなかった、誰もが覚えている最初のリリース」と述べています。

Kubernetes 1.27 のハイライト

この記事では、クラスターとワークロードに影響を与える可能性がある、Kubernetes バージョン 1.27 の最も重要な削除、非推奨、および機能に焦点を当てます。まず、v1.27 では、k8s.gcr.io イメージレジストリの凍結など、いくつかの機能とバージョンが非推奨になることに注意してください。これは、潜在的な問題を回避するために、ワークフローや設定を更新する必要がある可能性があることを意味します。最後に、私たち全員が興奮している素晴らしい kubelet の拡張機能により、特定のノードで実行されているコンテナワークロードを簡単に保護できる用になります。Kubernetes バージョン 1.27 の変更と更新の完全なリストについては、Kubernetes の変更ログを確認してください。

v1.27 では、いくつかの興味深い機能が一般利用可能 (GA) となっています。以下では、v1.27 リリースに関して私たちの技術コミュニティが興奮している機能強化をご紹介します。完全なリストについては、Feature graduations and deprecations in Kubernetes v1.27 を参照してください。

SeccompDefault が安定版へ移行

#2413 SeccompDefault は安定版に移行し、このフィーチャーゲートはデフォルトで有効になりました。このフィーチャーゲートは、広範囲にわたって seccomp プロファイルを設定することなく、ワークロードのセキュリティ体制を強化するのに役立ちます。デフォルトの seccomp プロファイルは、セキュリティとアプリケーションの互換性のバランスを取るように設計されています。安定版へ移行により、RuntimeDefault seccomp プロファイルは、すべてのワークロードのデフォルトとして使用されます。ノード上で実行されるすべてのコンテナに対してデフォルトの seccomp プロファイルを設定するには、ブートストラップスクリプトまたは起動テンプレートで --kubelet-extra-args に --seccomp-default フラグを渡します。これにより、Unconfined (seccomp 無効) モードを使用する代わりに、コンテナランタイムによって定義される RuntimeDefault seccomp プロファイルがすべてのワークロードのデフォルトとして設定されます。この機能を使用すると、悪意のある攻撃者によって悪用される一般的なシステムコールの脆弱性に対する保護レイヤーを追加できます。
現在、seccomp 無効で実行されているワークロードの一部では、seccomp をデフォルトで有効にした場合に、不具合が発生する可能性があります。互換性を確保し潜在的な問題を防ぐために、seccomp をデフォルトで有効にする前に、ステージング環境またはテスト環境でワークロードをテストすることを強くお勧めします。互換性の問題が発生した場合は、seccomp を無効にするか、特定のワークロードのためのカスタムプロファイルを作成できます。デフォルトのプロファイルは、いくつかのカスタムプロファイルほど制限的ではありませんが、アプリケーションの相互運用性を損なうことなく、ベースラインレベルのセキュリティを提供します。加えて、seccomp のプロファイルをより詳細に制御する必要があり、ワークロードのためのカスタムプロファイルを作成して実装したい場合は、security-profiles-operator を検討するとよいでしょう。このオペレーターを使用すると、クラスター内でカスタム seccomp プロファイルを定義および管理できます。
クラスターで kubelet 引数を使用する方法の詳細については、 Customizing managed nodes with launch templates を参照してください。

よりきめ細かな Pod Topology Spread ポリシーがベータ版に到達

v1.27 より前の Kubernetes バージョンでは、さまざまなドメイン (例えば kubernetes.io/hostname) にわたってバランスよく Pod を分散させることは難しいタスクでした。こうしたハードルに対応するため、Kubernetes v1.27 では、Pod Topology Spread 機能を改善する複数の機能が導入されました。KEP (#3022, #3094, #3243) で説明されているこれらの機能は、デフォルトで有効になっているため、すぐに利用できます。これらの機能は、ワークロードを均等に分散し、回復力を強化し、ローリングアップデートの実行を簡素化する強力なツールセットを提供します。
まず #3022 では、minDomains パラメータが導入されます。minDomains パラメータによって Pod が存在するドメインの最小数を設定できるようになり、十分な数のドメインが存在しない場合は新しいドメインをプロビジョニングさせることで、クラスター全体でワークロードのバランスのとれた分散を保証します。続いて #3094 では、nodeAffinityPolicy パラメータと nodeTaintPolicy パラメータが導入されます。これにより、制約毎に NodeAffinity と Taint を考慮するのかどうか、より細かい制御が可能になります。この機能は NodeInclusionPolicyInPodTopologySpread フィーチャーゲートと関連付けられており、デフォルトで有効になっています。最後に #3243 では、Pod 仕様の topologySpreadConstraints に matchLabelKeys フィールドを実装し、ローリングアップデート後に分散を計算する対象の Pod を選択できるようなりました。
詳細については、Kubernetes 1.27: More fine-grained pod topology spread policies reached beta を参照してください。

kubelet のデフォルトの 1 秒当たりの API クエリ数制限を引き上げ

v1.27 より前のバージョンでは、Amazon EKS の kubelet には、kubeAPIQPS が 10 リクエスト/秒というデフォルト値、そして kubeAPIBurst が 20 リクエストというバースト制限がありました。これらにより kubelet が受信リクエストを処理できる速度が決まりました。#1040 により、Amazon EKS 最適化 AMI は、kubeAPIQPS に 50リクエスト/秒、kubeAPIBurst に 100 リクエストという新しいデフォルト値を採用しました。これらの変更により、新しいノード上での Pod の起動速度が向上し、追加のリソースへの急な需要に対応できるようになりました。
kubelet のデフォルト値を増やすことにより、kubelet が 1 秒あたりより大量の API クエリを処理できるようになり、応答性とパフォーマンスが向上します。スケーリング要求により Pod に対する突然の需要が発生した場合、改訂されたデフォルト値により、kubelet が増加したワークロードを効率的に管理できるようになります。その結果、Pod の起動が高速化され、クラスターの運用がよりスムーズになります。Amazon EKS 最適化 AMI の kubelet デフォルト値のこれらの調整は、Kubernetes のパフォーマンスを最適化し、お客様に優れた体験を提供するための継続的な取り組みと連携しています。

削除された API バージョンや機能

昨今、Kubernetes の新バージョンがリリースされると、Kubernetes API (Application Programming Interface) のバージョンや機能が非推奨になったり、削除されたりすることは珍しくありません。このような場合、バージョン 1.27 にアップグレードする前に、すべてのマニフェストとコントローラーをこのセクションに記載されている新しいバージョンと機能に更新することが必要不可欠です。以下に、v1.27 リリースにおける主な変更点を示します。完全なリストについては、Deprecations and removals in Kubernetes v1.27 を参照してください。

k8s.gcr.io イメージレジストリの凍結

Kubernetes v1.27 から、Kubernetes プロジェクトは k8s.gcr.io レジストリを凍結しました。すなわち、v1.27 以降の新しい Kubernetes イメージと古いバージョンのパッチは k8s.gcr.io レジストリには公開されません。代わりに、最新の Kubernetes イメージを取得するために registry.k8s.io を使用する必要があります。現在、これが Kubernetes イメージの唯一のソースとなります。もしまだマニフェストや設定を新しいレジストリに更新していない場合は、AWS のデベロッパーアドボケイトの一人である Justin Garrison による YouTube ショート動画をご覧ください。

アルファ版 seccomp アノテーションの削除

seccomp.security.alpha.kubernetes.io/pod および container.seccomp.security.alpha.kubernetes.io アノテーションは削除されました。セキュアコンピューティングモード (seccomp) は、Pod または個々のコンテナのシステムコールを制限することによって、ワークロードセキュリティを改善します。アルファ版の seccomp アノテーションは v1.19 から非推奨となり、v1.27 で削除されました。これにより、seccomp アノテーションを持つ Pod に対して seccomp フィールドが自動入力されなくなりました。代わりに、Pod やコンテナの securityContext.seccompProfile フィールドを使用して seccomp プロファイルを設定する必要があります。クラスターで非推奨のアルファ版 seccomp アノテーションを使用しているかどうかを確認するには、次のコマンドを実行してください。

kubectl get pods --all-namespaces -o json | grep -E 'seccomp.security.alpha.kubernetes.io/pod|container.seccomp.security.alpha.kubernetes.io'

`--container-runtime` コマンドライン引数の削除

kubelet の --container-runtime コマンドライン引数は削除されました。Amazon EKS のデフォルトのコンテナランタイムは v1.24 以降 containerd となっており、コンテナランタイムの指定は不要になりました。ノードのブートストラッププロセス中のエラーを防ぐために、この引数を --kubelet-extra-args に渡さないようにすることが重要です。すべてのノード作成ワークフローとビルドスクリプトから --container-runtime 引数を削除する必要があります。これには、ブートストラップスクリプト、eksctl や Terraform のような Infrastructure as Code (IaC) テンプレート、Amazon EKS 最適化 Amazon Linux AMI ビルドスクリプトなどのカスタム AMI ビルドスクリプトが含まれます。以下では、eksctl と Terraform について考えてみましょう。

eksctl

以下の例では、kubeletExtraConfig フィールドから container-runtime を削除する必要があります。

nodeGroups:
  - name: your-nodegroup-name
    instanceType: m5.large
    desiredCapacity: 3
    minSize: 1
    maxSize: 4
    kubeletExtraConfig:
      container-runtime: "your-runtime"

Terraform

以下の例では、bootstrap_extra_args フィールドから container-runtime を削除する必要があります。

  node_groups = {
    eks_nodes = {
      desired_capacity = 2
      max_capacity     = 10
      min_capacity     = 1

      instance_type = "m5.large"
      k8s_labels = {
        Environment = "test"
        Name        = "eks-worker-node"
      }

      additional_userdata = "echo foo bar"
      bootstrap_extra_args = "--container-runtime=your-runtime"
    }

まとめ

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

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

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

Amazon Web Services ブログ