Kubernetes is getting a major update to enhance the features and fix the bugs for the enterprises adopting modern containerized systems. The latest version, Kubernetes 1.12, focuses on trust and stability.
This is the third major Kubernetes release this year. The releases are important because Kubernetes is a prominent orchestration tool for software containers. It allows developers to build apps and deploy containers at scale.
Kubernetes 1.12 will bring a number of new features, including TLS bootstrapping, and improvements to multitenancy, autoscaling and CSI support.
The main feature is the TLS Bootstrapping which has graduated to general availability. It is a security feature that streamlines ability of Kubernetes to add and remove nodes to the cluster.
“Security is a cornerstone of what we aim to provide with Kubernetes. Since Kubernetes 1.4, we’ve been working on a framework to provide cluster operators the ability to manage TLS assets for the Kubernetes control plane components and the kubelet,” wrote Stephen Augustus, Kubernetes project manager, CoreOS, in a blog post.
Improvements have been made to the Container Storage Interface (CSI) to provide a stable framework for presenting storage to clusters. This will be specifically useful for enterprises that move more and more stateful workloads into Kubernetes.
When the enterprises have the storage geographically distant from Kubernetes, they face issues related to latency and reliability. The latest Kubernetes version will address these issues.
The CSI will now support notion of topology awareness. With this functionality, the stateful workloads will have a conceptual understanding of location of the resources, whether it is a rack, datacenter, availability zone, etc.
Kubernetes 1.12 also comes with ability to support priority on several resource quotas through the ResourceQuotaSelector feature. This is aimed to make the multitenancy capability even better and enhance the existing priority and preemption feature.
Talking about the network security, a couple of network policy components are graduating to general availability. These components include egress and ipBlock. While the egress allows admins to define the way network traffic leaves a Pod, the ipBlock enables them to define CIDR ranges in NetworkPolicy definitions.
Image source: CoreOS