KubeCon Europe 2026 深度复盘：82% 采用率 vs 7% AI 部署率——云原生的第二次创始时刻
2026 年 6 月，阿姆斯特丹。KubeCon Europe 2026 不再是关于 Kubernetes 采用的问题——那场战争已经结束了。这是关于在其上运行什么，以及云原生生态能否在 AI 时代真正执行。
CNCF 执行董事 Jonathan Bryce 在主题演讲中抛出了两个数字：
- Kubernetes 采用率：82%
- AI 日常部署率：仅 7%
这不是差距，而是鸿沟。
核心矛盾：平台已就绪，但 AI 还没准备好
KubeCon 2026 传递的核心信号是：云原生基础设施已经成熟，但 AI 的生产级运营化还在挣扎。多年来我们谈论容器、编排和微服务是难题，今天这些问题已经解决。新的前沿是推理——模型如何在生产环境中实际运行、扩展和提供价值。
成熟度悖论
云原生成熟度 vs AI 运营成熟度：
云原生基础设施 AI 工作负载运营
┌──────────────────┐ ┌──────────────────┐
│ K8s 采用率 82% │ │ AI 日部署率 7% │
│ 容器标准化完成 │ │ 模型生命周期混乱 │
│ 微服务模式成熟 │ │ 推理优化碎片化 │
│ CI/CD 广泛落地 │ │ GPU 利用率低下 │
│ 安全策略 GA 化 │ │ 成本控制缺失 │
│ │ │ │
│ → 基础设施已就绪 │ │ → 执行差距巨大 │
└──────────────────┘ └──────────────────┘这个问题不是技术性的——Kubernetes 完全可以跑 AI 工作负载。真正的问题是运营化：模型部署、推理优化、成本治理、安全合规这些上层能力还不成熟。
今天的 AI 就像 2015 年的容器
我们正在看到早期云采用的重演：
| 2015 年容器 | 2026 年 AI |
|---|---|
| 提升和迁移行为 | 直接把模型扔进 Pod |
| 竖起和祈祷 | 部署完不管成本 |
| 糟糕的成本控制 | GPU利用率 < 30% |
| 碎片化工具 | 50+ 模型服务框架 |
| 上层缺乏标准化 | 无标准推理 API |
区别在于？风险成倍增加——AI 的基础设施成本比传统应用高一个数量级，错误决策的经济代价更大。
Kubernetes 正在成为 AI 操作系统
主题演讲中的另一个关键数据：三分之二的生成式 AI 工作负载已经在 Kubernetes 上运行。
这是 KubeCon 2026 的隐藏故事。Kubernetes 不再仅仅是基础设施，它正在成为AI 操作系统。
AI 控制平面的兴起
在美国和欧洲的许多对话都指向一个新兴想法：AI 需要自己的控制平面。不仅仅是基础设施编排，还包括：
AI 控制平面的五层架构：
┌──────────────────────────────────────────────────┐
│ 第 5 层：成本治理 │
│ GPU 利用率监控、推理成本优化、预算控制 │
├──────────────────────────────────────────────────┤
│ 第 4 层：策略执行 │
│ 模型安全策略、数据合规、审计日志 │
├──────────────────────────────────────────────────┤
│ 第 3 层：推理优化 │
│ 批处理、模型缓存、动态批大小、量化 │
├──────────────────────────────────────────────────┤
│ 第 2 层：模型生命周期 │
│ 版本管理、A/B 测试、回滚、模型签名 │
├──────────────────────────────────────────────────┤
│ 第 1 层：基础设施编排 │
│ GPU 分配、Pod 调度、水平扩展 │ ← Kubernetes 已解决
└──────────────────────────────────────────────────┘
Kubernetes 1.36 正在第 1 层向第 2-3 层演进参与者的变化
这次 KubeCon 的参与者与上一代完全不同：
- 英伟达：从硅片到软件推动 AI 工厂堆栈
- AWS / Google Cloud：将 Kubernetes 更深入地嵌入 AI 平台
- IBM / Red Hat：大规模运营开源，连接企业 IT 与 AI 工作负载
- 新兴厂商：vLLM、TensorRT-LLM、KServe 等推理框架百花齐放
它们共同代表了一种强大的融合：云原生遇见 AI 原生，开源作为连接组织。
但问题依然存在：仅仅因为 AI 可以在 Kubernetes 上运行，并不意味着它是优化的、高效的或经济可行的。
Kubernetes 1.36 "Haru"：安全 + AI 双焦点
K8s 1.36 代号 Haru，2026 年 4 月 22 日正式发布，包含 70 项增强功能：18 项 Stable、25 项 Beta、25 项 Alpha。两大焦点：安全加固和AI 工作负载支持。
安全焦点：User Namespaces GA
User Namespaces 经过多个版本周期的打磨，终于在 1.36 达到 GA。这是一个真正的安全改进：
yaml
# 启用 User Namespaces
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
spec:
securityContext:
userNamespace: true # ← 新的 GA 功能
containers:
- name: app
image: my-app:latest
securityContext:
runAsUser: 0 # 容器内 root
# 但在宿主机上映射为非特权用户安全效果：容器内的 root 用户在宿主机上映射为非特权用户。即使进程逃逸容器，也不会获得宿主机管理权限。
传统容器：
┌──────────────────┐
│ 容器 root (UID 0)│────→ 宿主机 root (UID 0) ← 逃逸即 root！
└──────────────────┘
User Namespaces：
┌──────────────────┐
│ 容器 root (UID 0)│────→ 宿主机 UID 100000+ ← 逃逸也无特权！
└──────────────────┘对多租户集群的意义：这是威胁模型的根本改变。共享基础设施上的容器逃逸漏洞不再自动授予宿主机 root 权限。
Mutating Admission Policies GA
Mutating Admission Policies 达到 GA 是另一个重要里程碑。之前需要部署和维护独立的 webhook 服务器来实现请求变异，现在可以用 CEL（Common Expression Language）直接定义变异逻辑：
yaml
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
name: auto-sidecar-inject
spec:
matchConstraints:
resources:
- apiGroups: [""]
kinds: ["Pod"]
conditions:
- expression: "has(object.metadata.annotations['inject-sidecar'])"
mutations:
- patchSet:
jsonPatches:
- path: "/spec/containers/-"
operation: Add
value: '{"name": "observability-sidecar", "image": "otel/injector:v1"}'优势：
- 无需额外基础设施（不再需要 webhook 服务器）
- 更低的延迟（CEL 原生执行 vs HTTP 调用）
- 更少的运维负担
AI 工作负载焦点：DRA 增强
Dynamic Resource Allocation（DRA）的多项增强达到 Beta 并默认启用：
yaml
# DRA 分区设备：GPU 可以被分区和共享
apiVersion: resource.k8s.io/v1beta1
kind: ResourceClaim
metadata:
name: gpu-partition
spec:
devices:
requests:
- name: gpu
deviceClassName: gpu.nvidia.com
# 请求 GPU 的 1/4 分区而非整卡
allocationMode: Fractional
count: 25 # 25% 的 GPU核心变化：
| 旧模式 | 新模式 |
|---|---|
| 整卡分配（一卡一 Pod） | 分区分配（一卡多 Pod） |
| GPU 利用率无法保证 | DRA Consumable Capacity 确保 |
| GPU 故障无恢复机制 | DRA Device Taints + Tolerations |
Workload-Aware Preemption：AI 训练的救星
这是 K8s 1.36 对 AI 工作负载最具影响力的 Alpha 功能。
旧行为的问题：当一个 8 节点的分布式训练任务需要抢占时，调度器逐个 Pod 抢占，可能导致 7 个节点运行但无法推进——部分抢占失败模式：
旧的 Pod 级别抢占：
分布式训练 Job（8 rank）：
┌────────┬────────┬────────┬────────┬────────┬────────┬────────┬────────┐
│ rank-0 │ rank-1 │ rank-2 │ rank-3 │ rank-4 │ rank-5 │ rank-6 │ rank-7 │
│ ✅ │ ✅ │ ❌ │ ✅ │ ✅ │ ✅ │ ✅ │ ✅ │
│ 运行中 │ 运行中 │ 被抢占 │ 运行中 │ 运行中 │ 运行中 │ 运行中 │ 运行中 │
└────────┴────────┴────────┴────────┴────────┴────────┴────────┴────────┘
↑ 7/8 运行但无法推进 → 浪费资源！新行为：PodGroup 作为整体抢占单元，调度器先验证高优先级组能否实际放置：
yaml
# PodGroup 抢占定义
apiVersion: scheduling.x-k8s.io/v1alpha1
kind: PodGroup
metadata:
name: training-job-group
spec:
minMember: 8 # 最少需要 8 个 Pod 同时运行
scheduleStartTime: "2026-07-01"
minResources:
nvidia.com/gpu: 8新的 PodGroup 级别抢占：
验证阶段：高优先级 Job 能否放置？
┌─────────────────────────────────────────┐
│ 检查：需要 8 GPU → 当前只有 6 GPU 可用 │
│ → 等待，不抢占 → 不浪费资源 │
└─────────────────────────────────────────┘
执行阶段：资源充足时整体抢占
┌────────┬────────┬────────┬────────┬────────┬────────┬────────┬────────┐
│ rank-0 │ rank-1 │ rank-2 │ rank-3 │ rank-4 │ rank-5 │ rank-6 │ rank-7 │
│ ✅ │ ✅ │ ✅ │ ✅ │ ✅ │ ✅ │ ✅ │ ✅ │
│ 全部运行 → 训练可以推进 │
└────────┴────────┴────────┴────────┴────────┴────────┴────────┴────────┘其他关键增强
yaml
# In-Place Vertical Scaling（Beta）
# 可以调整 Pod 的 CPU/内存而不重启容器
apiVersion: v1
kind: Pod
metadata:
name: model-server
spec:
containers:
- name: inference
image: vllm-server:latest
resources:
requests:
cpu: "4"
memory: "8Gi"
limits:
cpu: "8" # 可在运行时调整
memory: "16Gi"
resizePolicy: # 新字段
- resourceName: cpu
restartPolicy: NotRequired # 调整 CPU 不重启
- resourceName: memory
restartPolicy: RestartContainer # 调整内存需要重启ResizeDeferred 事件：当调整无法立即应用（节点容量不足）时，Pod 在当前大小继续运行，kubelet 在容量释放后自动重试。
经济性：开源模型的 248 亿美元节约
Linux 基会研究的一个关键洞察：优化开放模型可以释放 248 亿美元的全球 AI 年度节约。这不是增量的，而是结构性的。
我们正在进入一个AI 策略即成本结构策略的阶段：
封闭 vs 开开的经济对比：
封闭模型生态：
┌──────────────────────────────────────┐
│ 高推理成本（API 计费） │
│ 平台锁定（无法迁移） │
│ 原始性能优先 │
│ → 成本结构被动 │
└──────────────────────────────────────┘
开放模型 + 云原生：
┌──────────────────────────────────────┐
│ 低推理成本（自部署） │
│ 可移植性（Kubernetes 标准） │
│ 经济效率优先 │
│ → 成本结构主动 │
└──────────────────────────────────────┘这是经典的行业张力：封闭模型 vs 开放模型、平台锁定 vs 云原生可移植性、原始性能 vs 经济效率。
Go 开发者的 AI 成本优化实战
go
// 基于 Kubernetes 事件的成本优化控制器
package controller
import (
"context"
"fmt"
"math"
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
"k8s.io/client-go/kubernetes"
)
type GPUCostOptimizer struct {
clientset *kubernetes.Clientset
gpuCostPerHour float64 // GPU 单价（$/小时）
targetUtilization float64 // 目标利用率
}
func (o *GPUCostOptimizer) Optimize(ctx context.Context) error {
// 获取所有 GPU Pod
pods, err := o.clientset.CoreV1().Pods("").List(ctx, metav1.ListOptions{
LabelSelector: "nvidia.com/gpu.present=true",
})
if err != nil {
return err
}
var totalCost float64
var wastedCost float64
for _, pod := range pods.Items {
// 计算 GPU 利用率（从 metrics 获取）
utilization := o.getGPUUtilization(pod.Name, pod.Namespace)
// 计算成本
hoursRunning := o.getHoursRunning(pod)
podCost := hoursRunning * o.gpuCostPerHour
totalCost += podCost
// 计算浪费（利用率低于目标）
if utilization < o.targetUtilization {
wasteRatio := o.targetUtilization - utilization
wastedCost += podCost * wasteRatio
// 建议缩容
fmt.Printf("⚠️ Pod %s/%s: GPU利用率 %.1f%% < 目标 %.1f%%, 浪费 $%.2f\n",
pod.Namespace, pod.Name,
utilization*100, o.targetUtilization*100,
podCost*wasteRatio)
// 推荐动作
if utilization < 0.1 {
fmt.Printf(" → 建议：终止 Pod（利用率 < 10%%）\n")
} else if utilization < 0.3 {
fmt.Printf(" → 建议：In-Place Resize 到更小 GPU 配额\n")
}
}
}
fmt.Printf("\n=== GPU 成本报告 ===\n")
fmt.Printf("总成本: $%.2f/月\n", totalCost*730) // 730 小时/月
fmt.Printf("浪费成本: $%.2f/月 (%.1f%%)\n",
wastedCost*730,
math.Min(100, wastedCost/totalCost*100))
return nil
}
func (o *GPUCostOptimizer) getGPUUtilization(podName, namespace string) float64 {
// 实际实现：从 Prometheus/DCGM 获取 GPU 利用率
// 这里返回模拟数据
return 0.25 // 25% 利用率（常见场景）
}AI 推理优化：从碎片化到标准化
KubeCon 2026 上最活跃的讨论之一是推理优化。当前生态有 50+ 模型服务框架，但缺乏标准化：
2026 年 AI 推理生态（碎片化）：
┌─────────────────────────────────────────────┐
│ 模型服务框架（50+） │
│ │
│ vLLM | TensorRT-LLM | KServe | Triton │
│ TGI | LoRAX | SGLang | Inferless │
│ ...（还有很多） │
│ │
│ 问题： │
│ - 无标准推理 API │
│ - 无标准模型格式 │
│ - 无标准 GPU 分配协议 │
│ - 无标准成本计量 │
└─────────────────────────────────────────────┘
正在标准化（K8s AI 一致性工作组）：
┌─────────────────────────────────────────────┐
│ Kubernetes AI 推理标准 │
│ │
│ 1. DRA → GPU 分配标准化 │
│ 2. PodGroup → 训练任务标准化 │
│ 3. In-Place Resize → 运行时优化标准化 │
│ 4. KServe → 推理服务标准化 │
│ │
│ 目标：像 Ingress 标准化 HTTP 路由一样 │
│ 标准化 AI 推理路由 │
└─────────────────────────────────────────────┘Go 语言推理服务模板
go
// 基于 K8s In-Place Resize 的自适应推理服务
package main
import (
"context"
"log"
"net/http"
"os"
"os/signal"
"syscall"
"time"
"github.com/prometheus/client_golang/prometheus"
"github.com/prometheus/client_golang/prometheus/promhttp"
)
type AdaptiveInferenceServer struct {
currentGPUAllocation float64 // 当前 GPU 配额
targetLatencyMs float64 // 目标延迟
maxBatchSize int // 最大批大小
metrics *InferenceMetrics
}
type InferenceMetrics struct {
requestLatency prometheus.Histogram
batchSize prometheus.Gauge
gpuUtilization prometheus.Gauge
requestsPerSec prometheus.Counter
}
func NewAdaptiveInferenceServer() *AdaptiveInferenceServer {
metrics := &InferenceMetrics{
requestLatency: prometheus.NewHistogram(prometheus.HistogramOpts{
Name: "inference_latency_ms",
Help: "Inference request latency",
Buckets: prometheus.DefBuckets,
}),
batchSize: prometheus.NewGauge(prometheus.GaugeOpts{
Name: "inference_batch_size",
Help: "Current batch size",
}),
gpuUtilization: prometheus.NewGauge(prometheus.GaugeOpts{
Name: "gpu_utilization_percent",
Help: "GPU utilization percentage",
}),
requestsPerSec: prometheus.NewCounter(prometheus.CounterOpts{
Name: "inference_requests_total",
Help: "Total inference requests",
}),
}
prometheus.MustRegister(
metrics.requestLatency,
metrics.batchSize,
metrics.gpuUtilization,
metrics.requestsPerSec,
)
return &AdaptiveInferenceServer{
currentGPUAllocation: 1.0, // 默认整卡
targetLatencyMs: 100, // 100ms 目标延迟
maxBatchSize: 32,
metrics: metrics,
}
}
func (s *AdaptiveInferenceServer) ServeHTTP(w http.ResponseWriter, r *http.Request) {
start := time.Now()
// 动态调整批大小（基于当前负载和延迟目标）
batchSize := s.calculateBatchSize()
// 执行推理
result, err := s.infer(r, batchSize)
if err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
return
}
// 记录指标
latency := time.Since(start).Milliseconds()
s.metrics.requestLatency.Observe(float64(latency))
s.metrics.requestsPerSec.Inc()
w.Header().Set("Content-Type", "application/json")
w.Write(result)
}
func (s *AdaptiveInferenceServer) calculateBatchSize() int {
// 根据当前延迟和 GPU 利用率动态调整
// 目标：在延迟约束下最大化吞吐
recentLatency := s.getRecentAvgLatency()
gpuUtil := s.getCurrentGPUUtilization()
if recentLatency < s.targetLatencyMs*0.5 && gpuUtil < 0.5 {
// 延迟低、利用率低 → 增加批大小提升吞吐
return min(s.maxBatchSize, s.maxBatchSize*2/3)
}
if recentLatency > s.targetLatencyMs {
// 延迟超标 → 减小批大小
return max(1, s.maxBatchSize/4)
}
// 正常范围
return s.maxBatchSize / 2
}
func main() {
server := NewAdaptiveInferenceServer()
// 指标端点（供 Prometheus/K8s 抓取）
http.Handle("/metrics", promhttp.Handler())
http.Handle("/infer", server)
// 健康检查端点
http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(http.StatusOK)
w.Write([]byte("ok"))
})
// 优雅关闭
ctx, cancel := context.WithCancel(context.Background())
defer cancel()
go func() {
sigCh := make(chan os.Signal, 1)
signal.Notify(sigCh, syscall.SIGTERM, syscall.SIGINT)
<-sigCh
cancel()
}()
}KubeCon 2026 的关键趋势
1. AI 控制平面兴起
CNCF 中突出显示的 Kubernetes AI 一致性工作等项目标志着事情的发展方向——AI 工作负载在 Kubernetes 上的标准化。这还处于早期，但我们之前在容器方面看过这部电影：
标准化演进路径：
容器时代：
混乱 → 工具爆炸 → 标准化 → 平台整合
↓
AI 时代：
我们正处于第 1 步和第 2 步之间
↑ ↑ ↑ ↑
└─┘ └─┘
碎片化 工具爆发2. 从基础设施到智能
云原生已经向上移动了堆栈：
演进路径：
昨天：基础设施抽象 → Docker / K8s
今天：应用程序编排 → Service Mesh / GitOps
明天：智能编排 → AI 控制平面
← 基础设施层 → ← 应用层 → ← 智能层 →3. 开源是连接组织
英伟达、AWS、Google Cloud 和 Red Hat 的共同参与代表了一种强大融合：云原生遇见 AI 原生，开源作为连接组织。Kubernetes 作为中立控制平面的定位是关键——它不偏向任何云提供商。
4. FinOps 进入 AI 领域
GPU 成本优化成为 KubeCon 热门话题。248 亿美元的经济节约数据让 FinOps 从传统云成本管理延伸到 AI 成本治理：
传统 FinOps vs AI FinOps：
传统 FinOps：
- CPU/内存成本优化
- 存储成本优化
- 网络流量成本优化
AI FinOps（新增）：
- GPU 利用率优化
- 推理成本优化
- 模型大小 vs 推理速度权衡
- 训练成本（数据量 × GPU 小时）
- 开源模型 vs 商业 API 成本对比Go 开发者的云原生 AI 机遇
对于 Go 开发者来说，KubeCon 2026 传递了一个明确信号：Go 在云原生 AI 生态中占据核心位置。Kubernetes 的控制器、Operator、CRD 全部用 Go 编写。AI 控制平面的每一层都需要 Go：
go
// AI 推理控制器 Operator 框架
package controllers
import (
"context"
appsv1 "k8s.io/api/apps/v1"
corev1 "k8s.io/api/core/v1"
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
"sigs.k8s.io/controller-runtime/pkg/client"
"sigs.k8s.io/controller-runtime/pkg/controller/controllerutil"
)
const inferenceFinalizer = "inference.ailifecycle.io/finalizer"
// InferenceReconciler 管理推理服务的完整生命周期
type InferenceReconciler struct {
client.Client
Scheme *runtime.Scheme
}
func (r *InferenceReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
var inference aiv1.InferenceService
if err := r.Get(ctx, req.NamespacedName, &inference); err != nil {
return ctrl.Result{}, client.IgnoreNotFound(err)
}
// 1. 根据模型大小计算 GPU 需求
gpuRequest := calculateGPURequest(inference.Spec.Model)
// 2. 创建 Deployment（利用 DRA 分区设备）
deploy := &appsv1.Deployment{
ObjectMeta: metav1.ObjectMeta{
Name: inference.Name + "-server",
Namespace: inference.Namespace,
},
Spec: appsv1.DeploymentSpec{
Replicas: ptr.To(inference.Spec.Replicas),
Selector: &metav1.LabelSelector{
MatchLabels: map[string]string{"app": inference.Name},
},
Template: corev1.PodTemplateSpec{
ObjectMeta: metav1.ObjectMeta{
Labels: map[string]string{"app": inference.Name},
Annotations: map[string]string{
"inject-sidecar": "true", // 触发 MutatingAdmissionPolicy
},
},
Spec: corev1.PodSpec{
SecurityContext: &corev1.PodSecurityContext{
UserNamespace: ptr.To(true), // K8s 1.36 GA 功能
},
Containers: []corev1.Container{
{
Name: "inference-server",
Image: inference.Spec.Image,
Resources: corev1.ResourceRequirements{
Requests: gpuRequest,
Limits: gpuRequest,
},
ResizePolicy: []corev1.ContainerResizePolicy{
{
ResourceName: corev1.ResourceCPU,
RestartPolicy: corev1.NotRequiredResizePolicy,
},
{
ResourceName: corev1.ResourceMemory,
RestartPolicy: corev1.RestartContainerResizePolicy,
},
},
},
},
},
},
},
}
if err := controllerutil.SetControllerReference(&inference, deploy, r.Scheme); err != nil {
return ctrl.Result{}, err
}
if err := r.Create(ctx, deploy); err != nil {
return ctrl.Result{}, err
}
// 3. 创建 PodGroup（分布式训练）
if inference.Spec.DistributedTraining {
podGroup := createPodGroup(inference)
if err := r.Create(ctx, podGroup); err != nil {
return ctrl.Result{}, err
}
}
return ctrl.Result{}, nil
}
func calculateGPURequest(spec aiv1.InferenceServiceSpec) corev1.ResourceRequirements {
// 根据模型大小计算 GPU 需求
modelSizeGB := spec.ModelSizeGB
var gpuCount int64
if modelSizeGB < 7 {
gpuCount = 1 // 小模型：1 GPU
} else if modelSizeGB < 14 {
gpuCount = 2 // 中模型：2 GPU
} else if modelSizeGB < 70 {
gpuCount = 4 // 大模型：4 GPU
} else {
gpuCount = 8 // 超大模型：8 GPU
}
return corev1.ResourceRequirements{
Requests: corev1.ResourceList{
corev1.ResourceName("nvidia.com/gpu"): resource.MustParse(fmt.Sprintf("%d", gpuCount)),
corev1.ResourceCPU: resource.MustParse("4"),
corev1.ResourceMemory: resource.MustParse("16Gi"),
},
Limits: corev1.ResourceList{
corev1.ResourceName("nvidia.com/gpu"): resource.MustParse(fmt.Sprintf("%d", gpuCount)),
corev1.ResourceCPU: resource.MustParse("8"),
corev1.ResourceMemory: resource.MustParse("32Gi"),
},
}
}Go 在云原生 AI 中的具体角色
| 角色 | Go 实现 | K8s 1.36 利用 |
|---|---|---|
| GPU 调度控制器 | Custom Controller + DRA | DRA Partitionable Devices |
| 推理服务 Operator | Kubebuilder Operator | In-Place Resize |
| 成本优化引擎 | FinOps Controller | Kubelet Metrics + GPU Metrics |
| 安全策略执行 | CEL Admission Policy | User Namespaces + MAP |
| 训练任务编排 | PodGroup Controller | Workload-Aware Preemption |
KubeCon 2026 升级注意事项
K8s 1.36 的升级需要关注以下移除：
bash
# 检查是否使用了被移除的功能
# 1. gitRepo volume plugin（自 v1.11 废弃，1.36 正式移除）
kubectl get pods -A -o json | jq '.items[] | select(.spec.volumes[]?.gitRepo != null)'
# 如果存在，迁移到 init container 或 git-sync
# 旧方式：
# volumes:
# - name: code
# gitRepo:
# repository: "https://github.com/example/repo"
# revision: "main"
# 新方式：
# initContainers:
# - name: git-sync
# image: git-sync:v4
# args: ["--repo", "https://github.com/example/repo", "--branch", "main"]
# 2. IPVS mode in kube-proxy（移除）
kubectl -n kube-system get configmap kube-proxy -o yaml | grep mode
# 如果使用 IPVS，迁移到 iptables 或 eBPF
# iptables: kube-proxy --mode=iptables
# eBPF: 安装 Cilium/Calico eBPF dataplane
# 3. Flex-volume support in kubeadm（移除）
# 4. Portworx in-tree driver（移除）总结：云原生的第二次创始时刻
KubeCon Europe 2026 传递的最终信号：
平台已准备就绪，采用率已经存在，生态系统庞大。缺少的是执行。执行就是一切。
这是云原生要么演化为 AI 经济控制平面，要么被做得更好的人抽象化的拐点。如果 CNCF 和开源社区能够弥合 AI 执行差距，他们不仅保持相关性——他们还定义计算的下一个十年。
| 维度 | 状态 | 趋势 |
|---|---|---|
| Kubernetes 采用 | 82%（成熟） | → AI 操作系统 |
| AI 日常部署 | 7%（挣扎） | → 标准化进行中 |
| 安全加固 | User Namespaces GA | → 多租户安全基准 |
| AI 工作负载支持 | DRA Beta + PodGroup Alpha | → GPU 分区 + 整体抢占 |
| 经济性 | 248 亿美元节约潜力 | → 开放模型 + 云原生可移植 |
| Go 生态 | 核心位置 | → AI 控制平面首选语言 |
如果他们做不到，重心就会转移。这就是我们现在所处的时刻。毫无疑问，这是云原生的第二个创始时代。