Amazon EKS と Amazon EKS Distro が Kubernetes 1.36 に対応

はじめに

2026 年 6 月 2 日、AWS は Amazon EKS および Amazon EKS Distro が Kubernetes 1.36 に対応したことを発表しました。今回のリリースには多くの改善が含まれていますが、中でも、長年開発が続けられてきた 2 つの機能がついに GA（一般提供）へ到達したことが大きなトピックです。

コンテナ内で root として振る舞っているプロセスは、実はホスト上でも本物の root として扱われています。そんな状況に漠然とした不安を感じたことはないでしょうか。あるいは、Admission Webhook の証明書管理や可用性確保に運用負荷を感じている方もいるかもしれません。今回 GA となった 2 つの機能は、まさにこうした課題に応えるものです。

本記事では「何が変わったのか」「どう設定して使うのか」「どんな場面で活用できるのか」を中心に、この 2 機能を掘り下げて解説します。それ以外のアップデートについても概要を紹介しますので、EKS のバージョンアップグレードを検討しているエンジニアの方はぜひ参考にしてください。

---

何が変わったのか

前章で触れた 2 つの課題に対応する機能を含め、Kubernetes 1.36 で EKS が対応した主な変更点を整理すると、次の 4 つです。

機能	成熟度	概要
User Namespaces	GA	コンテナの root ユーザーをホスト上の非特権ユーザーにマッピングし、コンテナブレイクアウト時にもホストへの権限昇格を防ぐ
Mutating Admission Policies	GA	Webhook インフラを使わずに、CEL（Common Expression Language）でリソースのミューテーションを API サーバー内で完結させる
In-Place Pod-Level Resources Vertical Scaling	Beta	Pod 単位で集約された CPU・メモリのリソース予算（spec.resources）を、再起動なしにリサイズできる
Resource Health Status	Beta	デバイスのヘルス状態を Pod ステータスに反映し、ハードウェア起因のクラッシュループを切り分けやすくする

このうち User Namespaces と Mutating Admission Policies は、いずれも Alpha・Beta の段階を経て 1.36 で GA に到達した機能です。前者はコンテナのセキュリティ境界、後者は Admission 制御のアーキテクチャに関わる変更で、影響範囲が広いため、次章以降ではこの 2 つを中心に、仕組みと設定方法を掘り下げて解説します。

残り 2 つの Beta 機能、In-Place Pod-Level Resources Vertical Scaling と Resource Health Status については、記事の後半で概要とユースケースを簡単に紹介します。

---

User Namespaces がGA

仕組み

User Namespaces は、Linux カーネルの user namespace 機能を使って、コンテナ内のプロセスが認識する UID/GID と、ホスト上で実際に使われる UID/GID を分離する仕組みです。2022 年の Alpha 導入、2024 年の Beta 化、2025 年のデフォルト有効化を経て、1.36 でようやく GA (Stable) に到達しました。数年単位で開発が積み重ねられてきた機能です。

	1.35 まで	1.36 (Stable)
コンテナ内の root (UID 0)	ホスト上でも UID 0 (root) として実行される	ホスト上の非特権 UID にマッピングされる
コンテナブレイクアウト時の影響	ホストに対して root 権限を持つ可能性がある	ホストに対する特権昇格は発生しない

設定は Pod の spec.hostUsers フィールドで行います。hostUsers: false を指定すると、その Pod 専用の user namespace が作成され、コンテナ内の UID/GID はホスト上の非特権 UID/GID 範囲にマッピングされます。マッピングの管理は kubelet とコンテナランタイムが自動で行うため、利用者が UID の範囲を意識する必要はありません。

Kubernetes 公式ブログでは、hostUsers: false を指定した場合でも CAP_NET_ADMIN のようなケーパビリティはコンテナ内のリソースに対してのみ有効になり、ホストには影響しないと説明されています。

設定方法

Pod manifest の例です。

apiVersion: v1
kind: Pod
metadata:
  name: userns-demo
spec:
  hostUsers: false
  containers:
    - name: app
      image: public.ecr.aws/amazonlinux/amazonlinux:2023
      command: ["sleep", "3600"]

動作確認は、コンテナ内とノード側の両方で UID を見比べると分かりやすいです。

# コンテナ内で確認すると UID 0 (root) に見える
kubectl exec -it userns-demo -- id

