The next component I’m going to cover in vSphere with Tanzu for the vSphere Administrator is vSphere Namespaces. vSphere Namespaces are set up by the vSphere Admin, run in the context of the Supervisor Cluster and allow admins to control resource limits and other policies. We’ll go into those details below!
What is a Kubernetes Namespace?
In a large Kubernetes cluster with many projects, teams or customers there may be a need to carve out a piece to ensure fair allocation of resources and permissions. A Namespace provides that method to better share the resources of a Kubernetes cluster. It also allows you to attach policies and authorization. It can also provide the scope for Pods, Services and Deployments in a cluster. Click on the link to the Kubernetes website to learn more about Kubernetes Namespaces
What is a vSphere Namespace?
As I mentioned previously the Supervisor Cluster IS a Kubernetes Cluster and Kubernetes is great at running “platforms.” And sometimes, like in the case of a TKG cluster, that platform is Kubernetes! In this image you can see where the two types of Namespaces are used.
Figure 1 – Namespaces running Pods and TKG cluster
Now, for a LONG time in vSphere we’ve had the concepts of Resource Pools, RBAC, encryption and other vSphere features and capabilities. But what has been missing is a wrapper of sorts that a vSphere administrator could leverage to make Day 2 operations easier. Each feature or component is normally manipulated individually or as part of a tool like a PowerCLI script.
vSphere Namespaces has the potential to change all of that. With vSphere Namespaces I can give a project, team or customer a “sandbox” they can play in. They can’t see the other sandboxes and they can’t expand past their sandbox limits. The vSphere Namespace construct allows the vSphere admin to set several policies in one place. The user/team/customer/project can create new workloads to their hearts content within their vSphere Namespace.
Remember, VM isolation already ensures the VM’s can’t see each other. NSX-T isolation ensures the workloads can’t communicate with each other. I’ll keep repeating “Same rules apply. We’re leveraging the proven infrastructure of vSphere”. You can run Development and Production on the same infrastructure and control the impact of each with Namespaces.
As a vSphere Administrator looking to simplify operations this could make for some interesting capabilities going forward. It could also save you a significant amount of time and effort in standing up new applications. There’s nothing in vSphere with Kubernetes that says the DevOps team gets to have all the fun!
Let’s get into some of the things the vSphere Administrator can set on a Namespace.
Resource Limits
Sounds a lot like a Resource Pool because it’s backed by a Resource Pool! You can see here in the image below.
Figure 2 – Namespace Configuration
I have created a Namespace called “demo-app-01” and it’s a Resource Pool with a new Namespace icon. If I click on “Capacity and Usage” I’m presented with a dialog box that allows me to set the various CPU, Memory and Storage limits.
In this example I’m granting the user CPBU.LAB\mike permissions to view content in this Namespace
Figure 4 – Animated GIF of adding permissions to a Namespace
Storage
In Kubernetes there are Storage Classes. In vSphere there is Storage Based Policy Management. These map one to one. On the left are the VM Storage Policies and on the right are the Kubernetes Storage
Figure 5 – VM Storage Policies
Figure 6 – Namespace Storage Policies
Registry Service
The Registry Service allows for a private registry of container images. It is based on the VMware Harbor project. Why would you use a private registry? To ensure that only the container images that are “approved” are running in your infrastructure. Downloading untested, un-updated container images could lead to some very interesting talks with your compliance and security teams.
When you configure a Registry Service a private Namespace is created to run the registry. You enable the Registry Service on a per-cluster basis. The following image will show a configured Registry Service.
Figure 7 – Image Registry settings
Network
As part of the installation and configuration of vSphere with Kubernetes you needed to have configured NSX-T to provide the necessary networking used by vSphere to support Kubernetes. Within vCenter you can display the settings for the management network and Workload Network.
Figure 8 – Namespace Network settings
You can also make minor edits to some of the settings for both right here as well.
Figure 9 – Management Network Settings
Figure 10 – Workload Network Settings
Wrap Up
I hope this introductory series of blogs is helpful for those of you that are vSphere Administrators. It’s meant to help you better understand the components and features that make up vSphere with Tanzu. If you have any ideas on vSphere with Tanzu topics that you’d like to learn more about from a vSphere Administrator standpoint then please reach out to me on Twitter. I’m @mikefoley and my DM’s are open.
Thanks,
mike
We are excited about vSphere 7 and what it means for our customers and the future. Watch the vSphere 7 Launch Event replay, an event designed for vSphere Admins, hosted by theCUBE. We will continue posting new technical and product information about vSphere 7 and vSphere with Tanzu Monday through Thursdays into May 2020. Join us by following the blog directly using the RSS feed, on Facebook, and on Twitter. Thank you, and please stay safe.
The next component I’m going to cover in vSphere with Tanzu for the vSphere Administrator is vSphere Namespaces. vSphere Namespaces are set up by the vSphere Admin, run in the context of the Supervisor Cluster and allow admins to control resource limits and other policies. We’ll go into those details below!
