On the second week of May, just after the end of the Japanese Golden Week, I went to Boston for 2017’s first OpenStack Summit. In a previous article I talked about the sessions related to OpenStack itself .
In this article I want to talk about the special sessions that were held about Kubernetes and NFV. What these two very disparate projects have in common is that, currently, both are poised to operate as applications on top of OpenStack.
With the advent of Kubernetes (Google’s container orchestration engine), there was a shared feeling in the community that we may be on the verge of a paradigm shift in private cloud, from OpenStack into Kubernetes. However, multiple speakers, including Google’s Cloud Platforms CTO Brian Stevens (previously an OpenStack board member), pointed out that Kubernetes is not designed to deal with the infrastructure. In their vision OpenStack does a very good job of managing that, and Kubernetes can be built on top of it to orchestrate the containers where the actual applications reside . In Canonical’s words, “OpenStack is like a spreadsheet of your infrastructure, Kubernetes is the same for your containers”. That said, it was pointed out that not all of the available OpenStack functions would be required in such a scenario. I wouldn’t be surprised if a lighter version of OpenStack, giving just essential support to Kubernetes, is discussed in a future release.
In this model of Kubernetes on OpenStack, perhaps unexpectedly, the burden of installing and maintaining the OpenStack components over a large array of machines is left to… Kubernetes! CloudOps, among multiple other speakers, considered TripleO to be a worthwhile effort, but ultimately too complicated for normal use. Instead, Kubernetes can be installed in individual machines to launch and orchestrate containers that hold the different parts of OpenStack. A new Kubernetes instance can then be built on top of OpenStack with full, transparent access to the whole infrastructure. The underlying Kubernetes also helps with high availability and upgradeability (it’s easy to swap containers).
CloudOps and AT&T introduced Helm as a new project in the OpenStack family that can help with the installation of OpenStack on top of Kubernetes . In their words, “Helm is the Kubernetes package manager, designed to manage the entire lifecycle of an application running in Kubernetes”. They seem to have learnt one or two things from Terraform, e.g. numerical values (for example, replica numbers) are removed from the manifest and are instead written in a separate variables file.
Terraform itself was also discussed by Mirantis . Despite the power of the platform, and how well it can manage hybrid clouds, they highlighted its steep learning curve, and how easy it is to break your whole infrastructure if you are not careful with it. A member of the audience commented that it may still be a bit immature for use with OpenStack. Their main issue seemed to be with the update rollout, which Terraform usually handles by dropping all existing virtual machines and creating them anew, losing state and data in the process.
NFV (Network Function Virtualization) is also a very hot topic among carriers of every size . Using OpenStack as a platform, the carriers want to virtualize most of the functions that are nowadays performed by special hardware. This will allow for faster introduction of new technologies, resizing of the network, and updates rollout. However, it was apparent in many of the sessions that there is no clear consensus yet on what direction to take.
Both Kubernetes and NFV have great potential for the immediate future. There are some obstacles that need to be overcome, but if they can manage to do it they have the community interest and the industry support to become as ubiquitous as OpenStack.