WilliamLam.com

Beta for VMware Cloud Consumption Interface (CCI) formally Project Cascade

by // Leave a Comment

When Project Pacific was first announced back in 2019, most of the focus was on Kubernetes and how it would be re-architected into vSphere, basically the "how" or the implementation details. As much as I enjoy diving into the tech, what really stood out to me about Project Pacific was the implication it would have on workload evolution for vSphere.

In fact, I wrote about this very topic in this blog post: Project Pacific - Workload Evolution in vSphere because I felt that most of the focus was only on the "how" but not the "why". Here is a quote from the blog that summarizes why I was excited for Project Pacific:

However, Project Pacific is actually more than just Kubernetes but with all the new lingo like Supervisor and Guest Clusters, one can easily get lost in the implementation or what I would refer to as the "how" part of Project Pacific. If you ask me, the "why" part is much more significant and Project Pacific is fundamentally re-defining what and how to deploy a workload in vSphere.

Fast forward to today, vSphere with Tanzu has been delivering on the vision of Project Pacific since its introduction with vSphere 7 back in 2020. Developers, DevOps and Platform Engineering teams can easily deploy workloads like Tanzu Kubernetes Grid Clusters (TKC) or Virtual Machines into a vSphere Cluster that has been enabled with vSphere with Tanzu, also known as a Supervisor Cluster.

While the current vSphere with Tanzu experience works well for most environments with a handful of Supervisor Clusters, but what happens when you need to support more users, teams and an increased number of Supervisor Clusters across different locations? How do you manage access control for these users and the compute resources that they can consume while providing a simple and intuitive developer ready interface? This is where VMware Cloud Consumption Interface (CCI), formally known as Project Cascade comes in!

[Read more...]

How to configure Knative and containerd in VMware Event Broker Appliance (VEBA) to use a private registry?

by // 2 Comments

I was recently helping out fellow colleague Patrick Kremer who was looking into an issue that one of our users had filed on how to configure the VMware Event Broker Appliance (VEBA) so that it can take advantage of a custom container registry for deploying VEBA functions. If you attempt to specify a container image from a private container registry, especially one that has a self-signed certificate, you will see the following error:

Unable to fetch image "harbor.primp-industries.local/library/veba/kn-py-echo:1.0": failed to resolve image to digest: Get "https://harbor.primp-industries.local/v2/": x509: certificate signed by unknown authority; Get "https://harbor.primp-industries.local:443/v2/": x509: certificate signed by unknown authority

I had assumed that this should have been a pretty trivial configuration change to make the underlying Kubernetes container runtime trust the desired container registry and that there would be an easy to follow tutorial that Patrick could search for. The latest release of VEBA has moved away from using the Docker runtime to containerd and this should have helped narrow down the search results, at least that was our assumption.

Not only are there plenty of resources online, but there seem to be multiple methods depending on the version of Kubernetes and containerd which was pretty overwhelming. After several attempts using various blog articles, Patrick found that the trust error has still not gone away. I finally decided to take a closer look and discovered that there are actually two components that must be updated to properly support a private container registry: containerd & Knative Serving Controller. I eventually found this page in the Knative Serving documentation that provided a hint but ultimately, I was not able to fully grok the details until I came across this Github thread that brought clarity on how to create the required secret for the root CA certificate which would allow the Knative Serving controller to trust the root CA certificate.

Below are the instructions for the required changes and I have also attempted to simplify the steps by providing automation snippets that makes it easy for anyone to consume. In my setup, I am using Harbor registry which was built from my Harbor Virtual Appliance but the steps should apply for any other private container registry.

[Read more...]

Enhancements to VMware Tools 12 for Container Application Discovery in vSphere 

by // 2 Comments

VMware Tools 12 was just released and it adds a number of new features including support for Windows 11 and Windows Server 2022, Salt Stack Minion deployment and the use of OpenSSL 3.0 library to just name a few.

One additional feature that is quite interesting is the enhancement to the Application Discovery feature that was shipped with VMware Tools 11 which provides organizations with additional visibility of the running processes within a VM.

With VMware Tools 12, we now have a more granular method for discovering container-based processes (Docker or Containerd) running within a Linux VM, which is pretty cool if you ask me!


Similiar to the Application Discovery feature, a new VM guestinfo variable has been introduced called guestinfo.vmtools.containerinfo that will be populated with the list of running containers. By default, the polling interval is every 6 hours with a default of listing the first 100 containers, these and other settings can be adjusted which you can find in the official VMware documentation.

Simliar to the Application Discovery feature, I have also updated my PowerCLI function Get-VMApplicationInfo.ps1 to include this additional functionality for users that would like to extract this information and I have created a new function called Get-VMContainerInfo, which you see how it functions in the screenshot above. In addition to console output, you can also save the information in both CSV and JSON format.