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

4. 资源模型基础：Kubernetes 资源模型概述、自定义资源(CRD)设计原则、资源模型与备份的映射关系

4.1 Kubernetes 资源模型概述

Kubernetes 资源模型是集群内所有可管理对象的抽象描述。每个资源都通过 API Server 暴露，并遵循声明式 API 的设计范式。理解资源模型是设计灾备策略的前提——备份的本质是对资源对象的元数据与状态进行持久化复制。

4.1.1 核心资源分类

类别	典型资源	备份关注点
工作负载	Deployment, StatefulSet, DaemonSet, Job, CronJob	Pod 模板、副本数、更新策略、卷挂载
服务与网络	Service, Ingress, EndpointSlice, NetworkPolicy	ClusterIP、端口映射、DNS 记录、网络隔离规则
存储与配置	ConfigMap, Secret, PersistentVolumeClaim, StorageClass	敏感数据加密、存储类绑定、卷快照一致性
身份与策略	ServiceAccount, Role, RoleBinding, PodSecurityPolicy	RBAC 绑定关系、安全上下文、策略继承
集群基础设施	Node, Namespace, CustomResourceDefinition, APIService	CRD 定义、API 版本兼容、集群级资源隔离

4.1.2 资源对象的通用结构

所有 Kubernetes 资源都遵循相同的顶层结构，Velero 在备份时正是基于此结构进行序列化与反序列化：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: production
  labels:
    app: my-app
  annotations:
    backup.velero.io/backup-volumes: data-volume
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-app:1.0
        volumeMounts:
        - name: data-volume
          mountPath: /data
      volumes:
      - name: data-volume
        persistentVolumeClaim:
          claimName: my-pvc
status:
  replicas: 3
  readyReplicas: 3

备份要点：Velero 默认备份 metadata 和 spec 部分，status 通常不备份（因为恢复时会由控制器重新计算）。但 metadata.uid 和 metadata.resourceVersion 会被清除，以确保恢复后的对象不与现有对象冲突。

4.2 自定义资源(CRD)设计原则

CRD 是 Kubernetes 可扩展性的核心机制。在灾备场景中，CRD 的备份与恢复比内置资源更复杂，因为 CRD 本身（定义）和 CR（实例）是两种不同的资源，且 CRD 的版本管理、存储版本、转换策略直接影响备份的兼容性。

4.2.1 CRD 设计七原则

版本管理优先：始终使用 v1 作为存储版本，后续版本通过 conversion webhook 或 storageVersion 字段控制。备份时只备份存储版本，恢复时由 API Server 自动转换。
结构化 Schema：使用 openAPIV3Schema 定义完整的字段约束，避免使用 x-kubernetes-preserve-unknown-fields: true。结构化 Schema 确保 Velero 能正确解析字段依赖关系。
状态与规约分离：spec 只包含用户期望状态，status 由控制器维护。备份时只备份 spec，status 在恢复后由控制器重新计算。
避免引用外部 ID：CR 中不应硬编码集群内其他资源的 UID 或 ResourceVersion，应使用名称引用。跨集群恢复时，UID 会变化，名称引用更可靠。
Finalizer 设计：如果 CR 需要清理外部资源，使用 Finalizer 机制。Velero 在恢复时会保留 Finalizer，但需要确保控制器在恢复后能正常执行清理逻辑。
子资源隔离：将 /status 和 /scale 定义为子资源，避免备份时携带大量状态数据。Velero 默认不备份子资源。
依赖声明：在 CRD 的 annotations 或 spec 中声明依赖的其他资源类型（如 PVC、Service），帮助 Velero 构建正确的备份顺序。

4.2.2 CRD 版本兼容性矩阵

