Beyond Expectations: OpenStack via Kubernetes Helm (Fully Automated With Digital Rebar)
Service provisioning and persistent data, while necessary for OpenStack, pose problems in Kubernetes. Fortunately, one team has found a way around those.
Join the DZone community and get the full member experience.Join For Free
I’ve been an outspoken skeptic of a Joint OpenStack Kubernetes Environment (my OpenStack BCN preso, Super User follow-up, and BOS Proposal) because I felt that the technical hurdles of cloud-native architecture would prove challenging. Issues like stable service positioning and persistent data are requirements for OpenStack and hard problems in Kubernetes.
I was wrong: I underestimated how fast these issues could be addressed.
The Kubernetes Helm work out of the AT&T Comm Dev lab takes on the integration with a “do it the K8s native way” approach that the RackN team finds very effective. In fact, we’ve created a fully integrated Digital Rebar deployment that lays down Kubernetes using Kargo and then adds OpenStack via Helm. The provisioning automation includes a Ceph cluster to provide stateful sets for data persistence.
This joint approach dramatically reduces operational challenges associated with running OpenStack without taking over a general purpose Kubernetes infrastructure for a single task.
Given the rise of SRE thinking, the RackN team believes that this approach changes the field for OpenStack deployments and will ultimately dominate the field (which is already mainly containerized). There is still work to be completed: some complex configuration is required to allow both Kubernetes CNI and Neutron to collaborate so that containers and VMs can cross-communicate.
Published at DZone with permission of Rob Hirschfeld, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.