Planning your Event Gateway deployment

Edit online

Decide the Event Gateway deployment method, how many gateways you require, review resource requirements, and plan your network configuration.

Event Gateways are added to Event Endpoint Management by deploying them with a configuration that points to your Event Manager. When the gateway is deployed, it registers itself with the Event Manager that is specified in its configuration. Use the Event Endpoint Management UI to generate the configuration properties for your gateway. The Event Endpoint Management UI can generate Event Gateway configurations for the following deployment methods:

  • Docker container. The Event Endpoint Management UI generates a Docker command to run an Event Gateway. The gateway configuration is contained in the Docker run command's arguments.
  • Kubernetes Deployment. The Event Endpoint Management UI generates the YAML for a Kubernetes Deployment that runs the Event Gateway. The Kubernetes environment monitors and manages your Event Gateway instance. For external access to your gateway, you must manually create and manage the Kubernetes ingresses or Red Hat OpenShift routes to your gateway endpoints.
  • Operator-managed. The Event Endpoint Management UI generates the YAML for a custom resource that is managed by the Event Endpoint Management operator. To use the operator-managed gateway, you must first install the Event Endpoint Management operator. The operator monitors and maintains your Event Gateway instance, and creates and manages the Kubernetes ingresses or Red Hat OpenShift routes that are required for external access to the Event Gateway instance.

Event Gateway planning

Consider the following questions:
  • How many Event Gateways and gateway groups do you require?
  • Where do you want to run your Event Gateways? To minimize latency, locate Event Gateways as close as possible to the Kafka cluster.
  • How will the Event Gateways be run and managed? In Red Hat OpenShift, in some other Kubernetes platform, or as a stand-alone Docker container?
  • What network access is required? Do your Kafka clients connect from the public internet, or from a private network?
  • What certificates will secure the Event Gateway endpoint? You must provide the TLS certificates to secure your Event Gateway. If your organization does not have its own certificates, then you can create certificates:
    • For a Kubernetes Deployment and operator-managed gateway, use cert-manager to generate certificates.
    • For Docker gateways, use OpenSSL to create certificate files.
  • Do you want the Event Gateway to send record trace information to IBM webMethods Hybrid Integration End-to-end Monitoring?
  • What hostnames do you want for your Event Gateways?

    Before you add any Event Gateways to your deployment, work out the number of gateway hostnames that you require:

    Calculate the total number of Kafka brokers across all the Kafka clusters that you expect your Event Gateway instances to connect to. If you plan to use different gateway groups for different Kafka clusters, then calculate the total number of brokers for each gateway group.

    The total number of hostnames for all gateways in a gateway group must be the same or greater than the total number of Kafka brokers that you plan the gateway group to serve topics from. If this requirement is not met, then your gateway group does not have enough unique hostnames to use for all the Kafka brokers.

    If your gateway environment supports wildcard addresses, then you can specify a single hostname with the * wildcard character. For example, the hostname:
    *-gwy1-grp1
    supports any hostname that ends with -gwy1-grp1.
    Note: If you create multiple connections to the same Kafka cluster, then the total number of hostnames that are required are equal to the number of brokers on that Kafka cluster multiplied by the number of connections you create to that cluster.

System and resource requirements

The Event Gateway image is provided as a multi-architecture container image that is based on the Red Hat UBIv9 image. The container image can run on Linux 64-bit (x86_64) systems and Linux on IBM z14 (s390x) or later architectures.

Supported platforms for Red Hat OpenShift and Kubernetes:
  • Red Hat OpenShift Container Platform versions 4.12, 4.14, 4.15, 4.16, 4.17, 4.18, and 4.19 all fix levels (see support dates).
  • Managed Red Hat OpenShift services on cloud platforms (PaaS):
    • Red Hat OpenShift on IBM Cloud.
    • Azure Red Hat OpenShift.
    • Red Hat OpenShift Service on AWS.
      Note: AWS ECS Fargate is not supported.
  • Red Hat OpenShift on cloud infrastructure (IaaS):
    • IBM Cloud.
    • Microsoft Azure.
    • Amazon Web Services.
  • Kubernetes platforms that support the Red Hat Universal Base Images (UBI) containers, versions 1.25 to 1.33

For a Docker gateway deployment, ensure that you have at least 2 CPU cores and 2 GiB of memory available on the Event Gateway host system. For information about the supported Red Hat Enterprise Linux host environments, see the Red Hat documentation. If your Docker environment is on Windows or macOS, then see Red Hat Universal Base Images for Docker users.

Network requirements on Kubernetes and Red Hat OpenShift

Review the following network considerations for Kubernetes Deployment and operator-managed gateways:
  • Event Endpoint Management is supported for use with IPv4 networks only.
  • On Red Hat OpenShift, routes are used to expose your gateway endpoint.
  • On other Kubernetes platforms, ingresses are used to expose your gateway endpoint. Ensure that you have an ingress controller installed in your Kubernetes environment.
  • TLS passthrough must be enabled on your ingresses or routes.

Before you start the installation process, determine the Fully Qualified Domain Names (FQDNs) for your Event Gateway instance by following these steps:

  1. Identify the DNS domain of your cluster's ingress controller.
    On Red Hat OpenShift, the default domain can be found with this command: 
    oc get ingresses.config/cluster -o jsonpath={.spec.domain}
  2. Decide the hostnames for your Event Gateway instance. Ensure that you provide as many hostnames as you have Kafka brokers, for more information about gateway hostname requirements, refer to gateway hostnames.
    Tip: To easily identify your Event Gateway, set the hostnames as <gateway group>-<gateway-id>-<kafka broker>, where <kafka broker> is an integer to represent each Kafka broker in the Kafka cluster that your Event Gateway is to manage traffic for.
  3. Determine the FQDNs of your Event Gateway.
    The FQDN is formed from <gateway hostname>.<dns ingress domain>. For example, if your Kafka cluster has 3 brokers, your gateway group name is grp1, your gateway ID is gwy1, and your DNS domain is example.com then the FQDNs for your Event Gateway are the following:
    • grp1-gwy1-1.example.com
    • grp1-gwy1-2.example.com
    • grp1-gwy1-3.example.com

TLS Certificates

The best way to create the TLS certificates to secure your Event Gateway endpoint is to use cert-manager. Cert-manager creates TLS certificates, stores them in Kubernetes secrets, and automatically renews them before they expire. Cert-manager supports integration with external public signers, and can also create self-signed certificates.
  • On Red Hat OpenShift Container Platform, install the cert-manager operator for Red Hat OpenShift.
    Important: You can have only one cert-manager operator for Red Hat OpenShift installed on your cluster.
  • On other Kubernetes platforms, install the cert-manager community operator, or other cert-manager that supports Issuer.cert-manager.io/v1 and Certificate.cert-manager.io/v1 GroupVersionKind (GVK).

If you do not want to use cert-manager, then you can create certificates manually and provide them to Event Endpoint Management by using Kubernetes secrets.