Reputation: 101
Using different tools (kubent for example) I see that I have deprecated API in my cluster. For example
Type: Ingress Name: kibana API: networking.k8s.io/v1beta1
But when I open Ingress itself, I can see this:
apiVersion: networking.k8s.io/v1
kind: Ingress
managedFields:
- manager: Go-http-client
operation: Update
apiVersion: networking.k8s.io/v1beta1
So, it shows that API of my Ingress is actually "v1", not "beta". But "managedFields" section indeed has "v1beta1" API. According to official documentation, this is server side API that should not be edited by user.
So, my question is - should/can I do anything with deprecated API in this "managedField"? Will there be any issues during upgrade to next k8s version? Because currently my GCP console shows that there will be problems.
Upvotes: 4
Views: 2196
Reputation: 6707
A detection of deprecated K8S APIs by 'kubent' tool can be performed in various modes:
According the official documentation, the 'kubectl' mode ('-c=true') uses the following field to scan deperecated API on live cluster resources:
kubectl.kubernetes.io/last-applied-configuration
- that's one of the reasons you probably see it as deprecated
Upvotes: 1
Reputation: 2323
There will be no issue while upgrading your Kubernetes cluster to the latest version even if you have deprecated API version in the managed field
in the ingress configuration. The reason why you still see versions “/v1beta1” in the UI is because there are different parts of GKE that rely on both versions(v1 and v1beta1).
Between the two Kubernetes versions 1.19 and 1.21, both endpoints networking.k8s.io/v1
and extensions/v1beta1
are supported. They are functionally identical, and it is down to the given UI's preference for which version is displayed. So it won’t affect the functionality of your Ingress. As said, GKE clusters were created on versions 1.22 and later stopped supporting extensions/v1beta1 and networking.k8s.io/v1beta1 Ingress.
Upvotes: 3