场景	存储版本	备份版本	恢复版本	兼容性风险
单版本 CRD	v1	v1	v1	无风险
多版本 CRD（无转换）	v1	v1	v1	低风险，需确保目标集群 CRD 定义一致
多版本 CRD（有 Webhook）	v1	v1	v1 或 v2	中风险，Webhook 在恢复时可能不可用
CRD 升级中	v1 → v2	v1	v2	高风险，需验证转换逻辑

CRD 备份陷阱：如果 CRD 定义本身被删除，其所有 CR 实例也会被级联删除。因此，备份策略必须确保 CRD 定义 和 CR 实例 同时备份，且恢复时先恢复 CRD 定义，再恢复 CR 实例。Velero 的 --include-cluster-resources 参数可以控制是否包含 CRD 定义。

4.3 资源模型与备份的映射关系

Velero 的备份引擎本质上是一个资源模型遍历器。它从 API Server 获取资源列表，按照资源间的依赖关系进行拓扑排序，然后序列化为 JSON 或 YAML 格式的备份文件。理解这个映射关系，可以帮助我们设计更高效的备份策略。

4.3.1 备份映射的三层模型

4.3.2 资源依赖关系与备份顺序

Velero 在备份时不会改变资源顺序（按 GVR 字母序），但在恢复时会根据依赖关系进行拓扑排序。以下是常见的资源依赖链：

依赖类型	父资源	子资源	备份策略
OwnerReference	Deployment	ReplicaSet → Pod	备份 Deployment 即可，子资源由控制器重建
卷依赖	PersistentVolumeClaim	Pod	先备份 PVC，再备份 Pod；恢复时先恢复 PVC
配置依赖	ConfigMap / Secret	Pod / Deployment	先备份 ConfigMap/Secret，再备份工作负载
网络依赖	Service	EndpointSlice / Ingress	先备份 Service，再备份 Ingress
CRD 依赖	CustomResourceDefinition	CR 实例	必须同时备份，恢复时先恢复 CRD 定义

4.3.3 资源模型映射的实践要点

GVR 唯一标识：每个资源由 Group、Version、Resource 三元组唯一标识。Velero 使用 GVR 进行 API 调用，备份时记录 GVR，恢复时按 GVR 创建。
集群作用域 vs 命名空间作用域：集群作用域资源（Node、CRD、Namespace）需要特殊处理，Velero 通过 --include-cluster-resources 控制是否备份。
资源版本兼容：备份时记录的 API 版本可能与恢复时集群支持的版本不同。Velero 依赖 API Server 的版本转换能力，建议目标集群的 API 版本不低于源集群。
自定义资源的特殊处理：对于 CRD 资源，Velero 需要知道 CRD 的存储版本。如果 CRD 定义在备份后发生变化，恢复时可能失败。建议在备份策略中固定 CRD 版本。

  设计建议：在灾备准入设计中，建议为每个 CRD 资源创建独立的备份配置文件，明确指定 --include-resources 和 --exclude-resources，避免备份无关的 CRD 实例。同时，在 CRD 的 metadata.annotations 中添加 velero.io/backup-priority: "high" 等标签，帮助 Velero 识别关键资源。

4.4 资源模型与 Velero 备份的协同设计

资源模型与备份的协同设计，核心在于建立资源类型到备份策略的映射矩阵。以下是一个推荐的映射模板：

资源类型	备份频率	备份范围	恢复优先级	特殊处理
Deployment / StatefulSet	每小时	命名空间	高	排除 Pod（由控制器重建）
ConfigMap / Secret	每次变更	命名空间	高	Secret 加密存储
PersistentVolumeClaim	每小时	命名空间	中	关联卷快照
CustomResourceDefinition	每次变更	集群	最高	与 CR 实例一起备份
Namespace	每日	集群	低	恢复时自动创建
Node / ClusterRole	每日	集群	低	仅备份关键标签和注解

通过这种映射关系，Velero 可以在备份时自动识别资源类型，应用对应的备份策略，并在恢复时按照依赖关系进行拓扑排序，确保恢复后的集群状态与备份时一致。