Our OVHcloud Managed Kubernetes product has now been available for more than one year on general availability. From now on, Kubernetes version 1.19 is certified by the CNCF on our platform.
Kubernetes is in constant evolution and amelioration, every new version brings a lot of new feature and fixes. The 1.19 is not the exception:
Finally, we have arrived with Kubernetes 1.19, the second release for 2020, and by far the longest release cycle lasting 20 weeks in total. It consists of 34 enhancements: 10 enhancements are moving to stable, 15 enhancements in beta, and 9 enhancements in alpha.
So what’s new in Kubernetes 1.19?
You can find the whole change list in the official release notes, and a more casual reading version on the Kubernetes blog, but in this post we want to have a look to some of the (in our highly subjective point of view) major themes in this release:
Ingress graduates to General Availability
Ingress is a Kubernetes API object that manages external access to the services in a cluster, typically HTTP. It may provide load balancing, SSL termination and name-based virtual hosting.
Ingress is nowadays a central feature of Kubernetes, widely used in production. And surprisingly enough, it was still officially a beta. By graduating it to GA, the Kubernetes community acknowledges its importance and its de facto standard status. And of course, it opens the way to working on an Ingress v2, or some extensions, to give it even more features.
To get an overview of what’s Ingress and how does it compares (and interacts with) other ways to get external traffic into your Kubernetes cluster, you can read our Getting external traffic into Kubernetes – ClusterIp, NodePort, LoadBalancer, and Ingress post.
An you can of course find more informations about Ingress at the official documentation.
Avoiding permanent beta API Versions
Ingress isn’t the only API that have been in beta status for ages, in fact it’s only one of the numerous examples of a semi-permanent beta status for new APIs, where widely used features remain as beta release after release even if they are considered production-ready by most users.
From Kubernetes v1.20 and onwards, SIG community have decided of a new policy is to avoid features staying in beta for a long time: when a new feature’s API reaches beta, that starts a countdown. The beta-quality API now has three releases (about nine calendar months) to either:
- reach general availability (GA), and deprecate the beta, or
- have a new beta version (and deprecate the previous beta).
More informations in this Kubernetes blog post.
Increase Kubernetes support window to one year
Until this release 1.19, minor versions of Kubernetes had a support window of nine months, from Kubernetes 1.19 onwards, the support window for minor releases increases to one year.
As a Managed Kubernetes provider, we are particularly happy of this change, as our observations fully align with the working group (WG) Long Term Support (LTS) showing that a significant proportion of Kubernetes users didn’t upgrade in the 9-month support period.
Other APIs graduate to GA, and some new betas
Some other Kubernetes APIs that been upgraded to general availability, and the old API endpoints have been deprecated:
apiextensions.k8s.io/v1beta1->apiextensions.k8s.io/v1apiregistration.k8s.io/v1beta1->apiregistration.k8s.io/v1authentication.k8s.io/v1beta1->authentication.k8s.ioauthorization.k8s.io/v1beta1->authorization.k8s.io/v1coordination.k8s.io/v1beta1->coordination.k8s.io/v1
Some APIs also get a new beta version:
autoscaling/v2beta1->autoscaling/v2beta2
Better Logging
Dealing with logs in Kubernetes has always been a tricky task. As there was no uniform structure neither for log messages in the Kubernetes control plane nor for the reference to Kubernetes objects in the logs, automating the log management relied in ad-hoc solutions and in fine on dreaded regular expressions… In consequence, building analytical solutions using those logs, was not only complicated to develop but also hard to maintain.
Version 1.19, the SIG-instrumentation begins the migration towards a new structured log paradigm. The migration is ongoing, not all the logs are structured yet, so you still should have to handle the unstructured log messages. But the promise is that when the migration will be done, most common logs will be more easily queryable, with standardized log messages and references to Kubernetes objects.
You can get more information in the corresponding KEP (Kubernetes Enhancement Proposal) and in the system logs section of the documentation.
Did you know ?
Deprecated detection
In Kubernetes 1.19, SIG API Machinery has implemented deprecation warning on Kubernetes APIs. From this version onwards, making an API request to a deprecated REST API endpoint returns a Warning header in the response and a deprecation annotation on the audit event associated to the API call, and some metrics.
The warning includes details about the release in which the API will no longer be available, and the replacement API version. The idea is to inform both the end-user and the cluster administrator when deprecated APIs are used in the cluster.
To help you to upgrade those deprecated APIs, kubectl may warn you when you’re using them. the resource is deprecated. Simply use the –raw or --warnings-as-errors flag in your kubectl calls:
~$ kubectl get --raw /apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions > /dev/null
Warning: apiextensions.k8s.io/v1beta1 CustomResourceDefinition is deprecated in v1.16+, unavailable in v1.22+; use apiextensions.k8s.io/v1 CustomResourceDefinitionMore information on this Kubernetes blog post.
Ecosystem
The Certified Kubernetes Security Specialist (CKS) coming in November! CKS focuses on cluster & system hardening, minimizing microservice vulnerabilities and the security of the supply chain.
Community
Kubernetes.dev, a Kubernetes contributor focused website has been launched. It brings the contributor documentation, resources and project event information into one central location.
Some useful links
https://kubernetes.io/docs/setup/release/notes/
https://www.cncf.io/blog/2020/07/15/certified-kubernetes-security-specialist-cks-coming-in-november/
I am an SRE Engineer working on the OVHCloud Managed Kubernetes Service product, very enthusiastic about contributing to the french Cloud.