October 1, 2019 By Richard Theis 3 min read

Kubernetes version 1.16 has removed several deprecated APIs that you’ll likely recognize and may use on a daily basis.

Kubernetes version 1.16 removed the deprecated APIs by default. However, Kubernetes providers had the option to temporarily keep the APIs enabled. IBM Cloud Kubernetes Service kept the community default and removed the APIs starting in version 1.16. On the other hand, Red Hat OpenShift on IBM Cloud version 4.3, which is based on Kubernetes version 1.16, kept these APIs enabled. Now, Red Hat OpenShift on IBM Cloud version 4.4, which is based on Kubernetes version 1.17, removes the APIs as well.

The apps/v1beta1 and apps/v1beta2 APIs have been completely removed. In addition, the extensions/v1beta1 API has been removed for select resources. Removal of these APIs impacts the following Kubernetes resources: NetworkPolicy, PodSecurityPolicy, DaemonSet, Deployment, StatefulSet, and ReplicaSet

The good news is that replacement APIs are available now and have been for a long time. Every supported IBM Cloud Kubernetes Service and Red Hat OpenShift on IBM Cloud version supports the replacement APIs. So, if you haven’t started your transition, now is the time. 

For more information, see the Kubernetes blog: “Deprecated APIs Removed In 1.16: Here’s What You Need To Know.”

Overview of the replacement APIs

  • Use the networking.k8s.io/v1 API for NetworkPolicy resources.
  • Use the policy/v1beta1 API for PodSecurityPolicy resources.
  • Use the apps/v1 API for DaemonSet, Deployment, StatefulSet, and ReplicaSet resources.

Some tips to help you with this transition

Review kubectl last applied configurations

The Kubernetes kubectl command provides a very useful resource annotation—kubectl.kubernetes.io/last-applied-configuration—that can help you find Kubernetes resources created or updated via kubectl using the removed APIs.  

Run the following commands as a cluster administrator to find all resources last applied using the impacted APIs. Any resources found are likely backed by YAML that you or someone that you depend on needs to change. More on converting your YAML later:

$ kubectl get NetworkPolicy,PodSecurityPolicy,DaemonSet,Deployment,ReplicaSet --all-namespaces -o 'jsonpath={range .items[*]}{.metadata.annotations.kubectl\.kubernetes\.io/last-applied-configuration}{"\n"}{end}' | grep '"apiVersion":"extensions/v1beta1"'
$ kubectl get DaemonSet,Deployment,StatefulSet,ReplicaSet --all-namespaces -o 'jsonpath={range .items[*]}{.metadata.annotations.kubectl\.kubernetes\.io/last-applied-configuration}{"\n"}{end}' | grep '"apiVersion":"apps/v1beta'

Review Kubernetes API server usage metrics

The Kubernetes API server provides API usage metrics that can help you find clients using the removed APIs. 

Run the following commands as a cluster administrator. The commands filter out the dashboard (i.e., Kubernetes Dashboard), hyperkube (Kubernetes master and worker node components), and kubectl clients since these clients will transition to the replacement APIs as part of the upgrade process. Since IBM Cloud Kubernetes Service and Red Hat OpenShift on IBM Cloud clusters have highly available (HA) masters, you will have to run these commands several times to ensure data is collected from all three Kubernetes API servers.

kubectl get --raw="/metrics" | grep apiserver_request_count | grep 'group="extensions"' | grep 'version="v1beta1"' | grep -v ingresses | grep -v 'client="hyperkube' | grep -v 'client="kubectl' | grep -v 'client="dashboard' | grep -v 'component="apiserver"'
$ kubectl get --raw="/metrics" | grep apiserver_request_count | grep 'group="apps"' | grep 'version="v1beta' | grep -v 'client="hyperkube' | grep -v 'client="kubectl' | grep -v 'client="dashboard'

Review your dependencies

Even if your apps are ready for this transition, a review of the earlier command results may identify dependencies that are not. 

Convert your YAML

From the Kubernetes blog referenced earlier, “You can use the kubectl convert command to automatically convert an existing object: kubectl convert -f <file> --output-version <group>/<version>. … Note that this may use non-ideal default values.” Be sure to review and test the results of the conversion.

Next steps

The Kubernetes blog “Deprecated APIs Removed In 1.16: Here’s What You Need To Know” and Kubernetes version 1.16 CHANGELOG identify other deprecated APIs that are targeted for removal in later releases.

Once you are ready for Kubernetes version 1.16, update your to-do list to include handling these future API removals. Also, please help get the message out and open issues so the entire Kubernetes community is ready for versions 1.16 and later.

Questions?

For general questions, engage our team via Slack by registering here, and join the discussion in the #general channel on our public IBM Cloud Kubernetes Service Slack.

More from Announcements

IBM Consulting augments expertise with AWS Competencies: A win-win for clients 

3 min read - In today's dynamic economic landscape, businesses demand continuous innovation and speed of execution. At IBM Consulting®, our unwavering focus on partnerships and shared commitment to delivering enterprise-level solutions to mutual clients have been core to our success.   We are thrilled to announce that IBM® has recently gained five competencies from Amazon Web Services (AWS) in vital domains including Cloud Operations, Internet of Things (IoT), Life Sciences, Mainframe Modernization, and Telecommunications. With these credentials, IBM further establishes its position as a…

Probable Root Cause: Accelerating incident remediation with causal AI 

5 min read - It has been proven time and time again that a business application’s outages are very costly. The estimated cost of an average downtime can run USD 50,000 to 500,000 per hour, and more as businesses are actively moving to digitization. The complexity of applications is growing as well, so Site Reliability Engineers (SREs) require hours—and sometimes days—to identify and resolve problems.   To alleviate this problem, we have introduced the new feature Probable Root Cause as part of Intelligent Incident…

Reflecting on IBM’s legacy of environmental innovation and leadership

4 min read - Upholding a legacy of more than 50 years of environmental responsibility through our company’s actions and commitments, IBM continues to be a leader in driving sustainability for our business, our communities and our clients—including a 34-year history of annual, public environmental reporting, which we continue today. As a hybrid cloud and artificial intelligence (AI) company, we believe that leveraging technology is key to unlocking impact, and it will play a substantial role in how society addresses, adapts to, and overcomes…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters