VMware Foresees a Future Where Photon, Kubernetes, and NSX Work on Bare Metal – InApps Technology 2022

For a firm often portrayed as “the hypervisor company,” it’s astonishing to see VMware enabling a future for itself in data centers where hypervisors may be completely absent. While VMware’s vSphere Integrated Containers (VIC) are designed to work with its ESX hypervisor, its Photon platform addresses the exclusive needs of the new and emerging class of servers that is the pre-eminent focus of this publication: scalable clusters.

Last year at VMworld in Las Vegas, VMware executives promised Kubernetes support for VMware’s Photon container host, allowing open source orchestration to work with its NSX network virtualization platform. Thursday morning, the company took the next big step in that direction, telling InApps Technology it is launching a beta of a project that will link Photon to the Kubernetes container orchestration engine by way of Kubernetes’ own Container Network Interface (CNI).

This way, acknowledged VMware’s NSX vice president Milin Desai, in an interview with InApps Technology, Kubernetes should be able to support network microsegmentation directly — subdividing networks not just per-application but per-function, according to rules. In a microservices environment, he told us, microsegmentation will be feasible on a per-pod basis.

“Through the Kubernetes interface, you are now able to create networking and segmentation policies, which are delivered by NSX,” said Desai. “You can always pre-create an overlay network, and then poke a container into a Kubernetes pod on top of it. But in this case, you are orchestrating as part of the DevOps workflow, through the Kubernetes CLI, through the CNI, into NSX, which then delivers a network on-demand, delivers a security group on-demand, and allowing for seamless integration.”

NSX-T is VMware’s alternative version of the NSX platform, designed to enable support for an alternate, open source hypervisor such as KVM, or to manage network virtualization on bare metal.  VMware hasn’t talked much about NSX-T publicly until now, although privately it was being developed last year under the code name “Transformers,” and was designed to replace a component called NSX Edge (not intended to be said three times real fast) in certain situations. NSX Edge was originally intended to serve as a network services gateway or as a remote, logical router, but folks discovered it also had the advantage of extending an NSX virtual network to bare metal.

Up to now, the problem with containerization with seemingly infinite scalability is that it appears impossible to confidently secure. Marrying the microservices model with today’s security frameworks was a topic of last year’s RSA Security conference — one that appeared to have as much hope of being reconciled as the U.S. President with Sally Yates.

Solutions that bolt microsegmentation onto Kubernetes have been suggested before, but have typically involved disabling the Kubernetes proxy process and grafting an open source network controller. VMware’s new solution with NSX-T does appear, at least for now, to be a bit less messy. It’s being arrived at in concert with the Kubernetes community, according to Desai, and it uses the orchestrator’s existing CNI framework.

Last November, Cloud Foundry began implementing a pluggable networking stack it calls netman-release, which its Foundation described as a transitional system that will move its users to a new networking model over time. Since that stack is based around the Flannel networking fabric, which was designed for Kubernetes and intended for use with CNI, Desai pointed out, this opens up new avenues for direct programmability of the network layer using Java, Ruby, or Go. He said all of VMware’s contributions to this effort will be made “public,” though that may be one step shy of complete open source involvement.

In its current, beta incarnation, the Kubernetes + Photon pairing does require a hypervisor for its underpinnings. But as the project develops, Desai told us, it is VMware’s intention to let customers deploy Photon on bare metal, using NSX-T for the network layer and Kubernetes as the orchestrator.

“The combination of Photon Platform, NSX-T, and Kubernetes running on top, is what we at VMware are trying to achieve going forward,” stated Desai, “to completely automate the end-to-end delivery of containers in a secure way. The infrastructure almost becomes invisible. Photon delivers a single infrastructure API into Kubernetes, setting up pods, securing them, and scaling them super-efficiently going forward.”

Desai acknowledged that, if the ongoing CRI-O project were to be added to the mix, it would conceivably become possible to automate the deployment of container images from their repositories, in direct response to network conditions, without the involvement of container engines such as Docker or CoreOS rkt.

Last August, VMware officials told InApps Technology that Photon would eventually attain a scheduling and orchestration component. If this Kubernetes project proceeds as planned, VMware may not need — or want — to make one.

Feature image: The cover of Wonder Stories magazine, February 1932, in the public domain.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.