Kubernetes 1.34の変更点とEOL｜EKS・GKE・AKSのサポート期限とDRA GA

Kubernetes 1.34は2025年8月27日にリリースされたマイナーバージョンで、コミュニティによるパッチ提供は2026年10月27日に終わります。Amazon EKSでは2025年10月2日から使えるようになり、標準サポートは2026年12月2日まで続きます。本記事は1.34に固有の変更点とサポート期限、EKSで1.34を運用・更新するときの注意点を扱います。現行の最新マイナーは1.37なので、最新版を探している場合はKubernetesの最新バージョンと各版のEOL一覧を、1.34の次の版はKubernetes 1.35の新機能と変更点を参照してください。

まとめ｜1.34のサポート期限と押さえるべき変更点

• コミュニティ版：2026年8月27日にメンテナンスモードへ入り、EOLは2026年10月27日。2026年9月28日時点の最新パッチはv1.34.12
• Amazon EKS：標準サポート終了は2026年12月2日、延長サポート終了は2027年12月2日。延長に入ると1クラスタあたり1時間0.10ドルが0.60ドルになる
• 目玉：Dynamic Resource Allocation（DRA）のコアAPIが resource.k8s.io/v1 でGA。58件の変更のうちStableは23件
• EKSでの落とし穴：コンテナ単位の再起動ルールなどアルファ機能はEKSでは使えない。ゲートが無効だとフィールドがエラーなしで消える
• 次の一手：1.34を使い続けられるのは長くても延長サポートの終わりまで。EKSは1マイナーずつしか上げられないため、1.35への更新を先に計画する

以下、期限の一覧、変更点、EKSでの更新手順の順に説明します。

1.34のサポート期限：コミュニティとEKS・GKE・AKS

「1.34をいつまで使えるか」は、どこで動かしているかで1年以上変わります。各社の公式表から1.34の行だけを抜き出しました（2026年9月28日確認。出典はKubernetesのリリース一覧、Amazon EKSのKubernetesリリースカレンダー、GKEのリリーススケジュール、AKSのサポート対象バージョン一覧）。

EKSの日付はリリースカレンダーの値で、AWSのWhat’s Newでの告知は2025年10月6日でした。GKEはチャネルごとに提供日が違い、Stableチャネルで使えるようになったのは2026年2月18日です。AKSの公式表は月単位でしか載せておらず、コミュニティサポートの終了は2026年11月です。

コミュニティ版1.34のパッチ履歴とメンテナンス対象

1.34系列のパッチは2025年9月9日の1.34.1から始まり、ほぼ毎月出ています。2026年2月26日の1.34.5はGoのCVE対応だけを取り込んだ臨時リリースでした。メンテナンスモードに入った2026年8月27日以降は、CVE番号の付いた脆弱性、依存関係（ベースイメージを含む）、中核コンポーネントの重大な不具合に限って修正版が出ます。EOLの10月27日を過ぎると、脆弱性が見つかっても1.34向けの修正は出ません。

EKS延長サポートのクラスタ料金と自動更新

EKSは各版を提供開始から14か月は標準サポート、その後12か月は延長サポートとして扱います。延長サポートは既定で有効で、料金は1クラスタあたり1時間0.10ドルから0.60ドルに上がります。1か月を730時間として換算すると、クラスタ料金は73ドルから438ドルです。EC2などのノード料金やストレージ料金は別途かかります。26か月を過ぎてもクラスタを上げなかった場合は、EKSがコントロールプレーンを自動で次の版へ上げます。ただしマネージドノードグループとセルフマネージドノードは古い版のまま残るので、ノードとの版差が一気に開きます。

1.34の変更の規模：58件と目玉のDRA GA

1.34（リリース名「Of Wind & Will (O’ WaW)」）には58件のエンハンスメントが入り、内訳はStable 23件、Beta 22件、Alpha 13件です。開発期間は2025年5月19日から8月27日までの15週間で、Kubernetes本体には106社・491人が貢献しました。全変更の一覧は、kubernetes/kubernetesリポジトリのCHANGELOG-1.34.mdに版ごとのリリースノートとしてまとまっています。

