Amazon Web Services ブログ
Amazon EKS が Kubernetes 1.25 のサポートを開始
この記事は Amazon EKS now supports Kubernetes version 1.25 (記事公開日: 2023 年 2 月 22 日) を翻訳したものです。
はじめに
Amazon Elastic Kubernetes Service (Amazon EKS) チームは、Amazon EKS および Amazon EKS Distro の Kubernetes バージョン 1.25 のサポートを発表できることを嬉しく思います。Amazon EKS Anywhere (リリース 0.14.2) も Kubernetes 1.25 をサポートします。このバージョンのテーマは、プロジェクトを構成する多様なコンポーネントと、プロジェクトに貢献した個人の両方をたたえるために選ばれました。それゆえ、「Combiner」というリリース名がぴったりです。Combiner は、オープンソースの共同作業の性質とその影響を、一般的な観点と Kubernetes に特有の観点の両方で強調しています。Kubernetes のリリースチームは次のように述べています。「このリリースでは、世界中に散らばる孤立した開発者、ライター、ユーザーから、世界を変えることができる力を結集させる、協調的でオープンな精神に敬意を表したいと考えています。」
アップグレードの前提条件
最近では、Kubernetes の新バージョンがリリースされたときに、API バージョンが非推奨になることが珍しくありません。このような場合、これらの非推奨の API を参照しているすべてのマニフェストとコントローラーを更新することが不可欠です。バージョン 1.25 で非推奨となった API バージョンのリストは、Deprecated API Migration Guide に記載されています。1.25 で削除された API バージョンには、discovery.k8s.io/v1beta1 API が含まれています。AWS Load Balancer Controller で enable-endpoint-slices フラグを使用している場合、Kubernetes 1.25 へアップグレードする前に、コントローラーを 2.4.7 へアップグレードする必要があります。現在実行しているコントローラーのバージョンがわからない場合は、以下のコマンドを実行してバージョン番号を取得できます。
バージョン番号はコロンの後に表示されます。
AWS Load Balancer Controller の最新バージョンへのインストール/アップグレードの手順は、ドキュメントに記載されています。EKS 1.25 へアップグレードする前にコントローラーを v2.4.7 へアップグレードしないと、ワークロードが中断する可能性があります。
Kubernetes 1.25 のハイライト
この記事では、Kubernetes バージョン 1.25 リリースにおける機能強化の一部を紹介します。最も注目すべき変更点は、Pod Security Policy (PSP) の廃止です。 Kubernetes 1.21 で非推奨となった PSP は、Pod Security Admission (PSA) コントローラーに置き換えられました。PSA は 1.25 で安定版へ移行しました。加えて、多くのセキュリティに関する変更が導入または改善されています。セキュリティ関連の機能には、Network Policy でのポート範囲の指定や、デフォルトの seccomp プロファイルとしての RuntimeDefault の使用などがあります。もう 1 つのセキュリティ関連の発展は、このバージョンリリースに同梱されている CoreDNS プラグインにおけるワイルドカードクエリの削除です。また、in-tree ストレージドライバーからの移行に向けた継続的な取り組みも注目に値します。Kubernetes 1.25 では、多くのストレージプラグインが削除され、CSI (Container Storage Interface) Migration は安定版へと移行しました。
機能強化の完全なリストを確認するには、Kubernetes の変更ログを参照してください。
Pod Security Admission の安定版への移行と Pod Security Policy の削除
Kubernetes 1.23 の時点で、PSA がベータ機能として導入され、PSP による Pod のセキュリティ対策の実装を引き継ぎました。これらの対策は Pod Security Standards (PSS) によって定義されており、Namespace レベルで Pod の動作を制限できます。Kubernetes 1.25 では PSA は安定版であり、Amazon EKS でデフォルトで有効になっています。一方、PSP は Kubernetes API から完全に削除され、使用できなくなります。PSP から PSA へのワークロードの移行を検討しているお客様向けに、この AWS ブログ記事で移行に関するガイダンスを提供しています。Kubernetes の公式ドキュメントも、この移行に関する支援を提供しています。EKS ユーザーガイドの PSP の削除に関する FAQ も参照してください。EKS ベストプラクティスガイドに記載されているように、お客様は PSA の代替としてオープンソースの Policy as Code (PaC) ソリューションの使用を検討できます。Amazon EKS アドオンの Amazon EKS 1.25 との互換性に関する追加情報については、このドキュメントを参照してください。
エフェメラルコンテナが安定版へ到達
エフェメラルコンテナは、実行中の Pod のデバッグプロセスを強化するために設計された特別な目的のコンテナとして、Kubernetes 1.16 で初めて導入されました。エフェメラルコンテナは、デバッグする予定の実行中の Pod と同じ Linux namespace (Linux 名前空間) にデプロイされ、そのコンテナのファイルシステムとプロセス名前空間にアクセスできます。このタイプのコンテナは、トラブルシューティングの実践には便利ですが、通常のアプリケーションのデプロイに使用することは意図されていません。そのため、ports、readinessProbe、livenessProbe などのフィールドを持つ他のコンテナのように設定できません。この機能は一般利用可能 (GA) になり、Amazon EKS 1.25 でワークロードのデバッグと検査に使用できます。
Network Policy のポート範囲が安定版へ移行
以前のバージョンの Kubernetes では、Network Policy でポート制限を適用する場合、ルールを適用すべきターゲットポートをそれぞれ指定する必要がありました。endPort が安定版へ移行したことで、お客様はポート範囲を宣言できるようになり、制限が簡単になりました。Network Policy がない場合、Kubernetes クラスター上のすべての Pod は、デフォルトで相互に通信できます。このデザインは、初期の採用を簡素化し、デフォルトの構成として残されています。しかし、Pod 間の内部ネットワーク接続 (East-West Traffic) を保護するために、本番ワークロードには Network Policy を採用することが強く推奨されます。Network Policy は、許可ベースのファイアウォールルールを実装します。Amazon EKS は、Pod ネットワーキングのために Amazon VPC CNI をインストールし、デフォルトの Container Network Interface (CNI) とします。現在のところ、Amazon EKS は、Calico、Cilium、Weave などの Network Policy エンジンの実行をサポートしています。Amazon EKS での Network Policy の実装については、EKS ベストプラクティスガイドのネットワーキング部分で詳しく説明されています。
SeccompDefault プロファイルがベータ版へ移行
seccomp は、Linux Kernel のセキュリティ機能で、ノード上のコンテナの動作を制限するために使用できます。コンテナワークロードの実行と密接に関係する多くのセキュリティリスクを考えると、seccomp プロファイルの使用はますます重要になってきています。Amazon EKS 1.25 では、この機能はデフォルトで無効になっています。そのため、ノードにこれらの厳格なセキュリティプロファイルを適用したいお客様は、kubelet を構成する際に --seccomp-default フラグを適用し、この機能を有効にする必要があります。ノードでは、Unconfined (seccomp が無効) モードではなく、RuntimeDefault seccomp プロファイルが使用されます。シナリオによっては、すべてのコンテナで同じレベルのシステムコール制限が必要なわけではないため、一部のワークロードにカスタム seccomp プロファイルを設定できます。あるいは、RuntimeDefault seccomp プロファイルを持つ専用ノードに Taint を適用し、より高い制限レベルを必要とするワークロードを選択して適切な Toleration でデプロイできます。お客様は、Kubernetes Security Profile を使用して、seccomp プロファイルを作成および伝播し、ノードにセキュリティを適用することもできます。
cgroup v2 が安定版へ移行
cgroup (コントロールグループ) は、Linux カーネルの機能で、プロセスを実行するためのリソースを管理します。cgroup を使用すると、CPU、メモリ、ネットワーク、ディスク I/O などの使用量を割り当てたり制限したりできます。この機能強化は、cgroup API バージョン 2 との Kubernetes 互換性に関連するもので、1.25 で安定版へ移行しました。Amazon EKS 1.25 で cgroups v2 を使用する場合、新しい設定値を確認して、リソースの値の範囲の変更のいくつかを確認する必要があります (cpu.weight が [2-262144] から [1-10000] に変更されるなど) 。現在、EKS では cgroups v2 をサポートする最適化された AMI を提供していません。この問題については、この Issue でトラッキングされています。
DaemonSet の maxSurge が安定版へ移行
この機能を使用すると、ローリングアップデート中に古い Pod の代わりに作成できる Pod の最大数を制御できます。この機能を利用するには、オプションの spec.strategy.rollingUpdate.maxSurge フィールドに、希望する Pod 数の値を追加します。この値は、既存の希望する Pod 数に対するパーセンテージとして表すこともできます。この機能は安定版へ移行し、Amazon EKS 1.25 ではデフォルトで有効になっています。
Local Ephemeral Storage Capacity Isolation が安定版へ移行
Kubernetes は永続的なストレージとエフェメラルなストレージの両方をサポートしています。エフェメラルストレージは、キャッシュ、マルチコンテナ Pod での一時的なデータの共有、ロギングといった用途に便利です。Kubernetes 1.7 で初めて導入されたこの機能は、Pod が消費するローカルエフェメラルストレージを隔離して制限する方法を提供します。CPU やメモリのリソース管理と同様に、リソース要求 (resource.requests) でエフェメラルストレージを予約するだけでなく、制限 (resource.limits) を設定できます。Pod のローカルエフェメラルストレージは、そのライフサイクルを Pod と共有し、超えることはありません。ハード制限を使用することで、Pod が個別に設定した容量を超えた場合に、Pod を退去 (eviction) させることができます。Kubernetes 1.25 では、この機能が一般利用可能 (GA) になりました。
Core CSI Migration が安定版へ移行
CSI (Container Storage Interface) Migration は、Kubernetes にエンコードされた in-tree ストレージプラグインを取り巻く複雑さを解決するために導入されました。ゴールは、これらの in-tree プラグインを、対応する out-of-tree の CSI ドライバー (Amazon EBS CSI など) に置き換えることでした。このアプローチにより、ストレージプロバイダープラグインが Kubernetes のソースコードから切り離され、Kubernetes とストレージプロバイダープラグインの両方のメンテナンスが改善されます。CSI Migration は一般利用可能 (GA) になり、CSI を介してクラスター上のワークロードと対話するドライバーを使用できるようになりました。Amazon EKS 1.25 では、Amazon EBS の CSI Migration はデフォルトで有効になっています。ただし、StorageClass、PersistentVolume、および PersistentVolumeClaim などのリソースに Amazon EBS ボリュームを使用するには、対応する Amazon EBS CSI ドライバーを Amazon EKS アドオンとしてインストールする必要があります。なお、この発展は、in-tree CSI ドライバーを持たない Amazon EKS Anywhere には適用されません。
その他のアップデート
AWS IAM Authenticator のアップデート
Amazon EKS 1.25 には、クラスター認証の機能強化も含まれています。kube-system Namespace にある aws-auth ConfigMap の YAML の値がマクロで始まる (つまり、最初の文字が中括弧である) 場合、中括弧の前後に二重引用符を追加する必要があります。これは、Amazon EKS 1.25 で使用される aws-iam-authenticator v0.6.3 による aws-auth ConfigMap の正確なパース処理を保証するために必要です。例えば、aws-auth ConfigMap でユーザー名を {{SessionName}} のように二重引用符を付けずに設定している場合、
"{{SessionName}}" に更新する必要があります。しかし、最初の文字が中括弧でない場合、
この場合は、何もする必要はありません。この変更を行わない場合、クラスターで認証に失敗する可能性があります。
まとめ
お客様は、Kubernetes バージョン 1.25 を実行する EKS クラスターを作成できるようになり、この記事で取り上げた機能、およびリリースノートに記載されているその他の機能強化の恩恵を受けることができるようになりました。現在 PSP を実行しているお客様は、PSA または PaC ソリューションへ移行するために、ワークロードの移行を計画することを強くお勧めします。クラスターを Amazon EKS の最新バージョンへアップグレードする際に支援が必要な場合は、こちらのドキュメントを参照してください。1.21 や 1.22 などの古いバージョンの Kubernetes をまだ実行している場合は、サポートされている新しいバージョンのいずれかにアップグレードすることを検討してください。1.21 クラスターは 2023 年 2 月 16 日にサポートが終了しています。1.22 クラスターのサポート終了は 2023 年 5 月です。Amazon EKS バージョンのサポートに関してさらに質問がある場合は、よくある質問を参照してください。
翻訳はプロフェッショナルサービスの杉田が担当しました。原文はこちらです。