很多开发者第一次接触 Kubernetes 时，常把 Deployment 当作“部署命令”，把 Service 当作“负载均衡器”。但如果你只停留在这种工具层面的理解，就很容易在生产环境中踩坑：Pod 启动了却收不到流量、滚动更新导致服务中断、配置硬编码无法动态调整……

Kubernetes 的核心不是命令，而是“声明式 API”——你描述“期望状态”，系统自动达成并维持它。

本文将带你深入理解 K8s 最核心的五大对象：Pod、Deployment、Service、ConfigMap/Secret 和探针机制，并通过一张清晰的流量拓扑图，揭示它们如何协同工作，让应用真正“活”在集群中。

---

一、Pod：共享网络与存储的最小调度单元

Pod 是 Kubernetes 调度的最小单位，不是容器。

一个 Pod 可包含一个或多个容器，这些容器：

• 共享 同一个网络命名空间（即 localhost 可互通）；
• 共享 存储卷（Volumes）；
• 具有相同的生命周期。

例如，主应用容器 + 日志收集 sidecar 容器，可放在同一个 Pod 中：

spec:
  containers:
    - name: app
      image: my-go-app
    - name: log-collector
      image: fluentd
      volumeMounts:
        - name: logs
          mountPath: /var/log/app
  volumes:
    - name: logs
      emptyDir: {}

⚠️ 注意：除非有强耦合需求（如日志收集、网络代理），否则一个 Pod 只应运行一个主业务容器。

---

二、Deployment：副本管理与滚动更新

Pod 本身是“一次性”的，一旦被删除就不会自动恢复。Deployment 才是管理无状态应用的核心控制器。

它通过 ReplicaSet 确保指定数量的 Pod 副本始终运行，并支持滚动更新（Rolling Update）：

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1   # 更新时最多不可用1个
      maxSurge: 1         # 最多超配1个
  template:
    spec:
      containers:
        - name: app
          image: my-app:v2

关键优势：

• 自动重建故障 Pod；
• 零停机更新（配合 readiness 探针）；
• 支持一键回滚：kubectl rollout undo deployment/my-app

---

三、Service：ClusterIP 实现服务发现

当 Pod 被重建，其 IP 会变化。如何让其他服务稳定访问它？答案是 Service。

K8s Service 通过 ClusterIP 提供稳定的虚拟 IP 和 DNS 名称：

apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service   # 匹配带此标签的 Pod
  ports:
    - port: 80
      targetPort: 8080

其他服务可通过 http://user-service 访问，无需关心后端 Pod IP。

与 Consul 对比

能力	K8s Service	Consul
服务注册	自动（基于 Pod 标签）	需 Agent 或 API 注册
服务发现	DNS + iptables/IPVS	DNS + HTTP API
健康检查	依赖 K8s 探针	内置 TCP/HTTP/TTL 检查
多集群/混合云	需额外方案（如 Istio）	原生支持

K8s Service 提供了基础服务发现能力，但复杂治理（如熔断、限流、重试）仍需在应用层实现，（详见《微服务》【容错篇】）。

---

四、ConfigMap 与 Secret：配置外置的最佳实践

永远不要把配置写死在镜像里！

• ConfigMap：存储非敏感配置（如数据库地址、日志级别）；
• Secret：存储敏感信息（如密码、API 密钥），Base64 编码（注意：不是加密）。

使用方式：

# 挂载为文件
volumeMounts:
  - name: config-volume
    mountPath: /etc/config
volumes:
  - name: config-volume
    configMap:
      name: app-config

# 或注入为环境变量
env:
  - name: DB_HOST
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: db_host

优势：

• 配置变更无需重新构建镜像；
• 不同环境（dev/staging/prod）只需切换 ConfigMap；
• 符合 12-Factor App 的“配置外置”原则。

---

五、探针：liveness vs readiness，别再搞混！

这是生产环境中最容易被忽视、却最关键的机制。

readinessProbe（就绪探针）

• 作用：判断 Pod 是否准备好接收流量；
• 未就绪时：从 Service 的 Endpoints 中剔除，不转发请求；
• 典型场景：应用启动需加载缓存、连接数据库。

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5

livenessProbe（存活探针）

• 作用：判断应用是否“卡死”；
• 失败时：K8s 会重启 Pod；
• 慎用：错误配置会导致频繁重启（如探针路径返回 5xx）。

✅ 最佳实践：

• /healthz 用于 readiness（检查依赖服务是否连通）；
• /livez 用于 liveness（仅检查进程是否响应）。

---

六、流量拓扑：从 Service 到 Pod 的完整链路

以下图展示了请求如何从 Service 流向具体 Pod：

流程说明：

1. Client 通过 user-service DNS 解析到 ClusterIP；
2. K8s kube-proxy 将流量通过 iptables/IPVS 转发到后端 Pod；
3. 只有通过 readinessProbe 的 Pod 才会被加入 Endpoints；
4. 流量最终到达某个 Pod 的容器端口。

---

结语：理解对象关系，才能驾驭 K8s

Kubernetes 不是“部署工具”，而是一个声明式、自愈的分布式操作系统。
掌握 Pod、Deployment、Service、ConfigMap 和探针这五大核心对象，你就已经跨过了 80% 的入门门槛。