バージョンスキューポリシー

このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異(バージョンスキュー)について説明します。特定のクラスターデプロイツールは、バージョンの差異に追加の制限を加える場合があります。

サポートされるバージョン

Kubernetesのバージョンはx.y.zの形式で表現され、xはメジャーバージョン、yはマイナーバージョン、zはパッチバージョンを指します。これはセマンティックバージョニングに従っています。詳細は、Kubernetesのリリースバージョニングを参照してください。

Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています (1.34、1.33、1.32)。 Kubernetes 1.19 以降では、パッチリリースに対して約1年間のサポートが提供されます。Kubernetes 1.18 以前のバージョンは約9ヶ月間のパッチサポートを受け付けていました。

セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、これらのブランチから 定期的に 切り出され、必要に応じて追加の緊急リリースも行われます。

リリースマネージャーグループがこれを決定しています。

詳細は、Kubernetesパッチリリースページを参照してください。

サポートされるバージョンの差異

kube-apiserver

高可用性(HA)クラスターでは、最新および最古のkube-apiserverインスタンスがそれぞれ1つのマイナーバージョン内でなければなりません。

例:

• 最新のkube-apiserverが1.34であるとします
• ほかのkube-apiserverインスタンスは1.34および1.33がサポートされます

kubelet

kubeletはkube-apiserverより新しいものであってはならず、2つの古いマイナーバージョンまで有効です。

例:

• kube-apiserverが1.34であるとします
• kubeletは1.34、1.33および1.32がサポートされます

例:

• kube-apiserverインスタンスが1.34および1.33であるとします
• kubeletは1.33および1.32がサポートされます（1.34はバージョン1.33の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.34であるとします
• kube-proxyは1.34、1.33、 1.32および1.31がサポートされます

例:

• kube-apiserverインスタンスが1.34および1.33であるとします
• kube-proxyは1.33、1.32、 1.31がサポートされます (1.34は、1.33のkube-apiserverインスタンスよりも新しいためサポートされません)

kube-controller-manager、kube-scheduler、およびcloud-controller-manager

kube-controller-manager、kube-schedulerおよびcloud-controller-managerは、通信するkube-apiserverインスタンスよりも新しいバージョンであってはなりません。kube-apiserverのマイナーバージョンと一致することが期待されますが、1つ古いマイナーバージョンでも可能です(ライブアップグレードを可能にするため)。

例:

• kube-apiserverが1.34であるとします
• kube-controller-manager、kube-schedulerおよびcloud-controller-managerは1.34および1.33がサポートされます

例:

• kube-apiserverインスタンスが1.34および1.33であるとします
• いずれかのkube-apiserverインスタンスへ配信するロードバランサーと通信するkube-controller-manager、kube-schedulerおよびcloud-controller-managerは1.33がサポートされます(1.34はバージョン1.33のkube-apiserverよりも新しくなるためサポートされません)

kubectl

kubectlはkube-apiserverの1つ以内のバージョン(古い、または新しいもの)をサポートします。

例:

• kube-apiserverが1.34であるとします
• kubectlは1.35、1.34および1.33がサポートされます

例:

• kube-apiserverインスタンスが1.34および1.33であるとします
• kubectlは1.34および1.33がサポートされます(ほかのバージョンでは、あるkube-apiserverコンポーネントからマイナーバージョンが2つ以上離れる可能性があります)

サポートされるコンポーネントのアップグレード順序

コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン1.33から1.34 へ移行するために、コンポーネントをアップグレードする順序を説明します。

kube-apiserver

前提条件:

• シングルインスタンスのクラスターにおいて、既存のkube-apiserverインスタンスは1.33とします
• HAクラスターにおいて、既存のkube-apiserverは1.33または1.34 とします(最新と最古の間で、最大で1つのマイナーバージョンの差異となります)
• サーバーと通信するkube-controller-manager、kube-schedulerおよびcloud-controller-managerはバージョン1.33とします(必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります)
• すべてのノードのkubeletインスタンスはバージョン1.33または1.32 とします(必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります)
• 登録されたAdmission webhookは、新しいkube-apiserverインスタンスが送信するこれらのデータを扱うことができます:
  • ValidatingWebhookConfigurationおよびMutatingWebhookConfigurationオブジェクトは、1.34 で追加されたRESTリソースの新しいバージョンを含んで更新されます(または、v1.15から利用可能なmatchPolicy: Equivalentオプションを使用してください)
  • Webhookは送信されたRESTリソースの新しいバージョン、および1.34 のバージョンで追加された新しいフィールドを扱うことができます

kube-apiserverを1.34 にアップグレードしてください。

kube-controller-manager、kube-scheduler、およびcloud-controller-manager

前提条件:

• これらのコンポーネントと通信するkube-apiserverインスタンスが1.34 であること(これらのコントロールプレーンコンポーネントが、クラスター内のkube-apiserverインスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべてのkube-apiserverインスタンスをアップグレードしなければなりません)

kube-controller-manager、kube-schedulerおよびcloud-controller-managerを1.34 にアップグレードしてください。

kubelet

前提条件:

• kubeletと通信するkube-apiserverが1.34 であること

必要に応じて、kubeletインスタンスを1.34 にアップグレードしてください(1.33や1.32 のままにすることもできます)。

kube-proxy

前提条件:

• kube-proxyと通信するkube-apiserverインスタンスが1.34 であること

必要に応じて、kube-proxyインスタンスを1.34 にアップグレードしてください(1.33や1.32、1.31のままにすることもできます)。