# ノード側で実プロセスの UID を確認すると、非特権 UID にマッピングされている
kubectl debug node/<NODE_NAME> -it --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- chroot /host ps -eo pid,uid,user,comm | grep sleep

コンテナ内では uid=0(root) と表示される一方、ノード側で同じプロセスを確認すると非特権 UID として実行されていることが確認できます。

前提条件

User Namespaces は 1.36 で GA (デフォルト有効) に到達した機能のため、EKS 側で追加の feature gate 設定をする必要はなく、Pod manifest に hostUsers: false を指定するだけで利用できます。

一方で、ノード側にはいくつか前提があります。コンテナランタイムは containerd 2.0 以降が必要です (1.36 へのアップグレード自体が containerd 2.0 以降を前提としているため、1.36 クラスターであれば基本的に満たされます)。Kubernetes 1.36 用の EKS 最適化 AL2023 AMI では、Linux カーネル 6.18・containerd 2.2.3・runc 1.3.4 が採用されており (amazon-eks-ami のリリース情報 より)、User Namespaces の動作要件は十分に満たされています。EKS 最適化 AMI をそのまま利用していれば、追加のカーネルアップグレード等の作業は基本的に不要です。なお User Namespaces は Linux 専用の機能で、Windows ノードでは利用できません。

活用シーン

User Namespaces が特に効果を発揮するのは、複数のテナントのワークロードを同一クラスターで動かすマルチテナント SaaS や、金融・医療・政府系などコンプライアンス要件が厳しい環境です。コンテナエスケープが発生しても、ホストノードや他テナントへの影響を遮断できるため、ゼロトラストに近いセキュリティモデルを実現しやすくなります。

また、「特権付きだがホストには影響しない」という性質は、ネットワーク診断ツールのように CAP_NET_ADMIN を必要とするものの、ホストの権限までは渡したくないワークロードにも新しい選択肢になります。

セキュリティ強化という観点では、コンテナエスケープが発生した際のインシデント対応コストを抑えられる点も、運用チームにとって見逃せないメリットです。

---

Mutating Admission Policies がGA

仕組み

Mutating Admission Policy は、Pod などのリソースが作成・更新される際に、CEL (Common Expression Language) で記述したルールに従ってリソースの内容を自動的に変更する仕組みです。2024 年に Alpha として導入された後、2025 年に Beta へ移行し、1.36 で GA (v1) に到達、デフォルトで有効化されました。

これまで同様のミューテーションを実現するには、Mutating Admission Webhook という仕組みを使い、kube-apiserver から外部の Webhook サーバーを HTTPS で呼び出す必要がありました。Mutating Admission Policy は、この処理を kube-apiserver の内部で完結させます。

	Before (Webhook)	After (Mutating Admission Policy, GA)
ミューテーションの記述方法	Webhook サーバーのコード (任意言語)	CEL 式 (YAML で宣言的に記述)
実行場所	外部の Webhook サーバー (ネットワークホップが発生)	kube-apiserver の内部
必要なインフラ	Webhook サーバーの構築・TLS 証明書の発行・更新・可用性管理	不要
障害時の影響	Webhook サーバー停止時、failurePolicy の設定によってはリクエストが失敗する	kube-apiserver 自体の可用性に依存

Before: Admission Webhook

After: Mutating Admission Policy (GA)

設定方法

「production という namespace の Pod に、team: platform というラベルを自動で付与する」例を見てみます。ポリシー本体 (MutatingAdmissionPolicy) と、それを適用範囲に結び付けるバインディング (MutatingAdmissionPolicyBinding) の 2 つのオブジェクトで構成します。

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
  name: add-team-label
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE"]
        resources: ["pods"]
  reinvocationPolicy: IfNeeded
  mutations:
    - patchType: "ApplyConfiguration"
      applyConfiguration:
        expression: >
          Object{
            metadata: Object.metadata{
              labels: Object.metadata.labels{
                "team": "platform"
              }
            }
          }
---
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicyBinding
metadata:
  name: add-team-label-binding
spec:
  policyName: add-team-label
  matchResources:
    namespaceSelector:
      matchLabels:
        environment: production

applyConfiguration.expression の CEL 式は、Object{...} という専用の型を使って「適用したい差分」を組み立てます。ここでは metadata.labels に team: platform を追加する内容です。

動作確認は、対象 namespace に Pod を作成し、ラベルが自動付与されているかを見ます。

