Serverless Blog
all
guides & tutorials
user stories
operations & observability
engineering culture
news

Host your own CNCF CloudEvents compatible Event Gateway on Kubernetes, point to any FaaS

written by  
  Sebastian Borza

Last year, we launched the Event Gateway open source project: the event router for the serverless world.

In a nutshell, the Event Gateway is the way you take your business events, and route them to serverless (FaaS) compute. You can use it to easily build APIs or react to custom business events. You can even connect events across different vendors to integrate your new applications with legacy infrastructure or other SaaS.

While we do have a hosted (read: serverless) version of the Event Gateway contained inside our new Serverless Platform, the open source version is one that you have to host yourself.

And today, doing that is about to get a lot easier. You can now deploy your own self-hosted Event Gateway instance to a Kubernetes cluster in just a few commands!

Even better: the Event Gateway uses the CNCF’s CloudEvents format. Meaning, it’s cloud-agnostic down to its core. Use it with any FaaS provider you want.

Read on to learn how to get set up with the Event Gateway on your own Kubernetes cluster, or read the full release notes in GitHub.

Self-hosting the Event Gateway

The Event Gateway is a distributed system. It’s designed to be highly-available and continue running even in the event that one of its component pieces fail.

In order to self-host it, you would need to stand up all the underlying infrastructure for the Event Gateway. That means building out and managing the VM, setting up an etcd cluster, and handling ingress via a load balancer (nginx, proxy). This can be a complex undertaking.

But now, if you’re already Kubernetes, self-hosting your own Event Gateway instance is easy. YES.

Why Kubernetes?

Kubernetes abstracts away all the support logic required in running your own infrastructure. You can just let the system do it for you. YES x2.

How to run the Event Gateway right now, on Kubernetes

Here are all the steps you need to get set up with a multi-node cluster.

Getting Started

You'll need to have an existing Kubernetes cluster that supports Ingress for Deployments. The instructions contained here outline how to get that configured with minikube's native nginx ingress.

Install Helm

You’ll also need Helm installed.

Run helm init on your cluster to generate the helm and tiller files. This will help us easily deploy our config files later.

Install the Helm Components

You’ll need to grab the etcd-operator from Helm, and use event-gateway components from the serverless/event-gateway github repo.

The etcd-operator is a community-added component that starts, stops and manages the etcd cluster you’ll be using. In this case, we're going to run 3 distinct Event Gateway copies and they'll each hook into the central etcd cluster managed by the etcd-operator.

To install the etcd-operator component, type:

helm install stable/etcd-operator --name ego

Then install the event-gateway component:

helm install event-gateway --name ego

These commands will install the components into the default namespace in Kubernetes. If you’d like to install them in a specific namespace, then you will need to append a --namespace <namespace> on the end of your install command, like so:

helm install stable/etcd-operator --name ego --namespace <namespace>
helm install event-gateway --name eg --namespace <namespace>

Note: the namespace here is separate from the concept of a space within the Event Gateway. You can read more about Event Gateway spaces here, but it’s not necessary for installation.

Accessing the Event Gateway

If you have successfully installed the helm charts as listed above, you should now be able to access the event-gateway at your minikube IP. The helm chart explicitly assigns eventgateway.minikube to your Ingress ExternalIP. To enable your DNS resolution you can add this to your /etc/hosts file as follows:

echo "$(kubectl get ingress event-gateway-ingress -o jsonpath={.status.loadBalancer.ingress[0].ip}) eventgateway.minikube" | sudo tee -a "/etc/hosts"

The Ingress explicitly routes path access to the Event Gateway on your behalf, sending all configuration API calls over to the config service and all events API calls over to the events service. To test this out, you can pull the Event Gateway Prometheus metrics as follows:

curl --request GET \
--url http://eventgateway.minikube/v1/metrics
--header ‘content-type: application/json’

Note: if you did not add the hostname to your /etc/hosts file as above, you can replace eventgateway.minikube with your Ingress IP to do the same.

Congrats, you’re done!

Well, that was easy. Now you have your very own self-hosted Event Gateway up and running on Kubernetes!

How (and why) you’d use the Event Gateway

The Event Gateway gives developers a really easy way to ingest all business events as data, which they can then route anywhere they want—other cloud providers, SaaS, legacy infrastructure or containers.

Building REST APIs

One of the most popular use cases is building REST APIs, which we have a walkthrough of here.

Reacting to custom events

You can also use the Event Gateway to react to a single business event in multiple ways.

Let’s say a new user gets created. This event would route to the Event Gateway, from where three different things can occur asynchronously: (1) a new user gets created in your user table; (2) the user gets a welcome message; (3) the sales team gets notified that a new user just signed up.

All this can happen without updating any code on the original business event itself. (Read more on this here.)

Using services from different clouds together

Kelsey Hightower demoed a multi-cloud scenario earlier this year. He ran the Event Gateway on Kubernetes via his own integration, and deployed it to Google Cloud. An S3 event on AWS was sent through the Event Gateway and routed to a Google Cloud Function:

Austen Collins from Serverless, Inc., used the Event Gateway to trigger 11 different cloud providers:

Additional Resources

About Sebastian Borza

Sebastian Borza is a Software Engineer at Serverless.

engineering-culture - 04.04.18

Strategies for working with remote and distributed teams

Distributed teams allow you to hire the best people from over the world. Here are some lessons learned, and how-tos, for doing them right.

written by Casey Shultz

guides-and-tutorials - 18.12.17

How to build a static Serverless site with Netlify

How Serverless.com manages their static, serverless website with Netlify and the Serverless Framework.

written by David Wells

Join 12,000+ other serverless devs & keep up to speed on the latest serverless trends.

Join 12,000+ other serverless devs & keep up to speed on the latest serverless trends.

Made with love in San Francisco + Atlanta, Austria, Germany, Pakistan, Poland, Nebraska & Thailand

Serverless, Inc. © 2018

Join our newsletter and get the latest news about Serverless products and happenings. #noSpamWePromise