最小闭环：Deployment 与 Service

最小闭环之所以重要，是因为它把「声明式」这个 Kubernetes 的灵魂压缩成了一个可触摸的动作。你不再 SSH 上机器执行 docker run，也不再手动配负载均衡；你把期望状态写进清单，kubectl apply 之后，控制器会替你对齐现实。你要做的只是观察、验证、再清理现场。

Deployment 的核心是一份 Pod 模板。它不关心集群里现在有多少台 Node，也不关心某个副本是否挂掉；它只保证「带有 app=web 标签的 Pod 始终有 2 个在运行」。当某个 Pod 被删除或失败时，ReplicaSet 控制器会创建新的来补足。这种「面向终态」的设计，让发布、扩缩容、故障恢复都变成了同一个模式：改期望，然后观察现实追上来。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27-alpine
          ports:
            - containerPort: 80

Service 则负责解决「访问」问题。Pod 的 IP 会随生命周期变化，直接访问 Pod IP 就像追着蝴蝶跑。Service 通过 selector 把流量稳定地代理到所有带 app=web 标签的 Pod 上，无论这些 Pod 被调度到哪个 Node、被重建了多少次。默认类型 ClusterIP 只在集群内部暴露，配合 port-forward 就能在本地完成验证，不需要任何外部负载均衡。

apiVersion: v1
kind: Service
metadata:
  name: web
  labels:
    app: web
spec:
  selector:
    app: web
  ports:
    - name: http
      port: 80
      targetPort: 80
  type: ClusterIP

要点

Kubernetes 不是帮你运行容器，而是帮你维持一份声明：你想要的 N 个副本、某种访问方式、以及它们持续存在的承诺。

完成验证后，用 kubectl delete -f examples/minimal-loop/ 清理现场。这个习惯在本地实验阶段尤其重要：它让你把「apply → 验证 → delete」当成一个完整的回合来练习，而不是在集群里留下一堆连自己都不记得含义的资源。当你能在五分钟内独立完成这个闭环，中阶阶段的探针、配置、发布回滚，都会自然地从这条主干上生长出来。