---
title: "Kubernetes 1.34の変更点とEOL｜EKS・GKE・AKSのサポート期限とDRA GA"
url: "https://www.issoh.co.jp/tech/details/8967/"
published: 2025-09-24
updated: 2026-10-12
categories: ["Kubernetes・コンテナ"]
publisher: "株式会社一創"
---

# 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一覧](/tech/details/17151/)を、1.34の次の版は[Kubernetes 1.35の新機能と変更点](/tech/details/10465/)を参照してください。

## まとめ｜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のサポート対象バージョン一覧）。

| 提供元                | 1.34の提供開始         | 標準サポート終了   | 延長サポート終了         |
| ------------------ | ----------------- | ---------- | ---------------- |
| Kubernetes（コミュニティ） | 2025-08-27        | 2026-10-27 | なし               |
| Amazon EKS         | 2025-10-02        | 2026-12-02 | 2027-12-02       |
| GKE                | 2025-09-02（Rapid） | 2027-01-25 | 2027-11-25       |
| AKS                | 2025年11月（GA）      | 2026年11月   | 2027年11月（LTS有効時） |

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の仕組みとノード提供形態](/tech/details/15437/)、containerd自体の役割は[containerdとKubernetesでの役割](/tech/details/15681/)で整理しています。

## 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](/tech/details/4524/)のノードは自動で更新される場合があります。

ノードの更新を後回しにできる幅は、版差ポリシーで決まっています。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の最新バージョンの記事](/tech/details/17151/)で更新しています。

### 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一覧とアップグレード手順](/tech/details/17151/)
- [Kubernetes 1.35の新機能と変更点｜リリース内容とサポート終了日](/tech/details/10465/)
- [Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説](/tech/details/15437/)
- [Google Kubernetes Engine（GKE）とは？Autopilot／Standardの違い・料金モデルとEKSとの使い分けを解説](/tech/details/15661/)
- [containerdとは？Dockerとの関係・runc/CRIの仕組みとKubernetesでの役割を解説](/tech/details/15681/)

---

出典: [Kubernetes 1.34の変更点とEOL｜EKS・GKE・AKSのサポート期限とDRA GA](<https://www.issoh.co.jp/tech/details/8967/>)（株式会社一創）