WilliamLam.com

Custom webhook function to publish events into VMware Event Broker Appliance (VEBA)

by // Leave a Comment

In my previous article, I demonstrated how you can leverage the upcoming v0.7 release of the VMware Event Broker Appliance (VEBA) to publish and consume custom events to easily extend your event-driven automation to other event sources. As a recap, this is accomplished by constructing and sending a conformant CloudEvent to VEBA, which can then be consumed by your functions.


This is perfect for external event sources that can create a custom HTTP payload that conforms to the CloudEvent specification, however not all solutions have this type of functionality or flexibility. An alternative solution to this is to simply create a VEBA function that can accept a custom payload and then handle the transformation of the data into a valid CloudEvent and then forward that off to broker running within VEBA. This is just one of the many benefits of Knative, the backend for VEBA, where each function deployment includes an endpoint that is automatically served as a subdomain to the VEBA hostname (e.g. https://my-function.NAMESPACE.VEBA-FQDN)


This solution would enable external "Event Producer" to send a non-CloudEvent payload which can then be processed by your function and re-publish as a conformant CloudEvent that can then be consumed by other function and services.

  1. Event Provider would make HTTP request to the function webhook with a custom payload
  2. A conformant CloudEvent payload is constructed by the webhook function
  3. Webhook function will then forward the CloudEvent internally to the VMware Event Broker Appliance
  4. VEBA functions can now react to these custom CloudEvents

[Read more...]

Quick Tip - How to deploy NSX Advanced Load Balancer (NSX-ALB) with a single Service Engine

by // Leave a Comment

I saw an interesting question today from Robert Kloosterhuis in the private vExpert App Modernization Slack Channel who working with vSphere with Tanzu using NSX Advanced Load Balancer (NSX-ALB) and wanted to know if it was possible to deploy NSX-ALB with just a single Service Engine (SE)?

The default behavior of NSX-ALB is to deploy two SE for availability purpose but for testing and/or homelab usage, it could certainly help with resources and time to spin up an environment using NSX-ALB. I was also curious if this was possible and reached out to NSX-ALB Engineering team and within a few minutes, I got a response that not only was this possible to do but pretty easy to configure.

To modify this default behavior, we need to update the Service Engine group prior to SE VMs being deployed. To do so, login to NSX-ALB UI and under Infrastructure->Service Engine Group and then click on the Advanced tab and change the default Buffer Service Engines value of 1 to 0 which will will have NSX-ALB deploy just a single SE VM rather than the default two.


To confirm that our NSX-ALB have been configured correctly, I have enabled vSphere with Tanzu using NSX-ALB and as you can see from the screenshot below, only a single SE VM has been deployed rather than the default behavior of two SE.

Quick Tip - Setting up Kubernetes using Containerd on Photon OS

by // Leave a Comment

As part of the VMware Event Broker Appliance (VEBA) project, I was recently evaluating a newer version of Kubernetes (v1.21.3) and also switching the container runtime from Docker to Containerd. I figured this probably should not be that difficult, especially since we are already use Containerd within Tanzu Kubernetes Grid (TKG) which is our commercial Kubernetes (k8s) offering and that base OS is VMware Photon OS. How hard could this be, right!? (famous last words) 😂

We use kubeadm to setup K8s and read in a very basic configuration file and after following the official K8s instructions for prepping the environment to use containerd, I was surprised when I ran into the following error:

Unfortunately, an error has occurred:
timed out waiting for the condition

This error is likely caused by:
- The kubelet is not running
- The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)

If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'

Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI.

Here is one example how you may list all Kubernetes containers running in cri-o/containerd using crictl:
- 'crictl --runtime-endpoint /run/containerd/containerd.sock ps -a | grep kube | grep -v pause'
Once you have found the failing container, you can inspect its logs with:
- 'crictl --runtime-endpoint /run/containerd/containerd.sock logs CONTAINERID'

error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster
To see the stack trace of this error execute with --v=5 or higher

Unfortunately, this lead me down a huge rat hole of troubleshooting and trying various configurations and suggestions from the Internet. Ultimately, none of the suggested solutions solved my problem. After exhausting all my options and spending more time that I would like to admit, I decided to ask in the Kubernetes Slack community to see if anyone might have an idea. There were not any specific suggestions that helped me understand the issue further but there was a question about how Containerd came to be on the system and that gave me one more thing to try.

Both Photon OS 3.0 and 4.0 ships with Containerd and after installing the desired kubeadm, kubectl and kubelet, I had wrongfully assumed that the version of Containerd would simply work.

[Read more...]