Four reasons to be happy about the release of Kubernetes 1.7
We’ve been keen advocates of Kubernetes since its inception, and the latest release has piqued our interest even more. As the container management system has been adopted in more production environments, it has continued to deliver significant improvements and upgrades, demonstrating that the Kubernetes community isn’t likely to become complacent anytime soon.
Kubernetes was initially implemented at Ocado Technology as a container management system for the upcoming Code for Life AI MMO game. Code for Life now has over 100,000 users internationally, so when the team started working on the MMO game, they realised they needed a system capable of processing and managing large sets of data continuously, in order for the application to run smoothly. This is where Kubernetes came into play.
In addition to Code for Life, we have also been working on another game changing Kubernetes project — Kubermesh — our revolutionary approach to on-site data. To find out more about Kubermesh read our recent blog post or visit the GitHub page.
What to look out for in Kubernetes 1.7
I spoke to Mike Bryant, the creator of Kubermesh and team leader of our infrastructure team, to find out more about the features he’d noticed in Kubernetes 1.7 that really make a difference:
1) StatefulSets upgrades
StatefulSets have been have been in existence for a couple of releases, however Kubernetes 1.7 sees the introduction of support for upgrades, which makes a previously labour intensive, manual task much easier. This is great for using databases within Kubernetes!
2) Security improvements
More security is generally a good thing. The TLS bootstrapping process has now developed in such a way that the individual agents — the kubelets on each machine — can bootstrap to get their own authentication certificate.
There’s also a great little feature called the node authoriser, which allows for unique authorisation. Previously every node had the ability to get every secret in the cluster, but now a node can only get the secrets related to pods that have actually been assigned to it.
3) Custom Resource Definitions (CRDs)
This feature was previously released in alpha (as ThirdPartyResources), and had many associated issues that needed working through. Kubernetes 1.7 introduces CRDs in beta, having taken into account user feedback from previous releases to create a stable system. This is great for extensibility, allowing you to easily build your own abstractions.
4) NetworkPolicy promotion
NetworkPolicy has now been promoted from beta to general availability. Isolation is now defined on a per-pod basis, meaning you can define what is allowed to talk to each pod. An isolated pod exclusively accepts traffic specified by the relevant NetworkPolicy.
To read more about the changes to look out for and how to upgrade to the latest Kubernetes release, visit their GitHub page today!
