vSphere 7.0, Cloud Native Storage, CSI and vVols support

With the release of vSphere 7.0, we also announced enhancements to our Cloud Native Storage (CNS) offering. One of the new features that we now offer in vSphere 7.0 is the ability to provision Virtual Volumes (vVols) to back Kubernetes Persistent Volumes (PVs) via our updated version of the vSphere Container Storage Interface (CSI) driver. In this post, I will walk through the steps involved in consuming vVols via Kubernetes manifest files when dynamically provisioning PVs. I will also show some enhancements to our CNS UI in vSphere 7.0 so that you can easily identify vVol backed PVs. Step 1…

Building a TKG Cluster in vSphere with Kubernetes

Now that we have our vSphere with Kubernetes deployed, we take the next logical step in this post and deploy a Tanzu Kubernetes Grid (TKG) guest cluster. [Update] Whilst guest cluster isn’t an official name for the Tanzu Kubernetes cluster, I’ll use it in this post to differentiate it from the Supervisor cluster deployed with vSphere with Kubernetes. TKG is a full CNCF certified Kubernetes distribution. It is deployed as a set of virtual machines, in accordance with a TanzuKubernetesCluster manifest which we will look at later. The OS and K8s distribution is also specified in the manifest. There may…

A first look at vSphere with Kubernetes in action

In my previous post on VCF 4.0, we looked at the steps involved in deploying vSphere with Kubernetes in a Workload Domain (WLD). When we completed that step, we had rolled out the Supervisor Control Plane VMs, and installed the Spherelet components which allows our ESXi hosts to behave as Kubernetes worker nodes. Let’s now take a closer look at that configuration, and I will show you a few simple Kubernetes operations to get you started on the Supervisor Cluster in vSphere with Kubernetes. Disclaimer: “Like my earlier posts, I want to be clear, this post is based on a…

Getting started with VCF 4.0 Part 2 – Commission hosts, Create Workload Domain, Deploy NSX-T Edge

Now that a VCF 4.0 Management Domain has been deployed, we can move onto creating our very first VCF 4.0 Virtual Infrastructure Workload Domain (VI WLD). We will require a VI WLD with an NSX-T Edge cluster before we can deploy Kubernetes on vSphere (formerly known as Project Pacific). Not too much has changed in the WLD creation workflow since version 3.9. We still have to commission ESXi hosts before we can create the WLD. But something different to previous versions of VCF is that today in VCF 4.0 we can automatically provision NSX-T Edge clusters from SDDC Manager to…

Getting started with VMware Cloud Foundation (VCF) 4.0

On March 10th, VMware announced a range of new updated products and features. One of these was VMware Cloud Foundation (VCF) version 4.0. In the following series of blogs, I am going to show you the steps to deploy VCF 4.0. We will begin with the deployment of a Management Domain. Once this is complete, we will commission some additional hosts and build our first workload domain (WLD). After that, we will deploy the latest version of NSX-T Edge Cluster to our Workload Domain. The great news here is that this part has now been automated in VCF 4.0. Finally,…

Getting started with VCF Part 14 – Connecting vRA to NSX-T WLD (alternate method)

In my most recent VMware Cloud Foundation post (part 13), I highlighted the fact that if you used NSX-T as the networking platform for your workload domain (WLD), you could not attach vRealize Automation (vRA) to such a WLD via SDDC Manager. In that previous post, I showed how to manually deploy the vRA proxy agents on the Proxy VMs. These Proxy VMs were already deployed via SDDC Manager as part of the overall vRA deployment through SDDC Manager, but the agents were not installed at this point. If NSX-V was used as the networking platform for the WLD, then…

Getting started with VCF Part 11 – External Storage

I got an interesting question recently on my VMware Cloud Foundation (VCF) blog series. An observation was made that all of my posts highlighted vSAN as the storage for both the management domain and the workload domains. The question was whether other types of storage could be used in VCF. While we would always promote vSAN as the primary storage for VCF, the answer is yes, other storage types can be used. But I need to qualify this statement. The management domain always uses vSAN. This is automatically configured during the bring up process of the management domain and provides…