Last week, the CNCF released Kubernetes 1.18. In this new version, there are a lot of exciting new features. A lot of existing features are promoted from alpha to beta or from beta to stable. Previous releases were a bit smaller, but 1.18 is a big step forward. In this article I highlight some of the features that contribute to different aspects of the deployment of containerized applications.
Facts and figures
Before we do a deeper dive into individual improvements, let’s first look at the numbers and facts of this release. In Kubernetes 1.18, 15 features are promoted to a stable release. This means the feature has been out of the test-phase and is now generally available to everyone. Just some of the new features which are stable now:
- The option to run API server commands in “dry run” mode (test mode)
- Support “RunAsUser” for Windows containers (welcome enhanced container security)
- Extending the “hugepage” feature to avoid resource overloads
Another 5 other features have major changes. This makes the core product more significant from various perspectives. It is more likely now that those features will be promoted to stable in an upcoming version. A big plus for all of the people that contributed to it.
Two of the most compelling changes:
- Improvements in the Certificate Signing Requests which makes the handling of certificates easier and more secure. Also the process can be automated to a greater extent, making it easier to integrate into build pipelines.
- Promotion and separation of the kubectl package – which makes this package easier to maintain.
Many features are promoted from an alpha to a beta stage. At first glance, this might not mean a lot. However, keep in mind that a lot of companies also use “preview” features for their major cloud-native services. For example, the Azure preview features page. So also the progression of these features in the Kubernetes ecosystem make sense. Companies are extremely eager to try our new components and a lot of developers push these forward. Innovation is the big winner here.
Support for the Windows ecosystem
For long, Linux dominated the market of containers. Slowly, Windows is catching up. Windows containers are getting more traction and enterprises choose Microsoft Azure for their cloud-native services. Integration with Windows-based applications becomes more straightforward.
The CNCF recognizes this trend and they put significant effort in supporting the Windows ecosystem. Some of the enhancements:
- Previously released in Kubernetes 1.16 and now stable in version 1.18: Windows containers can now run as a (Windows) domain user. It means a lot to security since it’s now possible to specify a user (or a user group) which can be bound to a role which only the least possible permissions needed.
- Windows Server containers can now use “Group Managed Service Accounts” (GMSA) as an authentication mechanism. The key benefit here is to be able to connect in a more consistent and secure way to other cloud-native services like databases or APIs.
Kubectl improvements
Kubectl is one of the main ways developers and operators interact with a Kubernetes cluster. Before release 1.18, it was part of the core Kubernetes source code repository. Since this version, the source code of kubectl is restructured for a higher goal.
Storing the code in its own source code repository sounds like a small change. But it’s more than just moving it somewhere else. Decoupling makes re-use of the source code easier and also the source code is easier to maintain. Think in terms of micro-services. It makes sense since a lot of Kubernetes operators and developers use this tool on a daily basis.
Further Kubectl related improvements are:
- Kubectl diff is promoted to stable. It makes it possible to preview the intended changes to a cluster without actually executing it. Don’t forget to enable the “dry-run” feature of the API server.
- Kubectl debug is now in the alpha stage. This new feature makes it possible to create disposable containers in a running pod. Pods can be restarted based upon these containers. All of this makes debugging a lot easier. Developer experience is improved, lowering the barrier to adopt Kubernetes.
Certificate Signing Requests
Certificate management has always been a pain. Not only because of its complexity to maintain proper Certificate Authorities, but also because signing and storing certificates in a secure way is hard. Let alone the lifecycle management of those (chained) certificates. In Kubernetes certificates are everywhere – in almost every component.
Kubernetes uses a Certificate Signing Request API to handle the signing process. One of the biggest benefits of the CSR API the ability to automate the handling of certificates. Manual certificate rotations are difficult to execute consistently so it poses risks when configuration drift occurs due to manual processes. Besides this clear drawback, it slows the DevOps processes down since it is not automated and often relies on tribal knowledge. For sure this will change with the promotion of the Certificate Signing Request API to the beta stage.
Improvements to worker nodes
Worker nodes are the workhorses of any Kubernetes cluster. In Azure Kubernetes Service (AKS), Microsoft manages those Virtual Machines for you. In Elastic Kubernetes Service (EKS), AWS gives you the option to manage those worker nodes using their cloud-native service called Fargate. On a container level you still need to choose your configuration wisely to prevent problems and financial consequences.
Kubernetes 1.18 offers several improvements to optimize the usage of your infrastructure and to prevent (future) problems:
- The “Extending Hugepage Feature” is now promoted to stable. Two major improvements: it helps to prevent Pods from using more memory than the defined maximum. This in turn will make your Kubernetes cluster more stable. And the second one: reserve big blocks (in different sizes) of memory to speed up data-intensive processes. This reduces the latency of applications which helps to deploy Edge computing specific solution.
- Preventing restart loops. Kubernetes components are smart, monitoring of the status of your applications is one of the features which make it so. Sometimes an application is considered “dead” while it’s just in the process of starting up. The “startupProbe” feature is promoted to beta. Kubernetes takes more time before it marks the application as “dead”. As a result: fewer troubleshooting sessions for developers and more reliable deployments.
Storage and performance
Storage for stateful containerized applications has always been a hot topic. There are many commercial solutions on the market like Portworkx that offer their enterprise storage services.
Kubernetes 1.18 now promotes the “usage of raw block devices” from beta to stable. As of now it is not needed anymore to specify the filesystem type when using the persistent data of the block device. Yet another level of abstraction since the implementation details are hidden for the end user now. Furthermore, performance improves significantly. It helps to reduce the latency of critical applications like databases or messaging systems. Less overhead to check the data flows also means less traffic and in a “pay per request” this makes sense.
From a security perspective, there is also a big improvement: Pass Pod information in CSI (Container Storage Interface) calls. Simply said, this feature allows auditing of the usage of (data) volumes. Whatever organization runs the Kubernetes cluster, it is vital to protect their precious data – especially in the public cloud. Auditing keeps track of who accesses the data and what that person or system did with it.
More to explore
Besides the improvements in the previous sections, there is more to explore. A number of other features include:
- Extended use of Kubernetes Service Accounts. The new (alpha) feature is called “Provide OIDC discovery for service account token issuer”. In short it means the Kubernetes API Server is not the only place anymore to authenticate the tokens being used by Kubernetes Service Accounts. It is now easier and more secure to authenticate services from within the perspective of Kubernetes. This lowers the barrier to integrate with other (cloud-native) services.
- The Kubernetes API server is now capable of executing “dry-run” commands. It lets you create real API requests without affecting the current state of the cluster. Components/features which would benefit are admission controllers, validation webhooks, and more. This feature also works in close collaboration with the previously mentioned feature kubectl diff.
- Force to run workloads on specific nodes. It is now possible to specify which kind of worker nodes you have deployed in your cluster (e.g. Linux or Windows-based nodes). With the help of this feature, you can now specify on which (Windows) node a Pod should run. The new feature is called run-time class on Windows.
- Immutable secrets and configmaps. In previous versions of Kubernetes, secrets like passwords, certificates, etc could easily be overwritten with new values. Sometimes these values are incorrect, your application would fail after the change. Protect your secrets and configmaps and mark them as “immutable”.
It would be impossible to describe all new and promoted features. For the complete list, please check out the official announcement.
Cloud-native Adoption
One of the easiest ways to install Kubernetes is to use Kubeadm. This helps you to set up practically the entire cluster and all of its components. What about the large public cloud providers that offer Kubernetes as a cloud-native service?
- Microsoft Azure supports Kubernetes up until version 1.16. At present, version 1.17 is in preview mode.
- Founding father of Kubernetes, Google, offers GCE. The default version is 1.14, while 1.15 is also available. 1.16+ is available in the “rapid release channel”.
- Compared to the other cloud providers, Amazon EKS is a bit behind. In a recent post, they mentioned the support for Kubernetes 1.15. On May 11th Amazon will start to deprecate Kubernetes 1.12, so the oldest version being supported is 1.13.
Check out this very good comparison table for more (slight outdated) info.
Conclusion
Kubernetes 1.18 is a major step forward. Furthermore, stability, security and automation all get a big upgrade with all of these great new features. A lot of operators and developers are very enthusiastic about it, so am I. Can’t wait to test it out.
One final word: be sure to check out the new logo as well 🙂