DRAのコアAPIがresource.k8s.io/v1でGA

DRAは、GPU・TPU・NICのような特殊なデバイスをPodへ割り当てる仕組みです。ドライバがノード上のデバイスをResourceSliceとして公開し、管理者がDeviceClassで選択条件を定義し、利用者がResourceClaim（またはResourceClaimTemplate）で必要なデバイスを要求します。1.34でこれらのAPIがStableになり、追加の設定なしで使えるようになりました。

ベータ版のマニフェストをそのまま持ち込むときは、書式の変更に注意が必要です。1.34のkube-apiserver（envtest同梱のv1.34.1）に対して、次のマニフェストを実際に適用し、APIによる受理と保存を確かめました。この検証はGPUの割り当てやPodの実行を確認するものではありません。

apiVersion: resource.k8s.io/v1
kind: DeviceClass
metadata:
  name: gpu.example.com
spec:
  selectors:
  - cel:
      expression: device.driver == "gpu.example.com"
---
apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: single-gpu
spec:
  spec:
    devices:
      requests:
      - name: gpu
        exactly:
          deviceClassName: gpu.example.com

この2つは作成に成功しました。一方、exactly を挟まずに deviceClassName を直接書く旧書式は、strict decoding error: unknown field "spec.spec.devices.requests[0].deviceClassName" で拒否されます。既定の設定で起動したkube-apiserverが resource.k8s.io 配下で提供したのは v1 だけでした。v1beta1 のマニフェストは「no matches for kind」になり、v1beta2 は --runtime-config で明示的に有効にしたときだけ現れました。ただし上流の既定の話で、EKSは既存のベータAPIを有効のまま残す方針なので、自分のクラスタでは kubectl api-versions で確かめてください。

APIがGAになっても、実際にデバイスを割り当てるにはベンダーのDRAドライバ（kubeletプラグイン）が必要です。GPUドライバがDRAに対応していなければ、1.34に上げただけではResourceClaimは満たされません。

Podレベルのリソース指定とイメージ取得認証のベータ昇格

1.34でベータに上がり、既定で有効になった機能のうち、運用に影響が大きいものは次の2つです。

• Podレベルのリソース指定（PodLevelResources）：複数コンテナのPodで、requestsとlimitsをPod全体の予算として書ける。1.34からHPAもこの指定を扱う
• イメージ取得用のServiceAccountトークン（KubeletServiceAccountTokenForCredentialProviders）：kubeletのクレデンシャルプロバイダが、ノードに置いた長期のSecretではなく、Pod単位の短命トークンでレジストリに認証する

このほかStableに上がったものには、JobのPod再作成タイミングを制御する .spec.podReplacementPolicy、ボリューム性能を後から変える VolumeAttributesClass（storage.k8s.io/v1）、ボリューム拡張に失敗したときの回復、Linuxノードのswap対応があります。

アルファ機能はEKSでは使えない：再起動ルールで実測

1.34で追加されたアルファ機能は、コンテナ単位の再起動ルール（ContainerRestartRules）、ファイルから環境変数を読む EnvFiles、mTLS用のPod証明書などです。アルファ機能はfeature gateが既定で無効で、EKSは公式FAQで「Alpha features aren’t supported」としています。つまりEKS 1.34では、これらを有効にする手段がありません。

厄介なのは、ゲートが無効でもエラーにならないことです。次のPodを、ゲートを有効にしたkube-apiserverと無効のkube-apiserverの両方に適用しました。

apiVersion: v1
kind: Pod
metadata:
  name: rr
spec:
  restartPolicy: Never
  containers:
  - name: trainer
    image: busybox:1.37
    command: ["sh", "-c", "exit 42"]
    restartPolicy: Never
    restartPolicyRules:
    - action: Restart
      exitCodes:
        operator: In
        values: [42]

どちらも pod/rr created と表示され、終了コードは0でした。ゲートを有効にした側では保存されたPodに restartPolicyRules が残りましたが、無効の側では restartPolicy も restartPolicyRules も空になっていました。適用が成功しても設定が効いているとは限らないので、kubectl get pod rr -o jsonpath='{.spec.containers[0].restartPolicyRules}' で保存後の値を確かめてください。この機能は1.35でベータになり既定で有効になったので、EKSで使いたい場合は1.35以降が前提です。

