📚 课程目录第3章常见弃用API场景分析

3. 常见 API 弃用案例：旧版 extensions/v1beta1、apps/v1beta2、networking.k8s.io/v1beta1

Kubernetes 社区在 v1.16 至 v1.22 期间集中清理了一批长期标记为“弃用”的 API 版本。其中 extensions/v1beta1、apps/v1beta2 和 networking.k8s.io/v1beta1 是影响面最广的三个弃用案例。理解它们的迁移路径，是构建 Kyverno 资源校准策略的基础。

3.1 弃用时间线与影响范围

下表列出三个旧版 API 的移除版本、替代版本及典型资源类型：

旧版 API	移除版本	替代 API	受影响的主要资源
`extensions/v1beta1`	v1.22	`networking.k8s.io/v1` `policy/v1beta1` `apps/v1`	Ingress, DaemonSet, Deployment, ReplicaSet, NetworkPolicy, PodSecurityPolicy
`apps/v1beta2`	v1.16	`apps/v1`	Deployment, StatefulSet, DaemonSet, ReplicaSet, ControllerRevision
`networking.k8s.io/v1beta1`	v1.22	`networking.k8s.io/v1`	Ingress, IngressClass

⚠️ 关键风险： 从 v1.22 开始，extensions/v1beta1 和 networking.k8s.io/v1beta1 的 Ingress 资源已完全不可用。集群升级前若未完成迁移，Ingress 规则将全部失效，导致外部流量中断。

3.2 核心迁移差异：Ingress 示例

Ingress 是三个弃用案例中变化最典型的资源。从 extensions/v1beta1 到 networking.k8s.io/v1，字段结构发生了结构性调整：

apiVersion 变更： extensions/v1beta1 → networking.k8s.io/v1
spec.backend 废弃： 改为 spec.defaultBackend
pathType 成为必填： 旧版允许省略，新版必须显式指定 Prefix、Exact 或 ImplementationSpecific
serviceName / servicePort 废弃： 改为 service.name / service.port.number 嵌套结构

# 旧版 extensions/v1beta1（v1.22 后不可用）
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: old-ingress
spec:
  backend:
    serviceName: old-svc
    servicePort: 80

# 新版 networking.k8s.io/v1（推荐）
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: new-ingress
spec:
  defaultBackend:
    service:
      name: new-svc
      port:
        number: 80
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-svc
            port:
              number: 8080

💡 迁移建议： 使用 kubectl convert 命令可快速将旧版 YAML 转换为新版格式。但该工具无法处理所有边缘情况，建议转换后人工复核 pathType 和 service 字段。

3.3 弃用 API 检测流程

下图展示从集群中检测弃用 API 并生成校准策略的完整流程：

3.4 典型迁移清单与 Kyverno 策略映射

针对三个弃用案例，Kyverno 策略需要覆盖以下资源类型和版本组合：

旧版 API 组/版本	资源类型	Kyverno 策略匹配规则	建议操作
`extensions/v1beta1`	Ingress	`apiVersion: extensions/v1beta1`	拒绝创建 + 提示迁移至 `networking.k8s.io/v1`
`extensions/v1beta1`	DaemonSet, Deployment	`apiVersion: extensions/v1beta1`	拒绝创建 + 提示迁移至 `apps/v1`
`apps/v1beta2`	Deployment, StatefulSet	`apiVersion: apps/v1beta2`	拒绝创建 + 提示迁移至 `apps/v1`
`networking.k8s.io/v1beta1`	Ingress, IngressClass	`apiVersion: networking.k8s.io/v1beta1`	拒绝创建 + 提示迁移至 `networking.k8s.io/v1`

3.5 迁移优先级与风险等级

根据资源的重要性和弃用时间，建议按以下优先级执行迁移：

P0（立即迁移）： extensions/v1beta1 下的 Ingress —— 直接影响外部流量，v1.22 后完全不可用。
P1（高优先级）： apps/v1beta2 下的 Deployment 和 StatefulSet —— 影响工作负载调度，v1.16 已移除。
P2（中优先级）： networking.k8s.io/v1beta1 下的 IngressClass —— 通常数量较少，但迁移成本低。
P3（低优先级）： extensions/v1beta1 下的 DaemonSet 和 ReplicaSet —— 已被 apps/v1 替代多年，存量较少。

  🔍 审计发现： 在多个生产集群的审计中，extensions/v1beta1 的 Ingress 是存量最多的弃用资源，占比超过 60%。建议优先使用 Kyverno 的 validate 规则进行“软拦截”（仅告警），待业务方确认后再切换为“硬拦截”（拒绝创建）。

3.6 迁移后的验证要点

完成资源迁移后，需验证以下关键点以确保功能正常：

Ingress 规则生效： 使用 curl 或 kubectl port-forward 测试流量是否按预期路由。
Deployment 滚动更新： 触发一次滚动更新，确认 apps/v1 的 spec.selector 与旧版兼容。
StatefulSet 持久化： 验证 PVC 绑定和 Pod 标识符（ordinal index）未因 API 版本变更而丢失。
Kyverno 策略生效： 尝试创建旧版 API 资源，确认策略正确拦截并返回提示信息。