karmada
karmada copied to clipboard
karmada-io
API版本代沟问题
按照我的理解，用户在控制面APIServer创建Workload，然后由karmada按照API Version支持能力分发到下层集群。所以Workload的版本必须需要控制面和成员集群同时支持才可以。
但是随着事件推移，成员集群的版本可能会差别越来越多，甚至出现版本代沟。例如：
| API版本 | Cluster1 | Cluster2 |
|---|---|---|
| alphav1 | O | X |
| betav1 | X | O |
| v1 | X | O |
而控制面面的APIServer无法同时覆盖alphav1、alphav1、v1三个版本。 如果集群版本又升级不了，那么控制面就无法管理所有集群。
关于这个问题，不知道有什么想法？
很好的问题。控制面APIServer所支持的API应该是所管理集群的超集。
另外补充一点：karmada管理集群的方式通常不会变，单个API变化影响的仅仅是某个特性，不至于无法管理。
另外，可以说下你们的场景吗？比如具体哪个API变化，你们集群版本范围？
比如有些老的集群，Deployment还在用extensions/v1beta。但是k8s 1.16之后对extensions不再支持。
那如果如法下发旧版本API，那么联邦的意义也不存在了
比如有些老的集群，Deployment还在用extensions/v1beta。但是k8s 1.16之后对extensions不再支持。
k8s默认不再开启extensions/v1beta, 根据这个说明 仍然可以使用：
Serving these resources can be temporarily re-enabled using the --runtime-config apiserver flag.
- apps/v1beta1=true
- apps/v1beta2=true
- extensions/v1beta1/daemonsets=true,extensions/v1beta1/deployments=true,extensions/v1beta1/replicasets=true,extensions/v1beta1/networkpolicies=true,extensions/v1beta1/podsecuritypolicies=true
以下是我的观点： 1、K8s核心的API基本已达到GA。（除非很低版本的K8s） 2、karmada用kube-apiserver作为入口组件的原因：天然支持原生API，用户不需要手动安装K8s API（API版本由kube-apiserver版本决定）。当然也随着带来与子集群版本可能不一致的问题。 3、使用general-apiserver（即去掉Core api的kube-apiserver，或者采用社区kcp），用户可以自己安装对应版本CRD（把deployment、statefulset等也看做CRD）。 如何解决上述不一致的问题： 1、升级K8s版本 （推荐） 2、为了不同版本的API保持一致性，在集群中增加webhook，将v1的deployment请求转化为v1beta1的deployment以支持老版本集群。 3、Karmada支持集群级API版本配置，将对象转化对应版本后再下发。
后话：（出现“代沟”的问题，本质问题是集群升级难的问题） 使用单集群K8s，把节点从“宠物”当成“牛”看待。 使用Karmada，把集群从“宠物”当成“牛”看待。（多集群应用分发，应用故障迁移，多集群service等可以帮助你） 我们升级维护集群再也不用担心集群故障，导致业务出现问题。
我们也遇到了这个问题。中心的karmada集群版本是1.21，成员集群是1.20。cronjob的在1.21的版本号是batch/v1，1.20的版本号是batch/v1beta1，在karmada创建cronjob时，无法下发到member集群，排查后发现是由于版本号问题。社区对于这种场景有没有什么比较好的解决方案
有个问题，成员集群是1.20，为什么Karmada集群（我理解是karmada-apiserver）版本选用1.21？是否其他成员集群也有1.21？
如果用不到batch/v1，或许可以使用kube-apiserver的--runtime-config参数停掉，例如--runtime-config=batch/v1=false