kubectl 1.34の変更：.kubercとKYAML出力

kubectlはkube-apiserverと前後1マイナーの差まで対応するため、kubectl 1.34はクラスタが1.33〜1.35なら使えます。以下はkubectl v1.34.12で確かめた結果です。

.kubercによる既定オプションとエイリアスの定義

.kuberc は、kubeconfigとは別にkubectlの好みの設定だけを置くファイルです。1.34でベータになって既定で有効になり、置き場所の既定は ~/.kube/kuberc です。クラスタの接続情報や認証情報は入らないので、チームで共有しやすくなります。

apiVersion: kubectl.config.k8s.io/v1beta1
kind: Preference
defaults:
- command: apply
  options:
  - name: server-side
    default: "true"
aliases:
- name: getn
  command: get
  prependArgs:
  - namespace

この設定で kubectl apply -f svc.yaml を実行すると、結果は service/web serverside-applied になり、フラグを付けなくてもServer-Side Applyで適用されました。kubectl getn は kubectl get namespace として動きます。CIなど設定を読ませたくない環境では、KUBECTL_KUBERC=false を設定すると無効になります。

KYAML出力の有効化と環境変数

KYAMLは、インデントや暗黙の型変換で起きる事故を避けるために作られたYAMLのサブセットです。1.34ではアルファなので、環境変数を付けずに -o kyaml を指定すると、unable to match a printer suitable for the output format "kyaml" で失敗します。

$ KUBECTL_KYAML=true kubectl create deployment web --image=nginx:1.29 \
    --dry-run=client -o kyaml
