VMware Cloud on AWS

Tanzu Kubernetes Grid (TKG) Demo Appliance 1.2.0

10/28/2020 by William Lam 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.

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

10/27/2020 by William Lam 1 Comment

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).

Using PowerCLI and vSphere Tags to create/migrate HCX Mobility Groups to VMware Cloud SDDC

10/21/2020 by William Lam Leave a Comment

If using your voice to create an HCX Mobility Group and initiate a migration to a VMware Cloud SDDC is not your thing, here is a more practical example using PowerCLI which includes HCX cmdlets that was introduced awhile back.

Here are the 12 configurable variables that you will need to update based on your own environment.

$VC_SERVER="vcsa.vmware.corp"
$VC_USERNAME="*protected email*"
$VC_PASSWORD="VMware1!"
$HCX_SERVER="hcx.vmware.corp"

$VSPHERE_TAG_CATEGORY="Cloud"
$VSPHERE_TAG_NAME="VMC"

# vMotion, Bulk, Cold, RAV, OsAssistedMigration
$MIGRATION_TYPE="RAV"

$TARGET_NETWORK_NAME="L2E_HOL-10-f58e483b"
$TARGET_DATASTORE_NAME="WorkloadDatastore"
$TARGET_RESOURCE_POOL_NAME="Compute-ResourcePool"
$TARGET_VM_FOLDER_NAME="Workloads"

$MOBILITY_GROUP_NAME="VMworld-2020-Demo"

$VC_SERVER="vcsa.vmware.corp"

$VC_USERNAME="*protected email*"

$VC_PASSWORD="VMware1!"

$HCX_SERVER="hcx.vmware.corp"

$VSPHERE_TAG_CATEGORY="Cloud"

$VSPHERE_TAG_NAME="VMC"

# vMotion, Bulk, Cold, RAV, OsAssistedMigration

$MIGRATION_TYPE="RAV"

$TARGET_NETWORK_NAME="L2E_HOL-10-f58e483b"

$TARGET_DATASTORE_NAME="WorkloadDatastore"

$TARGET_RESOURCE_POOL_NAME="Compute-ResourcePool"

$TARGET_VM_FOLDER_NAME="Workloads"

$MOBILITY_GROUP_NAME="VMworld-2020-Demo"

Tanzu Kubernetes Grid (TKG) Demo Appliance 1.1.3

08/10/2020 by William Lam 1 Comment

It has been awhile since I have updated my Tanzu Kubernetes Grid (TKG) Demo Appliance Fling, which is a virtual appliance that enables anyone to go from zero to Kubernetes in less than 30 minutes with just an SSH client and a web browser. For VMware Cloud on AWS customers interested in running TKG, this is a great way to quickly get started on a proof of concept, demo or for development and testing purposes. One great benefit is that everything required for TKG is self contained within the appliance including an embedded Harbor registry and the respective TKG container images, great for air-gapped or non-internet accessible environments.

Here is a summary of what is new:

Support for latest TKG 1.1.3

There have been several of smaller releases to TKG since their 1.0.0 release but due to their short lifecycle, I decided to hold off. Behind the scenes, I have actually been working closely with TKG team on the latest TKG 1.1.3 release which was just release last week. One really cool feature that was introduced in TKG 1.1.2 is the ability to upgrade an existing TKG Workload Cluster to a newer version of Kubernetes.

With TKG 1.1.3, support for Kubernetes v1.18.6 and v1.17.9 is now possible and the latest version of the demo appliance will also support this workflow. In fact, I have also updated my TKG Workshop Guide to include all new updates including the upgrade workflow. To reduce the maintenance burden on myself, the TKG Demo Appliance 1.0.0 will be removed in the near future, for now it has been deprecated but all existing content is still available. I highly recommend checking out the latest version as you will get all the latest features of TKG.

Integrating VMware Cloud Notification Gateway with VMware Event Broker Appliance (VEBA)

07/29/2020 by William Lam Leave a Comment

I previously wrote about the VMware Cloud Notification Gateway (NGW) which provides curated notifications delivered to VMware Cloud on AWS users. By default, NGW supports several types of notification channels such as email, VMware Cloud Console UI, VMware Cloud Activity Log, vRealize Log Intelligence Cloud (vRLIC) and the vSphere UI when using the vCenter Cloud Gateway. A lesser known feature of NGW is the ability to extend into even more channels by leveraging its webhook functionality which is available when using NGW API.

For a basic "pass through" of the NGW notification to another cloud service such as Slack or Microsoft Teams as example, you can simple setup an incoming webhook on Slack or Microsoft Teams, which I had covered in the previous blog post. From there, you can configure an NGW subscription and forward the NGW notification to the specified incoming webhook.

For more interesting scenarios where customers may want to perform some additional data processing when the NGW notification arrives or run some code/automation and integrate that with other systems which can include your on-premises infrastructure, the basic webhook workflow is not sufficient. Having said that, at the end of the previous blog post I did hint at a solution that would enable customers to support such scenarios which is by leveraging the VMware Event Broker Appliance (VEBA) solution.

The way this works is that we are still taking advantage of the NGW webhook capability but instead of forwarding the NGW notification to a cloud service that supports an incoming webhook, we are sending it to VEBA for processing. Once the notification has been received by VEBA, customers can apply additional logic by using any language of their choice which runs as an automated function and is then responsible for sending the final payload to its destination. This is really the power of VEBA which enables customers to perform any additional processing or business logic to an event before sending it out to its intended target.

Using the new installation method for deploying OpenShift 4.5 on VMware Cloud on AWS

07/18/2020 by William Lam 1 Comment

I recently saw a tweet from Jason Shiplett who works over on the VMware Validated Design (VVD) team (also my former team before joining VMware Cloud) who shared a new validated design for running Redhat OpenShift 4.3 on VMware Cloud Foundation. Funny enough, a couple of days ago I was just researching into deploying OpenShift running on VMware Cloud on AWS from a customer inquiry.

Timing could not have been better as RedHat just announced their OpenShift 4.5 release a few days ago as and one of the major updates is support for vSphere using their full stack automation also known as te Installer Provisioned Infrastructure (IPI) option. Previous to this, customers who wanted to deploy OpenShift on vSphere had to use the User Provisioned Infrastructure (UPI) method, which the VVD design also uses, which is much lengthier and complex when compared to the native IPI method.

For someone who has never worked with OpenShift before, this was great news and I get to try out this new deployment method on an VMware Cloud on AWS infrastructure 🙂

Pre-Requisites:

Step 1 - You will need a Linux system to perform the installation and it should have access to the vCenter Server running in VMware Cloud on AWS (VMC). In my example, I am using an Ubuntu Server 20.04 VM which is also running in the SDDC and has outbound internet connectivity.

Step 2 - Login to VMware Cloud on AWS console and create a new NSX-T network segment that is DHCP enabled. In my example, I named it openshift-network with a 192.168.3.0/24 configuration.

Step 3 - Navigate to Inventory->Groups and create the following groups and replace the CIDR networks with that of your SDDC:

Group	Name	IP Address Members
Compute	OpenShift Network	192.168.3.0/24
Compute	SDDC Management Network	10.2.0.0/16
Management	OpenShift Network	192.168.3.0/24