📚 课程目录第2章 K8s核心概念回顾

2. K8s 核心概念回顾：Pod、Service、Deployment、Namespace 的作用与边界定义的关系

在深入业务模块边界拆分之前，必须重新理解 Kubernetes 的四个核心原语：Pod、Service、Deployment 和 Namespace。它们不仅是调度单元，更是定义模块边界、通信边界和运维边界的基石。

2.1 四原语的核心职责

原语	核心职责	与边界定义的关系
Pod	最小调度单元，封装一个或多个容器（共享网络栈、存储卷）	模块内聚边界：一个 Pod 内的容器应属于同一业务模块，不应跨模块
Service	提供稳定的网络端点（ClusterIP/NodePort/LB），实现 Pod 的负载均衡与发现	模块通信边界：每个模块对外暴露的唯一入口，隐藏后端 Pod 的变动
Deployment	声明式管理 Pod 的副本数、滚动更新、回滚	模块运维边界：定义模块的扩缩容策略、更新节奏和故障恢复行为
Namespace	逻辑隔离资源对象，提供多租户环境	模块环境边界：按环境（dev/staging/prod）或团队隔离资源，防止命名冲突

边界定义原则： 一个业务模块通常由一个 Deployment 管理一组同质 Pod，由一个 Service 暴露该模块的访问入口，并部署在独立的 Namespace 中。跨模块通信必须通过 Service 进行，禁止直接访问 Pod IP。

2.2 四原语的协作关系

下图展示了四个原语如何共同定义业务模块的边界：

2.3 边界定义的核心规则

2.3.1 内聚边界：Pod 内的容器组合

共享网络栈：Pod 内所有容器共享同一个 IP 和端口空间，通过 localhost 通信。
共享存储卷：Pod 内容器可以挂载相同的 Volume，实现数据交换。
边界约束：只有属于同一业务模块的容器才应放入同一个 Pod。例如：主业务容器 + 日志采集 sidecar + 监控指标 sidecar。

反模式示例： 将订单服务容器和支付服务容器放入同一个 Pod。这会导致两个模块耦合，无法独立扩缩容和更新，违背微服务拆分原则。

2.3.2 通信边界：Service 的抽象层

稳定端点：Service 提供固定的 ClusterIP 和 DNS 名称（如 service-a.ns-a.svc.cluster.local），屏蔽后端 Pod 的 IP 变化。
负载均衡：Service 将请求分发到匹配的 Pod 集合，支持 Session Affinity。
边界约束：模块 A 访问模块 B 必须通过模块 B 的 Service，禁止直接访问 Pod IP。这保证了模块 B 的 Pod 扩缩容、重启对调用方透明。

# 正确的跨模块调用方式
apiVersion: v1
kind: Service
metadata:
  name: payment-service
  namespace: production
spec:
  selector:
    app: payment
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
---
# 模块 A 通过 Service DNS 调用模块 B
# 调用地址：http://payment-service.production.svc.cluster.local:8080/api/pay

2.3.3 运维边界：Deployment 的声明式管理

扩缩容：通过 replicas 字段定义模块的实例数，支持 HPA 自动扩缩。
滚动更新：通过 strategy.rollingUpdate 控制更新速率和最大不可用 Pod 数。
回滚：保留历史版本，支持快速回退到上一版本。
边界约束：每个业务模块对应一个独立的 Deployment。不同模块的 Deployment 不应共享同一个 Pod 模板。

2.3.4 环境边界：Namespace 的逻辑隔离

资源隔离：不同 Namespace 中的资源可以同名，互不干扰。
网络策略：结合 NetworkPolicy 实现 Namespace 级别的网络访问控制。
配额管理：通过 ResourceQuota 限制每个 Namespace 的 CPU、内存、存储总量。
边界约束：建议按环境（dev/staging/prod）或按团队划分 Namespace。同一业务模块的不同环境应部署在不同 Namespace 中。

2.4 边界定义的最佳实践

维度	推荐做法	常见错误
Pod 内聚	一个 Pod 只包含一个主业务容器 + 必要的 sidecar	将多个业务容器放入同一个 Pod
Service 通信	每个模块一个 Service，使用 DNS 名称调用	直接使用 Pod IP 或硬编码 IP 地址
Deployment 管理	每个模块一个 Deployment，独立配置资源请求/限制	多个模块共享同一个 Deployment
Namespace 隔离	按环境或团队划分，配合 NetworkPolicy 和 ResourceQuota	所有资源放在 default Namespace 中

关键提醒： 边界定义不是一次性的。随着业务演进，模块边界可能发生变化。例如，当发现两个模块频繁通信且生命周期高度耦合时，应考虑合并为一个模块；反之，当模块内部出现多个独立演进的功能时，应考虑拆分为更细粒度的模块。

2.5 边界定义与配置管理的关系

清晰的边界定义是配置管理优化的前提：

Pod 边界决定了 ConfigMap 和 Secret 的作用范围——每个 Pod 只挂载与其模块相关的配置。
Service 边界决定了服务发现的配置方式——通过 DNS 名称而非 IP 地址。
Deployment 边界决定了配置更新的策略——滚动更新时配置的版本管理。
Namespace 边界决定了配置的隔离级别——不同环境的配置独立管理。