Edit This Page

Kubernetesバージョンとバージョンスキューサポートポリシー

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

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

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

Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています。

セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、定期的または必要に応じてこれらのブランチから分岐されます。パッチリリースマネージャーがこれを決定しています。パッチリリースマネージャーは各リリースのリリースチームのメンバーです。

マイナーリリースは約3ヶ月ごとに行われるため、それぞれのリリースブランチは約9ヶ月間メンテナンスされます。

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

kube-apiserver

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

例:

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

kubelet

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

例:

  • kube-apiserverが1.13であるとします
  • kubeletは1.13、1.12および1.11がサポートされます
備考: HAクラスター内のkube-apiserver間にバージョンの差異がある場合、有効なkubeletのバージョンは少なくなります。

例:

  • kube-apiserverインスタンスが1.13および1.12であるとします
  • kubeletは1.12および1.11がサポートされます（1.13はバージョン1.12の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.13であるとします
  • kube-controller-manager、kube-schedulerおよびcloud-controller-managerは1.13および1.12がサポートされます
備考: HAクラスター内のkube-apiserver間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかのkube-apiserverと通信する場合（たとえばロードバランサーを経由して）、コンポーネントの有効なバージョンは少なくなります。

例:

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

kubectl

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

例:

  • kube-apiserverが1.13であるとします
  • kubectlは1.14、1.13および1.12がサポートされます
備考: HAクラスター内のkube-apiserver間にバージョンの差異がある場合、有効なkubectlバージョンは少なくなります。

例:

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

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

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

kube-apiserver

前提条件:

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

kube-apiserverを**1.(n+1)**にアップグレードしてください。

備考: 非推奨APIおよびAPIの変更ガイドラインのプロジェクトポリシーにおいては、シングルインスタンスの場合でもkube-apiserverのアップグレードの際にマイナーバージョンをスキップしてはなりません。

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

前提条件:

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

kube-controller-manager、kube-schedulerおよびcloud-controller-managerを**1.(n+1)**にアップグレードしてください。

kubelet

前提条件:

  • kubeletと通信するkube-apiserverが**1.(n+1)**であること

必要に応じて、kubeletインスタンスを**1.(n+1)にアップグレードしてください（1.nや1.(n-1)**のままにすることもできます）。

警告:

kube-apiserverと2つのマイナーバージョンのkubeletインスタンスを使用してクラスターを実行させることは推奨されません:

  • コントロールプレーンをアップグレードする前に、インスタンスをkube-apiserverの1つのマイナーバージョン内にアップグレードさせる必要があります
  • メンテナンスされている3つのマイナーリリースよりも古いバージョンのkubeletを実行する可能性が高まります