# バージョンスキューポリシー
> さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンスキュー。
---
LLMS index: [llms.txt](/llms.txt)
---
このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異(バージョンスキュー)について説明します。
特定のクラスターデプロイツールは、バージョンスキューに追加の制限を加える場合があります。
## サポートされるバージョン {#supported-versions}
Kubernetesのバージョンは**x.y.z**の形式で表現され、**x**はメジャーバージョン、**y**はマイナーバージョン、**z**はパッチバージョンを指します。
これは[セマンティックバージョニング](https://semver.org/)に従っています。
詳細は、[Kubernetesのリリースバージョニング](https://git.k8s.io/sig-release/release-engineering/versioning.md#kubernetes-release-versioning)を参照してください。
Kubernetesプロジェクトでは、最新の3つのマイナーリリース(1.36、1.35、1.34)についてリリースブランチを管理しています。
Kubernetes 1.19以降では、パッチリリースに対して[約1年間のサポート](/releases/patch-releases/#support-period)が提供されます。
Kubernetes 1.18以前のバージョンは約9ヶ月間のパッチサポートが提供されていました。
セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。
パッチリリースは、これらのブランチから[定期的に](/releases/patch-releases/#cadence)切り出され、必要に応じて追加の緊急リリースも行われます。
[リリースマネージャー](/releases/release-managers/)グループがこれを決定しています。
詳細は、Kubernetes[パッチリリース](/releases/patch-releases/)ページを参照してください。
## サポートされるバージョンスキュー {#supported-version-skew}
### kube-apiserver
[高可用性(HA)クラスター](/docs/setup/production-environment/tools/kubeadm/high-availability/)では、最新および最古の`kube-apiserver`インスタンスは1つのマイナーバージョン以内でなければなりません。
例:
* 最新の`kube-apiserver`が**1.36**であるとします
* ほかの`kube-apiserver`インスタンスは**1.36**および**1.35**がサポートされます
### kubelet
* `kubelet`は`kube-apiserver`より新しいバージョンであってはなりません。
* `kubelet`は`kube-apiserver`より最大で3つ前のマイナーバージョンまでサポートされます(`kubelet` < 1.25の場合は最大2つ前のマイナーバージョンまで)。
例:
* `kube-apiserver`が**1.36**であるとします
* `kubelet`は**1.36**、**1.35**、**1.34**、および**1.33**がサポートされます
備考:
HAクラスター内のkube-apiserver間にバージョンスキューがある場合、有効なkubeletのバージョンは少なくなります。
例:
* `kube-apiserver`インスタンスが**1.36**および**1.35**であるとします
* `kubelet`は**1.35**、**1.34**、および**1.33**がサポートされます(**1.36**はバージョン**1.35**の`kube-apiserver`よりも新しくなるためサポートされません)
### kube-proxy
* `kube-proxy`は`kube-apiserver`よりも新しいバージョンであってはなりません。
* `kube-proxy`は`kube-apiserver`より最大で3つ前のマイナーバージョンまでサポートされます(`kube-proxy` < 1.25の場合は最大2つ前のマイナーバージョンまで)。
* `kube-proxy`は同一ノードで動作している`kubelet`より最大3マイナーバージョン古くても新しくてもサポートされます(`kube-proxy` < 1.25の場合は2バージョンまで)。
例:
* `kube-apiserver`のバージョンが**1.36**であるとします
* `kube-proxy`は**1.36**、**1.35**、**1.34**および**1.33**がサポートされます
備考:
HAクラスター内のkube-apiserver間にバージョンスキューがある場合、有効なkube-proxyのバージョンは少なくなります。
例:
* `kube-apiserver`インスタンスが**1.36**および**1.35**であるとします
* `kube-proxy`は**1.35**、**1.34**、**1.33**がサポートされます(**1.36**は、**1.35**の`kube-apiserver`インスタンスよりも新しいためサポートされません)
### kube-controller-manager、kube-scheduler、およびcloud-controller-manager {#kube-controller-manager-kube-scheduler-and-cloud-controller-manager}
`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は、通信する`kube-apiserver`インスタンスよりも新しいバージョンであってはなりません。
`kube-apiserver`のマイナーバージョンと一致することが期待されますが、1つ古いマイナーバージョンでも可能です(ライブアップグレードを可能にするため)。
例:
* `kube-apiserver`が**1.36**であるとします
* `kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.36**および**1.35**がサポートされます
備考:
HAクラスター内のkube-apiserver間にバージョンスキューがあり、これらのコンポーネントがクラスター内のいずれかのkube-apiserverと通信する場合(たとえばロードバランサーを経由して)、コンポーネントの有効なバージョンは少なくなります。
例:
* `kube-apiserver`インスタンスが**1.36**および**1.35**であるとします
* いずれかの`kube-apiserver`インスタンスへ配信するロードバランサーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`は**1.35**がサポートされます(**1.36**はバージョン**1.35**の`kube-apiserver`よりも新しくなるためサポートされません)
### kubectl
`kubectl`は`kube-apiserver`の1つ以内のバージョン(古い、または新しいバージョン)をサポートします。
例:
* `kube-apiserver`が**1.36**であるとします
* `kubectl`は**1.37**、**1.36**、および**1.35**がサポートされます
備考:
HAクラスター内のkube-apiserver間にバージョンスキューがある場合、有効なkubectlバージョンは少なくなります。
例:
* `kube-apiserver`インスタンスが**1.36**および**1.35**であるとします
* `kubectl`は**1.36**および**1.35**がサポートされます(ほかのバージョンでは、ある`kube-apiserver`コンポーネントからマイナーバージョンが2つ以上離れる可能性があります)
## サポートされるコンポーネントのアップグレード順序 {#supported-component-upgrade-order}
コンポーネント間でサポートされるバージョンスキューは、コンポーネントをアップグレードする順序に影響されます。
このセクションでは、既存のクラスターをバージョン**1.35**からバージョン**1.36**へ移行するために、コンポーネントをアップグレードする順序を説明します。
任意ですが、アップグレードを準備する際は、アップグレード中にできるだけ多くのリグレッション修正やバグ修正の恩恵を受けられるよう、以下を実施することをKubernetesプロジェクトでは推奨しています:
* コンポーネントが現在のマイナーバージョンの最新のパッチバージョンにあることを確認する。
* コンポーネントを対象のマイナーバージョンの最新のパッチバージョンにアップグレードする。
例えば、1.35を実行している場合は、最新のパッチバージョンにあることを確認してください。
その後、1.36の最新のパッチバージョンにアップグレードしてください。
### kube-apiserver
前提条件:
* シングルインスタンスのクラスターにおいて、既存の`kube-apiserver`インスタンスは**1.35**とします
* HAクラスターにおいて、既存の`kube-apiserver`は**1.35**または**1.36**とします(最新と最古の間で、最大で1つのマイナーバージョンスキューとなります)
* サーバーと通信する`kube-controller-manager`、`kube-scheduler`および`cloud-controller-manager`はバージョン**1.35**とします(必ず既存のAPIサーバーのバージョンよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります)
* すべてのノードの`kubelet`インスタンスはバージョン**1.35**または**1.34**とします(必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります)
* 登録されたAdmission webhookは、新しい`kube-apiserver`インスタンスが送信するこれらのデータを扱うことができます:
* `ValidatingWebhookConfiguration`および`MutatingWebhookConfiguration`オブジェクトは、**1.36**で追加されたRESTリソースの新しいバージョンを含んで更新されます(または、v1.15から利用可能な[`matchPolicy: Equivalent`オプション](/docs/reference/access-authn-authz/extensible-admission-controllers/#matching-requests-matchpolicy)を使用してください)
* Webhookは送信されたRESTリソースの新しいバージョン、および**1.36**のバージョンで追加された新しいフィールドを扱うことができます
`kube-apiserver`を**1.36**にアップグレードしてください。
備考:
非推奨APIおよび
APIの変更ガイドラインのプロジェクトポリシーにおいては、シングルインスタンスの場合でも
kube-apiserverのアップグレードの際にマイナーバージョンをスキップしてはなりません。
備考:
マイナーバージョンの
kubeletをアップグレードする前に、そのノードからPodを
ドレインしてください。
kubeletのマイナーバージョンのインプレースアップグレードはサポートされていません。
警告:
kube-apiserverより常に3つ前のマイナーバージョンのkubeletインスタンスでクラスターを実行する場合、コントロールプレーンをアップグレードする前にkubeletをアップグレードしなければなりません。
### kube-proxy
前提条件:
* `kube-proxy`と通信する`kube-apiserver`インスタンスが**1.36**であること
必要に応じて、`kube-proxy`インスタンスを**1.36**にアップグレードしてください(**1.35**や**1.34**、**1.33**のままにすることもできます)。
警告:
kube-apiserverより常に3つ前のマイナーバージョンで動作しているkube-proxyインスタンスは、コントロールプレーンをアップグレードする前にアップグレードしなければなりません。