Primer Series: Kubernetes on vSphere With Tanzu
In this blog
A multitude of options
VMware's latest suite of tools under the Tanzu umbrella provides many ways to run Kubernetes for modern, cloud-native applications. Multiple options come straight from VMware in the "run" portion of Tanzu, including:
- vSphere with Tanzu
- Tanzu Kubernetes Grid
- Tanzu Kubernetes Grid Integrated
All three of these can be deployed on-premises within vSphere and functionally are very close to one another. To separate them from each other, we'll focus on three characteristics by answering the following questions:
- Where the k8s management plane is running (in or on vSphere)?
- What is doing the underlying IaaS abstraction (BOSH or ClusterAPI)?
- How do operations teams interface with the platform resources (TKG UI or TKGi mgmt console)?
Running Kubernetes "in" vSphere
The first and easiest option is to run what is called "vSphere with Tanzu." In this particular instance, the "management" layer, or Supervisor cluster for Kubernetes, is actually fully integrated directly into vSphere. Although you technically can run workloads within the default namespace, it is highly recommended NOT to do so. As a result, once vSphere with Tanzu is turned on (quite literally), it looks and behaves exactly like TKG (below) going forward:
- Developer Interface: kubectl
- Operations Interface: TKG UI
- Dependencies: vSphere 7
- Licensing Entry Point: Tanzu Basic
- Other names: Project Pacific, TKGe (embedded), vSphere with k8s/Kubernetes
Note: These are previously used, not current and/or not official names. This is intended only for clarification.
Running Kubernetes "on" vSphere
The next type of deployment comes in two variants from VMware and technically many options from others out there in the industry. Before we dive into those, it's best to clarify what we mean by "ON" vSphere, and luckily this is very easy for us to do because it's how all workloads are currently deployed on top of vSphere today. Nothing embedded into the kernel or anything deployed to the hypervisor is required to utilize these solutions. There are two options from VMware and can be easily mistaken for one another due to how similar they are.
Tanzu Kubernetes Grid (TKG)
TKG's origins come from VMware's acquisition of Heptio and is a from-the-ground-up internal development of a new container platform based on vanilla Kubernetes. It utilizes other open-source CNCF technologies like ClusterAPI (the IaaS abstraction layer) as well, making it a true industry follower and standard. The TKG Management Cluster containing the default k8s namespace, amongst other platform components, runs alongside the rest of the workload clusters and is deployed just like other vSphere workloads:
- Developer Interface: kubectl
- Operations Interface: TKG UI
- Dependencies: vSphere 6.7+
- Licensing Entry Point: Tanzu Basic (on-prem only)
- Other names: Heptio and TKGm (multicloud)
Note: These are previously used, not current and/or not official names. This is intended only for clarification.
Tanzu Kubernetes Grid Integrated (TKGi)
TKGi's origins come from VMware's acquisition of and joint development efforts with Pivotal. Together the two companies made PKS, or Pivotal Kubernetes Service, which became TKGi. TKGi has several architectural differences compared to TKG. For instance, its IaaS abstraction layer is BOSH, and it depends on certain IaaS functionalities like NSX. Otherwise, it functionally has the same number of architectural boxes fulfilling the same high-level functionality.
- Developer Interface: kubectl
- Operations Interface: TKGi Management Console & CLI
- Dependencies: vSphere, NSX-T. & BOSH
- Licensing Entry Point: Individual (a la cart)
- Other names: VMware PKS, Pivotal Kubernetes Service and Pivotal Container Service
Note: These are previously used, not current and/or not official names. This is intended only for clarification.
All the others "on" vSphere
Almost all the major on-prem Kubernetes-based container platforms support the ability to be deployed on top of vSphere out of the box — in many cases, it's the only on-prem option. This includes many of the technologies we support at WWT via our container platforms practice, which we partner with closely. These include the following:
What about Tanzu NOT on vSphere?
One of the major benefits behind Tanzu in the first place is the ability to not only run it in or on vSphere but also natively in any of the major public clouds. In fact, the overall architecture and approach are very similar to the on-prem approach. TKG and TKGi function similarly in this regard.
Take a look at TKG, for example:
In these particular instances, really the only difference has to do with licensing and where the actual deployment happens to reside. In the case of TKG, the ability to run it "anywhere" on-prem or otherwise moves the license entry point up from "Tanzu Basic" to "Tanzu Standard." Licensing for TKGi remains the same in that it's purchased separately.
Where to begin?
VMware offers many different options based on application needs and the teams both making and supporting cloud-native applications. The short answer here is that there really isn't one that stands out from the others without determining those needs upfront — and we can help out with that.
One thing does stand out on this topic, however: vanilla Kubernetes isn't easy to deploy, and operational teams are trying to get out in front of this business need. It can be done more easily with Tanzu. In the case of vSphere with Tanzu, it can literally just be enabled from a standard vSphere 7 deployment. Additionally, no matter which version is used and no matter where it's deployed, all the platforms use vanilla Kubernetes, and that means developer and container operations teams' interface is the same and predictable: kubectl.
That's a huge win!