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
を実行する可能性が高まります
フィードバック
このページは役に立ちましたか?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to 問題を報告する or 改善を提案.