Kubernetes 1.33 (2026) - サイドカーコンテナGA、動的リソース割り当て、Gateway API正式版

Kubernetes 1.33の背景

Kubernetes 1.33は2026年4月15日にリリースされました。このバージョンでは、長らくBeta段階にあったサイドカーコンテナがついに一般提供（GA）に到達し、動的リソース割り当て（DRA）の導入によりGPUやFPGAなどの特殊ハードウェアの管理が大幅に改善されました。

Cloud Native Computing Foundation（CNCF）が2026年1月に発表した調査によると、本番環境でKubernetesを採用している組織は93%に達し、2025年の87%から更に拡大しています。一方で、リソース効率化とセキュリティ強化への要求は増し続けており、1.33はこれらの課題に直接応える設計となっています。

サイドカーコンテナのGA到達

サイドカーパターンとは

サイドカーコンテナは、メインアプリケーションコンテナと並行して動作する補助的なコンテナです。ログ収集、メトリクス出力、プロキシ、セキュリティスキャンなど、横断的な関心事を担当します。

新しいサイドカーコンテナの定義

apiVersion: v1
kind: Pod
metadata:
  name: myapp-with-sidecar
spec:
  initContainers:
  - name: istio-proxy
    image: istio/proxyv2:1.22.0
    restartPolicy: Always  # これがサイドカーを示すマーカー
    ports:
    - containerPort: 15090
      name: http-envoy-prom
  containers:
  - name: myapp
    image: myapp:v2.3.1
    ports:
    - containerPort: 8080

従来の initContainers セクション内に配置しつつ、restartPolicy: Always を指定することで、Kubernetesはこのコンテナをサイドカーとして認識します。これにより次の動作が保証されます。

ユースケース

• サービスメッシュ: IstioやLinkerdのプロキシ注入
• ログ転送: Fluentd/Fluent Bitでのログ集約
• セキュリティスキャン: Falcoなどのランタイム脅威検知
• キャッシュレイヤー: Redisサイドカーによるローカルキャッシュ

動的リソース割り当て（DRA）の導入

これまでの課題

KubernetesのDevice Plugin APIは2018年（v1.10）から存在していましたが、次の制約がありました。

• リソースは 整数単位 でのみ割り当て可能（GPU 1個、2個…）
• 複数種類のGPUを同一ノードで混在させる場合の柔軟性に欠ける
• デバイスの事前割り当て（pre-allocation）が必須で、動的な変更が困難

これにより、GPUメモリの一部だけを使いたい、異なるGPUアーキテクチャを同時に指定したいといった要求に応えられませんでした。

DRAの仕組み

動的リソース割り当て（Dynamic Resource Allocation, DRA）は、リソース要求をCRD（Custom Resource Definition）で表現し、専用ドライバが動的にデバイスを割り当てる アーキテクチャです。

apiVersion: resource.k8s.io/v1alpha3
kind: ResourceClaim
metadata:
  name: gpu-claim
spec:
  devices:
    requests:
    - name: gpu-for-training
      deviceClassName: nvidia.com/gpu
      selectors:
      - cel:
          expression: 'device.attributes["cuda.major"] >= 8 && device.attributes["memory"] >= "40Gi"'
---
apiVersion: v1
kind: Pod
metadata:
  name: ml-training
spec:
  containers:
  - name: trainer
    image: pytorch:2.3-cuda12
    resources:
      claims:
      - name: gpu-claim

上記の例では、CUDA Compute Capability 8.0以上かつ40GB以上のメモリを持つGPUを動的に要求しています。

従来のDevice Plugin APIとの比較

Gateway API v1.2のGA

Ingressの後継としての位置づけ

Kubernetes Ingress APIは2015年（v1.1）から存在し、HTTPルーティングの標準でした。しかし次の限界が指摘されていました。

• 表現力の不足: ヘッダベースルーティング、重み付け分割、リトライポリシーなどが未対応
• 単一リソースモデル: 複数チームでのIngress共有が困難
• 拡張の乱立: 各プロバイダ（NGINX、Istio、Traefik）独自のアノテーション

Gateway API v1.2は、これらを解決するロールベースの階層モデルを提供します。

Gateway APIの構造

# 1. インフラ管理者がGatewayClassを定義
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: external-lb
spec:
  controllerName: istio.io/gateway-controller
