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

2. 资源模型基础：Kubernetes原生资源、自定义资源CRD与资源模型的抽象层次

在Multi-Cluster拓扑中迁移资源之前，必须透彻理解Kubernetes资源模型的本质。本章从原生资源出发，逐步深入到自定义资源（CRD）与抽象层次，为后续跨集群资源映射与适配奠定基础。

2.1 Kubernetes原生资源体系

Kubernetes将一切视为资源（Resource），并通过声明式API进行管理。核心原生资源按功能可分为以下几类：

资源类型	API组	核心作用	跨集群迁移关注点
Pod	core/v1	最小调度单元，承载容器	IP依赖、节点选择器、卷挂载路径
Deployment	apps/v1	声明式无状态应用管理	副本数、更新策略、亲和性规则
Service	core/v1	Pod网络抽象与负载均衡	ClusterIP变更、DNS解析、类型转换
ConfigMap	core/v1	非敏感配置数据注入	数据完整性、命名空间隔离
Secret	core/v1	敏感信息存储	加密策略、跨集群同步安全
Namespace	core/v1	资源隔离与配额管理	命名冲突、RBAC映射

迁移提示： Deployment和Service是跨集群迁移中最常涉及的原生资源。Deployment的replicas字段在迁移时可能需要根据目标集群容量调整；Service的clusterIP在目标集群会重新分配，依赖固定IP的应用需改用DNS名称。

2.2 自定义资源（CRD）与扩展机制

CRD（Custom Resource Definition）允许用户扩展Kubernetes API，定义业务专属资源类型。CRD是Multi-Cluster资源模型差异化的主要来源。

2.2.1 CRD的结构组成

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: applications.example.com
spec:
  group: example.com
  names:
    kind: Application
    plural: applications
    singular: application
    shortNames:
      - app
  scope: Namespaced
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                replicas:
                  type: integer
                image:
                  type: string
                configRef:
                  type: string

2.2.2 CRD在Multi-Cluster中的挑战

版本一致性： 不同集群可能安装不同版本的CRD定义，导致资源结构不兼容。
控制器依赖： CRD通常依赖特定Operator或控制器，目标集群必须部署相同控制器。
存储版本差异： CRD的storage: true版本在集群间可能不同，迁移时需进行版本转换。
校验规则： CRD的OpenAPI Schema校验规则在集群间可能不一致，导致资源拒绝写入。

常见陷阱： 直接复制CRD资源到目标集群时，如果目标集群缺少对应的CRD定义或控制器，资源会被API Server拒绝或成为“孤儿资源”。迁移前必须执行CRD依赖检查。

2.3 资源模型的抽象层次

Kubernetes资源模型并非扁平结构，而是具有清晰的抽象层次。理解这一层次是设计跨集群资源映射策略的前提。

核心观点： 抽象层次越高，资源对底层集群拓扑的依赖越弱，跨集群迁移的适配成本越低。

2.4 抽象层次与迁移适配策略

不同抽象层次的资源在跨集群迁移时，需要采取不同的适配策略：

抽象层次	迁移适配策略	典型工作量
基础设施层	目标集群需提前准备等效资源；PV需手动或通过存储迁移工具重建	高（依赖底层环境）
核心工作负载层	Deployment/Service可直接迁移，但需调整ClusterIP、NodeSelector等字段	中（字段映射与重写）
策略与治理层	需评估目标集群策略引擎兼容性；NetworkPolicy需适配CNI差异	中高（策略转换）
业务抽象层	CRD定义与控制器必须预先部署；资源实例需版本校验与转换	高（依赖生态一致性）

2.5 资源模型的标准化与抽象

为了降低Multi-Cluster迁移的复杂度，社区和业界提出了多种资源抽象方案：

Kubernetes原生抽象： 使用Helm Chart、Kustomize overlay管理环境差异，但本质仍是YAML模板化。
OAM（Open Application Model）： 将应用组件、运维特征与工作负载分离，实现应用定义与基础设施解耦。
Crossplane： 通过Composite Resource（XR）和Composition将多云资源抽象为统一声明式API。
KubeVela： 基于OAM实现的应用交付平台，支持多集群资源编排与策略绑定。

实践建议： 在规划Multi-Cluster资源迁移时，优先将业务资源抽象到第4层（CRD/Operator），并采用OAM或Crossplane等标准化框架。这能显著减少底层集群差异对上层业务的影响，使迁移适配工作从“逐个资源修改”转变为“策略模板调整”。

2.6 本章小结

Kubernetes资源模型从原生资源到CRD，再到标准化抽象框架，形成了清晰的层次结构。在Multi-Cluster拓扑中，资源迁移的适配成本与抽象层次成反比。掌握资源模型的抽象本质，是设计高效、可复用的跨集群资源迁移方案的基础。