Developers 和 Platform Teams 都想要 Kubernetes Self-Service，但谁该为它“背锅”？

“开发者想要 Pod —— 就在他们敲下 git push 后 90 秒内；他们不想要的是 7 天后还在运行的、无人认领的 vLLM 推理服务——那不是环境，是技术债。”

背景动机：Self-Service 不是功能，而是责任边界的战争

Kubernetes 自服务（Self-Service）早已不是新概念。从早期 Helm Chart 仓库到如今 GitOps 驱动的自助式环境供给，平台团队（Platform Engineering Team）投入大量资源构建「开发者门户」（Developer Portal），集成 RBAC、命名空间配额、策略引擎（如 Kyverno/Opa）、CI/CD 网关与成本仪表盘。而开发者端的诉求也愈发明确：
✅ 我要一个带 GPU 的 namespace，预装 Prometheus Sidecar + Istio Ingress Gateway；
✅ 我要一键部署 vLLM Serving 实例，自动挂载 /models PVC 并暴露 /generate endpoint；
✅ 我不要审批工单、不要等 SRE 手动 YAML Review、不要在 Slack 里 @oncall 问 “我的 Pod 为什么 Pending？”

表面看，双方目标高度一致：加速交付、降低摩擦、提升自治性。
但矛盾在落地时立刻尖锐化——当一个 junior dev 在 dev cluster 创建了 3 个 nvidia.com/gpu: 4 的 Deployment，持续 12 天未清理，导致集群 GPU 利用率长期卡在 98%，此时：

开发者说：“平台承诺了 Self-Service，我按文档操作，凭什么罚我？”
Platform 团队回应：“你没配 ttl.sh/expire-after: 24h annotation，也没走 Cost Tagging Pipeline，这属于越权使用。”

问题本质从来不是“能不能做”，而是 “谁定义边界？谁承担后果？”
Self-Service 的幻觉，往往始于对“自动化”和“自治”的混淆：自动化是能力，自治是权利；而权利必须由清晰的责任契约（Ownership Contract）来锚定。

核心技术：用声明式契约替代口头约定（附可落地 YAML）

真正的自服务不是开放 kubectl apply -f，而是通过 Policy-as-Code + Context-Aware Provisioning 构建可审计、可回收、可计费的闭环。以下是经生产验证的三层技术栈设计：

1. 基于 OPA/Gatekeeper 的准入控制（Pre-flight Guardrails）

禁止无 TTL 的 GPU 工作负载进入集群：

yaml

# gatekeeper-constraint-gpu-ttl.yaml
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredTTLForGPU
metadata:
  name: gpu-workloads-must-have-ttl
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    minTTLHours: 24
    requiredAnnotation: "ttl.sh/expire-after"

配合 Rego 策略（简化版）：

rego

package k8srequiredttlforgpu

violation[{"msg": msg, "details": {"missing_annotation": input.request.object.metadata.annotations[requiredAnnotation]}}] {
  input.request.kind.kind == "Pod"
  input.request.object.spec.containers[_].resources.limits["nvidia.com/gpu"]
  not input.request.object.metadata.annotations[requiredAnnotation]
  msg := sprintf("GPU Pod must declare %v annotation (e.g., '24h')", [requiredAnnotation])
}

✅ 效果：kubectl apply 直接拒绝无 TTL 的 GPU Pod，错误信息含修复指引（如 kubectl annotate pod my-vllm ttl.sh/expire-after=48h）

2. 自助式环境模板（Templated Namespace Provisioning）

开发者通过 UI 或 CLI 请求环境，平台团队提供受控模板（非裸 YAML）。推荐使用 Crossplane + Composition 或 Argo CD ApplicationSet + Parameters。示例（ApplicationSet）：

yaml

# appset-dev-env.yaml
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: dev-env-template
spec:
  generators:
  - git:
      repoURL: https://git.example.com/platform/templates.git
      revision: main
      directories:
      - path: "envs/*"
  template:
    metadata:
      name: '{{path.basename}}-{{inputs.owner}}'
    spec:
      project: default
      source:
        repoURL: https://git.example.com/platform/templates.git
        targetRevision: main
        path: '{{path.path}}'
        helm:
          parameters:
          - name: owner
            value: '{{inputs.owner}}'
          - name: gpuCount
            value: '{{inputs.gpuCount | default "0"}}'
          - name: ttlHours
            value: '{{inputs.ttlHours | default "24"}}'
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{path.basename}}-{{inputs.owner}}'

