📢 Kubernetes API removals on 1.25/1.26 might impact your project #2841
Closed
camilamacedo86
announced in
Announcements
Replies: 1 comment
-
Closing since the versions were released already and it seems done so far. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Some APIs versions are deprecated and will no longer be served on the Kubernetes version
1.25/1.26
and consequently on vendors like Openshift4.12/4.13
. For further information, check the guide.1.25+
before upgrading their cluster from1.24
to1.25
. Otherwise, they might face workflow issues`1.23+
to check if your versions are or not using these APIs. In this case, you need to perform a full regression test and check the Kubernetes metrics and the Operator logs. (For further info and examples, check the section below:How can I find the usage of the deprecated APIs
)🙆 When the errors will appear
It will be unlikely to find problems by only installing the Operator/Manager on the cluster. These APIs are commonly used at runtime (e.g. reconciliations made when the user creates CRs to provision the Operand).
Example:
An Operator reconciles a Kind/API to create a CronJob using
batch/v1beta1
or raises an Event usingevents.k8s.io/v1beta1
. Then, these operations will not work from Kubernetes1.25+
. The API versions will not be found on the cluster, and you will probably check out errors in Operator logs (api not found
).💁♀️ What does it mean for you?
You must ensure that you no longer use these API versions. Otherwise, any operation of your project which requires these versions will fail on Kubernetes versions
1.25/1.26+
.You should also check if your Operator versions are using these APIs or not. Then, you can adequately inform its users.
🙋 What are the APIs? How can I upgrade my Operator?
You can find all apis/versions removed on
1.25/1.26
on the guide guide as the required steps to upgrade them. However, the following is a summary:APIs removed from k8s
1.25
:v1
instead ofv1beta1
.v1
has been available since k8s v1.21. No notable changesv1
instead ofv1beta1
.v1
has been available since k8s v1.21. (See the guide to check the notable changes)v1
instead ofv1beta1
.v1
has been available since k8s v1.19. (See the guide to check the notable changes)v2
instead ofv2beta1
.v2
has been available since k8s v1.23. (No notable changes)v1
instead ofv1beta1
.v1
has been available since k8s v1.21. (See the guide to check the notable changes.)v1
instead ofv1beta1
.v1
has been available since k8s v1.20. (No notable changes)APIs removed from k8s
1.26
:v2
instead ofv2beta2
.v2
has been available since k8s v1.23(No notable changes)v1beta2
instead ofv1beta1
.v1beta2
has been available since k8s v1.23(No notable changes)v1beta2
instead ofv1beta1
.v1beta2
has been available since k8s v1.23(No notable changes)🙋♀️ How can I find the usage of the deprecated APIs:
1. Inspect your Operator source code. Look for manifests and imports using the removed versions, e.g.:
2. By running your Operator on the cluster, you can check that the Kubernetes API will also try to warn you when a workflow that uses these API versions is executed, e.g.:
0.12.0
and k8s1.23+
. Please, do the tests against Kubernetes API1.23+
to ensure that the warnings will be fired.3. Use the metrics to see if your Operator workflows are calling these deprecated APIs (which will be removed)
You can use Kubernetes metrics to check if your Operator calls the deprecated APIs (More info).
💡 Note that it is not easy to identify if your Operator is doing the calls. Other components running on the cluster can also have called them. In this way, we recommend that you; initialise a new cluster for these tests. Then, before beginning to test your Operator verify the results so that you can compare the calls to these APIs before your Operator and workflows are executed with its result at the end.
Example
1.25
:Then, we checked as a result:
Beta Was this translation helpful? Give feedback.
All reactions