Chart兼容CronJob两个ApiVersion实践

实际环境

在工作中，有多个k8s集群需要同时管理，随着业务的扩充，先运行的K8s的版本和新运行的K8s版本就有出现差异，有些资源清单的apiVersion、格式、写法就会出现不兼容的情况。

实际情况是在部署CronJob的资源时，部署失败。差异：

• A集群版本为 v1.17.4
• B集群版本为 v1.26.1

在 Kubernetes 中，CronJob 的 API 版本变更是从 Kubernetes 1.21 版本开始引入的。在 Kubernetes 1.21 版本之前，batch/v1beta1 是 CronJob 的稳定版本。从 Kubernetes 1.21 版本开始，CronJob 被升级为稳定版本，使用的是 batch/v1 API 版本。

因此，如果 Kubernetes 版本是 1.21 或更高，应该使用 batch/v1 作为 CronJob 的 API 版本。如果 Kubernetes 版本低于 1.21，则应该使用 batch/v1beta1。

修改资源清单文件

通过对比batch/v1beta1 和 batch/v1 API 版本的差异，发现没有什么改变。

只需要在 apiVersion 前加一个集群版本判断即可。

# cronjob.yaml

{{- if semverCompare ">=1.21-0" .Capabilities.KubeVersion.GitVersion -}}
apiVersion: batch/v1
{{- else -}}
apiVersion: batch/v1beta1
{{- end }}
kind: CronJob
metadata:
...

以上意思为：判断k8s的集群版本，如果大于等于1.21版本，则使用batch/v1 API 版本，否则使用batch/v1beta1API 版本。

通过 helm 部署可用。