kubectl label namespace production environment=production
kubectl run nginx --image=nginx -n production
kubectl get pod nginx -n production --show-labels

team=platform のラベルが Webhook サーバーを経由せずに付与されていれば、ポリシーが意図通り動作しています。

前提条件

Mutating Admission Policy は 1.36 で GA (v1) に到達し、デフォルトで有効化された機能のため、EKS 側で追加の feature gate 設定をする必要はありません。admissionregistration.k8s.io/v1 の MutatingAdmissionPolicy / MutatingAdmissionPolicyBinding を作成するだけで利用できます。

1 点注意が必要なのは、ApplyConfiguration によるミューテーションは、atomic な構造体・マップ・配列を変更できないという制約です。こうしたフィールドを変更したい場合は patchType: JSONPatch を使う必要があります。

活用シーン

Mutating Admission Policy は、プラットフォームエンジニアリングの文脈で活躍します。全 Pod への共通ラベル付与、リソースリミットのデフォルト適用、特定 namespace への sidecar コンテナの自動挿入などを、Webhook サーバーを構築せずに実現でき、GitOps パイプラインとの統合もシンプルになります。

なお、同様のミューテーションは OPA Gatekeeper や Kyverno といった既存のポリシーツールでも実現できます。これらは内部的に Mutating Admission Webhook を使って動作しているため、Mutating Admission Policy の GA 化によって「既存ツールを置き換えるのか、併用するのか」という選択肢が生まれます。実際 Kyverno は、Mutating Admission Policy を拡張した MutatingPolicy という型を提供しており、既存のポリシー基盤を活かしながら段階的に移行する道も用意されています。

Webhook サーバーの構築・運用には、TLS 証明書の発行・更新、可用性確保のための冗長化、デプロイパイプラインの整備など、見えにくいコストが発生します。Mutating Admission Policy への移行は、こうした運用コストを直接的に削減できる施策として、コスト最適化の観点からも説明しやすい変更です。

---

その他の更新内容

ここでは、1.36 で Beta に到達した残り 2 つの機能を、概要とユースケースに絞って紹介します。

In-Place Pod-Level Resources Vertical Scaling (Beta)

1.34 で Beta となった「Pod-level Resources」は、複数コンテナで CPU・メモリを共有プールとして扱える spec.resources フィールドを Pod に追加しました。1.36 では、この Pod レベルのリソース予算を、再起動なしにその場でリサイズできるようになりました (InPlacePodLevelResourcesVerticalScaling、デフォルト有効)。

apiVersion: v1
kind: Pod
metadata:
  name: shared-pool-demo
spec:
  resources:
    requests:
      cpu: "1"
      memory: "1Gi"
    limits:
      cpu: "2"
      memory: "2Gi"
  containers:
    - name: app
      image: nginx
    - name: sidecar
      image: envoy

kubectl patch pod shared-pool-demo --subresource resize --patch '{"spec":{"resources":{"limits":{"cpu":"4"}}}}' のように resize サブリソースを使うと、この Pod 全体の CPU 上限をその場で変更できます。トラフィックスパイク時に、アプリケーションコンテナとサイドカーが共有する CPU・メモリ予算をまとめて拡張したい、というケースに向いています。

Resource Health Status (Beta)

GPU や専用デバイスを使うワークロードでは、Pod がクラッシュループしたとき、その原因がアプリケーションのバグなのか、デバイス側の異常なのかを切り分けるのに時間がかかることがあります。Resource Health Status (KEP-4680) は、Device Plugins や DRA (Dynamic Resource Allocation) で割り当てられたデバイスのヘルス状態 (Healthy / Unhealthy / Unknown) を Pod のステータスに反映する機能です。

クラッシュループが発生した際に、まず Pod ステータス上のデバイスヘルスを確認することで、「ハードウェア起因のクラッシュループ」と「アプリケーション起因のクラッシュループ」を即座に区別できるようになり、ML 推論や GPU バッチ処理のオンコール対応を効率化します。

---

アップグレードの進め方

cluster insights で事前にチェックする

Kubernetes バージョンのアップグレードは、コントロールプレーンのバージョンを上げるだけの作業に見えますが、実際には既存のマニフェストや API の互換性、廃止予定のフィールドなど、事前に確認すべき点が少なくありません。EKS には cluster insights という機能があり、Amazon EKS コンソールの「Upgrade insights」タブから、現在のクラスターが 1.36 へアップグレードする際に問題となりそうな箇所を事前に確認できます。問題が見つかった場合は修正し、再度チェックを実行して解消されたことを確認したうえでアップグレードに進む、という流れです。

