Extensions V1beta1

[Leronne Washington]

Thisis working as expected. When you create an ingress object, it canbe read via any version (the server handles converting into therequested version). kubectl get ingress is an ambiguous request,since it does not indicate what version is desired to be read.

For compatibility reasons, extensions/v1beta1 has historically beenpreferred over all other api versions. Now that ingress is the onlyresource remaining in that group, and is deprecated and has a GAreplacement, 1.20 will drop it in priority so that kubectl get ingress would read from networking.k8s.io/v1, but a 1.19 serverwill still follow the historical priority.

If you want to read a specific version, you can qualify the getrequest (like kubectl get ingresses.v1.networking.k8s.io ...) or canpass in a manifest file to request the same version specified in thefile (kubectl get -f ing.yaml -o yaml)

I had the same issue and was unable to update the k8s cluster which was subscribed to release channel.

One of the reasons for this log warning generation is the ClusterRole definition of external-dns. The external-dns keep querying the ingresses in k8s cluster as per the rules defined in the Cluster role

This page explains how to prepare clusters for upgrades to GKEversion 1.22. You can find API clients making calls to deprecated APIs removedin1.22and update those clients to use GA APIs. For more detailed information, see theKubernetes deprecated API migrationguide.

Most of the deprecated APIs in Kubernetes version 1.22 are former Beta APIs thathave since graduated from Beta (v1beta1) to GA (v1). The GA APIs provide longer-termcompatibility guaranteesand should be used in place of the deprecated Beta APIs.

The Beta API versions (extensions/v1beta1 and networking.k8s.io/v1beta1) ofIngress are no longer served for GKE clusters running version1.22 or later if the cluster was created on version 1.22 or later.

However, for clusters created on GKE version 1.21 or earlier andupgraded to 1.22 on the patch version 1.22.7-gke.300 or later, you can still usethe Beta API versions until the cluster is upgraded to version 1.23. This is aone-time exception for older clusters to give you more time to migrate yourclusters from using these API versions which are removed from the open-sourceKubernetes in version 1.22.

Any clusters running GKE version 1.23 and later will no longerserve the deprecated Ingress beta APIs. Manifests using those API versions canno longer be applied. Previously persisted objects remain functional and can beviewed and updated using the new API versions, before and after upgrading to1.23.

The Beta API version of ClusterRole, ClusterRoleBinding, Role, andRoleBinding is no longer served as of version 1.22. Migrate manifests and APIclients to use the rbac.authorization.k8s.io/v1 API version.

The Beta API version of CSIDriver, CSINode, StorageClass, andVolumeAttachment is no longer served as of version 1.22. Migrate manifests andAPI clients to use the storage.k8s.io/v1 API version.

Follow the instructions to Configure Data Access audit logs with the Google Cloud console. In the Google Cloud console, select the Kubernetes Engine API. In the Log Types tab in the information panel,select Admin Read and Data Read.

You do not need to delete and recreate any of your API objects. All existingpersisted API objects can already be read and updated using the new API versions.However, we recommend that you migrate your clients and manifests beforeupgrading to Kubernetes 1.22. Learn more in the"What to do" section of the Kubernetes Deprecated API Migration Guide.

You canview deprecation insights and recommendationsto determine if your cluster is using a Kubernetes feature or API that isdeprecated. Deprecation insights are based on observed API calls to deprecatedAPIs by user agents, not the configuration of your Kubernetes objects.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

What you use to create/edit an ingress?

Because if you use a third party tool e.x. Rancher (like me), every time I edit an ingress, it gets an annotation ("apiVersion": "extensions/v1beta1") even thought I have apiVersion: networking.k8s.io/v1, created directly from kubectl.

This is working as expected. When you create an ingress object, it can be read via any version (the server handles converting into the requested version). kubectl get ingress is an ambiguous request, since it does not indicate what version is desired to be read.

That's right, but kubeadd reads the "kubectl.kubernetes.io/last-applied-configuration" annotation. Kubernetes stores the plain manifest file that was applied to create that resource as a value to this annotation. I was able to identify an ingress that was created using deprecated API from this tool.

