k8s集群里如何支持或部署2套不同版本的tidb集群

【 TiDB 使用环境`】生产
【 TiDB 版本】v5.0.1
【遇到的问题】
k8s现有集群中已部署一套tidb,想再部署另外一套tidb。原operator版本是v1.1.4 ,想再安装新oper 1.3.3和最新tidb 5.4.1。 2个operator的crd 貌似差别挺大。
请问:
一个k8s集群再部署一套tidb,是否支持2个不同版本的operator和不同版本的tidb,若能如何支持?
若不能,如何支持2个不同tidb版本,有什么可行的方案?例如:升级crd后,升级operator到1.3.3。一个operator管理2个不同tidb集群么
【问题现象及影响】
【TiDB Operator 版本】:v1.1.4
【K8s 版本】:v1.12.4

通用的应该是这里提到的:升级 operator,部署不同版本的 tidb 集群。一个 operator 可以管理多套、多版本的 tidb 集群,只要在创建 tidb 集群时候指定好版本即可。

查阅资料也是这么理解的,但最佳实践方面有些担忧:升级crd,升级operator过程中,对原生产集群是否有影响?若升级失败是否能回退,该如何处理? 有最佳实践么

可以参考下升级 tidb operator 的官方文档:https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/upgrade-tidb-operator

嗯,看到这个链接了。还是刚才的担忧:升级crd,升级operator过程中,对原生产集群是否有影响?若升级失败是否能回退,该如何处理? 求最佳实践

关于影响官方资料已经写了,例如根据版本情况可能会滚动更新集群配置等。

在升级 tidb operator 过程中,可以考虑下这个参数,这个设置 ture 后,operator 会跳过对这个 tidb cluster 的 synce 流程(管理流程),也就不会进行滚动更新配置等;后面升级完成再关闭。

  ## if true, this tidb cluster is paused and will not be synced by the controller
  # paused: false

升级失败如何处理,升级主要是做更新 crd、scheduler、controller 等以及其他相关,怎么处理要看出现什么问题。

这里没有自动回退方案。

建议先熟练演练一下。

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。