In Part V of this series, I introduced working with multiple Kubernetes clusters. In this post, I will introduce the Sockeye service.
When you need to write an event-driven function, the first thing to do is figure out the name of the event that you’re looking. William Lam has published a repo listing out all events for current versions of VMC on AWS and vSphere. Some of the events are obvious, but you don’t always know what you’re looking for. In that case, you want to trigger the event and watch logs to see what event fired.
There are two ways to do this – Kubernetes command line, and as of the v0.6 release, the Sockeye endpoint on the VEBA appliance.
Command Line
If you’ve followed the Part V post and configured your local workstation, you can do this remotely. Otherwise, SSH into the VEBA appliance. First, find the vmware-event-router pod:
C:\git> kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
contour-external contour-5869594b-jtb7p 1/1 Running 0 23h
contour-external contour-5869594b-ls9vr 1/1 Running 0 23h
contour-external contour-certgen-v1.10.0-k5hkm 0/1 Completed 0 23h
contour-external envoy-brrpq 2/2 Running 0 23h
contour-internal contour-5d47766fd8-6fnsz 1/1 Running 0 23h
contour-internal contour-5d47766fd8-g8gn9 1/1 Running 0 23h
contour-internal contour-certgen-v1.10.0-fq28j 0/1 Completed 0 23h
contour-internal envoy-rvc8h 2/2 Running 0 23h
knative-eventing eventing-controller-658f454d9d-sjgjf 1/1 Running 0 23h
knative-eventing eventing-webhook-69fdcdf8d4-zg4qd 1/1 Running 0 23h
knative-eventing rabbitmq-broker-controller-88fc96b44-s4q6x 1/1 Running 0 23h
knative-serving activator-85cd6f6f9-tppk9 1/1 Running 0 23h
knative-serving autoscaler-7959969587-2bng5 1/1 Running 0 23h
knative-serving contour-ingress-controller-6d5777577c-gskv2 1/1 Running 0 23h
knative-serving controller-577558f799-6hfwd 1/1 Running 0 23h
knative-serving webhook-78f446786-t22jb 1/1 Running 0 23h
kube-system antrea-agent-k54gk 2/2 Running 0 23h
kube-system antrea-controller-849fff8c5d-g9tzv 1/1 Running 0 23h
kube-system coredns-74ff55c5b-5sbgk 1/1 Running 0 23h
kube-system coredns-74ff55c5b-9xfpm 1/1 Running 0 23h
kube-system etcd-veba03 1/1 Running 0 23h
kube-system kube-apiserver-veba03 1/1 Running 0 23h
kube-system kube-controller-manager-veba03 1/1 Running 0 23h
kube-system kube-proxy-fnzp6 1/1 Running 0 23h
kube-system kube-scheduler-veba03 1/1 Running 0 23h
local-path-storage local-path-provisioner-5696dbb894-pwwzm 1/1 Running 0 23h
rabbitmq-system rabbitmq-cluster-operator-7bbbb8d559-2bvdf 1/1 Running 0 23h
vmware-functions default-broker-ingress-5c98bf68bc-t2mbz 1/1 Running 0 23h
vmware-functions sockeye-65697bdfc4-6qlkr 1/1 Running 0 23h
vmware-functions sockeye-trigger-dispatcher-5fff8567fc-p8v94 1/1 Running 0 23h
vmware-system tinywww-dd88dc7db-k4t4c 1/1 Running 0 23h
vmware-system veba-rabbit-server-0 1/1 Running 0 23h
vmware-system veba-ui-5f4d9ddcdd-q5pv4 1/1 Running 0 23h
vmware-system vmware-event-router-ccdfdc67f-gwl45 1/1 Running 5 23h
Next, tail the pod’s logs. Note that the pod name will be unique to your environment.
The –tail=1 argument will show you only the most recent log entry, and the –follow argument will keep showing any new logs. –follow is essentially the same as tail -f in Linux. You could omit the –tail=1 argument, but the entire logfile will dump out to the screen before new events start scrolling.
C:\git> kubectl logs -n vmware-system vmware-event-router-ccdfdc67f-gwl45 --tail=1 --follow
2021-06-03T20:39:41.486Z INFO [KNATIVE] knative/knative.go:192 successfully sent event {"eventID": "9d29d2b3-faab-4b99-82be-56ae2034330d"}
I power on a VM in my vCenter, and a bunch of events
C:\git> kubectl logs -n vmware-system vmware-event-router-ccdfdc67f-gwl45 --tail=1 --follow
2021-06-03T20:42:48.396Z INFO [KNATIVE] knative/knative.go:192 successfully sent event {"eventID": "5d6fa120-e140-4e31-be2f-a35de2e18f19"}
2021-06-03T20:42:56.166Z INFO [VCENTER] vcenter/vcenter.go:304 invoking processor {"eventID": "e05c06da-4613-4c5c-8e1d-30f37f8b2ff0"}
2021-06-03T20:42:56.166Z INFO [KNATIVE] knative/knative.go:180 sending event {"eventID": "e05c06da-4613-4c5c-8e1d-30f37f8b2ff0",
"subject": "TaskEvent"}
2021-06-03T20:42:56.249Z INFO [KNATIVE] knative/knative.go:192 successfully sent event {"eventID": "e05c06da-4613-4c5c-8e1d-30f37f8b2ff0"}
2021-06-03T20:42:56.249Z INFO [VCENTER] vcenter/vcenter.go:304 invoking processor {"eventID": "a6e9f717-9fe9-41c0-be90-f4ef458296e0"}
2021-06-03T20:42:56.249Z INFO [KNATIVE] knative/knative.go:180 sending event {"eventID": "a6e9f717-9fe9-41c0-be90-f4ef458296e0",
"subject": "TaskEvent"}
2021-06-03T20:42:56.250Z INFO [KNATIVE] knative/knative.go:192 successfully sent event {"eventID": "a6e9f717-9fe9-41c0-be90-f4ef458296e0"}
2021-06-03T20:42:56.250Z INFO [VCENTER] vcenter/vcenter.go:304 invoking processor {"eventID": "27526c9b-afc5-42b4-bba0-7fb827622261"}
2021-06-03T20:42:56.250Z INFO [KNATIVE] knative/knative.go:180 sending event {"eventID": "27526c9b-afc5-42b4-bba0-7fb827622261",
"subject": "VmBeingRelocatedEvent"}
2021-06-03T20:42:56.251Z INFO [KNATIVE] knative/knative.go:192 successfully sent event {"eventID": "27526c9b-afc5-42b4-bba0-7fb827622261"}
2021-06-03T20:42:57.005Z INFO [VCENTER] vcenter/vcenter.go:304 invoking processor {"eventID": "92eff0e3-bf27-4ce1-b01e-38375ba8e1fd"}
2021-06-03T20:42:57.005Z INFO [KNATIVE] knative/knative.go:180 sending event {"eventID": "92eff0e3-bf27-4ce1-b01e-38375ba8e1fd",
"subject": "com.vmware.net.lsport.connected"}
2021-06-03T20:42:57.008Z INFO [KNATIVE] knative/knative.go:192 successfully sent event {"eventID": "92eff0e3-bf27-4ce1-b01e-38375ba8e1fd"}
2021-06-03T20:42:57.009Z INFO [VCENTER] vcenter/vcenter.go:304 invoking processor {"eventID": "da859b34-b31c-43f5-8853-ec708d4829f8"}
2021-06-03T20:42:57.009Z INFO [KNATIVE] knative/knative.go:180 sending event {"eventID": "da859b34-b31c-43f5-8853-ec708d4829f8",
"subject": "VmRelocatedEvent"}
2021-06-03T20:42:57.012Z INFO [KNATIVE] knative/knative.go:192 successfully sent event {"eventID": "da859b34-b31c-43f5-8853-ec708d4829f8"}
2021-06-03T20:42:57.012Z INFO [VCENTER] vcenter/vcenter.go:304 invoking processor {"eventID": "816761ec-11b4-48d7-b6ca-58ca240c7d36"}
2021-06-03T20:42:57.012Z INFO [KNATIVE] knative/knative.go:180 sending event {"eventID": "816761ec-11b4-48d7-b6ca-58ca240c7d36",
"subject": "VmStartingEvent"}
2021-06-03T20:42:57.014Z INFO [KNATIVE] knative/knative.go:192 successfully sent event {"eventID": "816761ec-11b4-48d7-b6ca-58ca240c7d36"}
2021-06-03T20:42:57.991Z INFO [VCENTER] vcenter/vcenter.go:304 invoking processor {"eventID": "4f434b8d-6083-4377-9721-c400a8775355"}
2021-06-03T20:42:57.991Z INFO [KNATIVE] knative/knative.go:180 sending event {"eventID": "4f434b8d-6083-4377-9721-c400a8775355",
"subject": "DvsPortLinkUpEvent"}
2021-06-03T20:42:57.992Z INFO [KNATIVE] knative/knative.go:192 successfully sent event {"eventID": "4f434b8d-6083-4377-9721-c400a8775355"}
2021-06-03T20:42:57.992Z INFO [VCENTER] vcenter/vcenter.go:304 invoking processor {"eventID": "2135d297-016d-40a5-8a52-39d5c240f55d"}
2021-06-03T20:42:57.992Z INFO [KNATIVE] knative/knative.go:180 sending event {"eventID": "2135d297-016d-40a5-8a52-39d5c240f55d",
"subject": "DvsPortBlockedEvent"}
2021-06-03T20:42:57.994Z INFO [KNATIVE] knative/knative.go:192 successfully sent event {"eventID": "2135d297-016d-40a5-8a52-39d5c240f55d"}
2021-06-03T20:42:57.994Z INFO [VCENTER] vcenter/vcenter.go:304 invoking processor {"eventID": "7090a265-a78d-481e-aa70-b79fda769dd4"}
2021-06-03T20:42:57.994Z INFO [KNATIVE] knative/knative.go:180 sending event {"eventID": "7090a265-a78d-481e-aa70-b79fda769dd4",
"subject": "DrsVmPoweredOnEvent"}
2021-06-03T20:42:57.998Z INFO [KNATIVE] knative/knative.go:192 successfully sent event {"eventID": "7090a265-a78d-481e-aa70-b79fda769dd4"}
8 different events fired as part of this power on task
TaskEvent
VmBeingRelocatedEvent
com.vmware.net.lsport.connected
VmRelocatedEvent
VmStartingEvent
DvsPortLinkUpEvent
DvsPortBlockedEvent
DrsVmPoweredOnEvent
Now we know that we can trigger our function on the DrsVmPoweredOnEvent
Sockeye
v0.6 of the appliance introduced the Sockeye project at the /events endpoint. Sockeye is a websocket-based cloud events viewer, a way to view a stream of events right in your browser.
To get started, browse to https://your-veba-url/events. It will start off blank.
Now I do the same VM power-on operation that I did before. The same set of events fire, we can see them all in Sockeye, including the entire formatted payload. You can now easily write your code to parse the event payload because an actual live payload is right there in your browser. I won’t screenshot all of the payloads, but here are a few.
If you already know the event you’re looking for, you can configure a filter to see only the relevant event. Pressing the menu button in the top left corner will bring up the events filter
I know that I want the DrsVmPoweredOnEvent – I filter on subject with a value of DrsVmPoweredOnEvent, then click Add Filter
The filter gets applied and now the only events I see in Sockeye are of subject DrsVmPoweredOnEvent
The inclusion of Sockeye in VEBA makes consuming event payloads simple!
VMware Event Broker Appliance – Part VIII – Building a new PowerCLI Function - Preparation -
[…] VEBA appliance has the Sockeye service running under the /events endpoint. The Sockeye service is essentially a logfile tail […]