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

# はじめに

このエントリは、Kubernetes 1.29 の [CHANGELOG](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md) 及び[Kubernetes v1.29: Mandala](https://kubernetes.io/blog/2023/12/13/kubernetes-v1-29-release/)についてまとめたページへのリンクです。
詳細については各まとめページを参照してください。

# 変更点の詳細へのリンク

- [Metrics Changes と SIG Instrumentation](https://qiita.com/watawuwu/items/d6c63744ba8b65cea748) @watawuwu 
- [SIG Apps](https://qiita.com/yosshi_/items/d7cb8add71ba719e48b5) @yosshi_ 
- [SIG API Machinery](https://qiita.com/Ladicle/items/987e608426a572b1673c) @Ladicle 
- [SIG Auth](https://qiita.com/hiyosi/items/d0946fd0839cc4c6e3d2) @hiyosi 
- [SIG CLI](https://qiita.com/superbrothers/items/d11f02e2bf9caac5bcb6) @superbrothers
- [SIG Cluster Lifecycle](https://qiita.com/yuanying/items/4d28f271922c6c0fc7c3)　@yuanying 
- [SIG Storage](https://qiita.com/ysakashita/items/de08b58ac87a52d02011) @ysakashita 
- [SIG Network](https://qiita.com/tkusumi/items/452d8ba0d7fa2e42b1be) @tkusumi 
- [SIG Scheduling](https://qiita.com/ordovicia/items/e99d8ab6ca3b540b70e1) @ordovicia 
- SIG Node TBD

## Improvements that graduated to stable in Kubernetes v1.29

### ReadWriteOncePod PersistentVolume access mode (SIG Storage)

<!--
In Kubernetes, volume [access modes](/docs/concepts/storage/persistent-volumes/#access-modes)
are the way you can define how durable storage is consumed. These access modes are a part of the spec for PersistentVolumes (PVs) and PersistentVolumeClaims (PVCs). When using storage, there are different ways to model how that storage is consumed. For example, a storage system like a network file share can have many users all reading and writing data simultaneously. In other cases maybe everyone is allowed to read data but not write it. For highly sensitive data, maybe only one user is allowed to read and write data but nobody else.

Before v1.22, Kubernetes offered three access modes for PVs and PVCs:
*	ReadWriteOnce – the volume can be mounted as read-write by a single node
*	ReadOnlyMany – the volume can be mounted read-only by many nodes
*	ReadWriteMany – the volume can be mounted as read-write by many nodes

The ReadWriteOnce access mode restricts volume access to a single node, which means it is possible for multiple pods on the same node to read from and write to the same volume. This could potentially be a major problem for some applications, especially if they require at most one writer for data safety guarantees.
    
To address this problem, a fourth access mode ReadWriteOncePod was introduced as an Alpha feature in v1.22 for CSI volumes. If you create a pod with a PVC that uses the ReadWriteOncePod access mode, Kubernetes ensures that pod is the only pod across your whole cluster that can read that PVC or write to it. In v1.29, this feature became Generally Available.
-->

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](https://github.com/kubernetes/community/tree/master/sig-storage))

<!--
In Kubernetes, a volume expansion operation may include the expansion of the volume on the node, which involves filesystem resize. Some CSI drivers require secrets, for example a credential for accessing a SAN fabric, during the node expansion for the following use cases:
* When a PersistentVolume represents encrypted block storage, for example using LUKS, you may need to provide a passphrase in order to expand the device.
* For various validations, the CSI driver needs to have credentials to communicate with the backend storage system at time of node expansion.

To meet this requirement, the CSI Node Expand Secret feature was introduced in Kubernetes v1.25. This allows an optional secret field to be sent as part of the NodeExpandVolumeRequest by the CSI drivers so that node volume expansion operation can be performed with the underlying storage system. In Kubernetes v1.29, this feature became generally available.
-->

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](https://github.com/kubernetes/community/tree/master/sig-auth))

<!--
One of the first things to consider when securing a Kubernetes cluster is encrypting persisted
API data at rest. KMS provides an interface for a provider to utilize a key stored in an external
key service to perform this encryption. With the Kubernetes v1.29, KMS v2 has become
a stable feature bringing numerous improvements in performance, key rotation,
health check & status, and observability.
These enhancements provide users with a reliable solution to encrypt all resources in their Kubernetes clusters. You can read more about this in [KEP-3299](https://kep.k8s.io/3299). 

It is recommended to use KMS v2. KMS v1 feature gate is disabled by default. You will have to opt in to continue to use it.
-->

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](https://github.com/kubernetes/community/tree/master/sig-scheduling))

<!--
As title describes, it's to decouple `TaintManager` that performs taint-based pod eviction from `NodeLifecycleController` and make them two separate controllers: `NodeLifecycleController` to add taints to unhealthy nodes and `TaintManager` to perform pod deletion on nodes tainted with NoExecute effect.
-->

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

### Clean up for legacy Secret-based ServiceAccount tokens ([SIG Auth](https://github.com/kubernetes/community/tree/master/sig-auth))

<!--
Kubernetes switched to using more secure service account tokens, which were time-limited and bound to specific pods by 1.22. Stopped auto-generating legacy secret-based service account tokens in 1.24. Then started labeling remaining auto-generated secret-based tokens still in use with their last-used date in 1.27.

In v1.29, to reduce potential attack surface, the LegacyServiceAccountTokenCleanUp feature labels legacy auto-generated secret-based tokens as invalid if they have not been used for a long time (1 year by default), and automatically removes them if use is not attempted for a long time after being marked as invalid (1 additional year by default). [KEP-2799](https://kep.k8s.io/2799)
-->

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

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

## New alpha features

### Define Pod affinity or anti-affinity using `matchLabelKeys` ([SIG Scheduling](https://github.com/kubernetes/community/tree/master/sig-scheduling)) {#match-label-keys-pod-affinity}

<!--
One enhancement will be introduced in PodAffinity/PodAntiAffinity as alpha. It will increase the accuracy of calculation during rolling updates.
-->

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

### nftables backend for kube-proxy ([SIG Network](https://github.com/kubernetes/community/tree/master/sig-network))

<!--
The default kube-proxy implementation on Linux is currently based on iptables. This was the preferred packet filtering and processing system in the Linux kernel for many years (starting with the 2.4 kernel in 2001). However, unsolvable problems with iptables led to the development of a successor, nftables. Development on iptables has mostly stopped, with new features and performance improvements primarily going into nftables instead.

This feature adds a new backend to kube-proxy based on nftables, since some Linux distributions already started to deprecate and remove iptables, and nftables claims to solve the main performance problems of iptables.
-->

現在、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](https://github.com/kubernetes/community/tree/master/sig-network)) {#ip-address-range-apis}

<!--
Services are an abstract way to expose an application running on a set of Pods. Services can have a cluster-scoped virtual IP address, that is allocated from a predefined CIDR defined in the kube-apiserver flags. However, users may want to add, remove, or resize existing IP ranges allocated for Services without having to restart the kube-apiserver.

This feature implements a new allocator logic that uses 2 new API Objects: ServiceCIDR and IPAddress, allowing users to dynamically increase the number of Services IPs available by creating new ServiceCIDRs. This helps to resolve problems like IP exhaustion or IP renumbering.
-->

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](https://github.com/kubernetes/community/tree/master/sig-windows))

<!--
Kubernetes v1.29 adds support to pull container images based on the RuntimeClass of the Pod that uses them.
This feature is off by default in v1.29 under a feature gate called `RuntimeClassInImageCriApi`.

Container images can either be a manifest or an index. When the image being pulled is an index (image index has a list of image manifests ordered by platform), platform matching logic in the container runtime is used to pull an appropriate image manifest from the index. By default, the platform matching logic picks a manifest that matches the host that the image pull is being executed from. This can be limiting for VM-based containers where a user could pull an image with the intention of running it as a VM-based container, for example, Windows Hyper-V containers.

The image pull per runtime class feature adds support to pull different images based the runtime class specified. This is achieved by referencing an image by a tuple of (`imageID`, `runtimeClass`), instead of just the `imageName` or `imageID`. Container runtimes could choose to add support for this feature if they'd like. If they do not, the default behavior of kubelet that existed prior to Kubernetes v1.29 will be retained.
-->

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](https://github.com/kubernetes/community/tree/master/sig-windows))

<!--
As an alpha feature, Kubernetes Pods can be mutable with respect to their `resources`, allowing users to change the _desired_ resource requests and limits for a Pod without the need to restart the Pod. With v1.29, this feature is now supported for Windows containers.
-->

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

## Graduations, deprecations and removals for Kubernetes v1.29

<!--
This lists all the features that graduated to stable (also known as _general availability_).
For a full list of updates including new features and graduations from alpha to beta, see the
[release notes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.29.md).

This release includes a total of 11 enhancements promoted to Stable:
-->

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

- [Remove transient node predicates from KCCM's service controller](https://kep.k8s.io/3458)
- [Reserve nodeport ranges for dynamic and static allocation](https://kep.k8s.io/3668)
- [Priority and Fairness for API Server Requests](https://kep.k8s.io/1040)
- [KMS v2 Improvements](https://kep.k8s.io/3299)
- [Support paged LIST queries from the Kubernetes API](https://kep.k8s.io/365)
- [ReadWriteOncePod PersistentVolume Access Mode](https://kep.k8s.io/2485)
- [Kubernetes Component Health SLIs](https://kep.k8s.io/3466)
- [CRD Validation Expression Language](https://kep.k8s.io/2876)
- [Introduce nodeExpandSecret in CSI PV source](https://kep.k8s.io/3107)
- [Track Ready Pods in Job status](https://kep.k8s.io/2879)
- [Kubelet Resource Metrics Endpoint](https://kep.k8s.io/727)

### Deprecations and removals

#### Removal of in-tree integrations with cloud providers ([SIG Cloud Provider](https://github.com/kubernetes/community/tree/master/sig-cloud-provider))

<!--
Kubernetes v1.29 defaults to operating _without_ a built-in integration to any cloud provider.
If you have previously been relying on in-tree cloud provider integrations (with Azure, GCE, or vSphere) then you can either:
- enable an equivalent external [cloud controller manager](/docs/concepts/architecture/cloud-controller/)
  integration _(recommended)_
- opt back in to the legacy integration by setting the associated feature gates to `false`; the feature
  gates to change are `DisableCloudProviders` and `DisableKubeletCloudCredentialProviders`
  
Enabling external cloud controller managers means you must run a suitable cloud controller manager within your cluster's control plane; it also requires setting the command line argument `--cloud-provider=external` for the kubelet (on every relevant node), and across the control plane (kube-apiserver and kube-controller-manager).

For more information about how to enable and run external cloud controller managers, read [Cloud Controller Manager Administration](/docs/tasks/administer-cluster/running-cloud-controller/) and [Migrate Replicated Control Plane To Use Cloud Controller Manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/).

If you need a cloud controller manager for one of the legacy in-tree providers, please see the following links: 
* [Cloud provider AWS](https://github.com/kubernetes/cloud-provider-aws)
* [Cloud provider Azure](https://github.com/kubernetes-sigs/cloud-provider-azure)
* [Cloud provider GCE](https://github.com/kubernetes/cloud-provider-gcp)
* [Cloud provider OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
* [Cloud provider vSphere](https://github.com/kubernetes/cloud-provider-vsphere)

There are more details in [KEP-2395](https://kep.k8s.io/2395).
-->

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

- 同等の[cloud controller manager](/docs/concepts/architecture/cloud-controller/)インテグレーションを有効化する(推奨)
- 関連する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](/docs/tasks/administer-cluster/running-cloud-controller/)と[Migrate Replicated Control Plane To Use Cloud Controller Manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/)をご参照ください。

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

* [Cloud provider AWS](https://github.com/kubernetes/cloud-provider-aws)
* [Cloud provider Azure](https://github.com/kubernetes-sigs/cloud-provider-azure)
* [Cloud provider GCE](https://github.com/kubernetes/cloud-provider-gcp)
* [Cloud provider OpenStack](https://github.com/kubernetes/cloud-provider-openstack)
* [Cloud provider vSphere](https://github.com/kubernetes/cloud-provider-vsphere)

詳細は[KEP-2395](https://kep.k8s.io/2395)をご確認ください。

#### Removal of the `v1beta2` flow control API group

<!--
The deprecated _flowcontrol.apiserver.k8s.io/v1beta2_ API version of FlowSchema and
PriorityLevelConfiguration are no longer served in Kubernetes v1.29. 

If you have manifests or client software that uses the deprecated beta API group, you should change
these before you upgrade to v1.29.
See the [deprecated API migration guide](/docs/reference/using-api/deprecation-guide/#v1-29)
for details and advice.
-->

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

#### Deprecation of the `status.nodeInfo.kubeProxyVersion` field for Node

<!--
The `.status.kubeProxyVersion` field for Node objects is now deprecated, and the Kubernetes project
is proposing to remove that field in a future release. The deprecated field is not accurate and has historically
been managed by kubelet - which does not actually know the kube-proxy version, or even whether kube-proxy
is running.

If you've been using this field in client software, stop - the information isn't reliable and the field is now
deprecated.
-->

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

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

#### Legacy Linux package repositories

<!--
Please note that in August of 2023, the legacy package repositories (`apt.kubernetes.io` and
`yum.kubernetes.io`) were formally deprecated and the Kubernetes project announced the
general availability of the community-owned package repositories for Debian and RPM packages,
available at `https://pkgs.k8s.io`.

These legacy repositories were frozen in September of 2023, and
will go away entirely in January of 2024. If you are currently relying on them, you **must** migrate.

_This deprecation is not directly related to the v1.29 release._ For more details, including how these changes may affect you and what to do if you are affected, please read the [legacy package repository deprecation announcement](/blog/2023/08/31/legacy-package-repository-deprecation/).
-->

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](/blog/2023/08/31/legacy-package-repository-deprecation/)を確認してください。

## Urgent Upgrade Notes 

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

<!--
- Stopped accepting component configuration for `kube-proxy` and `kubelet` during `kubeadm upgrade plan --config`. This was a legacy behavior that was not well supported for upgrades and could be used only at the plan stage to determine if the configuration for these components stored in the cluster needs manual version migration. In the future, `kubeadm` will attempt alternative component config migration approaches. ([#120788](https://github.com/kubernetes/kubernetes/pull/120788), [@chendave](https://github.com/chendave))
 - `kubeadm`: a separate "super-admin.conf" file is now deployed. The User in `admin.conf` is now bound to a new RBAC Group `kubeadm:cluster-admins` that has `cluster-admin` `ClusterRole` access. The User in `super-admin.conf` is now bound to the `system:masters` built-in super-powers / break-glass Group that can bypass RBAC. Before this change, the default `admin.conf` was bound to `system:masters` Group, which was undesired. Executing `kubeadm init phase kubeconfig all` or just `kubeadm init` will now generate the new `super-admin.conf` file. The cluster admin can then decide to keep the file present on a node host or move it to a safe location. `kubadm certs renew` will renew the certificate in `super-admin.conf` to one year if the file exists; if it does not exist a "MISSING" note will be printed. `kubeadm upgrade apply` for this release will migrate this particular node to the two file setup. Subsequent kubeadm releases will continue to optionally renew the certificate in `super-admin.conf` if the file exists on disk and if renew on upgrade is not disabled. `kubeadm join --control-plane` will now generate only an `admin.conf` file that has the less privileged User. ([#121305](https://github.com/kubernetes/kubernetes/pull/121305), [@neolit123](https://github.com/neolit123))
 -->

- `kubeadm upgrade plan --config` 中に `kube-proxy` と `kubelet` のコンポーネント設定を受け付けなくなりました。これはレガシーな動作であり、アップグレードのサポートが十分ではなく、クラスタに保存されているこれらのコンポーネントの設定を手動でバージョンマイグレーションする必要があるかどうかを判断するためのplanステージでのみ使用できるものでした。将来的には、`kubeadm` は別のコンポーネント設定の移行アプローチを試みる予定です。([#120788](https://github.com/kubernetes/kubernetes/pull/120788), [@chendave](https://github.com/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](https://github.com/kubernetes/kubernetes/pull/121305), [@neolit123](https://github.com/neolit123))