高可用性

artifacthub-shim 可以在一个 Kubernetes Service 后运行多个 API 从节点。使用此模式可提升读取可用性，并将 resolver/UI 流量分散到各个 pod。

HA 的含义

每个从节点都是一个独立的读取服务器：

它会监听相同的 repository 配置。
它会将 catalog 源刷新到自己的 source 工作目录中。
它会构建并发布自己不可变的只读快照。
只有在其第一个快照就绪后才会提供请求服务。

此模型提供读取冗余和读取流量分发。它不提供 leader election、共享的运行时元数据索引，或单一协调的源刷新器。repository 变更在不同从节点上可见的时间可能略有差异，因为每个 pod 都会完成各自的刷新周期。

基线 HA 值

对于常规离线 catalog 部署和中小型自定义 catalog 集合，请使用此配置文件：

replicaCount: 3

config:
  refreshInterval: 30m
  initialSyncTimeout: 5m
  repositoryEventDebounce: 5s
  maxConcurrentSources: 2
  enableConfigMapSources: true
  uiRBACCacheTTL: 60s
  kubeClientQPS: 50
  kubeClientBurst: 100

storage:
  contentStore:
    enabled: false

resources:
  requests:
    cpu: 200m
    memory: 512Mi
  limits:
    cpu: "1"
    memory: 1Gi

service:
  type: ClusterIP

该基线使 HA 部署保持简单：

三个从节点为集群内客户端提供冗余。
较长的刷新间隔可减少跨 pod 的重复 Git 和索引负载。
maxConcurrentSources: 2 将每个 pod 限制为同时加载两个源。
UI RBAC 缓存和 Kubernetes client 限制可减少 UI 流量带来的重复 TokenReview 和 SubjectAccessReview 压力。
ContentStore 保持禁用，因此不需要共享运行时存储。
资源基线为典型离线 catalog 部署中的刷新期内存叠加预留了空间。
ClusterIP 将 Tekton resolver 和 DevOps UI 路径的流量保持在集群内部。

规模和负载模型

config.maxConcurrentSources 是每个 pod 的限制。在 HA 模式下，集群范围内的源刷新并发量大致为：

replicaCount * config.maxConcurrentSources

在基线值下，集群在一次刷新周期中大约可同时加载 3 * 2 = 6 个源。只有当刷新延迟确实成为问题，并且 Git server、API server、CPU、内存和磁盘 I/O 预算能够吸收额外负载时，才应提高此值。

对于基于 ConfigMap 的 Git 源，一个源指的是 repository.yaml 中一个嵌套的 gitRepositories[].repositories[] 条目，而不是一个 ConfigMap 对象。单个 ConfigMap 可以声明多个外部可见的 repository，并且每个条目在刷新期间都会作为独立源进行加载和索引。在估算 HA 负载时，请统计所有带标签的 ConfigMap 中 repository 条目的总数。

保持资源请求切实可行。基线的 512Mi 内存请求和 1Gi 内存限制是起点，而不是容量保证。每个从节点都会构建自己的快照，并且在 ContentStore 禁用时，会将 manifest 和 README 负载保存在内存中。刷新期间可能会同时持有当前正在提供服务的快照和下一个快照。

对于大量基于 ConfigMap 的 Git 源、较大的 README 负载，或在禁用 ContentStore 时具有较大 catalog 集合的场景，请使用更大的配置文件：

resources:
  requests:
    cpu: 500m
    memory: 1Gi
  limits:
    cpu: "2"
    memory: 2Gi

HA 中的 Repository ConfigMap

对于在运维上属于同一责任域的条目，请使用多 repository ConfigMap，例如来自同一 Git repository 和同一团队的 task、pipeline 和 stepaction 路径。

避免将无关团队或高风险 repository 放入同一个 ConfigMap。如果 ConfigMap 中任何 gitRepositories[] 项或嵌套的 repositories[] 项无效，artifacthub-shim 会拒绝整个 ConfigMap 负载。将彼此独立的 repository 拆分到不同的 ConfigMap 中，可以将错误 URL、无效路径、重复名称或凭证引用带来的影响范围限制在更小范围内。

选择存储模式

sourceWorkDir 用于存储已物化的源代码检出内容和 provider 缓存。它可以设置为持久化，以降低大型外部 repository 源在 pod 重建时的成本，但它不会存储可直接提供服务的元数据索引。每个 pod 仍然会在就绪前获取或验证请求的 revision、扫描源文件并重建自己的快照。在 HA 模式下，sourceWorkDir 必须保持 pod 本地，因为 Git 检出内容属于可变的运行时状态。

| 模式 | 适用场景 | HA 行为

#高可用性

#目录

#HA 的含义

#基线 HA 值

#规模和负载模型

#HA 中的 Repository ConfigMap

#选择存储模式