Kubernetes 入门：从零理解 Pod 与 Deployment

很多刚接触 Kubernetes（常简称 K8s）的同学都会被一堆概念劝退：Pod、Deployment、ReplicaSet、Service……其实只要抓住**「Pod 是最小调度单元，Deployment 负责声明期望状态」**这条主线，剩下的都是围绕它打补丁。

为什么需要 Pod

容器（Container）是单个进程的隔离环境，但现实中的应用在启动前往往需要做初始化、共享存储卷、或者两个容器需要「同生共死」。Pod 就是把这些紧密耦合的容器打包在一起的最小调度单元——同一个 Pod 内的容器共享网络命名空间和存储卷。

一句话：Pod ≈ 一组必须在一起的容器；K8s 永远只调度 Pod，而不是直接调度容器。

用 Deployment 描述期望状态

直接创建 Pod 是不够的：Pod 挂了不会自动拉起。我们需要 Deployment 来声明「我期望始终有 3 个 nginx 副本在线」。

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

提交后，控制平面会创建 ReplicaSet，再由它创建出 3 个 Pod。你只需要关心 YAML 里写的「期望」，其余的「如何达成」交给 K8s。

滚动更新时发生了什么

当你把镜像改为 nginx:1.28 并重新 kubectl apply，Deployment 会：

新建一个 ReplicaSet，逐步扩容新版本 Pod；
同时逐步缩容旧版本 ReplicaSet；
通过 maxSurge / maxUnavailable 控制每次上/下线数量，保证服务不中断。

# 查看滚动更新进度
kubectl rollout status deployment/nginx

# 发现异常，一键回滚到上一个版本
kubectl rollout undo deployment/nginx

小贴士：把 maxSurge 与 maxUnavailable 调小，可以让更新过程更平稳，适合对可用性极度敏感的核心服务。

小结

Pod 是调度与资源共享的最小单元；
Deployment 通过声明「期望副本数」实现自愈与滚动更新；
回滚、扩缩容都只是修改「期望状态」，K8s 负责对齐现实。

下一篇我们会聊聊如何用 Service 与 Ingress 把这些 Pod 暴露到集群外部。