---
# 2. プラットフォームチームがGatewayを作成
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: prod-gateway
  namespace: infra
spec:
  gatewayClassName: external-lb
  listeners:
  - name: http
    protocol: HTTP
    port: 80
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: tls-cert
---
# 3. アプリ開発者がHTTPRouteで経路定義
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: myapp-route
  namespace: myapp
spec:
  parentRefs:
  - name: prod-gateway
    namespace: infra
  hostnames:
  - "api.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /v1
    backendRefs:
    - name: myapp-v1
      port: 8080
      weight: 90
    - name: myapp-v2-canary
      port: 8080
      weight: 10

上記では、90%のトラフィックを本番、10%をカナリアに振り分ける設定が宣言的に表現されています。

IngressとGateway APIの比較

セキュリティ強化

AppArmorプロファイルのデフォルト適用

Kubernetes 1.33では、AppArmorプロファイルがAlpha → Beta → GAの全段階を完了し、Podのセキュリティコンテキストで標準サポートされました。

apiVersion: v1
kind: Pod
metadata:
  name: secured-app
spec:
  securityContext:
    appArmorProfile:
      type: RuntimeDefault  # または Localhost / Unconfined
  containers:
  - name: app
    image: myapp:latest
    securityContext:
      appArmorProfile:
        type: Localhost
        localhostProfile: custom-profile

RuntimeDefault を指定すると、コンテナランタイム（containerd, CRI-O）のデフォルトAppArmorプロファイルが適用され、ファイルシステムへの書き込み、カーネル機能の使用、ネットワーク操作が制限されます。

Seccompプロファイルの強制

Seccomp（Secure Computing Mode）は、プロセスが呼び出せるシステムコールを制限する仕組みです。1.33では、Pod Security Standardsの baseline レベルで Seccomp RuntimeDefault が必須化されました。

主要セキュリティ機能の成熟度（1.33時点）

その他の注目すべき改善

CEL（Common Expression Language）の拡張

ValidatingAdmissionPolicyで使われるCELが拡張され、正規表現マッチング、JSON Schema検証、コスト制限の緩和が実現しました。

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingAdmissionPolicy
metadata:
  name: restrict-image-registries
spec:
  matchConstraints:
    resourceRules:
    - apiGroups: [""]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["pods"]
  validations:
  - expression: |
      object.spec.containers.all(c,
        c.image.startsWith('myregistry.io/') ||
        c.image.startsWith('ghcr.io/myorg/')
      )
    message: "Container images must come from approved registries"

上記のポリシーは、すべてのコンテナイメージが承認されたレジストリから取得されているかを検証します。

JobのSuccessPolicy・BackoffLimitPerIndex

Jobリソースに SuccessPolicy と BackoffLimitPerIndex が追加され、並列Jobの部分成功を許容できるようになりました。

apiVersion: batch/v1
kind: Job
metadata:
  name: batch-processing
spec:
  completions: 100
  parallelism: 10
  backoffLimitPerIndex: 3  # 各インデックス最大3回リトライ
  successPolicy:
    rules:
    - succeededIndexes: "0-79"  # 80%成功でJob全体を成功とみなす

Persistent Volume Last Phase Transition Time

PersistentVolumeに .status.lastTransitionTime フィールドが追加され、ボリュームのライフサイクル監視が容易になりました。

Kubernetes採用状況と今後の展望

CNCF調査データ（2026年1月）

CNCFの年次調査によると、次の傾向が確認されています。

• 本番環境でのKubernetes採用率：93%（2025年87%、2024年82%）
• マルチクラウド展開：71%（AWS + Azure + GCPの組み合わせ）
• サービスメッシュ採用率：58%（Istio 42%、Linkerd 16%）
• GitOps採用率：64%（Argo CD 48%、Flux 16%）

2027年に向けたロードマップ

Kubernetes 1.34以降で予定されている主要機能は次の通りです。

反対意見・課題

複雑性の増大

Gateway APIやDRAの導入により、学習すべきCRDとコンセプトが増加しています。37signalsやDHHは2024年に「KubernetesからVMへの回帰」を発表し、運用コストの削減を実現しました。

代替手段の台頭

