Kubernetes 基础概念：Pod、Service 与 Deployment

FreeGuideOnline 最新 2026-06-13

Kubernetes 基础概念：Pod、Service 与 Deployment

Kubernetes（K8s）是当今云原生时代最主流的容器编排平台。但面对集群、节点、容器等众多抽象，初学者往往不知从何入手。实际上，只要抓住三个核心概念 —— Pod、Service 与 Deployment，你就迈出了理解 Kubernetes 最关键的一步。本教程将用通俗的语言、直观的类比，帮你彻底弄懂这三者是什么、为什么需要它们以及它们是如何协作的。

Pod：最小的部署单元

什么是 Pod？

在 Kubernetes 中，你永远不会直接运行一个容器，而是将容器封装在 Pod 中。Pod 是 Kubernetes 创建、调度、管理的最小单元，可以理解为一个“逻辑主机”——它可能包含一个或多个紧密耦合的容器，这些容器共享相同的网络命名空间、IPC 命名空间，甚至可以共享存储卷。

  • 单容器 Pod：最常见的模式，一个 Pod 里只跑一个应用容器。
  • 多容器 Pod：适用于需要紧密协作的场景，例如主应用容器旁有一个辅助容器（Sidecar）负责日志收集、配置更新或代理转发。

为什么要有 Pod？

你可能会问：“为什么不直接管理容器？”这是因为 Pod 提供了一种比容器更高级的抽象，解决了：

  1. 亲密关系的封装：当多个容器必须共享网络（通过 localhost 通信）、共享存储或共享生命周期时，Pod 自然地把它们绑在一起。
  2. 可调度单位的统一：所有容器在同一个 Pod 里，调度器只需为 Pod 寻找一个合适的节点，保证它们运行在同一台机器上。
  3. 资源共享与隔离的平衡：Pod 内的容器拥有独立文件系统，但又能共享 Linux namespace，这种设计兼顾了隔离与协作。

Pod 的生命周期与限制

Pod 是临时性的。节点宕机、资源不足或者滚动更新时，Pod 都可能被终止并在其他节点重新创建。因此，永远不要在 Pod 消失后还期望其 IP 地址或本地存储的数据不会丢失。如果应用需要持久化，你应当使用 PersistentVolume 声明持久存储；如果需要固定访问端点，则必须借助 Service。

一个简单的 Pod 示例（YAML）：

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

你可以用 kubectl apply -f pod.yaml 创建它，但极少有人直接这样使用——因为没有自愈和副本能力。于是 Deployment 登场了。

Deployment：声明式副本管理

什么是 Deployment？

Deployment（部署）是 Kubernetes 中管理无状态应用的推荐方式。它允许你通过声明式配置描述应用的期望状态：运行多少个副本（Pod）、使用哪个容器镜像、如何更新等；Kubernetes 的控制循环会持续驱动当前状态向期望状态对齐。

简单说，你只需告诉 Deployment：“我需要 3 个运行 nginx:1.25 的 Pod 副本。”接下来，Kubernetes 会负责创建、调度、监控这些 Pod，并在某副本异常时自动替换。

Deployment 解决了什么痛点？

如果直接操作 Pod，你需要面对：

  • 副本保持：手动创建的 Pod 一旦死亡，不会自动重启。
  • 滚动更新：若想升级镜像版本，手动挨个删除 Pod 再创建，停机风险高。
  • 回滚：新版本出问题时，无法快速回到上一个稳定版本。

Deployment 利用底层的 ReplicaSet 控制器，提供了自动副本保持、声明式滚动更新、版本记录与回滚等能力。它遵循“不可变基础设施”的理念：更新时不修改现有 Pod，而是创建新 Pod，待新 Pod 就绪后再淘汰旧 Pod，从而实现零停机发布。

Deployment 的典型配置

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3                       # 期望的副本数
  selector:
    matchLabels:
      app: nginx                    # 选择器，管理带此标签的 Pod
  template:                         # Pod 模板
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
  • selector.matchLabels 定义了 Deployment 如何找到它管理的 Pod。Pod 模板必须包含匹配的标签。
  • 当修改 replicas 或 image 字段后应用，Kubernetes 会逐步完成配置更新。
  • 查看部署状态与历史：kubectl rollout status deployment/nginx-deployment、kubectl rollout history deployment/nginx-deployment。
  • 快速回滚：kubectl rollout undo deployment/nginx-deployment --to-revision=1。

注意：Deployment 擅长管理无状态、可任意替换的 Pod。如果你的应用需要有状态且拥有稳定标识（如数据库），应使用 StatefulSet，但那是后话了。

此时，你拥有了多个可自我修复的 Pod，但它们的 IP 地址是动态变化的，外部用户该如何访问？Service 就是来解决这个问题的。

