As Kubernetes releases iterate, many Helm Chart packages simply cannot keep up with the updates, resulting in many Helm Chart packages being incompatible when using newer versions of Kubernetes, so it is necessary to consider compatibility with different versions of Kubernetes when developing Helm Chart packages.
The core of achieving compatibility with different versions is to make use of the built-in object
Capabilities provided by the Helm Chart template, which provides information about Kubernetes cluster support features, including the following features.
Capabilities.APIVersionsGet the cluster version set
Capabilities.APIVersions.Has $versiondetermines if a version (e.g., batch/v1) or resource (e.g., apps/v1/Deployment) is available in the cluster
Capabilities.KubeVersion.Versionto get the Kubernetes version number
Capabilities.KubeVersion.MajorGet the major version of Kubernetes
Capabilities.KubeVersion.MinorGet the sub-version of Kubernetes
Capabilities.HelmVersionobject containing Helm version details, consistent with the output of
Capabilities.HelmVersion.Versionis the semantic format of the current Helm version
Capabilities.HelmVersion.GitTreeStateis the state of the Helm git tree
Capabilities.HelmVersion.GoVersionThe version of the Go compiler used
Using the above objects we can determine the API version or properties that the resource object needs to use, and we will use the Ingress resource object as an example.
Kubernetes introduced a new API for Ingress resources in version 1.19:
networking.k8s.io/v1, which is basically the same as the previous
networking.k8s.io/v1beta1 beta version, but is very different from the previous
extensions/ v1beta1 is very different from the previous
extensions/v1beta1 version, there are some differences in the properties of the resource objects, so to be compatible with the different versions, we need to do compatibility with the Ingress object in the template.
The format of the resource objects in the new version is shown below.
And the old version of the resource object format is as follows.
The exact format of the resource object to use depends on our cluster version, so first we add a few named templates to the
_helpers.tpl file in the Chart package to determine the cluster version or API
Capabilities.APIVersions.Has to determine which APIVersion we should use, and if the version is
isStable is defined, in addition to determining whether the
pathType property needs to be supported based on the version. The naming template defined above can then be used in the Ingress object template to determine which properties should be used, as shown in the
ingress.yaml file below.
The Ingress template uses variables in the named template to determine which properties should be used, so that the Chart template we define is compatible with different versions of Kubernetes, and if there are differences between other versions, we can define them separately.