Why you should be excited about Kubernetes 1.12?
I’m a bit late writing about this release of Kubernetes. It’s already their 3rd release of 2018. Looking over the release notes and playing around with the new features is clear that the focus of the last release (making internal improvements) is continued in this release. Most notable features for this release are the support for Azure Virtual Machine Scale Sets (VMSS) and my personal favorite kubelet TLS Bootstrap.
Let’s dive in and look at the feature that I am most excited by in this release, TLS Bootstrapping for the kubelet.
Kubelet TLS Bootstrap – Now GA
Kubernetes 1.4 introduced the API to request for certificates from a central cluster Certificate Authority (CA). This enabled provisioning of client certificates for the kubelets allowing the kubelet to bootstrap itself into a TLS-secured cluster along with automating the provisioning and distribution of signed certificates.
There were, however, a couple of challenges. When the kubelet ran for the first time, it needed client credentials that had to be provided out of band during cluster startup. This made it the operator’s responsibility to provision these credentials. This was a pretty involved task to execute manually and veered on the complex side to actually automate. This meant that many operators (myself included) deployed a single credential for all kubelets. This actually prevented the use and deployment of node lockdown features (Node Authorizer and Node Restriction).
To make this process less painful, going further, SIG Auth introduced a way for the kubelet to generate a private key and a CSR for submission to the CA at the cluster level.
With this release, the next logical step in this process the certificate rotation for when certificates are approaching expiry is moving to Beta. The same mechanism that is used to generate a key locally and then issue the CSR to the cluster API server to get a certificate from the CA will be used to request for new certificates to replace ones that are expiring.
Support for Azure Virtual Machine Scale Sets (VMSS) and Cluster-Autoscaler is now stable
Azure allows you to create and manage a homogenous VM pool that can scale up and down based on demand or to a set schedule. Azure calls this concept Virtual Machine Scale Sets. It’s a very powerful concept that lets you manage scale and load balance demand across a dynamic set of VMs that are elastic based on demand allowing for the applications you run on these scale sets to have resiliency.
Kubenertes now lets you integrate the cluster-autoscaler with VMSS and allows you the ability to automatically adjust the size of the Kubernetes cluster based on schedules or traffic pressure.
A few other notable updates
RuntimeClass – This is a new resource that has been introduced to surface container runtime properties to the control plane. This is in alpha at the moment but is interesting because it will solve the feature support problem across runtimes and heterogeneous nodes.
Also in alpha is the snapshot/restore functionality for CSI. This provides a standard API via CRDs and add support to CSI volume drivers for PV snapshot and restore.
Released to beta is Topology-aware dynamic provisioning, meaning storage resources can now understand where they live. Beta support for AWS EBS and GCE PD is available in this release.
Also moving to beta is an option to allow containers within a pod to share a common PID namespace via an option in the Podspec.
Another interesting feature moving to beta is the ability to Taint Nodes by conditions. This allows users the ability to block scheduling using taints based on conditions on the node.
There is also a second beta of the Horizontal Pod Autoscaler in this release with reworked support for custom metrics and status conditions. There are also performance improvements that allow the Horizontal Pod Autoscaler to reach proper size more quickly.
Vertical scaling of pods is also in beta in this release which makes it possible to alter resource limits for pods over its lifetime.
Encryption at rest in etcd via a KMS is also in beta. There are multiple encryption providers including Google’s Cloud KMS, Azure’s Key Vault, AWS KMS, and Hashicorp Vault. This feature allows the encryption of data as its stored in etcd.
Kubernetes 1.12 is available for download on GitHub. Get cracking!