The main difference is that port now defines explicit number and service fields here, which is drastically different than the earlier, non-stable extensions/v1beta1 version. Some of the other main changes in /V1 include:

However, the official Kubernetes documentation provides little guidance on apiVersion. This guide gives you a cheat sheet on which version to use, explains each version, and gives you the timeline of releases.

apps/v1

apps is the most common API group in Kubernetes, with many core objects being drawn from it and v1. It includes functionality related to running applications on Kubernetes, like Deployments, RollingUpdates, and ReplicaSets.

autoscaling/v1

This API version allows pods to be autoscaled based on different resource usage metrics. This stable version includes support for only CPU scaling, but future alpha and beta versions will allow you to scale based on memory usage and custom metrics.

batch/v1

The batch API group contains objects related to batch processing and job-like tasks (rather than application-like tasks like running a webserver indefinitely). This apiVersion is the first stable release of these API objects.

certificates.k8s.io/v1beta1

This API release adds functionality to validate network certificates for secure communication in your cluster. You can read more on the official docs.

extensions/v1beta1

This version of the API includes many new, commonly used features of Kubernetes. Deployments, DaemonSets, ReplicaSets, and Ingresses all received significant changes in this release.

rbac.authorization.k8s.io/v1

This apiVersion includes extra functionality for Kubernetes role-based access control. This helps you to secure your cluster. Check out the official blog post.

This was evident when we encountered the upgrade to Kubernetes 1.24, which brought an issue with service account default secrets. Consequently, it rendered the version incompatible with other Kubernetes terraform provider versions. Although it didn't cause a complete outage, it was a significant drain on our valuable time as we worked to identify the root cause of the problem.

The Kubernetes API serves as the interface to interact with a Kubernetes cluster. It allows users to query and manipulate various Kubernetes objects like pods, namespaces, and deployments. These APIs can be accessed through tools such as kubectl, via the REST API directly, or by using client libraries.

Kubernetes is a dynamic system driven by APIs, which evolve with each new release. A crucial aspect of any API-driven system is having a well-defined deprecation policy. This policy informs users about APIs that are slated for removal or modification. Kubernetes follows this principle and periodically refines or upgrades its APIs. Consequently, older APIs are marked as deprecated and eventually phased out.

In this context, deprecation implies identifying an API component for eventual removal. While it functions currently, it is scheduled to be eliminated in an upcoming version. Further details on how Kubernetes manages API deprecation can be found in the deprecation policy documentation.

When configuring an application, the user specifies the API version of the Kubernetes object to be employed. Whether it's a straightforward Kubernetes YAML manifest or a Helm chart, the apiVersion field designates the API version of the Kubernetes object. This underscores the importance for users or maintainers to be aware of deprecated Kubernetes API versions and the Kubernetes release in which they are set to be removed.

Additionally, during a Kubernetes cluster upgrade, encountering deprecated APIs is a possibility if the upgraded version does not support them. For instance, if resources in your cluster utilize an outdated API version, your application relying on that resource may cease to function if the deprecated API has been eliminated in the new cluster version.

An illustrative example is the APIVersion extensions/v1beta1 of the Ingress Resource, which was removed in Kubernetes version v1.22. Attempting to use such a removed API version in your configuration would result in an error message:

On top of that, Kubernetes abides by a stringent API versioning protocol, resulting in multiple deprecations of v1beta1 and v2beta1 APIs across several releases. Their policy states that Beta API versions are mandated to receive support for a minimum of 9 months or 3 releases (whichever is longer) after deprecation, after which they may be subject to removal.

In cases where APIs that have been deprecated are still actively employed by workloads, tools, or other components interfacing with the cluster, disruptions may occur. Hence, it is imperative for users and administrators to conduct a thorough assessment of their cluster to identify any APIs in use slated for removal, and subsequently migrate the affected components to leverage the appropriate new API version.

3a8082e126