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

3. 资源模型基础：Kubernetes 资源模型与 GitOps 数据载体

在 GitOps 控制平面中，所有期望状态都以 Kubernetes 资源的形式存储在 Git 仓库中。理解 Kubernetes 资源模型（Group/Version/Kind）、自定义资源（CRD）以及资源规范（Spec）与状态（Status）的分离，是构建 GitOps 工作流的核心基础。本节将深入剖析这些概念，并展示它们如何成为 GitOps 数据传输与状态同步的基石。

3.1 Kubernetes 资源模型：GVK 三元组

Kubernetes 资源模型的核心是 Group（组）、Version（版本） 和 Kind（类型） 组成的三元组，简称 GVK。每个 Kubernetes 资源对象都由其 GVK 唯一标识。这种设计使得 API 可以按功能域分组、按成熟度分版本，并支持多种资源类型。

组件	说明	示例
Group	资源所属的 API 组，通常对应功能域（如 apps、batch、networking.k8s.io）。核心资源（如 Pod、Node）属于空组 ""。	`apps`、`batch`、`networking.k8s.io`
Version	资源的 API 版本，表示稳定程度（如 v1、v1beta1、v1alpha1）。	`v1`、`v1beta1`、`v1alpha1`
Kind	资源的具体类型名称，通常采用 PascalCase 命名。	`Deployment`、`Service`、`Pod`

  GVK 在 GitOps 中的意义： GitOps 控制平面通过 GVK 精确识别 Git 仓库中每个 YAML 清单对应的资源类型，从而调用正确的 API 版本进行 apply 操作。版本管理（如从 v1beta1 迁移到 v1）直接决定了集群中资源的兼容性。

3.2 自定义资源（CRD）与 GitOps 扩展

自定义资源定义（CustomResourceDefinition，CRD）允许用户扩展 Kubernetes API，引入新的资源类型。在 GitOps 场景中，CRD 是定义应用配置、基础设施策略和运维编排的核心工具。例如，Argo CD 的 Application 资源就是一个典型的 CRD。

CRD 的生命周期管理在 GitOps 中至关重要：

声明式安装： CRD 本身作为 Kubernetes 资源，应存储在 Git 仓库中，通过 GitOps 工作流安装到集群。
版本兼容： CRD 的版本（如 v1、v1beta1）必须与集群中安装的 CRD 版本匹配，否则会导致资源无法识别。
资源清理： 删除 CRD 时，所有该 CRD 类型的自定义资源实例也会被级联删除，需谨慎操作。

最佳实践： 在 GitOps 仓库中，将 CRD 清单与应用配置清单分离存放（例如放在 crds/ 目录下），并确保 CRD 先于应用资源被同步到集群。

3.3 资源规范（Spec）与状态（Status）的分离

Kubernetes 资源模型强制将 期望状态（Spec） 与 实际状态（Status） 分离。这种设计是 GitOps 控制平面实现“声明式状态同步”的理论基础。

Spec（规范）： 用户声明的期望状态，存储在 Git 仓库中，由 GitOps 控制平面读取并应用到集群。
Status（状态）： 集群控制器实时更新的实际状态，反映资源在集群中的运行情况。Status 通常包含 conditions、observedGeneration 等字段。

以下是一个 Deployment 资源的简化示例，展示了 Spec 与 Status 的分离：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:1.0.0
---
# Status 由集群控制器自动填充，不会出现在 Git 仓库中
status:
  replicas: 3
  readyReplicas: 3
  conditions:
  - type: Available
    status: "True"
    lastUpdateTime: "2025-01-01T00:00:00Z"

关键约束： GitOps 控制平面（如 Argo CD）在比较 Git 仓库中的期望状态与集群实际状态时，只比较 Spec 部分。Status 字段的差异不会触发同步，因为 Status 是集群内部动态生成的，不应由 Git 管理。

3.4 GVK 与 Spec/Status 在 GitOps 数据流中的角色

下图展示了从 Git 仓库到 Kubernetes 集群的完整数据流，突出 GVK 解析、Spec 应用和 Status 反馈三个核心环节。

3.5 资源模型在 GitOps 中的关键设计原则

基于上述分析，在 GitOps 控制平面设计中，资源模型的应用需遵循以下原则：

GVK 唯一性： 每个资源在 Git 仓库中必须通过 apiVersion 和 kind 明确标识，控制平面据此路由到正确的 API 端点。
Spec 不可变（相对）： Git 仓库中的 Spec 是权威来源，任何手动修改集群中资源的 Status 都不会被 GitOps 控制平面采纳。
CRD 先行： 在 GitOps 工作流中，CRD 资源必须优先于其自定义资源实例被同步，否则会导致 apply 失败。
Status 只读： 控制平面只读取 Status 用于健康检查和状态展示，绝不将 Status 写回 Git 仓库。

  总结： Kubernetes 资源模型（GVK + Spec/Status 分离）为 GitOps 提供了声明式状态管理的理论框架。控制平面通过解析 GVK 确定资源类型，通过 Spec 定义期望状态，通过 Status 监控实际状态，最终实现 Git 仓库与集群状态的持续同步。