Kubernetesはおよそ4か月ごとに新しいマイナーバージョンが出るため、「いま使っている版はまだサポートされているのか」「最新はいくつなのか」を定期的に確かめる必要があります。この記事では、最新バージョンと各版のサポート終了日、手元のクラスタの版を確認するコマンド、そして最新版へ上げる前に必ず読むべき破壊的変更までを1ページにまとめます。版が上がるたびに更新しています。
まとめ｜最新バージョンと確認・更新の要点
結論だけ先に示します。2026年8月30日時点で、Kubernetesの最新マイナーバージョンは1.37です。1.37.0は2026年8月26日にリリースされました。パッチを含めた最新は1.37.0で、ひとつ前の系列は1.36.4です。
サポートされているのは直近3マイナーの1.37・1.36・1.35のみで、1.34は2026年10月27日にサポートが終了します。手元の版は kubectl version で確認できます。1.37へ上げる場合、SELinuxを有効にしたクラスタでは既存ワークロードが動かなくなる可能性があるため、後述の破壊的変更を先に読んでください。以下でそれぞれ詳しく説明します。
Kubernetesの最新バージョンは1.37（2026年8月時点）
Kubernetesのバージョンは「1.37.0」のように、メジャー・マイナー・パッチの3つの数字で表されます。新機能が入るのはマイナー版が上がるときで、これがおよそ4か月ごとです。パッチ版はバグ修正とセキュリティ修正のみで、同じマイナー系列の中で毎月のように更新されます。
マイナー版とパッチ版で「最新」の意味が変わります
「最新バージョン」という言葉は、新機能を含むマイナー版を指す場合と、いま入れるべきパッチ版を指す場合があります。新機能を追う目的ならマイナー版の1.37を見ますが、運用中のクラスタで適用すべきなのは、使っている系列の最新パッチです。1.36系を使い続けるなら1.36.4が適用対象になり、1.37へ上げる必要はありません。
公式サイトの掲載パッチは実際のリリースより遅れることがあります
注意したい点として、Kubernetes公式サイトのリリース一覧ページに載っているパッチ番号は、実際に公開されているものより古い場合があります。2026年8月30日に確認したところ、公式サイトの表記は1.36.2・1.35.6・1.34.9でしたが、GitHubのリリース情報では1.36.4・1.35.8・1.34.11がいずれも2026年8月20日に公開済みでした。適用すべきパッチを調べるときは、GitHubのリリース一覧を一次情報として確認するほうが確実です。
サポート対象バージョンとEOL一覧
Kubernetesプロジェクトが保守しているのは直近3マイナーのリリースブランチのみです。1.19以降の版は、おおむね1年間のパッチサポートを受けられます。各版のサポート終了日は次のとおりです。
| マイナー版 | 状態 | サポート終了日 |
|---|---|---|
| 1.37 | サポート対象（最新） | 2027-10-28 |
| 1.36 | サポート対象 | 2027-06-28 |
| 1.35 | サポート対象 | 2027-02-28 |
| 1.34 | まもなく終了 | 2026-10-27 |
| 1.33 | 終了済み | 2026-06-28 |
| 1.32 | 終了済み | 2026-02-28 |
1.34を使っている場合、残り期間は2か月を切っています。サポートが切れた版にはセキュリティ修正が提供されないため、1.35以降への計画的な移行が必要です。各版の個別の変更内容は、Kubernetes 1.35の新機能と変更点｜リリース内容とサポート終了日とKubernetes 1.34の新機能・変更点とEOL｜DRA GA・再起動ルール・EKS対応を解説で個別に解説しています。
使用中のバージョンを確認する方法
クラスタの版は、クライアント側とサーバー側で別々に管理されています。両方を確認しておくと、アップグレード時の食い違いを避けられます。
クラスタ全体の版を確認する
kubectl versionこのコマンドは、手元のkubectlの版（Client Version）と、接続先クラスタのAPIサーバーの版（Server Version）を両方表示します。「最新バージョンはいくつか」を調べる目的で使うのは、このServer Versionのほうです。
ノードごとのkubelet版を確認する
kubectl get nodes -o wideノードを1台ずつアップグレードしていく途中では、ノードによってkubeletの版が異なる状態になります。このコマンドの VERSION 列で各ノードの版が分かるため、アップグレードの進捗確認にも使えます。
1.37へ上げる前に確認すべき破壊的変更
1.37のリリースノートには、アップグレード前の対応が必須と明記された項目が複数あります。特に次の3点は、該当する環境ではそのまま上げると障害につながります。1.37で増えた機能の中身と、kindの検証クラスタで試す手順はKubernetes 1.37の新機能｜注目機能の要点とkindで試す機能ゲート設定で解説しています。
SELinuxMountがGAになり既定で有効になりました
SELinuxのボリュームラベル付けを制御する SELinuxMount という機能が正式版に昇格し、1.37では既定で有効になりました。公式のリリースノートは、SELinuxを有効にしているクラスタでは既存のワークロードが壊れる可能性があると明記しています。1.36の段階で影響を受けるワークロードを洗い出し、修正するか機能を無効化してから上げる必要があります。SELinuxを使っていないクラスタは、この項目を無視して構いません。
scheduling.k8s.io の v1alpha2 が削除されました
スケジューリング関連のAPIグループが v1alpha2 から v1alpha3 に上がり、v1alpha2 は完全に削除されました。リリースノートは、クラスタを更新する前に v1alpha2 のオブジェクトをすべてAPIサーバーから削除するよう求めています。削除せずに上げると、残ったオブジェクトを読めなくなります。
kubeletのeventRecordQPSで0の意味が変わりました
kubeletの設定項目 eventRecordQPS について、値0の扱いが「無制限（レート制限なし）」に変更されました。これはドキュメントの記述に挙動を合わせる修正ですが、従来の既定の挙動に依存していた場合は意味が変わります。従来どおりの制限をかけたいのであれば、0以外の値を明示的に設定してください。リリースノートは例として50を挙げています。
このほか、kubeletが起動時に実効設定をログへ出力するようになりました。設定内容がログに現れるため、nodes/logs の参照権限を信頼できる利用者に限定するよう注意喚起されています。
kube-proxyはnftablesへの移行が進んでいます
直近3世代をまたいで進んでいる変更として、kube-proxyの動作モードの移行があります。nftablesモードは1.33で正式版になり、ipvsモードは1.35で非推奨になりました。1.37ではkubeadmが、モードが明示されていない場合に警告を出すようになっています。
1.37時点の既定は依然としてiptablesですが、これは将来nftablesを既定にするための準備段階と説明されています。新しいLinuxカーネルを使っているならnftablesモードへ、古いカーネルではiptablesのままにするのが公式の案内です。設定を明示していないクラスタは、警告が出る前にモードを書いておくと移行時に慌てずに済みます。
アップグレードの進め方
マイナー版は1つずつ上げるのが原則です。1.35から1.37へ2段飛ばしで上げることはできず、1.36を経由します。kubeadmで構築したクラスタであれば、適用可能な版と手順は次のコマンドで確認できます。
kubeadm upgrade plan実際の作業はコントロールプレーンから先に上げ、その後ワーカーノードを1台ずつ入れ替えていきます。ノードを入れ替える間はPodが再配置されるため、Liveness Probeとは？Kubernetesの設定方法とReadiness・Startupとの違いで解説しているヘルスチェックの設定が適切かどうかを、事前に見直しておくと安全です。
よくある質問
Kubernetesの最新バージョンはいくつですか？
2026年8月30日時点で最新のマイナーバージョンは1.37で、1.37.0が2026年8月26日にリリースされています。ひとつ前の1.36系の最新パッチは1.36.4です。
サポートされているバージョンはどれですか？
直近3マイナーの1.37・1.36・1.35です。1.34は2026年10月27日でサポートが終了します。1.33以前はすでに終了しており、セキュリティ修正は提供されません。
自分のクラスタのバージョンを調べるには？
kubectl version でクライアントとサーバー双方の版が表示されます。ノードごとのkubelet版を見たい場合は kubectl get nodes -o wide を使います。
マイナー版を2つ飛ばしてアップグレードできますか？
できません。1つずつ順に上げる必要があります。1.35から1.37へ上げる場合は、いったん1.36を経由します。
1.37で特に注意すべき変更はありますか？
SELinuxを有効にしているクラスタでは、SELinuxMountが既定で有効になったことで既存ワークロードが動かなくなる可能性があります。また scheduling.k8s.io の v1alpha2 が削除されたため、該当するオブジェクトはアップグレード前に削除しておく必要があります。
