WilliamLam.com

Tanzu Kubernetes Grid (TKG) Demo Appliance 1.2.0

by // Leave a Comment

Happy to share that the Tanzu Kubernetes Grid (TKG) Demo Appliance Fling has been updated to support the latest TKG 1.2.0 release which just came out a couple of weeks ago. The TKG Workshop Guide has been updated to reflect all new TKG 1.2 changes along with an updated vSphere Content Library containing all the OVA required to get started. As mentioned in the workshop guide, you can use either a VMware Cloud on AWS SDDC (1-Node) or a vSphere 6.7 Update 3/vSphere 7.0+ environment.

The most notable change with this version is actually within TKG itself which now uses kube-vip to replace the functionality that the HAProxy VM used to provide. What this means when deploying either a TKG Management or Workload Cluster is that you will need to specify an IP Address which will be used for the Virtual IP endpoint of the K8s Cluster as shown in the screenshot below.

tkg init -i vsphere -p dev --name tkg-mgmt --vsphere-controlplane-endpoint-ip 192.168.2.10


Using the TKG Demo Appliance, you can deploy both v1.19.1 and v1.18.8 K8s Clusters. To exercise a TKG Cluster upgrade workflow, you just have to run these three simple commands:

export VSPHERE_TEMPLATE=photon-3-kube-v1.18.8_vmware.1
tkg create cluster tkg-cluster-01 --plan=dev --kubernetes-version=v1.18.8+vmware.1 --vsphere-controlplane-endpoint-ip 192.168.2.11
tkg upgrade cluster tkg-cluster-01


There has been a lot of demand for TKG on VMware Cloud on AWS, so that is where I have spent the bulk of my testing not to mention where it was originally developed. You can also deploy the TKG Demo Appliance in an on-premises vSphere environment running 6.7 Update 3 or newer.

[Read more...]

Automated Nested Lab Deployment on SDDC Part 1: VMware Cloud on AWS

by // 2 Comments


While preparing for this years VMworld, I had the unique opportunity to work across a number of VMware Cloud SDDC solutions such as VMware Cloud on AWS (VMConAWS), Azure VMware Solution (AVS), Google Cloud VMware Engine (GCVE) and Oracle Cloud VMware Solution (OCVS). During the the development of several demos, I found it invaluable to be able to deploy a Nested vSphere environment to validate my configurations prior to connecting our real vSphere on-premises infrastructure.

Putting aside VMworld demos, this can certainly be extended to other use cases such as accelerated pilots, proof of concepts and lab/development purposes. Customers have been leveraging Nested Virtualization technology for more than a decade plus now and it definitely makes sense that they would also want to do the same for certain workloads running within a VMware Cloud SDDC. With that said, Nested ESXi is not officially supported by VMware or on any other VMware-based platform.

As part of building my VMworld demos, I also had spent some time on creating some automation that would make it easier for me to re-deploy these Nested Lab environments and also being aware of the specific VMware Cloud SDDC solutions, so that I only have a single script to maintain. In case folks are also interested in being able to do this, you can follow this 4-part blog series which I will be kicking it off with VMware Cloud on AWS (VMConAWS).

[Read more...]

USB Network Native Driver now supports ESXi 7.0 Update 1

by // 8 Comments

I know many of you have been asking about this and today I am happy to share that the USB Network Native Driver for ESXi Fling is now supported with ESXi hosts running the latest 7.0 Update 1 release.

Note: The USB Network Native Driver is only supported with x86 ESXi and NOT with the ESXi-Arm Fling, there seems to be some confusion since these are two different CPU architectures.

In addition, there are a couple of minor enhancements (see changelog for details), but one feature that I am super excited to see incorporated into this version of the Fling is the automatic persistency of USB NIC binding, which maps physical USB NICs to either a Standard or Distributed Virtual Switch. Previously, this required users to update the local.sh script on ESXi to automatically restore the NIC bindings since the processing of these interfaces happens much later in the boot up process. These tweaks are no longer required when using this version of the Fling!

This enhancement was the direct result from Andrei Warkentin and his work on the ESXi-Arm Fling with the Raspberry Pi! Huge thanks to him for this contribution and hopefully we can repay that back one day with the integration of the USB Network Native Driver into the ESXi-Arm Fling ?