Skip to content

「kubefed 02」从入土到浇注

Published: at 23:00

理理一些边角的库、场景,也说说感受。为什么这篇是「浇注」,被核辐射过的一个特征是脱发,看完 kubefed 头发也少了一把,那是不是可以认为 kubefed ≈ 辐射源,所以对于隔绝辐射最好的解决方式之一就是水泥浇注(必要时候再盖一快 40m(没错 40m 来自某大佬建议)厚的铅板

几个出现频率比较高的 util

当前对于集群状态变更感知的几个 controller

当前处理比较简单就是当集群状态变更的时候,所有集群的相关 Object 都进一把队列。

对于一个 Deployment 在正常情况下,当一个集群从健康变为不健康,那么会又 ClusterController 发现然后更新 KubefedCluster.Status 而后触发 ClusterLifecycle.ClusterUnavailable 进而触发 SchedulingPreference 重新计算分配而后触发 re-Sync(不健康变为健康也是类似)。在某个集群不可用期间,Object 有变更的话,重新加入的时候也会被 re-Sync 覆盖掉。

但其实这块个人觉得会有几个风险点

高可用的问题

由于 kubefed 的控制层是在 Host Cluster(有且唯一)且当前的设计决定了只能在一个确定的 Kubernetes 集群中运行,所以在没有 Host Cluster 一定是高可用的前提下,我们可以认为其实是会有可用性问题的。但如果你假设「Host Cluster 不是高可用的」,那么就会翻车了:一旦 Host Cluster 挂了,就相当于失去全局的掌控能力和一定程度上的灾备能力(基于 SchedulingPreference)。

我考虑过一下集中奇怪的方式但都以失败告终

而且上面都会有一个 join 和 unjoin 的问题(这个问题后面说)。

社区也有人问过这茬 control plane on multiple clusters #967,得到的答复也是预期的:拒绝,如果要实现这样的目的需要引入外部的存储。在更早一点的一个关于异常恢复的 issue 中,marun 提到了通过第三方存储解决的方式(但也是需要改架构设计)

https://github.com/kubernetes-sigs/kubefed/issues/450#issuecomment-441760508

Another possibility to reduce the cost of fedv2 control plane downtime is pull propagation. In this mode, rather than the fedv2 control plane being responsible for applying changes to member clusters, the control plane would generate the desired configuration for member clusters and write it to a distributed store (e.g. s3/gcs/etc). Controllers in member clusters would be responsible for reading from the distributed store and applying configuration. This is only a partial solution to ensure that cluster configuration is maintained. Resilient traffic coordination (i.e. load balancing) would still be required.

绝境

独立 Host Cluster

找一个能保障高可用的 Kubernetes 集群,然后把 kubefed 控制层丢上去。这样做几个好处

  1. 高可用
  2. 异常的时候恢复负担小:比如集群炸了都可以直接直接起新的,然后拿 etcd 恢复等等
  3. 升级等场景也比较快、灵活:不会有影响业务的负担

综上,没啥可解。。。

Orphan annotation & Managed label

Orphan 是打在 FederatedResource 的 annotations 上 kubefed.io/orphan=true,而 Managed 是打在 TargetResource 的 Labels 上 kubefed.io/managed: true

关于 cluster join/unjoin 时候的保留

一时间找不到那看过 repo 里面有个讨论是关于 clusterStrategy 的里面提及了 retain 的事项,等后面找到再贴上来。

API Resource 升级的时候怎么处理

在 FTC 中是感知 GVK 的,所以跟 k8s 一样,需要手动给新的 API Resource 做 federation 然后手动做迁移。最后下掉旧的 Federated Object 和 FTC。

SchedulingPreference 那边的 ReplicaScheduler 只感知了 apps group 暂时不提供服务给 extensions 的 Deployment 和 ReplicaSet

一些已知问题

感受

Good

Bad(maybe)

Ugly

总的来说,kubefed 还是挺好的把很多 kube API 抽象能力体现得淋漓尽致,相比起它那死在岸边的前浪 federation 这货已经被挺多人接受和使用。可惜还没有 GA,活跃度也一般般,要拿去生产用还是挺担心的。如果一定还要造轮子的话,我会选择继续使用 schema 但少一点抽象、好好给变量、函数起名。