The next Kubernetes release is right around the corner and we’re all wondering what is new in this version. In this blog post we’ll check out some of the exciting new features of the upcoming release.
Getting an Overview
Kubernetes is one of the largest open source software projects these days, which can be expressed in numbers as well: A tremendous amount of 3412 commits have made it into the release v1.18.0 so far. This is a slight increase to the previous release since we had 3289 commits for v1.17.0, but in general the rough average for a new Kubernetes version. Only round about 10 percent of those commits contain an actual user-facing change, which means that we end up having 337 release notes entries. That is around 35 A4 pages full of release notes! The Kubernetes SIG Release team ensures that those release notes are of a high quality and reworks them manually for every minor release.
The source for this manual rework is the output of the Kubernetes Release Notes Generator, which collects the data from the previous minor release candidate v1.17.0-rc.1 to the latest state of the release-1.18 branch. The current output of these generated release notes can be found in the GitHub repository of SIG Release. The Release Managers of SIG Release will cut v1.18.0 on March 24th, whereas krel (the Kubernetes Release toolbox) will pick up these notes and push them into the official Kubernetes GitHub repository.
But how can we get an overview about this immense amount of changes? Well, for data scientists it’s a common practice to find the bag of words during natural language processing of such data sets. I did exactly that based on the currently available release notes. This is how it looks like for Kubernetes v1.18.0 if we display the bag of words in word cloud:
That’s an interesting start. It looks like that changes regarding
kubectl are major topics for that release. Let’s have a closer look at what happened to kubectl for example.
One feature worth to mention is that kubectl now contains a kubectl alpha debug command which allows attaching an ephemeral container to a running pod for the purposes of debugging (#88004).
There are other smaller changes done to kubectl, for example when deleting objects using kubectl with the
--force flag, then we’re no longer required to also specify
--dry-run flag now accepts the values client, server, and none. This allows us to support client-side and server-side dry-run strategies. The support for server-side dry-run in kubectl has been extended for commands like apply, patch and create as well (#87580, #87714, #88292).
ConfigMap values can now be marked as immutable. If these are set to
true, then changing the resources will be rejected. In any case, the deletion of those objects is still possible (#86377).
Kubernetes introduced a new
FsGroupChangePolicy field to allow users to specify the
fsGroup permission change policy for Pods. This allows for example to only change the file permissions on a storage mount if the root level file system does not match the expected
Horizontal Pod Autoscaler (HPA) API
Kubernetes added an HPA API, which allows users to scale the behavior of the HPA to be configured. Different behaviors can be specified separately for scaling up and down. Beside that, in each scaling direction a stabilization window can be specified as well as a list of policies and how to select amongst them. These policies can limit the absolute number of pods added or removed, or the percentage of pods added or removed. For example, such a behavior definition could look like:
behavior: scaleUp: policies: - type: Percent value: 100 periodSeconds: 10 scaleDown: policies: - type: Pods value: 2 periodSeconds: 30
This means pods can be scaled up every 10 seconds and scaled down to 2 pods every 30 seconds. (#74525).
Kubernetes is already capable of running multiple Schedulers, which can drastically increase the complexity when it comes to debugging scheduling scenarios at large scale. To solve this problem, the community introduced Scheduler Profiles which can apply to one single scheduler. This means that cluster operators now can offer different scheduling behaviors for a different set of pods (#88087).
Kubernetes supports the allocation and consumption of pre-allocated huge pages by applications in a Pod. The feature is already generally available, but now got support for multiple size huge pages on a container level (#84051). Beside that, huge page stats are now added to Allocated resources in kubectl describe node (#80605). It is also possible to support pre-allocated huge pages for more than one size now (#82820).
It is always worth an effort to have a look at the latest API deprecations in Kubernetes to ensure that the application deployment works in the same way as before an Kubernetes upgrade. For example, just some deprecations of v1.18.0 will be:
The Kubernetes API Server will no longer serve deprecated APIs like
replicasets and other resources (#85903).
The Kubelet resource metrics endpoint
/metrics/resource/v1alpha1 as well as all metrics under this endpoint have been deprecated (#86282).
All generators from kubectl run have been removed and they will now only create pods. Additionally, all the flags that are not relevant anymore have been deprecated as well (#87077).
These are by far not all the new changes worth mentioning, but that should be enough for my wrap-up of the changes coming to Kubernetes v1.18.0. If that is still not enough information for you and you need more details, then I’d like to point you to the official Kubernetes Release Notes Website or the change log file, which will contain all the details if the release is done.