VMware Photon Platform 1.1 Goes Live, Adds ‘Kubernetes-as-a-Service’ – InApps Technology 2022

Making good on a pledge last August to develop a fully containerized platform that supported the interests of developers, on Monday, VMware released into open source version 1.1 of Photon Platform, its container-centric workload management system.

With it comes support for an orchestration mechanism VMware describes as “Kubernetes-as-a-Service,” effectively letting developers, DevOps professionals, and administrators provision and deploy Kubernetes-driven environments from a completely remodeled Photon portal. First developed by Google, Kubernetes is an open source software for orchestrating the operations of many, often interlinked, containers.

This way, developers may be encouraged to request Kubernetes environments from their DevOps teams, instead of spinning them up themselves. One of VMware’s stated goals has been to reinforce best practices in its customer organizations, one of which it characterizes as returning control of data center resources to the IT department.

Container Ecosystem, Meet the Photon Economy

Two weeks ago at KubeCon in Seattle, VMware Chief Technology Officer for Cloud-Native Apps Jared Rosoff previewed this feature for attendees. He showed an evolved form of Photon architecture, where the platform components appeared to have selective control over certain VMware ESXi hypervisors in the software support layer — rather than all of them at once. The structure appears to take into account the likelihood that most customers deploying Photon will want its container-centered environment to coexist with pre-existing VMWare vSphere environments.

Photon’s distributed control plane, said Rosoff, extends Photon’s API throughout the virtualized platform, giving the software it hosts a single, unified view of the software infrastructure. While acknowledging VMware’s NSX network virtualization platform is neither free nor open source, he told attendees that Photon 1.1 will run without NSX, as well as utilizing only the free version of the ESX hypervisor.

The story he told depicts the operator or administrator as the ultimate owner of the infrastructure, whose principal job is to set up an economy within his own organization. In this economy are categories of users — data scientists, analytics users, and software engineers among them — who all have separate sets of requirements and unique demands they place on infrastructure. Rosoff portrayed these groups as classes in a supply-and-demand system, each of whom may be appeased individually so long as they remain separate.

“You’re both operating this hardware,” said Rosoff, referring to “you” as the administrator along with these various consumption groups. “Your job as an infrastructure administrator is [with] these customer groups inside the enterprise. You’ve got to think about, ‘How do I secure each of those groups? How do I make sure they can get the resources they need? That they don’t over-extend their consumption of the infrastructure? My big data team is always trampling all over my workload, so how do I stop them from using too much capacity in the underlying architecture?’”

As a guest of KubeCon, Rosoff was certainly aware that he was speaking to members of “them” as well as “you” — to the developers who helped establish the foundation for the Kubernetes community to begin with.

So Which Slot’s the Jackpot?

Rosoff explained that a member of the developer class will have a revised Photon portal, with which he may order up the creation of a Kubernetes cluster.

“Photon actually knows what a Kubernetes cluster looks like,” he told attendees. “So what’s happening inside the control plane, [is that it] is actually creating a new cluster object, and a whole bunch of stuff is going on — it’s like a big Plinko machine inside the control plane, where it’s creating VMs and disks and etcd nodes and API masters, and actually provisioning all the underlying virtual resources to run this cluster.”

After Photon provisions the cluster, Rosoff said, the developer may then communicate directly with that cluster with the kubectl command-line tool with which he’s already familiar. But unlike a typical IaaS platform, he went on, Photon will keep track of the fact that certain VMs in the control plane — the select VMs under its command — comprise that cluster. As a result, Photon can keep tabs on the health of all the nodes that were provisioned at the time the cluster was created. If one of the nodes in the cluster dies, Kubernetes typically knows to reschedule the affected pods. But Photon reacts first in this case by actually replacing the dead node with a newly provisioned one.

“So these types of operations, like the loss of any of the VMs or networks or disks that make up your Kubernetes cluster,” he stated, “will be automatically corrected by the Photon control plane — in most cases, without any human intervention.”

Many of the folks in the Kubernetes community have already accepted their platform as the central orchestrator of their software infrastructure. Some of them are developers who have set up that infrastructure separately from the rest of their employers’ systems, sometimes on bare metal. Some still advise that a bare metal deployment for Kubernetes is much more efficient, and much more like the architecture that Google originally intended. Although CenturyLink is officially exiting the server hosting and colocation business, that company’s engineers demonstrated back in March that Kubernetes offers three times less latency on bare metal than when hosted in VMs.

But VMware’s case is that bare metal is not the foundation for an information economy. From their perspective, big data engineers will prefer a batch-driven, parallel task environment run on the Hadoop or Spark engine; marketing will want their monolithic CMS; and developers will insist on a containerized platform. While VMware is evolving vSphere into the “to-each-his-own” platform for maintaining legacy, the company is simultaneously evolving Photon with the same goals in mind, for more modern technologies.

According to the latest release notes, the newest Photon Controller 1.1 supports only version 6.0, patch release 4, of the ESXi hypervisor, and not yet version 6.5. VMware’s Lightwave version 1.0.1 supplies identity and access control. With each deployment, Photon Controller will install agents inside each instance of ESXi, and communication between the hypervisors and the Controller will be encrypted by SSL.