Most feature-rich release by Kubernetes - 1.10

Kubernetes 1.10 is here! This is the first major release of 2018 for Kubernetes, which is fast becoming the largest and fastest-growing container orchestration platform. A beta version released on 2nd March provided us a taste of what was coming in the subsequent stable release on 26th March. The emphasis of this release is addressing problems in the key areas- storage, security, and networking plus key features such as the Container Storage Interface (CSI), API aggregation, and added support for hardware devices. Let's have a quick look under the hood and see what’s in store for us with 1.10.

Container Storage Interface (CSI)
CSI was introduced to Kubernetes to alleviate the pain of developing storage plugins which required plugin developers to check in code to the main Kubernetes tree. CSI aims to establish a standard mechanism for Container Orchestration systems to allow access to storage for their container workloads. Released in 1.9 as an alpha feature, 1.10 upgrades the feature to beta.
The maturity of this feature lets storage vendors have more control over their plugins and reduces the amount of work the community needs to do to get a new storage plugin approved and into Kubernetes.

API aggregation
API Aggregation has been upgraded to stable and this means that it's now possible to extend the Kubernetes API in more ways than currently allowed by CRDs. This feature means you can now run your custom functionality and register your functions so they are served alongside the core Kubernetes APIs.

An alternative to Kube-DNS
The default DNS server for Kubernetes has been Kube-DNS which includes dns-masq. In 1.10, Kubernetes now lets you switch to Core-DNS which is a CNCF project that is a successor to Sky-DNS (Kube-DNS is based on Sky-DNS). This feature is still in beta, but the number of improvements in Core-DNS have me excited. Mainly because it has fewer moving parts (single executable, single process) written in GO (memory safe). It also supports a number of use-cases that Kube-DNS doesn’t.

DevicePlugin API
DevIcePlugin API, now in beta for 1.10, is focused on the enablement of performance-sensitive workloads. This endpoint allows a stable integration endpoint for vendors to add support for devices like GPUs, FPGAs, and custom network interfaces, all without adding custom code to the Kubernetes repository.

TokenRequest API
This endpoint has been released to alpha in 1.10. It is aimed at improving the security of containers and put Kubernetes on the road to having individual identities for each running container. Currently, replicas of a container share the same identity. This feature is powerful because it opens the door to enable targeting policies to individual containers for example - deny TLS certificates to containers not running on the most secure nodes in the cluster.

Pod Security Policies (PSP)
Containers are supposed to run isolated from the host. While there are use cases that Kubernetes allows to break this isolation, it’s very dangerous from a security aspect. The flipping of the privileged flag allows access to all the host's devices. For malicious users, this is a very effective attack vector against a node. Pod security policies are designed to try and reduce this attack surface by restricting the kind of pods that can be run in a namespace. PSP will be rolled out in a phased manner, just like RBAC.

In addition to these, features such as volume resizing, topology-aware scheduling, CRI validation test suite, support for Windows Container Configuration in CRI, Azure support, and container debugging tools support show that Kubernetes, with its incrementally evolving releases, is maturing towards complete container orchestration solution. Every release is more focused on fulfilling the community’s expectations. So, what are you waiting for? Try your hands on the latest K8s; download it here.