Well actually, it was released last week, but we’re excited to announce that as of today it is fully supported on the Containership platform! While we’ve been busy integration testing support for the new version in Containership, hopefully you’ve found some time to check out all of the changes released with the newest version of Kubernetes. If you haven’t yet found the time, hopefully this post will serve you well. Below is a high-level overview of the major themes included in the release.
API aggregation has officially been upgraded to stable, and is ready for production. A number of improvements have been made to webhooks, including alpha support for self-hosting authorizer webhooks.
The groundwork has been laid for implementation of additional authentication methods with the release of the external client-go credentials provider, and the TokenRequest API. Additionally, cluster administrators can now limit node access to the API, as well as define what contexts a Pod can run in through the use of Pod Security Policies.
Azure users now have alpha access to Virtual Machine Scale Sets as well as support for cluster autoscaler! That means Azure users will be able to automatically adjust their Kubernetes cluster when a pod fails to run due to a lack of resources or when there are nodes that are not being used for an extended period of time.
On the networking front, end users now have finer control over a pods network configuration. Now in beta, users can specify a custom resolv.conf, as opposed to relying on cluster DNS. Additionally, NodePort IP addresses can now be specified. Last but not least, the default DNS plugin can now be changed to the beta CoreDNS plugin.
A significant subset of Kubelet configuration can now configured through a versioned config file. Alpha support is now available for configuring whether containers within a pod share a process namespace, and CRI has been upgraded to add support for Windows Container Configuration. Additionally, three features have been graduated to beta in this release:
- CPU manager allows users to request exclusive CPU cores to improve performance for a variety of use cases such as applications that benefit from CPU cache residency.
- Huge Page allocation and consumption is now tunable for memory intensive applications
- The Device Plugin feature provides a framework for vendors to advertise resources to the Kubelet, without modifying any core Kubernetes code.
Local storage and Persistent Volumes gain additional power with this release. Through the use of mount namespace propagation, containers can mount volumes as either rslave or rshared, such that host mounts can be seen within the container, or mounts made within the container can be seen from the host, respectively. Resource requests and limits can now be set on local ephemeral storage resources through Capacity Isolation. In addition, you can now create Local Persistent Storage, enabling PersistentVolumes to be created using local disks, as opposed to solely network-attached volumes. It is important to note that it is now impossible to delete storage resources which are in-use by a Pod. Also included is Topology Aware Volume Scheduling for local persistent disks, stable detailed storage metrics, and beta support for out-of-tree CSI volume plugins.
With 1.10.0, container CPU resources, image filesystem stats, and flexvolumes have been enabled. It is also worth noting that experimental support for Hyper-V isolation of single container pods has been included.
For an exhaustive list of changes, check out the official changelog.
As of today, support for attaching 1.7.x clusters will be deprecated in favor of support for the latest and greatest: 1.10.0. Moving forward, we will continue to support a sliding window of three stable minor versions of Kubernetes. Support in the platform now officially includes versions 1.8.x through 1.10.x. It is important to note that the removal of 1.7.x support will only affect attaching new clusters in the UI. All 1.7.x clusters which are already attached will continue to operate as expected. To continue to receive updates to any plugins, including our Containership agent & coordinator, simply upgrade your cluster to at least Kubernetes version 1.8.x!
Hopefully this overview was helpful in digesting what’s new in 1.10. We are excited for you to try out some of these new features within Containership! Please let us know if you have any questions or comments, and keep an eye out for automated provisioning and management of your 1.10 clusters in the near future!