InfraAcademy Blog

EKSの料金が6倍になる前に。Kubernetes 1.34のサポート終了と、年3回のバージョンアップの回し方

公開日: 2026-10-08 更新日: 2026-10-08 著者: ryu | #kubernetes #コンテナ #サポート終了

Linuxをブラウザで試してみる

Linux・ネットワーク・AWSを、環境構築なしで実践学習できます

こんにちは、インフラエンジニアのryuです。

いま動かしているKubernetesクラスタのバージョンを、すぐに答えられるでしょうか？

Kubernetes 1.34は、コミュニティによるサポートが2026年10月27日に終わります。2025年8月に出たバージョンなので、構築したのはつい最近という感覚の方も多いと思います。

Kubernetesは、OSのように5年や10年使い続けるものではありません。新しいバージョンが年に3回出て、それぞれ1年ちょっとでサポートが切れます。

マネージドサービスを使っていれば延長サポートで時間を稼げますが、Amazon EKSの場合はコントロールプレーンの料金が1時間あたり0.10ドルから0.60ドルに上がります。6倍です。

この記事では、Kubernetesのバージョンの寿命の仕組みと、EKS・AKS・GKEでの扱いの違い、バージョンアップを毎年の作業として回すための準備を整理します。

Kubernetesそのものの基本は『kubernetesとは?オーケストレーションツールの概要を１から解説』で書いているので、あわせて読んでみてください。

Kubernetesのバージョンはどれくらいで切れるのか？¶

まず、Kubernetesのバージョンの出方とサポート期間を確認しておきます。

Kubernetesのバージョンは 1.34.2 のように3つの数字で表します。真ん中の 34 がマイナーバージョン、最後の 2 がパッチバージョンです。

新機能が入るのはマイナーバージョンが上がるときで、パッチバージョンはセキュリティ修正や不具合修正だけです。

約4か月ごとに新しいマイナーバージョンが出る¶

Kubernetesの開発コミュニティは、おおむね4か月に1回のペースでマイナーバージョンを出しています。年に3回です。

直近の流れを並べると、次のようになります。

バージョン	リリース	状態（2026年10月時点）
1.34	2025年8月	2026年10月27日にサポート終了
1.35	2025年12月	サポート中（2026年12月にメンテナンスモード）
1.36	2026年4月	サポート中
1.37	2026年8月26日	サポート中（最新）

各マイナーバージョンには、およそ14か月のあいだパッチが出ます。最初の12か月が通常のサポートで、残りの2か月はメンテナンスモードとして重大なセキュリティ修正などに絞られます。

コミュニティがパッチを出すのは、常に直近の3つのマイナーバージョンだけです。4つ前のバージョンになった時点で、修正は出なくなると考えておくとよいです。

つまり、1年に1回もバージョンアップしないクラスタは、ほぼ確実にサポート切れのバージョンで動くことになります。

サポートが切れると何が困るのか¶

サポートが切れても、クラスタがその日に止まるわけではありません。動き続けます。

困るのは、脆弱性が見つかっても修正版が出なくなることです。コンテナランタイムやkubeletの脆弱性は、ノードを乗っ取られる被害につながることもあります。

もう1つは、バージョンアップの作業が重くなることです。後で説明しますが、Kubernetesはマイナーバージョンを飛ばして上げられないので、放置した分だけ作業の回数が増えます。

EKS・AKS・GKEではどう扱われるのか？¶

マネージドKubernetesを使っている場合は、コミュニティのサポート期間とは別に、クラウド事業者ごとのサポート期間があります。

ここが分かりにくいところなので、3つのサービスを並べてみます。

サービス	通常のサポート	延長の仕組み	延長したときの費用
Amazon EKS	リリースから14か月	延長サポートで12か月追加	コントロールプレーンが0.10ドル→0.60ドル／時間
Azure AKS	GAから約1年	Premiumティアの長期サポート（LTS）で合計約2年	Premiumティアの料金
Google GKE	リリースチャネルごとに決まる	Extendedチャネルで期間を延ばせる	延長期間は追加料金

どのサービスも、通常のサポートが終わったあとに延長の選択肢を用意しています。ただし、どれも追加の料金がかかります。

EKSは何もしないと延長サポートに入る¶

Amazon EKSでは、Kubernetesのバージョンごとに14か月の標準サポートがあり、その後12か月の延長サポートに移ります。

標準サポートの間はクラスタ1つあたり1時間0.10ドルですが、延長サポートに入ると1時間0.60ドルになります。

1か月を730時間として計算すると、次のくらいの差になります。

状態	1時間あたり	1か月あたり（730時間）
標準サポート	0.10ドル	73ドル
延長サポート	0.60ドル	438ドル

クラスタ1つで月に365ドルほどの差です。本番・検証・開発と環境ごとにクラスタを分けていれば、その分だけ増えます。

EKSでは、クラスタごとにアップグレードポリシーを設定できます。延長サポートに入るのを許可しない設定にすると、標準サポートが終わった時点で自動的にバージョンアップされます。

延長サポートは便利ですが、費用をかけて時間を買っているだけという点は覚えておきたいところです。延長サポートの期間も終われば、最終的には自動でバージョンアップされます。

AKSとGKEの延長サポート¶

AKSでは、通常はGAから約1年のサポートです。クラスタをPremiumティアにして長期サポート（LTS）を選ぶと、さらに1年延びて合計で約2年になります。