1.36 で新たに対応が必要になる項目

1.36 のリリースノートでは、新機能とは別に「Action required」として扱われている変更がいくつかあります。1.36 へのアップグレード前に、特に次の 3 点は確認しておくことをおすすめします。

gitRepo ボリュームの完全無効化

gitRepo ボリュームタイプは 1.36 で完全に無効化されます。API はこのボリュームを持つ Pod の作成自体は受け付けますが、kubelet が起動を拒否するようになります。gitRepo を使っているマニフェストがあれば、init container や git-sync サイドカーへの移行が必要です。

SELinux ボリュームラベリング方式の変更 (GA)

SELinux を有効にしたノードでは、ボリュームのラベリング方式がデフォルトで mount -o context ベースに切り替わります。同じボリュームを privileged / unprivileged 両方の Pod で共有している場合に問題が発生する可能性があるため、seLinuxChangePolicy の設定を事前に見直してください。

Strict IP/CIDR Validation のデフォルト有効化

先頭にゼロを含む IP アドレス表記 (010.000.000.005 など) や、非正規の CIDR 表記 (192.168.0.5/24 など) を含む API フィールドが、新規作成・更新時に拒否されるようになります。マニフェストや Helm チャート、IaC コードの中にこうした表記がないか確認してください。

アドオンのバージョンを確認する

cluster insights に加えて、CoreDNS・kube-proxy・VPC CNI といったアドオンが 1.36 に対応したバージョンになっているかも確認が必要です。コントロールプレーンを 1.36 に上げても、アドオン側のバージョンが古いままだと問題が発生することがあります。

EKS Distro を使っている場合

EKS Distro で 1.36 のビルドを利用する場合は、ECR Public Gallery または GitHub から取得できます。

アップグレードを後回しにした場合

EKS の Kubernetes バージョンは、リリースから 14 ヶ月間が標準サポート、その後 12 ヶ月間が拡張サポートという期間で管理されています。1.36 の場合、標準サポート終了は 2027 年 8 月 2 日、拡張サポート終了は 2028 年 8 月 2 日です。拡張サポート期間中もクラスターを稼働させ続けられますが、クラスター時間あたりの追加料金が発生します。アップグレードを後回しにするほど、こうした追加コストや対応が必要な変更点が積み重なっていく、という点は計画を立てる際の材料として覚えておくとよいでしょう。

---

まとめ

Amazon EKS および Amazon EKS Distro の Kubernetes 1.36 対応では、User Namespaces と Mutating Admission Policies が GA に到達しました。前者はコンテナのセキュリティ境界を、後者は Admission 制御のアーキテクチャを、それぞれ根本から見直す変更です。本記事では、この 2 機能を中心に仕組みと設定方法を確認したうえで、In-Place Pod-Level Resources Vertical Scaling や Resource Health Status といった Beta 機能、そしてアップグレード時に確認すべき項目を紹介しました。

いずれの機能も EKS 側で追加の設定をすることなく、クラスターを 1.36 にアップグレードするだけで試せます。まずは検証環境で、hostUsers: false を指定した Pod や MutatingAdmissionPolicy を実際に動かしてみることをおすすめします。

本番環境へのアップグレードを計画する際は、cluster insights による事前チェックと、本記事で紹介した 1.36 特有の確認項目 (gitRepo ボリューム、SELinux ラベリング、Strict IP/CIDR Validation) を併せて確認しておくと、スムーズに移行できるはずです。

---

参考リンク

• Amazon EKS and Amazon EKS Distro now supports Kubernetes version 1.36 (AWS What's New)
• Kubernetes v1.36 Release (Kubernetes Blog)
• User Namespaces in Kubernetes are finally GA (Kubernetes Blog)
• Mutating Admission Policy (Kubernetes Documentation)
• CHANGELOG-1.36.md (kubernetes/kubernetes)
• Kubernetes バージョン標準サポートのリリースノート (Amazon EKS User Guide)
• Kubernetes バージョンのライフサイクル (Amazon EKS User Guide)
• Cluster insights (Amazon EKS User Guide)
• amazon-eks-ami Releases (GitHub)
• MutatingPolicy (Kyverno Documentation)