Kubernetes 1.29: 変更点まとめ(What's new!)とアップグレード時の注意事項

はじめに

このエントリは、Kubernetes 1.29 の CHANGELOG 及びKubernetes v1.29: Mandalaについてまとめたページへのリンクです。
詳細については各まとめページを参照してください。

変更点の詳細へのリンク

• Metrics Changes と SIG Instrumentation @watawuwu
• SIG Apps @yosshi_
• SIG API Machinery @Ladicle
• SIG Auth @hiyosi
• SIG CLI @superbrothers
• SIG Cluster Lifecycle　@yuanying
• SIG Storage @ysakashita
• SIG Network @tkusumi
• SIG Scheduling @ordovicia
• SIG Node TBD

Improvements that graduated to stable in Kubernetes v1.29

ReadWriteOncePod PersistentVolume access mode (SIG Storage)

Kubernetesで、volumeのaccess modesは永続ストレージがどのように消費されるのかを定義できる方法です。access modeはPersistentVolumes(PVs)とPersistentVolumeClaims(PVCs)のためのspecの一部です。ストレージの利用時、そのストレージがどのように消費されるかをモデル化するための方法は様々です。例えば、ネットワークファイル共有のようなストレージシステムは多くのユーザがデータに対して同時に読み書き可能です。他のケースでは、同時のデータの読み込みは許可されていますが、書き込みは許可されていないものもあります。機密性の高いデータでは、一人のユーザしかデータの読み書きができない可能性もあります。

v1.22より前では、KubernetesはPVやPVCのために3つのaccess modeを提供していました。

• ReadWriteOnce - ボリュームは一つのノードにread-writeとしてマウントされる可能性がある
• ReadOnlyMany - ボリュームは多くのノードからread-onlyでマウントさる可能性がある
• ReadWriteMany - ボリュームは多くのノードからread-writeとしてマウントされる可能性がある

ReadWriteOnceというaccess modeはボリュームのアクセスが一つのノードへ制限されるため、同一ノード上の複数のPodが同じボリュームを読み書きできることを意味します。これは潜在的にいくつかのアプリケーションにとって主要な問題となる可能性があり、特にデータの安全性を保証するために同時に最大1台のwriterとしなければなりません。

この問題を解決するために、4つ目のaccess modeがCSIボリュームのためにalpha機能としてv1.22で導入されました。もしReadWriteOncePod access modeの使うPVCを持つPodを作成した場合、Kubernetesは、そのPodがクラスター全体で、そのPVCを読んだり、書き込んだりできる唯一のPodであることを保証します。v1.29では、この機能がGAとなりました。

Node volume expansion Secret support for CSI drivers (SIG Storage)

Kubernetesでは、volumeの拡張操作はノード上のボリュームの拡張を含むかもしれず、それはファイルシステムのリサイズも含みます。いくつかのCSIドライバーは以下のユースケースのために拡張時にシークレット(例えばSANのファブリックへアクセスためのクレデンシャル)を必要とします。

• PersistentVolumeがLUKSなどを使用して暗号化されたブロックストレージである場合、デバイスを拡張するためにパスフレーズを必要とする場合があります。
• 様々な検証のために、CSIドライバーはノード拡張時にバックエンドシステムと通信するためにクレデンシャルを持つ必要があります。

この要件を満たすために、CSI Node Expand Secret機能がKubernetes v1.25で導入されました。これにより、CSIドライバがNodeExpandVolumeRequestの一部としてオプションのシークレットフィールドを送信し、基盤となるストレージシステムとノードボリューム拡張操作を実行できるようになります。Kubernetes v1.29では、この機能はGAとなりました。

KMS v2 encryption at rest generally available (SIG Auth)

Kubernetesクラスタをセキュアにするために考慮すべき最初のことの一つとして、永続化されたAPIデータを暗号化することです。KMSはプロバイダーがこの暗号化を実行するために外部のキーサービスに保存されたキーを操作するためのインターフェースを提供します。Kubernetes v1.29で、KMS v2は安定した機能となり、パフォーマンス、キーローテーション、ヘルスチェックとステータス、そして観測可能性において多くの改善がもたらされました。これらのエンハンスメントは、Kubernetesクラスタ内のすべてのリソースを暗号化する信頼性の高いソリューションをユーザーに提供します。

KMV v2を使うことは推奨されています。KMV v1のfeature gateはデフォルトで無効化されました。利用するにはオプトインしなければなりません。

Improvements that graduated to beta in Kubernetes v1.29

Node lifecycle separated from taint management (SIG Scheduling)

タイトルの通り、Taint-baseのPodの削除を行う TaintManager と NodeLifecycleController を分離し、2つのコントローラにします： unhealthyなノードにtaintを追加する NodeLifecycleController と、NoExecute エフェクトのtaintが付与されたノード上のPodの削除を行う TaintManager です。

Clean up for legacy Secret-based ServiceAccount tokens (SIG Auth)

Kubernetesは有効期限があり、特定のPodへ紐づけられたよりセキュアなService account tokenを利用する方法にスイッチしました。v1.24ではレガシーのSecretベースのService Account Tokenは自動生成されなくなりました。
その後、1.27でまだ使用されている残りの自動生成されたSecretベースのトークンに最終使用日にラベル付けを開始しました。

潜在的な攻撃領域減らすためにv1.29では、LegacyServiceAccountTokenCleanUp機能がレガシーな自動生成されたシークレットベースのトークンが長期間（デフォルトで1年間）使用されていない場合、無効であるとラベル付けし、無効であるとマークされた後、長期間（デフォルトでさらに1年間）使用が試みられない場合、自動的に削除します。KEP-2799

New alpha features

Define Pod affinity or anti-affinity using matchLabelKeys (SIG Scheduling) {#match-label-keys-pod-affinity}

PodAffinity/PodAntiAffinityへアルファとして一つのエンハンスメントが導入されました。ローリングアップデート中の計算精度を上昇させるものです。

nftables backend for kube-proxy (SIG Network)

現在、Linux上のデフォルトのkube-proxyの実装はiptablesに基づいています。これは長年(2001年のkernel バージョンが2.4から)Linuxカーネル上でパケットフィルタ・処理システムとして使用されていました。しかしながら、iptablesで解決できない問題により、後続のnftablesの開発が実施されました。iptablesの開発はほぼ終了し、新しい機能やパフォーマンス改善は主にnftablesに取り入れられています。

いくつかのLinuxディストリビューションはすでにiptablesの廃止または削除しはじめており、nftablesはiptablesの主なパフォーマンスの問題を解決すると主張しているため、このfeatureは新しいnftablesに基づいた新しいkube-proxyのバックエンドを追加します。

APIs to manage IP address ranges for Services (SIG Network) {#ip-address-range-apis}

ServiceはPodのセット上で動作しているアプリケーションを公開するための抽象的な方法です。Serviceはkube-apiserのフラグで事前定義されたCIDRからクラスタースコープな仮想IPアドレスを持つことができます。しかしながら、ユーザはkube-apiserverをリスタートせずに、Serviceのための既存のIPレンジを追加・削除・リサイズしたいかもしれません。

この機能は2つの新しいAPIオブジェクトである新しいアロケーターのロジックを実装します:
それはServiceCIDRとIPAddressであり、ユーザがSerivceで利用可能なIPを、新しいServiceCIDRを作成することで動的に増やせるようにします。これはIPの枯渇やIPのリナンバリングのような問題の解決に役立ちます。

Add support to containerd/kubelet/CRI to support image pull per runtime class (SIG Windows)

Kubernetes v1.29はPodのコンテナイメージをPodのRuntimeClassに基づいてpullするためのサポートが追加されました。この機能はRuntimeClassInImageCriApiと呼ばれるfeature gateで、v1.29でデフォルトで無効化されています。

コンテナイメージはマニフェストまたはインデックスのいずれかになります。pullされるイメージがインデックス(イメージインデックスはプラットフォーム毎に並べられたイメージマニフェストのリストを持ちます)である場合、コンテナランタイムのプラットフォームマッチングロジックはインデックスから適切なイメージマニフェストをpullするために使用されます。デフォルトでは、プラットフォームのマッチングロジックは、イメージpullが実行されるホストに一致するマニフェストを選択します。これは、例えばWindows Hyper-Vコンテナなど、ユーザーがVM ベースのコンテナとして実行することを意図してイメージをpullする可能性があるVM ベースのコンテナでは制限になる可能性があります。

RuntimeClass毎のイメージpull機能は、指定されたRuntimeClassに基づいて異なるイメージをpullするサポートを追加します。これは imageName や imageID ではなく、(imageID, runtimeClass) のタプルでイメージを参照することで実現します。コンテナランタイムはこの機能のサポートを追加することができます。追加しない場合は、Kubernetes v1.29以前のkubeletのデフォルトの動作が維持されます。

In-place updates for Pod resources, for Windows Pods (SIG Windows)

アルファ機能として、KubernetesのPodはその resources に関してミュータブルにすることができ、ユーザーはPodを再起動することなく、Podのリソースのreuqestsとlimitsを変更することができます。v1.29では、この機能がWindowsコンテナでもサポートされるようになりました。

Graduations, deprecations and removals for Kubernetes v1.29

こちらはstable(またはGAと呼ばれているもの)へ昇格した全ての機能のリストです。
新しい機能やアルファからベータを含むアップデートの全てのリストは、release notesをご確認ください。
このリリースでは11のエンハンスメントがstableへ昇格したものを含みます。

• Remove transient node predicates from KCCM's service controller
• Reserve nodeport ranges for dynamic and static allocation
• Priority and Fairness for API Server Requests
• KMS v2 Improvements
• Support paged LIST queries from the Kubernetes API
• ReadWriteOncePod PersistentVolume Access Mode
• Kubernetes Component Health SLIs
• CRD Validation Expression Language
• Introduce nodeExpandSecret in CSI PV source
• Track Ready Pods in Job status
• Kubelet Resource Metrics Endpoint

Deprecations and removals

Removal of in-tree integrations with cloud providers (SIG Cloud Provider)

Kubernetes v1.29はcloud providerに対する全てのインテグレーションがデフォルトでビルトインされなくなりました。もし、in-treeのcloud providerのインテグレーション(AzureやGCEやvSphereなど)に以前から依存していた場合は、いずれかの対応がとれる。

• 同等のcloud controller managerインテグレーションを有効化する(推奨)
• 関連するfeature gateをfalseへセットすることでレガシーのインテグレーションを戻すことが可能
  • DisableCloudProvidersとDisableKubeletCloudCredentialProvidersです

external cloud controller managerを有効化は、クラスタのコントロールプレーン内で適切なcloud controller managerを動作させなければならないことを意味し、加えて--cloud-provider=externalをkubelet(関連する全てのノード上の)とコントロールプレーン(kube-apiserverとkube-controller-manager)のコマンドライン引数へセットする必要があります。

external cloud controller managerを有効・動作させる方法についての詳細はCloud Controller Manager AdministrationとMigrate Replicated Control Plane To Use Cloud Controller Managerをご参照ください。

レガシーのin-treeのproviderの移行先として、cloud controller managerが必要な場合は以下のリンクをご参照ください。

• Cloud provider AWS
• Cloud provider Azure
• Cloud provider GCE
• Cloud provider OpenStack
• Cloud provider vSphere

詳細はKEP-2395をご確認ください。

Removal of the v1beta2 flow control API group

非推奨の flowcontrol.apiserver.k8s.io/v1beta2 のFlowSchemaとPriorityLevelConfigurationは、もはやKubernetes v1.29では提供されません。
もし非推奨のbeta APIグループを利用しているマニフェストやクライアントソフトウェアがあれば、v1.29へアップグレードする前に変更してください。
詳細についてはdeprecated API migration guideをご確認ください。

Deprecation of the status.nodeInfo.kubeProxyVersion field for Node

Nodeオブジェクトの.status.kubeProxyVersionフィールドは非推奨となり、将来のリリースでそのフィールドは削除されるよう処理されます。そのフィールドは正確ではなく、歴史的にはkubeletにより管理せれていましたが、kubeletは正確なkube-proxyのバージョンや、むしろkube-proxyが動作しているかどうかさえ知りません。

もしクライアントソフトウェアでこのフィールドを使っていましたら、利用をやめてください。この情報は信頼できず、フィールドは非推奨となりました。

Legacy Linux package repositories

2023年8月にレガシーのパッケージリポジトリ(apt.kubernetes.ioとyum.kubernetes.io)は正式に非推奨となり、Kubernetesプロジェクトはコミュニティによって所有されているDebianとRPMパッケージのためのパッケージリポジトリのGAをアナウンスしました。https://pkgs.k8s.ioで利用可能です。

これらのレガシーのリポジトリは2023年9月に凍結され、2024年1月に完全に廃止されます。現在、これらのリポジトリに依存している場合は、必ず移行してください。

この廃止はv1.29のリリースとは直接的に関係していません。これらの変更の影響や影響を受けた場合のどうすべきかを含む詳細はlegacy package repository deprecation announcementを確認してください。

Urgent Upgrade Notes

(No, really, you MUST read this before you upgrade)

• kubeadm upgrade plan --config 中に kube-proxy と kubelet のコンポーネント設定を受け付けなくなりました。これはレガシーな動作であり、アップグレードのサポートが十分ではなく、クラスタに保存されているこれらのコンポーネントの設定を手動でバージョンマイグレーションする必要があるかどうかを判断するためのplanステージでのみ使用できるものでした。将来的には、kubeadm は別のコンポーネント設定の移行アプローチを試みる予定です。(#120788, @chendave)
• kubeadm: 新たに別の"super-admin.conf"ファイルが配置されるようになりました。admin.conf中のUserは新しいRBACグループのkubeadm:cluster-adminへ紐付けられ、それはcluster-adminとClusterRoleへのアクセス権があります。super-admin.conf中のUserはRBACを迂回できる組み込みの超権限/ブレークグラスグループであるsystem:mastersにバインドされます。この変更前には、デフォルトでadmin.confがsystem:mastersグループにバインドされていましたが、これは望ましくありませんでした。kubeadm init phase kubeconfig allまたは単にkubeadm initを実行すると、新しいsuper-admin.confファイルが生成されます。クラスタ管理者は、このファイルをノードホスト上に残すか、安全な場所に移動するかを決めることができます。kubeadm certs renewは、ファイルが存在する場合、super-admin.confの証明書を1年間更新します。ファイルが存在しない場合は、"MISSING"という注意書きが表示されます。kubeadm upgrade applyはこのリリースで特定のノードを2ファイル設定に移行します。今後のkubeadmリリースでは、ディスク上にファイルが存在し、アップグレード時の更新が無効になっていない場合、super-admin.confの証明書をオプションで更新し続けます。kubeadm join --control-planeは、より権限の少ないユーザを持つadmin.confファイルのみを生成するようになります。(#121305, @neolit123)