GKEでは、クラスタをリリースチャネルに登録して運用するのが基本です。Extendedチャネルを選ぶと、通常より長くマイナーバージョンを使い続けられますが、延長期間には追加の料金がかかります。

どのサービスでも、延長サポートを前提に計画を立てるのはおすすめしません。延長の期限が近づいてから慌てて2つ、3つとまとめて上げることになりやすいからです。

マイナーバージョンは1つずつしか上げられない¶

Kubernetesのバージョンアップで、最初に知っておきたいルールがあります。

マイナーバージョンは1つずつしか上げられません。 1.34 から 1.36 に直接上げることはできず、1.35 を経由する必要があります。

kubeadmで構築したクラスタの公式手順にも、マイナーバージョンを飛ばすアップグレードはサポートしないと書かれています。EKSなどのマネージドサービスでも、コントロールプレーンは1つずつ上げる仕組みです。

コントロールプレーンとノードの順番¶

Kubernetesには、コンポーネント同士のバージョンの差（スキュー）をどこまで許すかという決まりがあります。

ノードで動くkubeletは、APIサーバーより新しくなってはいけません。古い側には3つ前のマイナーバージョンまで許されています。

そのため、バージョンアップは次の順番で進めます。

1. コントロールプレーン（APIサーバーなど）を 1.34 → 1.35 に上げる
2. ノード（kubelet）を 1.34 → 1.35 に上げる
   └ ノードはPodを退避（drain）させてから入れ替える
3. アドオン（CNI、CoreDNS、kube-proxyなど）を1.35に合うバージョンへ
4. 動作確認をして、次の 1.35 → 1.36 へ

マネージドサービスでは、1のコントロールプレーンはボタン1つやコマンド1つで上がります。手間がかかるのは2と3です。

ノードのOSイメージやアドオンのバージョンも、Kubernetesのバージョンに合わせて変える必要があります。cgroup v1のノードで新しいkubeletが起動しなくなった話は『cgroup v1の終わりとv2への移行』でまとめています。

自分のクラスタのバージョンを確かめる¶

まずは、いま動いているバージョンを確認しておきましょう。kubectlで次のように確かめられます。

# クライアントとAPIサーバーのバージョン
kubectl version

# 各ノードのkubeletのバージョン（VERSION列）
kubectl get nodes -o wide

EKSの場合は、AWS CLIからもクラスタのバージョンを確認できます。

aws eks describe-cluster --name my-cluster \
  --query 'cluster.version' --output text

コントロールプレーンだけ上げてノードが古いまま、という状態はよく起きます。kubectl get nodes の結果で、ノードのバージョンがそろっているかも見ておくとよいです。

バージョンアップの前に確認しておくこと¶

ここからは、実際にバージョンアップを進める前に確認しておきたいことを整理します。

廃止されるAPIを使っていないか¶

Kubernetesのバージョンアップでいちばん多いトラブルは、古いAPIバージョンの廃止です。

マニフェストに書いた apiVersion が新しいバージョンで削除されていると、そのリソースは作成も更新もできなくなります。Helmチャートや、何年も前に書かれたマニフェストで起きやすいです。

確かめ方はいくつかあります。

方法	分かること
kubectlの警告メッセージ	非推奨のAPIを使って適用したときに `Warning:` が表示される
APIサーバーのメトリクス	非推奨のAPIへのリクエストがあったかを記録している
公式の非推奨API移行ガイド	どのバージョンでどのAPIが削除されるかの一覧
マネージドサービスの診断機能	EKSのアップグレードインサイトなど、事前チェックの結果

マニフェストをGitで管理していれば、apiVersion の行を検索するだけでもかなり洗い出せます。GitOpsの考え方は『2026年のGitOpsとArgo CD／Flux』で紹介しています。

アドオンと周辺ツールの対応状況¶

Kubernetes本体だけでなく、クラスタに入れているアドオンや周辺ツールも対応しているか確認が必要です。

たとえば、ネットワークを担うCNIプラグイン、Ingressコントローラー、監視エージェント、オートスケーラーなどです。それぞれに、対応するKubernetesのバージョンが決まっています。

Ingressコントローラーについては、ingress-nginxの開発終了という大きな変化もありました。詳しくは『Kubernetesの入口はGateway APIへどう移る？』で書いています。

本体のバージョンアップは数十分で終わっても、アドオンの確認に何日もかかることがあります。アドオンの一覧と、それぞれの対応バージョンを表にしておくと、次回以降の作業が楽になります。

検証用のクラスタで先に上げる¶

本番のクラスタをいきなり上げるのは避けたいところです。

検証用のクラスタを本番と同じバージョンで用意しておき、先にそちらで上げてアプリケーションの動作を確認します。問題がなければ、同じ手順で本番を上げます。

ノードを入れ替えるときには、Podが退避されて別のノードで起動し直します。PodDisruptionBudgetを設定しておくと、同時に止まるPodの数を制限できます。

年3回のバージョンアップを、毎年の作業にする¶

ここまで見てきたように、Kubernetesのバージョンアップは一度きりの作業ではありません。年に3回、新しいバージョンが出続けます。

すべてのバージョンに追いつく必要はありませんが、少なくとも年に1回は上げないと、サポート切れか延長サポートの料金のどちらかになります。

おすすめなのは、あらかじめ予定を決めておくやり方です。

時期の目安	やること
新バージョンのリリース直後	リリースノートで削除されるAPIや大きな変更を確認する
リリースから2〜3か月後	マネージドサービスで使えるようになったら検証クラスタで試す
標準サポート終了の3か月前	本番のバージョンアップを終える目標日