2. Resource Model 基础：Kubernetes Resource Model (KRM) 核心概念、API 资源与自定义资源

在深入集群升级与租户隔离治理之前，必须建立对 Kubernetes Resource Model (KRM) 的共识。KRM 是 Kubernetes 声明式运维的基石，它定义了“一切皆资源”的哲学，并规范了资源的描述、存储、访问与生命周期管理。本章将拆解 KRM 的核心概念，区分 API 资源与自定义资源，为后续的蓝图治理奠定理论基础。

2.1 KRM 核心概念：声明式资源模型

Kubernetes Resource Model 并非一个具体的软件库，而是一套架构规范。其核心思想是：用户通过声明期望的“终态”来管理集群，而非通过执行一系列命令。KRM 将集群中的每一个可管理实体（Pod、Service、Namespace、Node 等）都抽象为“资源”，并通过统一的 API 进行交互。

KRM 的三大支柱如下表所示：

支柱 说明 在租户隔离中的体现
声明式 API 用户提交 YAML/JSON 清单（Manifest），描述资源的期望状态。控制器（Controller）持续对比实际状态与期望状态，并执行调和（Reconcile）操作。 租户通过提交 ResourceQuota、NetworkPolicy 等清单声明隔离边界，控制器自动保障。
统一资源模型 所有资源遵循相同的元数据结构（apiVersion、kind、metadata、spec、status）。 无论是原生 Namespace 还是自定义 Tenant 资源，都使用同一套 CRUD 操作和存储机制（etcd）。
控制器模式 资源本身只存储数据，业务逻辑由控制器执行。控制器通过 Informer 监听资源变化，驱动系统达到期望状态。 租户隔离控制器监听 Tenant 资源变化，自动创建 Namespace、绑定 RBAC、配置网络策略。
关键认知： KRM 的核心价值在于将运维逻辑从“过程式”转变为“声明式”。在集群升级场景中，这意味着我们只需声明升级后的资源期望状态（如新的 API 版本），控制器会自动处理迁移与调和，极大降低了升级对租户业务的影响。

2.2 API 资源与自定义资源（CRD）

KRM 将资源分为两大类：内置 API 资源（Built-in Resources）和自定义资源（Custom Resources）。理解两者的区别与协作，是进行 Resource Model 治理的前提。

2.2.1 内置 API 资源

内置资源由 Kubernetes 核心组件提供，是集群的“原生公民”。它们通常分为不同的 API 组（Group），例如：

  • 核心组（Core Group）： v1，包含 Pod、Service、Namespace、Node、ConfigMap、Secret 等最基础的资源。
  • Apps 组： apps/v1，包含 Deployment、StatefulSet、DaemonSet、ReplicaSet 等工作负载资源。
  • Networking 组： networking.k8s.io/v1，包含 NetworkPolicy、Ingress 等网络资源。
  • RBAC 组： rbac.authorization.k8s.io/v1，包含 Role、ClusterRole、RoleBinding、ClusterRoleBinding。

2.2.2 自定义资源（CRD）

当内置资源无法满足特定业务需求时，可以通过 CustomResourceDefinition (CRD) 扩展 Kubernetes API。CRD 允许用户定义全新的资源类型，并像操作原生资源一样使用 kubectl 或 API 进行管理。

CRD 在租户隔离蓝图中的典型应用：

  • 定义租户抽象： 创建 Tenant 或 Project 资源，作为租户的顶层入口，聚合 Namespace、配额、策略等。
  • 定义隔离策略模板： 创建 NetworkIsolationPolicy 或 QuotaTemplate 资源，实现策略的标准化与复用。
  • 定义升级策略： 创建 UpgradePlan 资源，声明租户级别的升级顺序与灰度策略。
治理要点： 在集群升级中，CRD 本身也需要升级。CRD 的 API 版本（如 v1beta1 → v1）变更可能导致现有自定义资源对象无法被新版本控制器识别。因此，Resource Model 治理必须包含 CRD 的版本管理与迁移策略。

2.3 资源模型结构：从 API 到 etcd

一个完整的 KRM 资源从用户提交到最终存储，经历了清晰的层级转换。下图展示了这一核心流程：

KRM 资源生命周期：从声明到存储 用户声明 YAML / kubectl API Server 认证 · 授权 · 准入 etcd 持久化存储 POST /api/v1/... 存储到 etcd Controller 调和循环 实际状态 Pod / Service 等 Watch / Informer 创建/更新 状态反馈 说明： 用户声明 → API Server 校验并存储到 etcd → Controller 监听变化 → 驱动实际状态与期望状态一致。 虚线表示状态反馈回路，确保 Controller 持续调和。

2.4 资源版本与 API 组

KRM 通过 API 组（Group）、版本（Version） 和 资源（Resource） 三级结构来组织所有资源。这是理解集群升级兼容性的关键。

  • API 组： 逻辑上相关的资源集合，如 apps、batch、networking.k8s.io。空字符串表示核心组。
  • 版本： 同一资源在不同阶段的演进标识，如 v1、v1beta1、v1alpha1。版本级别越高，稳定性越强。
    • alpha：默认关闭，可能包含缺陷，不保证向后兼容。
    • beta：默认开启，经过充分测试，但可能仍有小范围变更。
    • stable (v1)：长期支持，保证向后兼容。
  • 资源： 具体的资源类型，如 deployments、pods、tenants。
升级风险提示： 在集群升级过程中，Kubernetes 会废弃（Deprecate）旧版本的 API。例如，extensions/v1beta1 下的 Ingress 在 v1.22 中被彻底移除。如果租户的 Resource Model 中仍引用已废弃的 API 版本，升级后将导致资源无法被识别，引发服务中断。Resource Model 治理必须包含 API 版本兼容性扫描。

2.5 资源规范（Spec）与状态（Status）

KRM 强制将资源的“期望”与“实际”分离，这是声明式模型的核心设计模式。

字段 位置 写入者 用途 租户隔离示例
spec 用户提交的 Manifest 用户 / 运维人员 定义资源的期望状态 Tenant.spec.namespaces: ["team-a", "team-b"]
status 集群内部 对应的 Controller 反映资源的实际状态 Tenant.status.phase: "Ready"

这种分离带来了两大治理优势：

  1. 可审计性： 通过对比 spec 与 status，可以精确判断资源是否达到预期，便于升级前的合规检查。
  2. 自动化修复： 当实际状态偏离期望状态（如升级导致 Pod 被驱逐），Controller 会自动进行调和，恢复隔离策略。

2.6 本章小结

← 上一章 📖 返回目录 下一章 →