Service：稳定的网络抽象

什么是 Service？

Kubernetes 中的 Service（服务）定义了一组 Pod 的逻辑集合以及访问它们的策略。Pod 会因重启、故障、扩缩容而产生动态 IP，Service 则提供一个**固定不变的虚拟 IP（ClusterIP）**和 DNS 名称，将请求负载均衡到后端健康的 Pod 上。

你可以把 Service 想象成一个基于标签的选择器：它说“将所有带有 app: nginx 标签的 Pod 纳入我的后端池”，然后持续监控这些 Pod 的 IP 和端口变化，自动更新转发规则。

Service 类型

根据暴露方式，Service 有四种常见类型：

  • ClusterIP（默认）：仅集群内部可访问，用于服务间通信。这是最安全、最推荐的内网调用方式。
  • NodePort：在每个节点上开一个静态端口（30000–32767），将请求转发到 Service。可用于外部测试，但不建议生产直接使用，因为端口管理混乱。
  • LoadBalancer：对接云厂商的负载均衡器（如 AWS ELB、阿里云 SLB），创建一个外部 IP 供公网访问，适合生产级对外服务。
  • ExternalName：通过返回 CNAME 记录将服务映射到 DNS 名称，用于将外部服务引入集群内部。

Service 如何与 Deployment 配合？

Service 通过 标签选择器 关联 Pod，而 Pod 的标签正由 Deployment 的 Pod 模板定义。这样一来，Deployment 负责 Pod 的生命周期，Service 负责网络入口，两者解耦且灵活。

一个 ClusterIP Service 示例：

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx       # 与 Deployment 中 Pod 的标签一致
  ports:
  - protocol: TCP
    port: 80         # Service 自身的端口
    targetPort: 80   # 后端 Pod 的容器端口

创建后，集群内的任何应用都可以通过 nginx-service 或 nginx-service.<namespace>.svc.cluster.local 来访问我们的 Nginx，无论 Pod IP 如何变化。

三者的协作全景图

现在让我们把 Pod、Deployment 和 Service 串联成一个完整的示例：

  1. Deployment 确保始终有 3 个 nginx:1.25 的 Pod 实例运行。
    • Pod 由 Deployment 自动创建，带有标签 app: nginx。
    • Pod 的容器暴露 80 端口。
  2. Service 通过 selector: app: nginx 发现这些 Pod。
    • 提供稳定的 ClusterIP（如 10.96.0.1）和服务名 nginx-service。
  3. 另一个应用可以通过 nginx-service（DNS自动解析）访问 Nginx，请求被负载均衡到任一 Pod。

如果你想进行滚动升级，只需更新 Deployment 的 image 字段：

  • 新的 Pod 按比例创建就绪，Service 自动包含新 Pod 并移除旧 Pod，升级过程服务不中断。
  • 一旦出现问题，可以立即回滚到旧版本。

实践建议与常见陷阱

  • 直接创建 Pod 要三思：几乎在所有的生产场景中，都应该使用更高级别的控制器（Deployment、Job、StatefulSet 等）来创建 Pod，因为它们能提供自愈、更新和副本管理。
  • Selector 必须唯一匹配：Service 和 Deployment 的标签选择器要精心设计，避免多个 Service 意外选中同一组 Pod，或者新 Deployment 匹配到旧 Pod 导致流量混乱。
  • 健康检查不可少：在 Deployment 的 Pod 模板中定义 livenessProbe 和 readinessProbe，让 Service 只将流量分发给真正就绪的 Pod，并帮助 kubelet 自动重启不健康的容器。
  • 用 Headless Service 访问特定 Pod：当你需要直接定位到每个 Pod（如 StatefulSet 中的数据库主从）时，设置 clusterIP: None 可创建 Headless Service，配合 StatefulSet 为每个 Pod 提供稳定的 DNS 记录。

总结

概念 解决的问题 关键特性
Pod 容器的运行与协作单元 最小调度单元、共享网络/存储、临时性
Deployment 无状态应用的副本管理、滚动更新、回滚 声明式副本保持、版本记录、免停机更新
Service Pod 动态 IP 带来的网络访问难题 固定虚拟 IP、基于标签的服务发现、负载均衡

理解这三者，你就已经抓住了 Kubernetes 核心运作逻辑的纲。在此基础上，你再去学习 ConfigMap、Secret、Ingress、Volume 等高级对象，会变得轻松自然。

接下来，你可以创建自己的测试集群（使用 Minikube、Kind 或 K3s），动手部署一个简单的微服务，感受 Pod 被重建时 Service 如何保持稳定访问，亲眼见证 Deployment 滚动更新的魅力。边写 YAML，边体悟 Kubernetes 声明式哲学的优雅。