Introducing Kubernetes Event Grid Bridge

Tom Kerkhove -

Over the past 3-to-4 years, I've been helping customers build scalable platforms on Microsoft Azure by using Kubernetes.

It is a great technology, if you need that level of control, that scales really well, and one of the reasons why I got involved in KEDA since it (will) become a cornerstone in every Kubernetes cluster for application autoscaling.

One of the things Kubernetes is great at is giving insights into what is going on in the cluster. For example, there are a lot of events that are emitted by various components, and the Kubernetes runtime itself.

This allows you to easily extend other workloads in a decoupled fashion, but there are a few hurdles to jump:

  • The event payload is very generic and does not provide a user-friendly way of filtering and interpreting the events
  • Documentation is poor on the events that are emitted due to the large scale of components emitting events
  • There is no easy way to flow Kubernetes events outside the cluster into Azure
  • Events are not compliant with CloudEvents spec, which makes it less ideal to process them

Unfortunately, this is somewhat of a trend in the Kubernetes community where it's so much focused on running everything on Kubernetes that it sometimes becomes hard to integrate with external pieces as well.

More than one year ago, I was hoping to make the native Kubernetes events CloudEvents-compatible by working with SIG-Instrumentation (GitHub issue) and trying to have Azure Kubernetes Service emit data-plane events to Azure Event Grid, but no luck so far.

So instead of asking, it's time to put my money where my mouth is and show the value of it!

Introducing Kubernetes Event Grid Bridge

Kubernetes Event Grid Bridge is an open-source bridge that will interpret Kubernetes events, transform them into user-friendly events that are CloudEvent 1.0 compliant.

It will automatically forward all events to a configure Azure Event Grid topic allowing you to flow Kubernetes events from one or more clusters into a centralized event router in Microsoft Azure.

This allows you to use Azure Event Grid as your centralized event hub for all your Kubernetes events. It gives you more flexibility by filtering on supported event types, subject, and more!

While in our initial version we only support Kubernetes.Events.Raw event type (overview), we are planning to provide a lot more of them (overview). If you have a specific event request, feel free to let us know.

Kubernetes Event Grid Bridge is a single-purpose product that does not poll for Kubernetes events but, instead relies on existing tools in the community such as Opsgenie's Kubernetes Event Exporter or any other exporter that you prefer.

The power of Kubernetes events outside of the cluster

Recently, I've created a Twitter poll recently and noticed that 35% was wondering why one would want to have Kubernetes events outside of their cluster.

Frankly, this amazed me a bit but comes back to what I said earlier that a lot of people only rely on Kubernetes and don't run workloads outside of it - Which is fair!

But why is this such a big deal to me? Well, it's easy - Consistency!

When building a platform on top of a cloud, you want to use the same experience for all your workloads, not depending on what service it runs on.

There are so many things you can do, here are just a few scenarios:

Autoscaling is my most favorite example - When autoscaling workloads I always highly recommend to have scaling awareness to learn how your platform is scaling and detect autoscaling loops.

When scaling Azure App Services, Azure API Management, etc. you can rely on Azure Monitor Autoscale - A great autoscaler that gives you not only scaling itself but also things such as scaling history, notifications, and logs.

By using these notifications, you can post messages in Slack, Teams, etc keeping the team up-to-date.

However, when using Kubernetes you cannot integrate it within your existing autoscaling awareness  flow so you have to use another tool (such as Kubernetes Event Exporter), or bring the events to Azure with Kubernetes Event Grid Bridge and take it from there.

While using another tool would cover this example, you will run into other issues when you need other events for other workflows, such as creating a scaling dashboard, react to failing pods in a push-fashion, etc.

What's next

With our first version we wanted to get you started easily to flow the events outside of the cluster into Microsoft Azure, but this is just the beginning!

In our next releases, we will focus on:

  • Providing user-friendly events to reduce the noise and make it easier to consumer/filter
  • Provide more contextual information such as cluster name and namespace for improved filtering
  • ...

Want to get started easily? We provide an end-to-end walkthrough that creates all the Azure resources, deploys everything in the cluster and uses the events in Azure Logic Apps.

Learn more about Kubernetes Event Grid Bridge in our documentation or on GitHub.

A shout-out to Khalid who created our nice logo and Felipe Cruz for sharing Opsgenie's Kubernetes Event Exporter!

Thanks for reading,

Tom Kerkhove

Photo by Bjorn Snelders on Unsplash