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/v1
• apiregistration.k8s.io/v1beta1 -> apiregistration.k8s.io/v1
• authentication.k8s.io/v1beta1 -> authentication.k8s.io
• authorization.k8s.io/v1beta1 -> authorization.k8s.io/v1
• coordination.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 CustomResourceDefinition

More 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.kubernetes.dev/

https://www.cncf.io/blog/2020/07/15/certified-kubernetes-security-specialist-cks-coming-in-november/

Kubernetes is in constant evolution and amelioration, every new version brings a lot of new feature and fixes. And this version 1.18 is not the exception:

Kubernetes 1.18 consists of 38 enhancements: 15 enhancements are moving to stable, 11 enhancements in beta and 12 enhancements in alpha.

We are very proud to help our customers transit to this very flexible and amazing product: Kubernetes!

Let’s check together some of the features of this new release.

Creating ephemeral containers with Kubectl for debugging (Alpha)

Kubernetes 1.18 adds new extended debugging capabilities to kubectl, as it can now create ephemeral Pods to debug other Pods in the same namespace.

For more informations: https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container

Server-side Apply – Beta 2

Server-side Apply is a new merging algorithm, so the system knows when two actors are trying to edit the same field.

This feature can be used with the following flag when applying a manifest: kubectl apply --server-side

If you need to force the conflicts you can use the flags “--force-conflicts” and that’s it.

For more informations: https://kubernetes.io/blog/2020/04/01/kubernetes-1.18-feature-server-side-apply-beta-2/

Improvements to the Ingress API

There are 3 significant additions to this API:

• A new pathType field that can specify how Ingress paths should be matched.
• A new IngressClass resource that can specify how Ingresses should be implemented by controllers.
• Support for wildcards in hostnames.

For more information: https://kubernetes.io/blog/2020/04/02/improvements-to-the-ingress-api-in-kubernetes-1.18/

Upgrading your Cluster to Kubernetes 1.18

Additionally to automatic patch updates according to the security policy you choose in your customer panel, OVHcloud offers you to upgrade easily your cluster to Kubernetes 1.18. Let’s look at it together!

Ensure you can upgrade

We recommend you to have at least 2 nodes in your cluster and properly configured ReplicaSets to minimize the downtime. Also take care of the processing capabilities of your cluster to ensure a graceful rolling upgrade of your worker nodes.

For example, if you have 2 nodes with a CPU usage of 50%, when the first node is going to be upgraded, the second node will take the load of the first node, so you need to ensure that you are in capacity to run your applications with 1 less node.

Ensure that you have all your Kubernetes manifests up to date and applicable, it is not a good practice to directly edit the server-side deployments.

You can use the KubePug tool to help you to detect the breaking change and deprecated usages, don’t forget Kubernetes is in continuous evolution.

Upgrading your cluster

Go to your cluster on the OVHcloud Control Panel and click on “Upgrade to the next minor version of Kubernetes”.

Last, but not least

The team is also polishing a series of new features, like control of your nodes and nodes pools directly through a Kubernetes CRD. Stay tuned !