4. Source Controller 详解：GitRepository 与 OCIRepository CRD、认证方式与轮询策略

Source Controller 是 Flux 控制平面中负责拉取、校验和缓存制品（Artifact）的核心组件。它通过两种自定义资源（CRD）——GitRepository 和 OCIRepository——来声明式地定义制品来源，并内置了多种认证机制与自动拉取策略。本章将深入剖析这两个 CRD 的字段结构、认证配置以及轮询调度原理。

4.1 GitRepository CRD：声明式 Git 仓库源

GitRepository 用于从 Git 仓库（支持 GitHub、GitLab、Bitbucket、自建 Git 等）拉取代码或配置。其核心字段如下：

4.1.1 GitRepository 认证方式

GitRepository 支持三种主流认证方式，配置均通过 spec.secretRef 指向的 Kubernetes Secret 实现：

• SSH 密钥认证：Secret 中必须包含 identity（私钥）和 known_hosts（可选，用于主机验证）字段。适用于私有仓库或企业 Git 服务器。
• HTTPS + 认证：Secret 中包含 username 和 password 字段。对于 GitHub/GitLab，password 通常填写 Personal Access 。
• HTTPS 无认证：公开仓库无需配置 secretRef，直接使用 https:// 地址即可。

4.2 OCIRepository CRD：容器镜像仓库作为配置源

OCIRepository 是 Flux v2 引入的新 CRD，允许将 OCI 制品（如 Helm Chart、Kubernetes 清单、策略文件）直接存储在容器镜像仓库中。其核心字段如下：

4.2.1 OCIRepository 认证方式

OCIRepository 的认证通过 spec.secretRef 引用 kubernetes.io/dockerconfigjson 类型的 Secret 实现。该 Secret 包含 .dockerconfigjson 字段，内容为 Docker 客户端认证格式的 JSON 字符串。

# 创建 OCI 仓库认证 Secret 示例
kubectl create secret docker-registry oci-auth \
  --docker-server=registry.example.com \
  --docker-username=myuser \
  --docker-password=mytoken \
  --namespace=flux-system

对于公有云托管仓库（如 AWS ECR、Azure ACR、GCR），通常使用 IAM 角色或服务账户进行认证，此时可以省略 secretRef，由 Source Controller 通过节点角色自动获取临时凭据。

4.3 自动拉取与轮询策略

Source Controller 采用 基于间隔的轮询（Interval-based Polling） 策略，而非事件驱动。每个 Source CR（GitRepository 或 OCIRepository）独立维护一个定时器，到期后触发拉取操作。

4.3.1 轮询策略关键参数

4.3.2 轮询与事件驱动的对比

Flux 选择轮询而非 Webhook 事件驱动，主要基于以下考虑：

• 声明式一致性：轮询确保集群状态与源仓库最终一致，不受网络抖动或 Webhook 丢失影响。
• 简化运维：无需暴露集群 Webhook 端点，无需配置防火墙或反向代理。
• 可预测性：轮询间隔固定，便于容量规划和审计。

4.4 GitRepository 与 OCIRepository 选型对比