We attended the recent Tectonic Summit in New York and it was a great chance to hear about the progress the Kubernetes community is making.
Our focus, from an OpenStack perspective, was to make clear that we are here to listen and collaborate. We are producing complementary technologies and we want to create better integration points and a seamless experience for our users.
We don’t want to duplicate efforts across the communities. For example, our development teams should especially take a look at the new Kubernetes 1.5 release to determine where tools like kubeadm might fit and those working on containers might take a look at Kuryr and Cinder and Swift which have already done the hard work to integrate enterprise technologies.
Jonathan Donaldson from Intel, Mike Saparov from CoreOS, organizers of the event, and Jonathan Bryce from the OpenStack Foundation participated on a panel moderated by Donnie Berholkz from 451 Group about the future of OpenStack and Kubernetes.
— Tectonic Summit (@TectonicSummit) December 13, 2016
It was a great discussion, so I thought I would share some of the most important questions and points here:
Berholkz kicked it off with a stat from 451 Group research showing OpenStack users are two- to five times more likely to be using containers than organizations who aren’t using OpenStack. He asked the panelists why they thought this might be the case?
The panelists all agreed that the technologies are inherently complementary. In short, Bryce said that in order to take the best advantage of application frameworks like Kubernetes, you need programmable infrastructure like OpenStack. The technologies are complementary and having OpenStack serve as the integration engine for your infrastructure and application stack allows users to quickly roll out technologies like Kubernetes without going through the process of re-integrating it with key enterprise systems. If you want to run these technologies together, the key to that is the network.
Should one run on top of the other, or should they run beside each other?
Jonathan Donaldson urged everyone to move beyond thinking of virtualization and container technologies as mutually exclusive. “We need to stop talking about VMs OR containers, and recognize for most organizations is VMs AND containers,” Donaldson said. He pointed out that each technology provides a different type of compute resource and for most users, they will have use cases that require both.
The panelists also talked about the “inception” happening with OpenStack and Kubernetes. OpenStack provides programmable infrastructure to run application tooling like Kuberentes. However, the OpenStack control plane services are long-running applications that can benefit from being orchestrated by Kubernetes. There are not yet clear lines or patterns for how the technologies intersect, but expect this to be a big focus in 2017.
What have the communities learned working on “Stackanetes?“
Mike Saparov has worked on Stackanetes, an open-source project started by CoreOS to provide a proof-of-concept system that can deploy and operate OpenStack services using Kuberetes. He said OpenStack is an application with complex requirements from Kubernetes that resulted in their team pushing updates into both OpenStack and Kubernetes. Work to turn this into a fully production ready model is also happening in the Kolla-Kubernetes project.
Does containerizing OpenStack make it as simple as helm/install?
On the previous day of the event, we heard about a new application install mechanism for Kubernetes called Helm. Berkholz asked if container images for OpenStack services would now be as simple as “helm install openstack.”
— Tectonic Summit (@TectonicSummit) December 13, 2016
The panelists discussed the current state of OpenStack deployments. Installing a multi-service infrastructure system like OpenStack is not as simple as helm install, but it’s definitely getting easier. Ultimately, the greater benefit to be gained from containerization is in the ongoing lifecycle management of distributed applications like OpenStack. Packaging the individual services in containers can make it easier to deploy, but more importantly, will make it easier to upgrade and use the self-healing capabilities of Kubernetes.
What about platform-as-a-service?
In one of the more controversial topics of the panel, Berkholz asked if PaaS was still relevant or would everyone move to container orchestration for development. Donaldson said he felt that the inherent guardrails of PaaS environments proved too limiting for many applications and that he thought the combination of flexibility with operations ease of use delivered by container orchestration would prove to be the winning combination.
— Jennifer Lankford (@jenlankford) December 13, 2016
Bryce said he felt that PaaS did have a market and that the combination of multiple technologies on top of standard infrastructure layers would prove to be the more adopted path over the long term. Saparov agreed that PaaS was a powerful tool that in his experience “usually met 80 percent of the user requirements” and that combining PaaS with VM and container technologies was the most effective deployment model.
Question from the audience: What should the Kubernetes community learn from the OpenStack community experiences?
Bryce said the rapid growth and scale of the OpenStack community presented a unique set of challenges. It’s not specific to vendor involvement, but rather the breadth and volume of contributions that has been a challenge to prioritize, manage and communicate. We’ve been working on a product working group function, but the effort requires continuous improvement.
— Donnie Berkholz (@dberkholz) December 13, 2016
If you’re interested in getting involved in these efforts, there’s a Kubernetes-OpenStack special interest group (SIG) that is defining requirements and of course the OpenStack Magnum, Kuryr and Kolla-Kubernetes team could use your support.
We are also interested in gathering more reference architectures and patterns for deploying OpenStack with container orchestration technologies, so please get in touch if you’d like to share your experience – [email protected] .