4. 资源模型概念：资源模型的定义、组成要素

在云原生与 GitOps 体系下，资源模型是对 Kubernetes 集群中所有可管理对象的一种结构化抽象。它不关心某个 Deployment 的具体 YAML 内容，而是关注：这个资源属于什么类型？它有哪些关键属性？它与其他资源之间存在怎样的依赖或关联？

资源模型是构建 Argo CD 项目级准入策略的数据基础。只有将零散的 Kubernetes 资源抽象为统一的模型，策略引擎才能进行规则匹配、依赖分析和变更影响评估。

4.1 资源模型的定义

资源模型（Resource Model）是对 Kubernetes 资源进行类型化、属性化、关系化的三维描述框架。它通过以下三个维度将原生资源转化为策略引擎可理解的结构化数据：

• 类型维度：标识资源的 API 组、版本、种类（Kind）。
• 属性维度：提取资源的元数据、规格、状态中的关键字段。
• 关系维度：描述资源之间的引用、依赖、包含、绑定等连接。

4.2 组成要素一：资源类型

资源类型是资源模型的第一分类键。在 Kubernetes 生态中，资源类型由 apiVersion 和 kind 共同决定。资源模型将其进一步细化为三层结构：

4.3 组成要素二：属性

属性是资源模型中可被策略引擎读取和比较的字段集合。并非所有 YAML 字段都需要纳入模型，只有与安全、合规、运维标准相关的属性才被提取。属性分为三类：

• 标识属性：name、namespace、labels、annotations。用于资源定位和分组。
• 安全属性：container[].image、container[].securityContext、serviceAccountName、hostNetwork、privileged。用于安全准入检查。
• 合规属性：replicas、resources.limits.cpu、resources.limits.memory、nodeSelector。用于资源配额和调度合规。

# 资源模型属性提取示例（Deployment）
{
  "type": {
    "apiGroup": "apps",
    "version": "v1",
    "kind": "Deployment"
  },
  "properties": {
    "name": "nginx-frontend",
    "namespace": "prod-web",
    "labels": {"app": "nginx", "tier": "frontend"},
    "containers": [
      {
        "image": "nginx:1.25",
        "privileged": false,
        "securityContext": {"runAsNonRoot": true}
      }
    ],
    "replicas": 3,
    "serviceAccountName": "nginx-sa"
  }
}

4.4 组成要素三：关系

关系是资源模型区别于普通字段清单的核心能力。Kubernetes 资源之间并非孤立存在，一个 Service 会通过 selector 关联 Pod，一个 Ingress 会引用后端 Service，一个 RoleBinding 会绑定 ServiceAccount。资源模型必须捕获这些关系，策略引擎才能进行跨资源推理。

常见的关系类型包括：

4.5 资源模型三层结构总览

下图展示了资源模型的完整三层结构，以及它们如何共同支撑 Argo CD 项目级准入策略的自动化判定：

4.6 资源模型在准入策略中的角色

资源模型不是最终产物，而是策略引擎的输入数据管道。在 Argo CD 项目级准入策略的自动化流程中，资源模型承担以下职责：

1. 标准化输入：将不同版本的 Kubernetes 资源统一为模型结构，屏蔽 API 版本差异。
2. 策略匹配：策略规则基于模型中的类型、属性、关系进行条件匹配，而非直接解析 YAML。
3. 依赖分析：通过关系要素，引擎可以自动发现资源变更的“涟漪效应”——例如，修改一个 Service 的端口，会影响所有引用该 Service 的 Ingress。
4. 审计与报告：模型化的资源数据便于存储、查询和可视化，为合规审计提供结构化证据。