---
{
  kind: "Deployment",
  apiVersion: "apps/v1",
  metadata: {
    name: "web",
    labels: {
      app: "web",
    },
  },
  ...

文字列はすべて引用符で囲まれ、構造は括弧で表されます。KYAMLは有効なYAMLでもあるので、出力をどの版のkubectlにもそのまま入力できます。1.35でベータ（既定で有効）、1.37でStableになりました。

1.34で非推奨になった設定と今後の削除

1.34で決まった非推奨は、1.34自体では動作を変えません。影響が出るのは、この先の版へ上げるときです。

• kubeletの cgroupDriver 設定：CRIからcgroupドライバを自動検出する機能が1.34でGAになり、手動設定は非推奨になった。削除は1.36より前には行われない
• containerd 1.x：1.35系列が最後のサポートで、1.36.0で打ち切られる。kubelet_cri_losing_support メトリクスで該当ノードを見つけられる
• Serviceの trafficDistribution: PreferClose：同じ意味の PreferSameZone へ改名され、同一ノードを優先する PreferSameNode が追加された（どちらも1.34でベータ・既定で有効）

PreferClose は1.34のkube-apiserverでも警告なしで受け付けられたので、放置してもすぐには壊れません。新しく書くマニフェストから PreferSameZone に切り替えておけば、将来の削除時に慌てずに済みます。

EKS 1.34に固有の変更点

EKSのリリースノートには、上流の変更点とは別に次の注意点があります。

• containerdは提供開始時点から2.1。containerd 1.xの打ち切りは、EKS最適化AMIを使う限り1.34の時点で済んでいる
• EKS最適化Amazon Linux 2 AMIは1.34から提供されない。Amazon Linux 2023などへの移行が前提
• AWSの文書は1.34でAppArmorを非推奨としており、seccompやPod Security Standardsへの移行を勧めている
• VolumeAttributesClassのベータAPIを使うEBS CSIドライバの構成は、1.34でGA APIへの切り替えが必要。AWS管理のサイドカーがベータAPIを扱うのはEKS 1.33の標準サポート終了（2026年7月29日）まで

自前のAMIでノードを組んでいる場合は、containerdの版とAL2依存が最初に詰まる箇所です。EKSの提供形態ごとの違いはAmazon EKSの仕組みとノード提供形態、containerd自体の役割はcontainerdとKubernetesでの役割で整理しています。

EKSで1.34から1.35へ上げる手順と版差の制約

2026年9月時点で1.34を使っている場合、実際の作業は1.34から1.35への更新です。EKSのコントロールプレーンは1回に1マイナーずつしか上げられません。2026年9月28日時点でEKSが提供しているのは1.36までなので、1.34から1.36へは1.35を経由して2回更新します。1.37への更新はEKSでの提供開始後に計画してください。

# 1. 次の版で問題になる箇所を確認する
aws eks list-insights --region ap-northeast-1 --cluster-name my-cluster \
  --filter '{"categories":["UPGRADE_READINESS"]}'

# 2. コントロールプレーンを1.35へ上げる
aws eks update-cluster-version --name my-cluster \
  --kubernetes-version 1.35 --region ap-northeast-1

# 3. 手順2が返した update.id で完了を確認する（status が Successful になるまで待つ）
aws eks describe-update --name my-cluster --update-id UPDATE_ID \
  --region ap-northeast-1

# 4. Successful を確認してからマネージドノードグループを追従させる
aws eks update-nodegroup-version --cluster-name my-cluster \
  --nodegroup-name ng-1 --kubernetes-version 1.35 --region ap-northeast-1

Upgrade Insightsは24時間ごとに再評価されるため、修正後は手動更新と最終更新時刻を確認します。ただし非推奨APIの使用状況は過去30日間を対象に判定されるので、修正後もステータスの解消に最大30日かかる場合があります。更新にはクラスタ作成時に指定したサブネットで最大5個の空きIPアドレスが必要です。マネージドノードグループはコントロールプレーンと一緒には上がりませんが、EKS Auto Modeのノードは自動で更新される場合があります。

ノードの更新を後回しにできる幅は、版差ポリシーで決まっています。kubeletはkube-apiserverより新しくしてはならず、古い側は3マイナーまで許されます。コントロールプレーンが1.35ならノードは1.32まで動きますが、次に1.36へ上げる前にノードを1.33以上へ上げないとポリシーから外れます。EKSでは、インプレースで上げたクラスタを7日以内なら1つ前のマイナーへ戻せます。7日を過ぎると戻せず、旧版で新しいクラスタを作って移すしかありません。

よくある質問

EKS 1.34のサポートはいつ終わりますか？

標準サポートは2026年12月2日、延長サポートは2027年12月2日に終わります。延長サポート期間は1クラスタあたり1時間0.60ドルかかり、期限を過ぎるとコントロールプレーンが自動で次の版へ上がります。

Kubernetes 1.34のEOLはいつですか？

コミュニティ版のEOLは2026年10月27日です。2026年8月27日からメンテナンスモードに入っており、2026年9月28日時点の最新パッチはv1.34.12です。

Kubernetes 1.34は最新バージョンですか？

いいえ。1.34の後に1.35（2025年12月17日）、1.36、1.37が出ています。最新版と各版のサポート期限はKubernetesの最新バージョンの記事で更新しています。

AKSとGKEの1.34はいつまで使えますか？

GKEの公表スケジュールでは、標準サポート終了は2027年1月25日、Extendedチャネルに登録したクラスタの延長サポート終了は2027年11月25日です。AKSはコミュニティサポートが2026年11月まで、LTSを有効にした場合は2027年11月までです。別制度のプラットフォームサポートは1.38のGAまで続きます。

1.33から1.35へ一気に上げられますか？

EKSのコントロールプレーンは1マイナーずつしか上げられないため、1.34を経由する必要があります。上流のkubeadmもマイナー版を飛ばした更新をサポートしていません。

関連記事

• Kubernetesの最新バージョンは1.37｜確認方法・EOL一覧とアップグレード手順
• Kubernetes 1.35の新機能と変更点｜リリース内容とサポート終了日
• Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説
• Google Kubernetes Engine（GKE）とは？Autopilot／Standardの違い・料金モデルとEKSとの使い分けを解説
• containerdとは？Dockerとの関係・runc/CRIの仕組みとKubernetesでの役割を解説