Deployment Architecture for Kubernetes

Advanced event mesh can be installed in a customer's on-premises or cloud-based Kubernetes cluster.

To orchestrate event broker services, SAP deploys the Mission Control Agent in a dedicated namespace. The Mission Control Agent creates a secure connection back to the Home Cloud and relays user commands from the console to the event broker service. This configuration is firewall friendly; all connections originate outbound.

The following diagram shows the deployment architecture for advanced event mesh in Kubernetes environments.

Diagram showing the architecture components involved when a user creates an event broker service or reads the new event broker service information. The Cloud Console sends a requests through the Home Cloud to the Mission Control Agent. The Mission Control Agent returns new event broker service information to the user through the same pathway. The Mission Control Agent also deploys and configures the event brokers in separate pods. The traffic received from the event brokers are load balanced by an external load balancer and external applications are connected through the load balancer address. Additionally, the Mission Control Agent creates a host name for a public I P address through Amazon Web services route 53. This host name also points to the load balancer address and connects to external applications.

For more details, see General Resource Requirements for Kubernetes and Default Port Configuration and Connectivity Model for Kubernetes Deployments.

Kubernetes Cluster Details

Advanced event mesh uses Availability Zones and Kubernetes StatefulSets to manage the deployment of event broker services, as shown in the following diagram:

Diagram showing the components described in the surrounding text.

The event broker service consists of three software event brokers, each deployed in a separate pod. Each pod also contains a Datadog agent that provides monitoring data and logs to the central monitoring service.

For details, see Central Monitoring Service and Datadog Agents.

Availability Zones

To ensure that high-availability event broker services are properly provisioned, advanced event mesh requires three Availability Zones (AZs), one for each member of the High Availability (HA) triplet (primary messaging broker, backup messaging broker, and monitoring broker). For each HA service, the Mission Control Agent deploys the primary pod in one AZ, the backup pod in a second AZ, and the monitoring pod in a third AZ. This guarantees that pods for the same HA service are not running on the same hardware.

No Availability Zones

Some regions do not have availability zones available, or you may decide that you don't require an availability zone configured for your Kubernetes cluster.

When your target cluster doesn't have Availability Zones, the Mission Control Agent still deploys the pods. In this case, it is possible for multiple pods to be affected by any outages that occur. Because of this, for those deployments without Availability Zones, we recommend that worker nodes be scheduled on separate physical machines.

When availability zones are not available, it's important to note that the IaaS has reduced fault tolerance when compared to having availability zones present. Regardless of this fact, the region operates with the best availability possible in all deployments.

Availability Zones for On-Premises Deployments

On-premises deployments should pay special attention to how they organize their Availability Zones (AZ). It is important, where possible, to have the individual worker nodes of high-availability (HA) event broker services physically distanced when possible. Any physical distance helps ensure the resiliency of your HA event broker services.

You can achieve physical distance by deploying your event broker services to different data centers you own, with each data center as an AZ. Even in situations where you only have one data center, you can sub-divide that data center into different AZs. Examples of how you can create separation include creating an AZ for each:

  • room in your data center
  • electric circuit within your data center
  • rack in your data center
  • server in your data center

Using availability zones requires you label each of the worker nodes in the Kubernetes cluster with its associated availability zone. See Running in multiple zones in the Kubernetes’ documentation for information.

StatefulSets

A StatefulSet is the Kubernetes Workload API object used to manage stateful applications.

StatefulSets manage the deployment and scaling of a set of pods, and provide guarantees about the ordering and uniqueness of these pods. Advanced event mesh uses three StatefulSets to manage the deployment of a HA group, one for each role (primary, backup, monitoring).

For more information about StatefulSets, see the Kubernetes documentation.

For information about the list of broker versions available in advanced event mesh, see Software Event Broker Versions and Support in SAP Integration Suite, Advanced Event Mesh.