• Nomad: HashiCorpによるシンプルなオーケストレータ、学習曲線が緩やか
• Fly.io / Railway: Herokuライクなデプロイ体験、内部でKubernetesを隠蔽
• Kamal: Railsチームが開発したDocker Composeベースのデプロイツール

Kubernetesが「標準」であることは間違いありませんが、小規模スタートアップや単純なWebアプリケーションには必ずしも最適解ではないという認識が広がっています。

セキュリティパッチの追従コスト

Kubernetes本体に加え、CNI（Calico、Cilium）、CSI（各種ストレージドライバ）、サービスメッシュ、Ingress Controller等の依存コンポーネントすべてにセキュリティパッチを適用し続ける運用負荷は小さくありません。

私たちはどう備えるか

個人（エンジニア）

• Gateway APIの学習: Ingressは今後レガシー扱いになる可能性が高い。公式チュートリアルで基礎を習得
• DRAの実験: NVIDIAやAMDのサンプルを使い、GPU管理の新しいパラダイムを体験
• セキュリティ標準の理解: Pod Security Standardsを読み、AppArmor/Seccompの影響範囲を把握

組織（企業）

• マネージドKubernetesの活用: GKE、EKS、AKSはすべて1.33対応済み。セルフホストの運用負荷と比較検討
• 段階的移行計画: Gateway APIへの移行は強制ではないが、2027年以降の新機能はGateway API前提になる可能性
• コスト最適化: DRAによりGPUシェアリングが可能になるため、GPU密度の高いワークロードではコスト削減余地あり

プラットフォームチーム

• セキュリティベースラインの設定: AppArmor RuntimeDefault の全Pod適用をPolicy-as-Codeで実施（Kyverno、OPA Gatekeeper）
• 観測性の整備: DRAリソースとGateway APIルーティングの両方をPrometheus + Grafanaで可視化
• アップグレード戦略: 1.33へのアップグレードは破壊的変更が少ないが、deprecated APIの確認は必須（kubectl-convertで事前検証）

よくある質問

Kubernetes 1.33へのアップグレードで破壊的変更はありますか

いいえ、1.33には意図的な破壊的変更はありません。ただし、Beta版APIのいくつかが削除されているため、事前に kubectl-convert で現行マニフェストの互換性を確認してください。特に flowcontrol.apiserver.k8s.io/v1beta2 は削除されており、v1 への移行が必要です。

DRAはいつ本番環境で使えますか

DRAは1.33時点でAlphaです。Kubernetesの慣例では、Alpha → Beta（1〜2リリース）→ GA（1〜2リリース）という流れなので、本番推奨は2027年前半（1.34または1.35）になる見込みです。NVIDIAとAMDは既にAlpha段階でドライバ提供を開始しており、実験環境での検証は可能です。

Gateway APIに移行しないとIngressは使えなくなりますか

いいえ、Ingress APIは引き続きサポートされます。しかし、新機能の追加はGateway APIに集中しており、Ingressは実質的にメンテナンスモードに入っています。2028年頃には「新規プロジェクトではGateway API推奨」が公式見解になると予想されます。

まとめ

Kubernetes 1.33は、成熟と革新が同居したリリースです。

• サイドカーコンテナのGA到達により、サービスメッシュとオブザーバビリティの実装が安定
• DRAの登場でGPU/FPGAなど特殊ハードウェアの管理が柔軟に
• Gateway API v1.2 GAにより、Ingressの後継が明確化
• AppArmor/SeccompのGA化でセキュリティベースラインが向上
• CNCF調査では本番採用率93%に到達、事実上の業界標準に

一方で、複雑性の増大と小規模ユースケースでの過剰感も指摘されており、すべての組織にKubernetesが最適とは限らないという認識も広がっています。自組織の規模・技術スタック・運用能力に応じた冷静な判断が求められます。

関連記事として、Kubernetes 2025年の動向やKubernetes 1.30の主要機能も併せてご覧ください。

参考リソース

• Kubernetes 1.33 Release Notes - 公式リリースブログ
• KEP-753: Sidecar Containers - サイドカーコンテナのKEP
• Gateway API v1.2 Announcement - Gateway API GA発表
• Dynamic Resource Allocation (DRA) Guide - DRA公式ドキュメント
• CNCF Annual Survey 2026 - CNCF年次調査レポート
• Pod Security Standards - AppArmor/Seccomp適用ガイド