Shulou(Shulou.com)05/31 Report--

This article introduces how to automatically detect and deal with abandoned API in Kubernetes, the content is very detailed, interested friends can refer to, hope to be helpful to you.

As Kubernetes 1.16 becomes available for some time and slowly launches on many managed Kubernetes platforms, you may have heard of API deprecation. Although it is quite simple to deal with, if no one is involved, this change can seriously disrupt your service.

What is API deprecation?

As the feature set of Kubernetes evolves, API must also evolve to support this change. There are some rules designed to ensure compatibility and stability. This will not happen in every version, but eventually you will have to use the new API version and format because the old API will no longer be supported.

Why is this so important for version 1.16?

Some deprecated API was retained in recent K8s versions and was eventually completely deleted in Kubernetes 1.16. This is the following API group and version:

Deployment-extensions/v1beta1, apps/v1beta1 and apps/v1beta2

NetworkPolicy-extensions/v1beta1

PodSecurityPolicy-extensions/v1beta1

DaemonSet-extensions/v1beta1 and apps/v1beta2

StatefulSet-apps/v1beta1 and apps/v1beta2

ReplicaSet-extensions/v1beta1, apps/v1beta1 and apps/v1beta2

If you try to create a resource using one of these in 1.16, the operation will fail.

How do I check to see if I am affected?

You can traverse all the lists manually, but this can be quite time-consuming. If you have multiple teams deployed to a cluster, or if you don't have all the current lists in one place, it's easy to lose some lists and may be very impractical. This is where kubent (Kube-No-Trouble) came to help.

What's the problem?

The information used to create the API version of a given resource is usually not easy to find because the resource is always internally converted to the preferred stored version and stored in the preferred stored version. However. If you use kubectl or Helm to deploy resources, the original list is also stored in the cluster, and we can take advantage of it. If it is kubectl, the form is kubectl.kubernetes.io/last-applied-configuration comment; if it is Helm, it is ConfigMap or Secret.

How to solve the problems caused by abandonment

The easiest way is to install:

Sh-c "$(curl-sSL 'https://git.io/install-kubent')"

This will install the latest version of kubent into / usr/local/bin.

(if you, like me, don't trust random scripts posted in blog posts, please download the latest version of your platform and unzip it wherever you like. )

Configure the current context of kubectl to point to the cluster where you want to check and run the kubent tool:

Figure 1:kubent run sample output

Kubent will connect to your cluster, retrieve all resources that may be affected, scan and print summaries of those resources that may be affected.

You can also use the-f json flag to get the output in JSON format, which is more suitable for you to integrate it into your CI/CD pipeline or further process the results. More details on the available configuration options are described in the README file in the doitintl/kube-no-trouble repository.

What should I do with the detected resources?

In some cases, this is as simple as changing the apiVersion in manifest, but in others, the structure may have changed and needs to be adjusted. Also, note that there are many default values that change between versions (a good article on this is David Schweikert's Kubernetes 1.16 API deprecations and changed defaults), so just change the apiVersion and apply the same listing, and you'll get different results. For example, StatefulSet's updateStrategy.type is changed from OnDelete to RollingUpdate, resulting in a very different behavior.

Https://medium.com/google-cloud/kubernetes-1-16-api-deprecations-and-changed-defaults-e53ccc5c73d5

The previously used kubectl convert command is now deprecated and may not convert resources correctly according to the default values mentioned earlier.

The best approach may be to simply apply resources (if you detect them using kubent, then you already have them) and retrieve the new version from API. This will ensure that the resource is correctly converted to the new version. You may have noticed that kubectl returns the version with some degree of uncertainty. To request a specific version of API, use the full form:

Kubectl get ingress.v1beta1.extensions-o yaml on how to automatically detect and deal with deprecated API in Kubernetes is shared here. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.