website/content/ja/docs/setup/release/version-skew-policy.md

title, content_type, weight

title	content_type	weight
Kubernetesバージョンとバージョンスキューサポートポリシー	concept	30

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

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

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

Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}})。

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

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

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

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

kube-apiserver

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

例:

• 最新のkube-apiserverが**{{< skew latestVersion >}}**であるとします
• ほかのkube-apiserverインスタンスは**{{< skew latestVersion >}}および{{< skew prevMinorVersion >}}**がサポートされます

kubelet

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

例:

• kube-apiserverが**{{< skew latestVersion >}}**であるとします
• kubeletは**{{< skew latestVersion >}}、{{< skew prevMinorVersion >}}および{{< skew oldestMinorVersion >}}**がサポートされます

{{< note >}} HAクラスター内のkube-apiserver間にバージョンの差異がある場合、有効なkubeletのバージョンは少なくなります。 {{</ note >}}

例:

• kube-apiserverインスタンスが**{{< skew latestVersion >}}および1.12**であるとします
• kubeletは**{{< skew prevMinorVersion >}}および{{< skew oldestMinorVersion >}}がサポートされます（{{< skew latestVersion >}}はバージョン{{< skew prevMinorVersion >}}**の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が**{{< skew latestVersion >}}**であるとします
• kube-controller-manager、kube-schedulerおよびcloud-controller-managerは**{{< skew latestVersion >}}および{{< skew prevMinorVersion >}}**がサポートされます

{{< note >}} HAクラスター内のkube-apiserver間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかのkube-apiserverと通信する場合(たとえばロードバランサーを経由して)、コンポーネントの有効なバージョンは少なくなります。 {{< /note >}}

例:

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

kubectl

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

例:

• kube-apiserverが**{{< skew latestVersion >}}**であるとします
• kubectlは**{{< skew nextMinorVersion >}}、{{< skew latestVersion >}}および{{< skew prevMinorVersion >}}**がサポートされます

{{< note >}} HAクラスター内のkube-apiserver間にバージョンの差異がある場合、有効なkubectlバージョンは少なくなります。 {{< /note >}}

例:

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

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

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

kube-apiserver

前提条件:

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

kube-apiserverを**{{< skew latestVersion >}}** にアップグレードしてください。

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

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

前提条件:

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

kube-controller-manager、kube-schedulerおよびcloud-controller-managerを**{{< skew latestVersion >}}** にアップグレードしてください。

kubelet

前提条件:

• kubeletと通信するkube-apiserverが**{{< skew latestVersion >}}** であること

必要に応じて、kubeletインスタンスを**{{< skew latestVersion >}}** にアップグレードしてください({{< skew prevMinorVersion >}}や{{< skew oldestMinorVersion >}} のままにすることもできます)。

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

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

kube-proxy

• kube-proxyのマイナーバージョンはノード上のkubeletと同じマイナーバージョンでなければなりません
• kube-proxyはkube-apiserverよりも新しいものであってはなりません
• kube-proxyのマイナーバージョンはkube-apiserverのマイナーバージョンよりも2つ以上古いものでなければなりません

例:

kube-proxyのバージョンが**{{< skew oldestMinorVersion >}}**の場合:

• kubeletのバージョンは**{{< skew oldestMinorVersion >}}**でなければなりません
• kube-apiserverのバージョンは**{{< skew oldestMinorVersion >}}と{{< skew latestVersion >}}**の間でなければなりません