Shirone

先换脑子：声明式，不是命令式#

传统运维是命令式的：「启动 3 个容器」「这台挂了，重启它」。K8s 是声明式的：你只提交期望状态（“这个应用要有 3 个副本”），K8s 的控制循环持续观察实际状态，发现偏差就自动纠正——副本少了就补，节点挂了就迁。

你提交的每一份 YAML 都是一张「愿望清单」，而不是操作手册。这个模型是理解一切 K8s 行为的前提。

Pod：最小调度单位#

Pod 是一个或多个共享网络与存储的容器组，是 K8s 调度的最小单位。同一 Pod 内的容器共享 IP 和端口空间，通过 localhost 互访。

为什么不是直接调度容器？因为存在「主容器 + 紧密耦合的辅助容器」场景：比如应用容器写日志到共享目录，边车（sidecar）容器负责把日志转发出去——它们必须同生共死、共享存储，打包成一个 Pod 正合适。

实践中很少手写 Pod 定义，但要知道它的两个特性：IP 是临时的（Pod 重建就换）、Pod 是不可变的（想改配置？删掉重建）。

Deployment：让 Pod 保持「想要的样子」#

直接创建 Pod 是自虐：它挂了就挂了，没人管。Deployment 在 Pod 之上加了副本管理和更新策略：

1
apiVersion: apps/v1
2
kind: Deployment
3
metadata:
4
  name: web
5
spec:
6
  replicas: 3                     # 期望 3 个副本
7
  selector:
8
    matchLabels:
9
      app: web
10
  template:                       # Pod 模板
11
    metadata:
12
      labels:
13
        app: web
14
    spec:
15
      containers:
16
        - name: web
17
          image: registry.example.com/myapp:1.4.2
18
          ports:
19
            - containerPort: 8080
20
          resources:
21
            requests:
22
              cpu: 100m
23
              memory: 128Mi
24
            limits:
25
              cpu: 500m
26
              memory: 256Mi

1
kubectl apply -f deployment.yaml
2
kubectl get pods                  # 看到 3 个 web-xxx 的 Pod

滚动更新：改 image 版本后再 apply，Deployment 默认用 RollingUpdate 策略——先起一个新版本 Pod，健康了再灭一个旧的，如此滚动，全程服务不中断。

回滚：历史版本被自动记录，新版出问题时一键回到上一个：

1
kubectl rollout status deployment/web      # 观察更新进度
2
kubectl rollout undo deployment/web        # 回滚

自愈：手动 kubectl delete pod web-xxx 试试——Deployment 立刻补一个新 Pod 维持 replicas: 3。这就是声明式控制循环的直观体现。

Service：给会漂移的 Pod 一个稳定地址#

Pod IP 会变、副本会扩缩，客户端该连哪个地址？Service 用标签选择器圈定一组 Pod，提供一个稳定的虚拟 IP 和 DNS 名，并把流量转发过去。

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: web
5
spec:
6
  selector:
7
    app: web              # 选中所有带 app=web 标签的 Pod
8
  ports:
9
    - port: 80            # Service 自己的端口
10
      targetPort: 8080    # 转发到 Pod 的端口

集群内其他应用现在可以通过 http://web（同命名空间下）访问你的服务——不用关心后面是 3 个还是 30 个 Pod、IP 换了几次。

Service 的三种常用类型：

对外提供 HTTP 服务时，更常见的组合是 Service + Ingress（统一域名、路径路由和 TLS 终结），Ingress 可以认为是「HTTP 层的 Service」。

三者关系一图流#

1
                 管理副本与更新
2
   Deployment ──────────────────► Pod × 3（标签 app=web）
3
                                      ▲
4
                                      │ 标签选择器
5
   Service ───────────────────────────┘
6
   （稳定 IP/DNS，负载均衡转发）

客户端访问 Service 的固定地址；Service 按标签把请求分发给当前存活的 Pod；Deployment 保证 Pod 的数量和版本符合期望。三层各司其职，任何一层都不需要知道其他层的实现细节。

动手前的建议#

本地学习用 minikube 或 kind（Kubernetes in Docker）起单节点集群；云厂商的托管 K8s（ACK、TKE、EKS）省掉控制面运维，适合生产起步。学会 kubectl get/describe/logs/apply 四件套，就足以完成日常 80% 的操作——describe 尤其重要，任何对象「不正常」，先看它末尾的 Events。

延伸阅读#

• Kubernetes 官方文档：Workloads
• Kubernetes 官方文档：Service
• Kubernetes 官方文档：kubectl 快速参考