3. 资源模型基础：Kubernetes资源模型、CRD、GVK、GVR、资源层次结构

Kubernetes 资源模型是整个控制平面与 GitOps 检测体系的基石。理解资源模型，意味着理解“一切皆对象”的声明式 API 如何被定义、寻址、存储与组合。本章从核心概念出发，逐步拆解 GVK、GVR、CRD 以及资源之间的层次关系。

3.1 Kubernetes 资源模型核心概念

Kubernetes 资源模型（KRM）是一套统一的声明式 API 规范。每个资源都是一个 JSON/YAML 对象，包含以下核心字段：

• apiVersion：标识资源所属的 API 组和版本，例如 apps/v1。
• kind：资源类型名称，例如 Deployment。
• metadata：元数据，包含 name、namespace、labels、annotations 等。
• spec：期望状态（Desired State）。
• status：实际状态（Actual State），由控制器更新。

3.2 GVK 与 GVR：资源的逻辑标识与物理寻址

Kubernetes 使用两套标识系统来定位资源：GVK（Group、Version、Kind）用于逻辑类型识别，GVR（Group、Version、Resource）用于 RESTful API 路由。

3.3 CRD：扩展资源模型的基石

CustomResourceDefinition（CRD）允许用户向 Kubernetes API 注册新的资源类型。CRD 本身也是一个 Kubernetes 资源，其核心结构如下：

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: applications.gitops.example.com
spec:
  group: gitops.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:
                repoURL:
                  type: string
                targetRevision:
                  type: string
                path:
                  type: string

CRD 注册后，Kubernetes 自动生成对应的 RESTful API 端点，用户即可像操作原生资源一样操作自定义资源。

3.4 资源层次结构：从集群到实例

Kubernetes 资源存在清晰的层次结构，理解这一结构对 GitOps 检测的权限控制、资源隔离和状态聚合至关重要。

3.5 资源模型在 GitOps 检测中的映射

在 GitOps 检测场景中，资源模型直接决定了检测的范围、粒度和策略：

• GVK 用于策略匹配：检测规则通过 GVK 指定要监控的资源类型，例如只检测 apps/v1/Deployment 和 gitops.example.com/v1/Application。
• GVR 用于 API 调用：检测引擎通过 GVR 构造 REST 请求，从集群拉取资源状态，或通过 Watch 订阅变更事件。
• CRD 用于扩展检测范围：通过 CRD 定义的自定义资源（如 ArgoCD Application、Flux Kustomization）是 GitOps 检测的核心对象。
• 资源层次用于权限隔离：Cluster 级别的资源（如 ClusterRole）与 Namespace 级别的资源（如 Role）需要不同的检测策略和 RBAC 配置。

3.6 资源模型与控制器调和循环

资源模型不仅是静态定义，更是动态调和循环的载体。控制器通过以下步骤实现状态收敛：

1. 观察（Observe）：通过 GVR 的 Watch 或 List 接口获取当前资源状态。
2. 分析（Analyze）：对比 spec（期望状态）与 status（实际状态），计算差异。
3. 执行（Act）：调用 Kubernetes API 创建、更新或删除子资源，使实际状态向期望状态收敛。
4. 更新状态（Update Status）：将调和结果写回资源的 status 字段。

GitOps 检测引擎本质上是一个“元控制器”，它监控多个资源的 spec 与 status，并报告偏离 Git 仓库期望状态的差异。