Kubernetes 入门：Pod、Deployment 与 Service 核心概念

Kubernetes（简称 K8s）是目前最主流的容器编排平台，它把容器的部署、扩缩容、滚动更新和故障自愈等工作自动化，让开发者不必再逐台机器手工管理容器。刚接触 Kubernetes 的新手常常被大量概念淹没，其实入门只需要先抓住三个核心对象：Pod、Deployment 与 Service。理解了它们各自的职责以及彼此之间的配合关系，就等于拿到了 Kubernetes 的地图，其余概念大多是在这张地图上的延伸。

一、Pod：最小的调度单元

Pod 是 Kubernetes 中最小的可部署单元，也是调度的基本单位。一个 Pod 可以包含一个或多个容器，这些容器共享同一个网络命名空间和存储卷，总是被一起调度到同一台节点上，并且一起启动、一起停止。初学者最容易犯的错误是把 Pod 等同于容器：实际上 Pod 是容器的“外壳”，容器是 Pod 里真正运行的进程。

大多数场景下一个 Pod 只放一个主容器，需要辅助能力的场合才会放多个容器，例如主容器负责业务逻辑，边车容器负责收集日志或代理流量。Pod 本身是短暂的，节点故障或资源驱逐都会让 Pod 消失，所以不要把重要数据只写在 Pod 内部，数据持久化要交给存储卷。

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80

二、Deployment：声明式管理无状态应用

直接创建 Pod 虽然简单，但 Pod 挂了不会自动重建，扩容和升级也要手工操作，生产环境几乎不会这样用。Deployment 是面向无状态应用的控制器，它通过 ReplicaSet 来保证指定数量的 Pod 副本一直处于运行状态。

使用 Deployment 时只需声明期望状态，例如“运行 3 个副本，使用 nginx:1.25 镜像”，控制器就会不断把实际状态向期望状态收敛。副本少了自动补齐，节点故障导致 Pod 丢失也会自动在其他节点重建。升级时修改镜像版本即可触发滚动更新：新版本 Pod 逐个启动并替换旧版本，服务不中断；一旦新版本有问题，还可以用回滚命令快速回到上一个版本。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-deploy
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: nginx
        image: nginx:1.25

三、Service：稳定的访问入口

Pod 的 IP 地址是临时分配的，重启或重建后就会变化，客户端不可能直接依赖它。Service 为一组 Pod 提供一个稳定不变的访问入口，它通过标签选择器找到后端 Pod，并把流量负载均衡到这些 Pod 上。

常见的 Service 类型有三种：ClusterIP 只在集群内部可访问，适合内部服务之间的调用；NodePort 把服务暴露到每个节点的固定端口，方便测试访问；LoadBalancer 则在云环境中自动创建负载均衡器，对外提供公网入口。理解 Service 的关键是分清“访问入口”和“后端 Pod”是分离的：入口稳定不变，后端 Pod 可以随时增减替换。

apiVersion: v1
kind: Service
metadata:
  name: demo-svc
spec:
  type: ClusterIP
  selector:
    app: demo
  ports:
  - port: 80
    targetPort: 80

四、三者如何协同工作

三者的配合关系可以用一条链来概括：Deployment 创建并管理 ReplicaSet，ReplicaSet 创建并维持 Pod，Service 通过标签选择器发现 Pod 并提供稳定的访问入口。用户访问 Service，Service 把请求转发给某个健康的 Pod，Pod 的数量和版本则由 Deployment 控制。

这条链路的好处在于各司其职：Pod 只负责运行容器，Deployment 只负责副本数量和版本变更，Service 只负责发现和负载均衡。排查问题时也可以沿着这条链反向检查：服务不通先看 Service 的选择器是否匹配到 Pod，再看 Pod 是否正常运行，最后看 Deployment 的配置是否正确。

五、常用命令与排查思路

掌握几个 kubectl 命令就能完成大部分日常操作：kubectl get pods -o wide 查看 Pod 状态与所在节点，kubectl describe pod 查看事件和异常原因，kubectl logs 查看容器日志，kubectl get svc 查看服务地址与端口，kubectl apply -f deploy.yaml 应用配置，kubectl rollout undo 回滚版本。

Pod 出现 CrashLoopBackOff 通常是容器启动失败，先查日志再看镜像和启动命令；Pod 长时间处于 Pending 多半是资源不足或节点选择器不匹配；Service 访问不通则重点检查选择器标签、目标端口和 Pod 的就绪状态。养成“先看状态、再看事件、最后看日志”的顺序，能少走很多弯路。

六、新手常见误区

第一，不要直接操作 Pod 做生产部署，凡是需要副本、升级和自愈的场景都应使用 Deployment。第二，标签是 Service 发现 Pod 的唯一依据，Deployment 模板里的标签必须与 Service 选择器一致，拼写差一个字符都会导致服务找不到后端。第三，滚动更新不是万能的，镜像版本号写成 latest 会导致各节点实际版本不一致，生产环境应使用明确的版本号。

结语

Pod 解决“容器怎么跑”，Deployment 解决“跑几个、怎么升级”，Service 解决“别人怎么找到它”。掌握这三个概念之后，再去学习 ConfigMap、Secret、Ingress、持久卷等对象，就会发现它们都是在这套模型上的自然补充。建议新手在本地 Minikube 或华为云 CCE 集群上亲手部署一次示例应用，观察 Deployment 扩容与 Service 转发的变化，概念会在实践中迅速变得清晰。