Companies are seeking ways to scale and evolve their solutions using modern application development approaches. Those approaches include the use of event-driven architectures, componentization of their application via microservices, use of containers to run reliably in different computing hosts, lightweight APIs, Big Data stores and/or RDBMS as appropriate, and the use of various architecture design patterns to meet scalability and reliability requirements. Prominent among those approaches is the event-driven orientation of modern applications that announce changes in their state to other applications or services. Those services may react to it in some way, such as processing the event, or ignore it altogether. By design, events do not convey any expectation from its publisher on whether the event should be processed, how or when is processed, etc. Under this integration paradigm, a recipient has a greater level of decoupling from the component that raised the event because of the lack of expectations from the publisher beyond informing the occurrence of a system state change. Additionally, PubSub event brokers, such as Event Grid, afford integrated applications to be loosely coupled. The event handler does not need to know what the publisher of the events is. It just needs to expose an HTTP endpoint and understand the events’ schema in order to read (deserialize) and to react to them, if appropriate.
We already offer Azure Event Grid to build event-driven solutions on the cloud. We are now announcing the public preview availability of Event Grid on Kubernetes with Azure Arc. With this new offering, you can integrate your workloads running on Kubernetes clusters using Event Grid Topics. You can also build hybrid architectures where events raised by your Kubernetes workloads are available to solutions running on Azure or any other destination to which Event Grid on Kubernetes has access. Event Grid on Kubernetes supports several types of event handlers deployed to Kubernetes, Azure, or any hosting environment via webHooks.
Use cases
Event Grid on Kubernetes helps you meet the following integration requirements.
Intra-cluster integration
User requirement: As an owner of a system deployed to a Kubernetes cluster, I want to communicate my system's state changes by publishing events and configuring routing of those events so that event handlers deployed on the same cluster, under my control or otherwise, can process my system's events in a way they see fit.
Event handler destinations supported include Azure App Service, Functions, and Logic Apps on Kubernetes with Azure Arc.
Private IP service integration (on-prem integration)
This is a generalization of the previous use case where the publisher and/or event subscriber is hosted on the same private network but outside the Kubernetes cluster. This scenario is typically representative of event publisher applications deployed to an on-prem private network, but it also applies to applications deployed to private networks on the cloud.
User requirement: As an owner of a system deployed within my private network, I want to communicate my system's state changes by publishing events and configuring routing of those events so that event handlers deployed on the same private network, under my control or otherwise, can process my system's events in a way they see fit.
Event forwarding to external public endpoints (Hybrid cloud and third-party integration)
This scenario addresses the requirement that calls for the ability to send events from a cluster to any public endpoint regardless of where that is hosted. Those endpoints include supported Azure services destinations such as Azure Event Grid, Event Hubs, Service Bus, Functions, and Storage Queues.
User requirement: As an owner of a system deployed to a Kubernetes cluster, I want to communicate my system's state changes by publishing events and configuring routing of those events so that event handlers deployed to Azure, other cloud providers or other on-prem data centers, under my control or otherwise, can process my system's events in a way they see fit.
Receive events from third-party services
User requirement: As an owner of a system deployed to a Kubernetes cluster, I want to expose a public Event Grid topic endpoint and configure event routing to my workloads so that I can receive events from third-party event publishers and process those events in a way I see fit.
Azure Arc
Azure Arc enabled Kubernetes is a feature that allows your cluster to be connected to Azure. Once connected, you can deploy Event Grid to your Kubernetes cluster. Azure Arc also offers Custom Locations which are ARM resources that represent Kubernetes namespaces. It is through Custom Locations that Event Grid topics and event subscriptions are deployed from Azure (Portal, API, CLI) to a specific Kubernetes namespace (Custom Location).
Features and Supported Kubernetes distributions
Event Grid on Kubernetes shares the same rest API (starting with version 2020-10-15-preview), Event Grid CLI, Azure portal experience, management SDKs, and data plane SDKs with Azure Event Grid, which is the cloud edition of the same service. Data plane SDK examples provided in different languages work for both editions of Event Grid too. That is, whether you use Event Grid on Kubernetes or on Azure you get the same user experience.
Although Event Grid on Kubernetes and Azure Event Grid share many features, there are some differences given the unique requirements they seek to meet and the stage in which they are on their software lifecycle. For example, the only type of topic available in Event Grid on Kubernetes are Event Grid Topics. For an account of the main differences between the two editions of Event Grid, consult the Features article.
Supported Kubernetes distributions
Following are the supported Kubernetes distributions to which Event Grid on Kubernetes with Azure Arc can be deployed and run.
- Azure AKS supported Kubernetes distributions.
- RedHat OpenShift Container Platform.
More distributions will be onboarded according to user's feedback and its support by Azure Arc enabled Kubernetes.
Event Grid broker
When you install Event Grid on Kubernetes, an Event Grid broker is deployed to the cluster. The broker is exposed as a Kubernetes ClusterIP service. This means that the Event Grid broker is only reachable from within the hosting cluster. This way, Event Grid on Kubernetes supports the intra-cluster integration use case without any extra configuration.
Not sure if Event Grid is for you?
If you have questions on whether Event Grid (on Kubernetes or on Azure) meets your requirements, please consult this article to help you understand the different message brokers that Azure provides and their applicability for different messaging use cases.
Questions?
We are here to help you through your journey. Following are the ways you can get your issues or questions answered by our teams:
- Problems with Event Grid on Kubernetes? Please create a support request using the Azure Portal. Please make sure to select “Event Grid on Kubernetes” as the value for Service type on the Basics (first step) tab.
- Problems with any of our data plane SDK clients used to send events? Just submit a GitHub issue in any of the following repositories: Java, .Net, JavaScript, and Python.
- 300+ level questions about the use of Event Grid on Kubernetes for which you did not find an answer in the service documentation? Please send your questions to askgrid@microsoft.com.
Feedback
We value your feedback. If you have an improvement idea around a feature, please search the existing suggestions on the Event Grid forum. If you find that your idea has already been proposed, vote on it so that we can get a sense of its relative importance among all ideas. Otherwise, please submit a new idea clearly stating that it is for Event Grid on Kubernetes with Azure Arc.
Next steps
- Ensure that you are running a Kubernetes cluster with a supported distribution.
- Check region availability for Event Grid on Kubernetes, Azure Arc Enabled Kubernetes and Custom Locations. Availability for Custom Locations is documented in this article section. All three services are required to deploy Event Grid on Kubernetes. Make sure all are available in your target region before attempting to install them.
- Learn about Event Grid on Kubernetes with Azure Arc.
- Install Event Grid on Kubernetes with Azure Arc. Among other steps, installing Event Grid includes:
- Connect (register) your Kubernetes cluster to Azure.
- Deploy Event Grid (extension) to your connected cluster.
- Create a custom location. This step is required before you can create Event Grid Topics and event subscriptions.
- Create topics and an event subscription that use a webhook event handler.
Resources
- Event Grid on Kubernetes with Azure Arc documentation.
- Features available in Event Grid on Kubernetes with Azure Arc and Azure Event Grid.
- Data plane SDKs to publish events. Under the samples, look for samples that send events to Event Grid Topics using Cloud Events schema, which are the kind of topic and schema supported.
- Data plane SDKs announcement with plenty of good information: https://devblogs.microsoft.com/azure-sdk/event-grid-ga/.
- Data plane SDKs packages.
- Management SDK packages.
- Azure Arc enabled Kubernetes documentation.
- Azure Custom Locations documentation.