《 九 阴 真 经 卷 八 》联邦集群

《 九 阴 真 经 卷 八 》联邦集群

1. Karmada

https://karmada.io/zh/docs/

2. 联邦集群管理

成员集群上启动work-agent，形态为5个controller

• cluster-status-controller
  • 向联邦集群注册
  • 周期性上报状态（心跳）
  • 将secret同步到联邦集群
• exec-controller
  • 监听联邦集群的work事件，操作成员集群workload
• cert-rotation-controller
  • 联邦证书快过期时，负责更新联邦集群证书
    联邦集群上启动
• cluster-controller：
  • 为成员集群准备exec namespace，用于管理下发到该集群的work对象
• exec-controller：
  • 负责编排和分发work对象，到多个member集群的namespace
  • 监听member集群中关注的资源列表，比如pod

4. 联邦集群的数据规模

总的在线机器规模在20W，平均每台机器40个pod，共800W个在线任务。加上大数据的200W任务，平均到4AZ，每个AZ 250W实例
全局资源视图，通过在联邦集群的api- server实现aggregation-api实现

• 实现一个Router，决定查询请求真正查询的是联邦集群、成员集群还是cache
• 实现一个cache，list/watch聚合后的成员集群资源
  cache分片：按namespace对resource进行分片，此处要考虑上层平台不均匀的问题
  cache数据量：按照一个pod 20KB计算，每个AZ 250W个pod，50GB。其他资源大概是pod的一半，共计75GB
  对联邦集群资源的list watch会经过一个聚合器MUX，将多cache分片的资源聚合起来

kube-apiserver cacher

cache实际上使用的是kube-apiserver的cacher
kube-apiserver是Kubernetes集群的核心组件，负责处理REST请求，并且提供对Kubernetes资源的访问。kube-apiserver的性能直接影响整个集群的响应时间和稳定性。为了优化性能，kube-apiserver实现了一种缓存机制，称为cacher。

kube-apiserver Cacher机制的作用

kube-apiserver的Cacher机制通过缓存数据来减少对etcd的访问次数，从而提升API请求的处理速度。由于etcd是分布式键值存储，频繁的操作会增加延迟并降低性能。通过缓存，kube-apiserver能够快速地响应常见的请求，减少对etcd的负载，并且提高整体性能。

Cacher的工作方式

kube-apiserver的Cacher机制基于informer模式工作，通过informer机制监听Kubernetes API对象的事件，并将对象的状态存储在内存中。当请求到来时，kube-apiserver首先检查缓存中是否存在所需的信息，如果存在，则直接返回缓存中的数据。如果缓存中没有，kube-apiserver会向etcd查询数据，并将其存储在缓存中。

Cacher的缓存策略

kube-apiserver的缓存策略可以根据不同的情况进行调整，以满足不同的性能需求。常见的缓存策略包括：

• TTL（Time to Live）：为每个缓存条目设置一个过期时间，一旦超过这个时间，条目就会被淘汰。
• 大小限制：限制缓存的大小，当缓存达到最大限制时，最旧的条目将被淘汰。
• 优先级：根据请求频率或重要性给缓存条目设置优先级，使得经常访问或重要的条目在缓存中保留更长时间。

Cacher的维护

为了确保缓存的有效性，kube-apiserver需要定期更新缓存。这通常是通过informer机制自动完成的，当etcd中的资源发生变更时，informer会收到事件，并更新缓存。此外，kube-apiserver还可以配置定期刷新缓存的策略，以确保缓存数据与etcd中的数据保持同步。

注意事项

虽然缓存可以显著提高性能，但同时也引入了复杂性。如果缓存数据变得陈旧或者不一致，可能会导致错误的响应。因此，维护缓存的准确性是至关重要的。此外，缓存机制增加了kube-apiserver的内存使用量，可能会影响服务器的性能。

总之，kube-apiserver的Cacher机制通过缓存数据来减少对etcd的访问次数，从而提升API请求的处理速度，但同时也需要仔细管理和维护以确保缓存的准确性和一致性。

全局ResourceVersion

ResourceVersion的作用

在 Kubernetes 中，ResourceVersion（简称 RV）是 Kubernetes API 中的一个字段，用于追踪资源版本。ResourceVersion 是 Kubernetes API 中所有资源对象的一个字段，它代表了资源的版本信息。具体来说，ResourceVersion 是一个整数，用于唯一标识一个资源在 Kubernetes API 服务器中的版本。

ResourceVersion 的主要作用包括：

1. 乐观并发控制：ResourceVersion 用于乐观并发控制。当多个客户端尝试同时修改或读取同一个资源对象时，ResourceVersion 用于确保数据的一致性和完整性。客户端在发送修改请求时会包含一个 ResourceVersion，API 服务器会比较这个 ResourceVersion 和服务器上的 ResourceVersion。如果它们不匹配，那么说明资源在客户端和服务器之间已经被修改，API 服务器会返回一个冲突错误，客户端需要决定是重试操作还是放弃。

2. 避免过时数据：ResourceVersion 还可以帮助客户端避免读取过时的数据。当客户端读取资源时，它可以指定 ResourceVersion。如果指定的 ResourceVersion 与资源当前的 ResourceVersion 不匹配，那么客户端会收到一个指示，表明资源在读取时已经被更新。

3. 垃圾回收：Kubernetes 使用 ResourceVersion 来确定哪些旧的资源版本可以被垃圾回收。只有当资源的 ResourceVersion 小于垃圾回收阈值时，旧的资源版本才会被删除。

ResourceVersion 在 Kubernetes 中是一个非常重要的概念，它保证了 API 的稳定性和一致性。同时，了解 ResourceVersion 的工作原理对于处理 Kubernetes 集群中的并发操作和错误情况也是非常关键的。

联邦集群的ResourceVersion

联邦集群维护一个全局的ResourceVersion，以集群名：version的映射形式提供，任何一个成员集群的事件都会使这个全局的ResourceVersion对应的Key + 1