What’s new in Kubernetes 1.19

Thanks to Sascha Grunert for the technical content of this post. In addition to being a member of the Containers Squad of the SUSE CaaS Platform team, Sascha is Technical Lead in the Kubernetes Release Engineering Subproject, which is part of SIG Release. He participated in many Kubernetes release cycles from different roles and is thrilled to give you an update about the next version.

SUSE congratulates the Kubernetes Project on another evolution of the most popular container orchestration and management platform, which forms the basis of our SUSE CaaS Platform. You can expect to see Kubernetes 1.19 supported in a future SUSE release.

Now let’s turn the keyboard over to Sascha…

Overview

On August 27th the Special Interest Group (SIG) Release published the next milestone in container orchestration software. This time we decided to stretch the release cycle from the usual three to more than four months. The general idea behind this decision was to slow down the development and reduce the stress for the contributors and consumers of Kubernetes, particularly in the time where so many of us are making work process adjustments for COVID-19. Let’s have a look if we managed to achieve that goal.

At the time of writing this blog post (a few days before the release), there are currently 3757 commits which made it into the master branch between v1.18.0 and the latest release candidate (RC) v.19.0-rc.4. But not all of those commits contain user facing changes: only 395 release notes are part of the latest RC. That’s about 100 release notes more than usual, which maps directly to the increased release cycle time span.

A good way to get an overview about what is currently going on in Kubernetes development is to have a look at the current Release Notes version. Let’s have a look at some highlights of the release.

Security Fixes

Two Common Vulnerabilities and Exposures (CVE) will be fixed in Kubernetes v1.19.0.

The first one is CVE-2020-8559, which allows a privilege escalation from a node inside the cluster. This means if it is possible to intercept certain requests to the Kubelet, then an attacker could send a redirect response that may be followed by a client request using the credentials from the original request. This can lead to compromise of other nodes inside the cluster.

The other fixed vulnerability is CVE-2020-8557. This CVE allows a Denial of Service (DoS) via a mounted /etc/hosts file inside a container. If a container writes a huge set of data to the /etc/hosts file, then it could fill the storage space of the node and cause the node to fail. Root cause for this issue was that the kubelet does not evict this part of the ephemeral storage.

Feature Highlights

Seccomp, or Secure Compute Mode, has been graduated to General Availability (GA). Seccomp makes it possible for DevSecOps to create “guard rails” around containers or pods by guaranteeing that they are permitted to execute only the system calls that are required for their code. This prevents many privilege escalation exploits. A new ‘seccompProfile’ field has been added to the pod and container securityContext objects. (The support for seccomp.security.alpha.kubernetes.io/pod and container.seccomp.security.alpha.kubernetes.io/... annotations are now deprecated, and will be removed in Kubernetes v1.22.0. Right now, an automatic version skew handling will convert the new field into the annotations and vice versa.)

The Kube Scheduler config kubescheduler.config.k8s.io has been graduated from v1alpha2 to v1beta1. This API makes it easier for developers of alternate scheduler plugins to configure their code without tinkering with command line options. There is some manual action required when moving to the new API, but the corresponding Kubernetes Enhancement Proposal (KEP) should provide all the necessary details about the change.

The Kube API Server’s componentstatus API is now deprecated. This API previously provided status of etcd, kube-scheduler, and kube-controller-manager components. A main drawback of this API was that it only worked when the components were local to the API server and exposed unsecured health endpoints. Instead of this API, etcd health is now included in the kube-apiserver health check and kube-scheduler/kube-controller-manager health checks can be made directly against those components’ health endpoints. This provides mechanisms for health checks that are both externally accessible and more secure.

CustomResourceDefinitions now features support for marking versions as deprecated by setting spec.versions[*].deprecated to true, and for optionally overriding the default deprecation warning with a spec.versions[*].deprecationWarning field. This will make it possible for developers of Custom Resources and Custom Resource Definitions (CRDs) to prepare consumers of their enhancements for the need to upgrade their code.

SetHostnameAsFQDN is now a new field in the PodSpec. When it is set to true, then the fully qualified domain name (FQDN) of a pod is set as hostname of its containers. This helps eliminate confusion in the management of hostnames.

Other Changes

CoreDNS has been updated to v1.7.0. This is a backwards-incompatible release; for example, the metrics names have been changed, and the federation plugin has been removed.

The Kubelet now features initial support for cgroups v2. This means that it is now possible to run the kubelet on hosts which use cgroups v2 unified or standalone mode.

Kubernetes now uses Golang version 1.15.0 for its builds. Besides that, Kubernetes no longer supports building hyperkube images. If you’ve seen relying on that in the past, please switch over to the new Debian distroless container images.

There are have many changes in conjunction with Kubeadm. For example, the kubeadm config view command has been deprecated and will be removed in a feature release. Kubeadm now distinguishes between generated and user supplied component configs, regenerating the former if a config upgrade is required.

Another change to highlight is that Kubeadm now respects user specified etcd versions in the ClusterConfiguration and properly uses them. Kubeadm now respects the resolvConf value set by user even if systemd-resolved service is active. The kubeadm config upload command is now finally removed after its deprecation. If you still rely on it, please, use kubeadm init phase upload-config instead.

Some API fields have been deprecated, like apiextensions.k8s.io/v1beta1 (in favor of apiextensions.k8s.io/v1), apiregistration.k8s.io/v1beta1 (in favor of apiregistration.k8s.io/v1), authentication.k8s.io/v1beta1, authorization.k8s.io/v1beta1, autoscaling/v2beta1 (in favor of autoscaling/v2beta2) and coordination.k8s.io/v1beta1.

Custom Endpoints are now mirrored to EndpointSlices by a new EndpointSliceMirroring controller. The Kube Proxy now consumes EndpointSlices instead of Endpoints by default on Linux.

The CertificateSigningRequest API has been promoted to certificates.k8s.io/v1. This implies some changes to the API; for example, spec.signerName is now required and requests for kubernetes.io/legacy-unknown are not allowed to be created via the certificates.k8s.io/v1 API.

We have many changes to kubectl. For example, it is now supported to create a deployment with replicas and a specified --port. kubectl annotate now has a --list option, whereas the deprecated --server-dry-run flag has been removed from kubectl apply. kubectl config view now redacts bearer tokens by default in the same way it did to client certificates. The kubectl alpha debug command now supports debugging pods by copying the original ones. It also supports debugging nodes by creating a debugging container running in the host namespaces of the node.

Summary

This is by no means a complete list of changes in Kubernetes v1.19.0. As usual, every Kubernetes release comes with a huge bunch of fixes, features, deprecations and enhancements. If you like to dive deeper into the recent changes, then I recommend giving the current release notes version a look.