Kubernetesプロジェクトは、最新の3つのマイナーリリース(1.35、1.34、1.33)のリリースブランチをメンテナンスしています。 Kubernetes 1.19以降のバージョンは、約1年間のパッチサポートを受け付けています。 Kubernetes 1.18以前のバージョンは、約9ヶ月間のパッチサポートを受け付けていました。
Kubernetesのバージョンは、x.y.zと表されます。 ここで、xはメジャーバージョン、yはマイナーバージョン、zはパッチバージョンを指し、これらはセマンティックバージョニングの用語に従います。
詳細は、バージョンスキューポリシーのドキュメントで確認できます。
Kubernetes1.36のリリーススケジュールをチェックしてみてください！
このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異(バージョンスキュー)について説明します。 特定のクラスターデプロイツールは、バージョンスキューに追加の制限を加える場合があります。
Kubernetesのバージョンはx.y.zの形式で表現され、xはメジャーバージョン、yはマイナーバージョン、zはパッチバージョンを指します。 これはセマンティックバージョニングに従っています。 詳細は、Kubernetesのリリースバージョニングを参照してください。
Kubernetesプロジェクトでは、最新の3つのマイナーリリース(1.35、1.34、1.33)についてリリースブランチを管理しています。 Kubernetes 1.19以降では、パッチリリースに対して約1年間のサポートが提供されます。 Kubernetes 1.18以前のバージョンは約9ヶ月間のパッチサポートが提供されていました。
セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。 パッチリリースは、これらのブランチから定期的に切り出され、必要に応じて追加の緊急リリースも行われます。
リリースマネージャーグループがこれを決定しています。
詳細は、Kubernetesパッチリリースページを参照してください。
高可用性(HA)クラスターでは、最新および最古のkube-apiserverインスタンスは1つのマイナーバージョン以内でなければなりません。
例:
kube-apiserverが1.35であるとしますkube-apiserverインスタンスは1.35および1.34がサポートされますkubeletはkube-apiserverより新しいバージョンであってはなりません。kubeletはkube-apiserverより最大で3つ前のマイナーバージョンまでサポートされます(kubelet < 1.25の場合は最大2つ前のマイナーバージョンまで)。例:
kube-apiserverが1.35であるとしますkubeletは1.35、1.34、1.33、および1.32がサポートされますkube-apiserver間にバージョンスキューがある場合、有効なkubeletのバージョンは少なくなります。例:
kube-apiserverインスタンスが1.35および1.34であるとしますkubeletは1.34、1.33、および1.32がサポートされます(1.35はバージョン1.34のkube-apiserverよりも新しくなるためサポートされません)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.35であるとしますkube-proxyは1.35、1.34、1.33および1.32がサポートされますkube-apiserver間にバージョンスキューがある場合、有効なkube-proxyのバージョンは少なくなります。例:
kube-apiserverインスタンスが1.35および1.34であるとしますkube-proxyは1.34、1.33、1.32がサポートされます(1.35は、1.34のkube-apiserverインスタンスよりも新しいためサポートされません)kube-controller-manager、kube-schedulerおよびcloud-controller-managerは、通信するkube-apiserverインスタンスよりも新しいバージョンであってはなりません。
kube-apiserverのマイナーバージョンと一致することが期待されますが、1つ古いマイナーバージョンでも可能です(ライブアップグレードを可能にするため)。
例:
kube-apiserverが1.35であるとしますkube-controller-manager、kube-schedulerおよびcloud-controller-managerは1.35および1.34がサポートされますkube-apiserver間にバージョンスキューがあり、これらのコンポーネントがクラスター内のいずれかのkube-apiserverと通信する場合(たとえばロードバランサーを経由して)、コンポーネントの有効なバージョンは少なくなります。例:
kube-apiserverインスタンスが1.35および1.34であるとしますkube-apiserverインスタンスへ配信するロードバランサーと通信するkube-controller-manager、kube-schedulerおよびcloud-controller-managerは1.34がサポートされます(1.35はバージョン1.34のkube-apiserverよりも新しくなるためサポートされません)kubectlはkube-apiserverの1つ以内のバージョン(古い、または新しいバージョン)をサポートします。
例:
kube-apiserverが1.35であるとしますkubectlは1.36、1.35、および1.34がサポートされますkube-apiserver間にバージョンスキューがある場合、有効なkubectlバージョンは少なくなります。例:
kube-apiserverインスタンスが1.35および1.34であるとしますkubectlは1.35および1.34がサポートされます(ほかのバージョンでは、あるkube-apiserverコンポーネントからマイナーバージョンが2つ以上離れる可能性があります)コンポーネント間でサポートされるバージョンスキューは、コンポーネントをアップグレードする順序に影響されます。 このセクションでは、既存のクラスターをバージョン1.34からバージョン1.35へ移行するために、コンポーネントをアップグレードする順序を説明します。
任意ですが、アップグレードを準備する際は、アップグレード中にできるだけ多くのリグレッション修正やバグ修正の恩恵を受けられるよう、以下を実施することをKubernetesプロジェクトでは推奨しています:
例えば、1.34を実行している場合は、最新のパッチバージョンにあることを確認してください。 その後、1.35の最新のパッチバージョンにアップグレードしてください。
前提条件:
kube-apiserverインスタンスは1.34としますkube-apiserverは1.34または1.35とします(最新と最古の間で、最大で1つのマイナーバージョンスキューとなります)kube-controller-manager、kube-schedulerおよびcloud-controller-managerはバージョン1.34とします(必ず既存のAPIサーバーのバージョンよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります)kubeletインスタンスはバージョン1.34または1.33とします(必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります)kube-apiserverインスタンスが送信するこれらのデータを扱うことができます:
ValidatingWebhookConfigurationおよびMutatingWebhookConfigurationオブジェクトは、1.35で追加されたRESTリソースの新しいバージョンを含んで更新されます(または、v1.15から利用可能なmatchPolicy: Equivalentオプションを使用してください)kube-apiserverを1.35にアップグレードしてください。
kube-apiserverのアップグレードの際にマイナーバージョンをスキップしてはなりません。前提条件:
kube-apiserverインスタンスが1.35であること(これらのコントロールプレーンコンポーネントが、クラスター内のkube-apiserverインスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべてのkube-apiserverインスタンスをアップグレードしなければなりません)kube-controller-manager、kube-schedulerおよびcloud-controller-managerを1.35にアップグレードしてください。
kube-controller-manager、kube-scheduler、cloud-controller-managerの間にアップグレードの順序はありません。
これらのコンポーネントはいずれの順序でも、同時にでもアップグレードできます。
前提条件:
kubeletと通信するkube-apiserverが1.35であること必要に応じて、kubeletインスタンスを1.35にアップグレードしてください(1.34、1.33、または1.32のままにすることもできます)。
kubeletをアップグレードする前に、そのノードからPodをドレインしてください。
kubeletのマイナーバージョンのインプレースアップグレードはサポートされていません。kube-apiserverより常に3つ前のマイナーバージョンのkubeletインスタンスでクラスターを実行する場合、コントロールプレーンをアップグレードする前にkubeletをアップグレードしなければなりません。前提条件:
kube-proxyと通信するkube-apiserverインスタンスが1.35であること必要に応じて、kube-proxyインスタンスを1.35にアップグレードしてください(1.34や1.33、1.32のままにすることもできます)。
kube-apiserverより常に3つ前のマイナーバージョンで動作しているkube-proxyインスタンスは、コントロールプレーンをアップグレードする前にアップグレードしなければなりません。リリースノートは、使用しているKubernetesのバージョンに合ったChangelogを読むことで確認できます。 1.35のchangelogを見るにはGitHubを参照してください。
またリリースノートは、relnotes.k8s.io上で検索してフィルタリングすることもできます。 1.35のフィルタリングされたリリースノートを見るにはrelnotes.k8s.ioを参照してください。