✅ 关键设计：所有参数（owner, gpuCount, ttlHours）强制来自可信输入源（如内部 IDP 的 OIDC claim），杜绝 --set owner=hacker 类绕过。

3. 自动化回收与成本归因（Post-flight Accountability）

利用 ttl.sh CRD + CronJob 实现无人值守清理，并将成本标签注入云账单：

yaml

# crd-ttl-resource.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: ttls.ttl.sh
spec:
  group: ttl.sh
  versions:
  - name: v1
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              expireAfter:
                type: string # e.g., "24h", "7d"
              owner:
                type: string
              costCenter:
                type: string
  scope: Namespaced
  names:
    plural: ttls
    singular: ttl
    kind: TTL
    listKind: TTLList

配套回收 Job（每日扫描）：

yaml

# job-ttl-cleanup.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: ttl-cleanup
spec:
  schedule: "0 2 * * *" # UTC 02:00 daily
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: cleanup
            image: ghcr.io/ttl-sh/cleanup:v0.4.2
            env:
            - name: KUBECONFIG
              value: /etc/kubeconfig
            volumeMounts:
            - name: kubeconfig
              mountPath: /etc/kubeconfig
              readOnly: true
          volumes:
          - name: kubeconfig
            secret:
              secretName: platform-sa-kubeconfig

✅ 运维价值：每个 TTL 资源绑定 owner 和 costCenter，可直接对接 FinOps 工具（如 Kubecost）生成部门级成本报表。

运维建议：建立「三权分立」的 Self-Service 治理模型

别再用“我们建个 Portal 就行了”应付需求。真正的平台工程需在组织层设计权责：

维度	Platform Team 职责	Developer 职责	共同职责（SLA 约定）
创建权	提供参数化模板、预审策略、配额基线	选择模板、填写业务上下文（owner/costCenter）	模板更新通知 ≤ 24h，变更需兼容旧参数
运维权	保障底层组件（etcd/Istio/GPU Operator）SLA	自行调试应用层问题（Pod 日志、metrics、traces）	P99 API 延迟 ≤ 200ms（由 Argo Rollouts 金丝雀验证）
销毁权	执行 TTL 清理、回收 PV/PVC、释放云资源	主动标注 `ttl.sh/expire-after`，避免依赖自动兜底	资源泄露告警 → 15min 内自动打标 + 通知责任人

关键实践：

拒绝“无主资源”：所有 Namespace 必须关联 platform.dev/owner: team-ai-infra Label，否则被 NamespaceValidator 拒绝创建；
成本可视化前置：在自助 Portal 中，用户提交前即显示预估月成本（基于 GPU 类型 × TTL × 当前 Spot 价格）；
SLO 驱动的权限升降级：连续 3 次违规（如漏设 TTL）→ 自动降级为只读权限，需完成平台治理培训后恢复。

⚠️ 警惕陷阱：把 ClusterRoleBinding 直接给 DevGroup = 把消防栓交给纵火犯。真正的自服务，是给开发者一把精准的瑞士军刀，而不是一罐汽油。

Developers 和 Platform Teams 都想要 Kubernetes Self-Service，但谁该为它“背锅”？ ​

背景动机：Self-Service 不是功能，而是责任边界的战争 ​

核心技术：用声明式契约替代口头约定（附可落地 YAML） ​

1. 基于 OPA/Gatekeeper 的准入控制（Pre-flight Guardrails） ​

2. 自助式环境模板（Templated Namespace Provisioning） ​

3. 自动化回收与成本归因（Post-flight Accountability） ​

运维建议：建立「三权分立」的 Self-Service 治理模型 ​

延伸阅读：超越 Kubernetes 的自服务演进 ​

Developers 和 Platform Teams 都想要 Kubernetes Self-Service，但谁该为它“背锅”？

背景动机：Self-Service 不是功能，而是责任边界的战争

核心技术：用声明式契约替代口头约定（附可落地 YAML）

1. 基于 OPA/Gatekeeper 的准入控制（Pre-flight Guardrails）

2. 自助式环境模板（Templated Namespace Provisioning）

3. 自动化回收与成本归因（Post-flight Accountability）

运维建议：建立「三权分立」的 Self-Service 治理模型

延伸阅读：超越 Kubernetes 的自服务演进