リリース
Kubernetesプロジェクトは、最新の3つのマイナーリリース(1.30、1.29、1.28)のリリースブランチをメンテナンスしています。
Kubernetes 1.19以降のバージョンは、約1年間のパッチサポートを受け付けています。
Kubernetes 1.18以前のバージョンは、約9ヶ月間のパッチサポートを受け付けていました。
Kubernetesのバージョンは、x.y.zと表されます。
ここで、xはメジャーバージョン、yはマイナーバージョン、zはパッチバージョンを指し、これらはセマンティックバージョニングの用語に従います。
詳細は、バージョンスキューポリシーのドキュメントで確認できます。
リリース履歴
1.30
最新リリース1.30.3 (リリース日: )
サポート終了日
Complete 1.30
Schedule and
Changelog
1.29
最新リリース1.29.7 (リリース日: )
サポート終了日
Complete 1.29
Schedule and
Changelog
1.28
最新リリース1.28.12 (リリース日: )
サポート終了日
パッチリリース
1.28.0,
1.28.1,
1.28.2,
1.28.3,
1.28.4,
1.28.5,
1.28.6,
1.28.7,
1.28.8,
1.28.9,
1.28.10,
1.28.11,
1.28.12
Complete 1.28
Schedule and
Changelog
リリース予定
Kubernetes1.31のリリーススケジュールをチェックしてみてください!
リソース
1 - バージョンスキューポリシー
さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンスキュー。
このドキュメントでは、さまざまなKubernetesコンポーネント間でサポートされる最大のバージョンの差異(バージョンスキュー)について説明します。特定のクラスターデプロイツールは、バージョンの差異に追加の制限を加える場合があります。
サポートされるバージョン
Kubernetesのバージョンはx.y.zの形式で表現され、xはメジャーバージョン、yはマイナーバージョン、zはパッチバージョンを指します。これはセマンティック バージョニングに従っています。詳細は、Kubernetesのリリースバージョニングを参照してください。
Kubernetesプロジェクトでは、最新の3つのマイナーリリースについてリリースブランチを管理しています (1.30, 1.29, 1.28)。
セキュリティフィックスを含む適用可能な修正は、重大度や実行可能性によってはこれら3つのリリースブランチにバックポートされることもあります。パッチリリースは、これらのブランチから 定期的に 切り出され、必要に応じて追加の緊急リリースも行われます。
リリースマネージャーグループがこれを決定しています。
詳細は、Kubernetesパッチリリースページを参照してください。
サポートされるバージョンの差異
kube-apiserver
高可用性 (HA) クラスターでは、最新および最古のkube-apiserver
インスタンスがそれぞれ1つのマイナーバージョン内でなければなりません。
例:
- 最新の
kube-apiserver
が1.30であるとします
- ほかの
kube-apiserver
インスタンスは1.30および1.29がサポートされます
kubelet
kubelet
はkube-apiserver
より新しいものであってはならず、2つの古いマイナーバージョンまで有効です。
例:
kube-apiserver
が1.30であるとします
kubelet
は1.30、1.29および1.28がサポートされます
備考:
HAクラスター内のkube-apiserver
間にバージョンの差異がある場合、有効なkubelet
のバージョンは少なくなります。
例:
kube-apiserver
インスタンスが1.30および1.12であるとします
kubelet
は1.29および1.28がサポートされます(1.30はバージョン1.29の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.30であるとします
kube-controller-manager
、kube-scheduler
およびcloud-controller-manager
は1.30および1.29がサポートされます
備考:
HAクラスター内のkube-apiserver
間にバージョンの差異があり、これらのコンポーネントがクラスター内のいずれかのkube-apiserver
と通信する場合(たとえばロードバランサーを経由して)、コンポーネントの有効なバージョンは少なくなります。
例:
kube-apiserver
インスタンスが1.30および1.29であるとします
- いずれかの
kube-apiserver
インスタンスへ配信するロードバランサーと通信するkube-controller-manager
、kube-scheduler
およびcloud-controller-manager
は1.29がサポートされます(1.30はバージョン1.29のkube-apiserver
よりも新しくなるためサポートされません)
kubectl
kubectl
はkube-apiserver
の1つ以内のバージョン(古い、または新しいもの)をサポートします。
例:
kube-apiserver
が1.30であるとします
kubectl
は1.31、1.30および1.29がサポートされます
備考:
HAクラスター内のkube-apiserver
間にバージョンの差異がある場合、有効なkubectl
バージョンは少なくなります。
例:
kube-apiserver
インスタンスが1.30および1.29であるとします
kubectl
は1.30および1.29がサポートされます(ほかのバージョンでは、あるkube-apiserver
コンポーネントからマイナーバージョンが2つ以上離れる可能性があります)
サポートされるコンポーネントのアップグレード順序
コンポーネント間でサポートされるバージョンの差異は、コンポーネントをアップグレードする順序に影響されます。このセクションでは、既存のクラスターをバージョン1.29から1.30 へ移行するために、コンポーネントをアップグレードする順序を説明します。
kube-apiserver
前提条件:
- シングルインスタンスのクラスターにおいて、既存の
kube-apiserver
インスタンスは1.29とします
- HAクラスターにおいて、既存の
kube-apiserver
は1.29または1.30 とします(最新と最古の間で、最大で1つのマイナーバージョンの差異となります)
- サーバーと通信する
kube-controller-manager
、kube-scheduler
およびcloud-controller-manager
はバージョン1.29とします(必ず既存のAPIサーバーのバージョンよりも新しいものでなく、かつ新しいAPIサーバーのバージョンの1つ以内のマイナーバージョンとなります)
- すべてのノードの
kubelet
インスタンスはバージョン1.29または1.28 とします(必ず既存のAPIサーバーよりも新しいバージョンでなく、かつ新しいAPIサーバーのバージョンの2つ以内のマイナーバージョンとなります)
- 登録されたAdmission webhookは、新しい
kube-apiserver
インスタンスが送信するこれらのデータを扱うことができます:
ValidatingWebhookConfiguration
およびMutatingWebhookConfiguration
オブジェクトは、1.30 で追加されたRESTリソースの新しいバージョンを含んで更新されます(または、v1.15から利用可能なmatchPolicy: Equivalent
オプションを使用してください)
- Webhookは送信されたRESTリソースの新しいバージョン、および1.30 のバージョンで追加された新しいフィールドを扱うことができます
kube-apiserver
を1.30 にアップグレードしてください。
備考:
非推奨APIおよび
APIの変更ガイドラインのプロジェクトポリシーにおいては、シングルインスタンスの場合でも
kube-apiserver
のアップグレードの際にマイナーバージョンをスキップしてはなりません。
kube-controller-manager、kube-scheduler、およびcloud-controller-manager
前提条件:
- これらのコンポーネントと通信する
kube-apiserver
インスタンスが1.30 であること(これらのコントロールプレーンコンポーネントが、クラスター内のkube-apiserver
インスタンスと通信できるHAクラスターでは、これらのコンポーネントをアップグレードする前にすべてのkube-apiserver
インスタンスをアップグレードしなければなりません)
kube-controller-manager
、kube-scheduler
およびcloud-controller-manager
を1.30 にアップグレードしてください。
kubelet
前提条件:
kubelet
と通信するkube-apiserver
が1.30 であること
必要に応じて、kubelet
インスタンスを1.30 にアップグレードしてください(1.29や1.28 のままにすることもできます)。
警告:
kube-apiserver
と2つのマイナーバージョンのkubelet
インスタンスを使用してクラスターを実行させることは推奨されません:
- コントロールプレーンをアップグレードする前に、インスタンスを
kube-apiserver
の1つのマイナーバージョン内にアップグレードさせる必要があります
- メンテナンスされている3つのマイナーリリースよりも古いバージョンの
kubelet
を実行する可能性が高まります
kube-proxy
kube-proxy
のマイナーバージョンはノード上のkubelet
と同じマイナーバージョンでなければなりません
kube-proxy
はkube-apiserver
よりも新しいものであってはなりません
kube-proxy
のマイナーバージョンはkube-apiserver
のマイナーバージョンよりも2つ以上古いものでなければなりません
例:
kube-proxy
のバージョンが1.28の場合:
kubelet
のバージョンは1.28でなければなりません
kube-apiserver
のバージョンは1.28と1.30の間でなければなりません
2 - ノート
Kubernetesのリリースノート
リリースノートは、使用しているKubernetesのバージョンに合ったChangelogを読むことで確認できます。
1.30のchangelogを見るにはGitHubを参照してください。
またリリースノートは、relnotes.k8s.io上で検索してフィルタリングすることもできます。
1.30のフィルタリングされたリリースノートを見るにはrelnotes.k8s.ioを参照してください。