📚 课程目录第3章资源模型基础

3. 资源模型基础：Kubernetes原生资源模型回顾

在进入多集群资源迁移之前，必须对单集群下的核心资源模型建立统一认知。Kubernetes 的资源模型围绕“声明式状态管理”设计，所有工作负载、网络、存储与配置均通过 API 对象表达。本章聚焦于四个最基础的资源类型：Pod、Deployment、Service 与 ConfigMap，它们构成了多集群迁移中最频繁操作的对象集合。

3.1 资源模型层次结构

Kubernetes 资源模型可抽象为三层：基础设施层（节点、网络、存储）、工作负载层（Pod、控制器）与服务与配置层（Service、ConfigMap、Secret）。多集群迁移的核心挑战在于保持这三层之间的依赖关系不变。

  关键认知： 资源模型迁移不是简单的 YAML 复制，而是将资源间的标签选择器、引用关系与命名空间边界整体搬迁到目标集群。

3.2 Pod：最小调度单元

Pod 是 Kubernetes 中可创建和管理的最小部署单元，一个 Pod 包含一个或多个共享网络栈与存储卷的容器。在多集群迁移中，Pod 的临时性决定了我们通常不直接迁移 Pod 对象，而是迁移其控制器（如 Deployment）。

Pod 属性	说明	迁移关注点
containers	容器镜像、命令、端口、资源限制	镜像仓库地址需跨集群可达
volumes	emptyDir、hostPath、PVC 挂载	持久卷需提前在目标集群创建
nodeSelector / affinity	节点选择与亲和性规则	目标集群节点标签需对齐
tolerations	容忍污点调度	目标集群污点策略可能不同
restartPolicy	Always / OnFailure / Never	通常保持默认 Always

迁移最佳实践： 不要直接迁移 Pod 对象。始终通过 Deployment、StatefulSet 等控制器管理 Pod，迁移时只迁移控制器 YAML，让目标集群重新创建 Pod。

3.3 Deployment：声明式更新引擎

Deployment 是 Kubernetes 中最常用的工作负载控制器，提供声明式更新、滚动升级与回滚能力。其核心机制是 ReplicaSet 的版本化管理。

Deployment 的 YAML 结构包含三个关键部分：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  namespace: production
  labels:
    app: web
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 500m
            memory: 256Mi
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

迁移陷阱： Deployment 的 spec.selector.matchLabels 在创建后不可修改。跨集群迁移时，如果目标集群已存在同名 Deployment，必须确保标签选择器一致，否则更新会失败。

3.4 Service：服务发现与负载均衡

Service 为 Pod 提供稳定的网络端点，屏蔽 Pod IP 的动态变化。多集群场景下，Service 的 ClusterIP 在不同集群中不保证一致，这是迁移中需要重点处理的网络差异。

Service 的四种类型对比：

类型	访问范围	实现方式	迁移注意事项
ClusterIP	集群内部	kube-proxy iptables/IPVS	ClusterIP 会变，依赖 DNS 名称
NodePort	集群外部（节点端口）	每个节点开放固定端口	端口号需在目标集群可用
LoadBalancer	外部负载均衡器	云厂商 LB 或 MetalLB	LB 地址会变，需更新 DNS
ExternalName	CNAME 映射	DNS 层转发	目标集群 DNS 解析需可达

3.5 ConfigMap：配置解耦

ConfigMap 用于将配置数据与容器镜像解耦，支持以环境变量、命令行参数或卷挂载的方式注入 Pod。在多集群迁移中，ConfigMap 的数据内容通常保持不变，但引用路径可能需要调整。

ConfigMap 的三种使用方式：

环境变量注入： 通过 envFrom 或 valueFrom.configMapKeyRef 将配置项映射为容器环境变量。
卷挂载： 将 ConfigMap 挂载为 Pod 内的文件系统路径，适合配置文件场景。
命令行参数： 结合环境变量或 $(VAR_NAME) 语法动态生成启动参数。

# ConfigMap 定义
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: production
data:
  app.properties: |
    db.host=mysql-service
    db.port=3306
    cache.ttl=300
  log.level: INFO

# Pod 中通过卷挂载引用
spec:
  containers:
  - name: app
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: app-config

  迁移策略： ConfigMap 通常可以直接复制到目标集群，但需注意：

  • 目标集群的命名空间必须与源集群一致，或提前创建映射关系。

  • 如果 ConfigMap 中包含了集群特定的地址（如 Service 名称），需在迁移后验证。

  • 使用 kubectl get configmap <name> -o yaml --export 导出时，需清理 resourceVersion、uid 等元数据。

3.6 资源模型迁移要点总结

资源类型	迁移方式	依赖关系	常见风险
Pod	不直接迁移，通过控制器重建	依赖 ConfigMap、Secret、PVC	镜像拉取失败、资源限制不匹配
Deployment	导出 YAML → 清理元数据 → 导入	依赖 ConfigMap、Service 名称	selector 不可变、副本数超限
Service	导出 YAML → 清理 ClusterIP → 导入	依赖 Pod 标签选择器	ClusterIP 冲突、NodePort 被占用
ConfigMap	直接复制，注意命名空间	被 Deployment/Pod 引用	数据内容包含硬编码地址

迁移顺序建议： 先迁移 ConfigMap 和 Secret（配置依赖），再迁移 Service（网络依赖），最后迁移 Deployment 等工作负载控制器。这个顺序可以最大程度减少 Pod 启动时的依赖缺失错误。