1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 21:46:22 +01:00
Files
openshift-docs/modules/update-api-compatibility.adoc
Cavalle 64e845d54d TELCODOCS-2171-lifecycle-mgmt-lcavalle: Generalize Day2Ops Lifecycle management
TELCODOCS-2171-lifecycle-mgmt-lcavalle: fixing some vale errors
2026-01-13 16:57:30 +00:00

24 lines
1.3 KiB
Plaintext

// Module included in the following assemblies:
//
// * edge_computing/day_2_core_cnf_clusters/updating/update-api.adoc
:_mod-docs-content-type: PROCEDURE
[id="update-openshift-container-platform-api-compatibility_{context}"]
= {product-title} API compatibility
[role="_abstract"]
When considering what z-stream release to update to as part of a new y-stream update, you must be sure that all the patches that are in the z-stream version you are moving from are in the new z-stream version.
If the version you update to does not have all the required patches, the built-in compatibility of Kubernetes is broken.
For example, if the cluster version is 4.15.32, you must update to 4.16 z-stream release that has all of the patches that are applied to 4.15.32.
[id="update-about-kubernetes-version-skew_{context}"]
== About Kubernetes version skew
Each cluster Operator supports specific API versions.
Kubernetes APIs evolve over time, and newer versions can be deprecated or change existing APIs.
This is referred to as "version skew".
For every new release, you must review the API changes.
The APIs might be compatible across several releases of an Operator, but compatibility is not guaranteed.
To mitigate against problems that arise from version skew, follow a well-defined update strategy.