3. K8s核心概念回顾：Pod、Service、Deployment、Namespace与资源隔离

在深入业务模块边界设计之前，必须对Kubernetes的四个核心抽象——Pod、Service、Deployment、Namespace——建立精确的认知。它们是承载业务逻辑、暴露服务、管理副本和实现多租户隔离的基石。本节将逐一拆解其定义、职责与交互关系，并重点分析资源隔离的实现机制。

3.1 核心概念速览

3.2 Pod：业务进程的原子载体

Pod是Kubernetes中可创建和管理的最小部署单元。一个Pod封装一个或多个容器、存储资源、唯一的网络IP以及容器运行选项。在业务模块边界设计中，Pod代表一个不可分割的业务进程实例。

• 单容器Pod：最常见的模式，一个Pod只运行一个业务容器，边界清晰，易于调试。
• 多容器Pod：用于“边车（Sidecar）”模式，例如日志采集、代理、配置同步等辅助容器与主业务容器共享生命周期。
• Pod的IP是短暂的：Pod重建后IP会变化，因此不能直接依赖Pod IP进行服务发现。

3.3 Service：稳定的访问抽象层

Service为一组功能相同的Pod提供稳定的虚拟IP（ClusterIP）和DNS名称，并负责将请求负载均衡到后端的Pod实例。它是业务模块对外暴露的契约接口。

• ClusterIP：默认类型，仅在集群内部可访问。
• NodePort：在每个节点上开放一个静态端口，外部流量可通过节点IP+端口访问。
• LoadBalancer：云厂商提供的负载均衡器，将外部流量导入Service。
• Headless Service：不分配ClusterIP，直接返回后端Pod IP列表，用于有状态应用。

3.4 Deployment：声明式的副本管理

Deployment负责管理Pod的期望状态，包括副本数量、更新策略、回滚版本等。它通过ReplicaSet来创建和销毁Pod，确保集群中始终运行指定数量的Pod副本。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
  namespace: business
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order
  template:
    metadata:
      labels:
        app: order
    spec:
      containers:
      - name: order-container
        image: registry/order-service:v2.1
        ports:
        - containerPort: 8080
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

• 滚动更新：逐步替换旧Pod，保证服务不中断。
• 回滚：通过 kubectl rollout undo 快速恢复到上一个稳定版本。
• 扩缩容：修改 replicas 字段即可实现水平扩展。

3.5 Namespace：多租户与资源隔离的边界

Namespace是Kubernetes实现逻辑隔离的核心机制。它将集群内的资源划分为多个虚拟集群，每个Namespace内的资源名称必须唯一，但不同Namespace之间可以重名。

在业务模块边界设计中，Namespace通常用于以下场景：

• 环境隔离：dev、test、prod 各占一个Namespace。
• 业务领域隔离：订单域、支付域、用户域分别部署在不同的Namespace。
• 租户隔离：SaaS场景下，每个租户拥有独立的Namespace。

3.6 资源隔离机制详解

Namespace级别的资源隔离通过以下三种机制实现：

3.7 四者协作关系：一个完整的业务模块部署

下图展示了Namespace、Deployment、Service和Pod如何协同工作，构成一个完整的业务模块。

3.8 资源隔离的边界设计原则

基于上述核心概念，在业务模块边界设计中应遵循以下原则：

1. 一个Namespace一个业务域：将紧密相关的微服务（如订单、支付、库存）放入同一个Namespace，便于统一管理资源配额和网络策略。
2. 一个Deployment一个模块版本：每个业务模块（如订单服务）对应一个Deployment，通过标签选择器与Service关联。
3. 一个Service一个访问入口：每个业务模块对外暴露一个Service，模块内部通信使用Service DNS，模块间通信跨Namespace。
4. Pod无状态优先：业务模块尽量设计为无状态，便于Deployment快速扩缩容和滚动更新。

3.9 常见设计误区