Skip to content

Kubernetes Version Support

Andrew Azores edited this page Jul 15, 2024 · 1 revision

The minimum Kubernetes version required for any given Cryostat Operator or Cryostat Helm Chart release is determined using the following algorithm:

  1. Find the minimum k8s version availability for all features used across Operator and Helm - featureLevel
  2. Check the oldest supported upstream k8s version - upstreamKube
  3. Check the k8s version corresponding to oldest supported OpenShift - openShiftKube
  4. Set the Helm/Operator minKubeVersion to max(min(upstreamKube, openShiftKube), featureLevel)

For example, if:

  • a new Cryostat version will be released on date X
  • the Operator/Helm Chart use a feature that was introduced in Kubernetes 1.21
  • the oldest supported OpenShift version on date X is 4.12, which corresponds to Kubernetes 1.25
  • the oldest supported upstream Kubernetes version on date X is 1.28

then the Cryostat version to be released should advertise its minimum supported Kubernetes version as 1.25. It will run on 1.21, but this version is too far out of date to consider for testing and validation, so the older version between OpenShift and upstream Kubernetes is selected. In most cases, the OpenShift version will diverge from the upstream Kubernetes version the same way as in this scenario, so it is likely that OpenShift drives the version selection. Care should always be taken to ensure this assumption actually holds before setting the release's minimum supported version.

From the other side, when developing new Operator and Helm Chart features, care should be taken in selecting which Kubernetes features should be used so that Cryostat does not require the very latest Kubernetes API to be available. Doing so would cause the Cryostat Operator/Helm Chart to be unusable on still-supported Kubernetes and OpenShift clusters.

Clone this wiki locally