Decide the purpose of your deployment, for example, whether you want to try a starter deployment for testing purposes, or start setting up a production deployment.
- Use the sample deployments described in the following sections as a starting point if you need something to base your deployment on.
- For production use, and when you don’t want to lose your data after a restart, set up persistent storage.
- Consider the options for securing your deployment.
Sample deployments for Event Manager
A number of Event Endpoint Management sample configurations are available, from which you can base your deployment. These samples range from smaller deployments for non-production development to deployments that can handle a production workload.
If you are installing on the OpenShift Container Platform or on other Kubernetes platforms, the following samples are available:
- Quick start
- Quick start - with ephemeral storage
- Quick start with API Connect v10 integration
- Production
- Production with IBM API Connect Developer Portal v12.1.1.2 or later integration
If you are installing in the IBM Integration Software (formerly IBM Cloud Pak for Integration) UI, you can select the following sample configurations:
- Quick start
- Quick start - with ephemeral storage
- Quick start with API Connect v10 integration
- Production
- Production with IBM API Connect Developer Portal v12.1.1.2 or later integration
- Usage-based pricing
The sample configurations for both the OpenShift Container Platform and other Kubernetes platforms are also available in GitHub where you can select the GitHub tag for your Event Endpoint Management version, and then go to /cr-examples/eventendpointmanagement/openshift or /cr-examples/eventendpointmanagement/kubernetes to access the samples.
Important: For a production setup, the sample configuration values are for guidance only, and you might need to change them.
Example deployment: Quick start
Overview: A development Event Manager instance with reduced resources, dynamically provisioned persistence storage, and local authentication.
This example provides a starter deployment that can be used if you want to try Event Endpoint Management with a minimum resource footprint. This example is deployed with persistence and reduced resources.
Resource requirements for this deployment:
| CPU request (cores) | CPU limit (cores) | Memory request (GiB) | Memory limit (GiB) | Chargeable cores (see licensing) |
|---|---|---|---|---|
| 0.25 | 0.5 | 0.25 | 0.5 | 1 |
Ensure that you have sufficient CPU capacity and physical memory in your environment to service at least the resource request values. The resource limit values constrain the amount of resource the Event Manager instance is able to consume.
Example deployment: Quick start - with ephemeral
Overview: A development Event Manager instance with reduced resources that uses ephemeral storage and local authentication, suitable for prototyping, but not long-term use.
This example provides a starter deployment that can be used if you want to try Event Endpoint Management with a minimum resource footprint. This example is deployed without persistence and reduced resources.
Resource requirements for this deployment:
| CPU request (cores) | CPU limit (cores) | Memory request (GiB) | Memory limit (GiB) | Chargeable cores (see licensing) |
|---|---|---|---|---|
| 0.25 | 0.5 | 0.25 | 0.5 | 1 |
Ensure that you have sufficient CPU capacity and physical memory in your environment to service at least the resource request values. The resource limit values constrain the amount of resource the Event Manager instance is able to consume.
Important: All data is lost if the manager pod is restarted.
Example deployment: Production
Overview: A production instance with support for persistence and OpenID Connect (OIDC) authentication.
This example installs a production-ready Event Manager instance, with dynamically provisioned persistence, OIDC authentication with keycloak, and specified CA and UI certificates.
Resource requirements for this deployment:
| CPU request (cores) | CPU limit (cores) | Memory request (GiB) | Memory limit (GiB) | Chargeable cores (see licensing) |
|---|---|---|---|---|
| 0.5 | 1.0 | 0.5 | 1.0 | 1 |
Ensure that you have sufficient CPU capacity and physical memory in your environment to service at least the resource request values. The resource limit values constrain the amount of resource the Event Manager instance is able to consume.
Example deployment: Production with IBM API Connect Developer Portal v12.1.1.2 or later integration
This example installs a production-ready Event Manager instance, with dynamically provisioned persistence, OIDC authentication with keycloak, specified CA and UI certificates, and configuration options for the integration with IBM API Connect Developer Portal v12.1.1.2 or later.
Resource requirements for this deployment:
| CPU request (cores) | CPU limit (cores) | Memory request (GiB) | Memory limit (GiB) | Chargeable cores (see licensing) |
|---|---|---|---|---|
| 0.5 | 1.0 | 0.5 | 1.0 | 1 |
Ensure that you have sufficient CPU capacity and physical memory in your environment to service at least the resource request values. The resource limit values constrain the amount of resource the Event Manager instance is able to consume.
Example deployment: Quick start with API Connect integration v10 integration
Overview: A development Event Manager instance with no persistence, local authentication, and configuration options for the API Connect integration v10.0.6 or later 10.x.x.
This example is suitable for testing a starter deployment of Event Manager that can be configured to integrate with API Connect v10.
Resource requirements for this deployment:
| CPU request (cores) | CPU limit (cores) | Memory request (GiB) | Memory limit (GiB) | Chargeable cores (see licensing) |
|---|---|---|---|---|
| 0.5 | 1.0 | 0.5 | 1.0 | 1 |
Ensure that you have sufficient CPU capacity and physical memory in your environment to service at least the resource request values. The resource limit values constrain the amount of resource the Event Manager instance is able to consume.
Example deployment: Usage-based pricing
Overview: A production instance with additional fields to point to an installed License Service server to record usage-based metrics.
| CPU request (cores) | CPU limit (cores) | Memory request (GiB) | Memory limit (GiB) | Chargeable cores (see licensing) |
|---|---|---|---|---|
| 0.5 | 1.0 | 0.5 | 1.0 | 1 |
Ensure that you have sufficient CPU capacity and physical memory in your environment to service at least the resource request values. The resource limit values constrain the amount of resource the Event Manager instance is able to consume.
Planning for persistent storage
If you plan to have persistent volumes, consider the disk space that is required for storage. Event Endpoint Management stores data in JSON format. The amount of data that is stored is proportional to the number of entries in the Event Endpoint Management catalog and the number of subscribers. For storage classes that support resizing, it might be sufficient to begin with 100Mi and monitor and extend as needed. By default, a value of 500Mi is used.
You either need to create a persistent volume, a persistent volume, and persistent volume claim, or specify a storage class that supports dynamic provisioning.
For information about creating persistent volumes and creating a storage class that supports dynamic provisioning:
- For OpenShift Container Platform, see the OpenShift Container Platform documentation.
- For other Kubernetes platforms, see the Kubernetes documentation.
You must have the Cluster Administrator role for creating persistent volumes or a storage class.
- If these persistent volumes are to be created manually, the cluster administrator must create the volumes before Event Endpoint Management is installed. The volumes are claimed from a central pool when the Event Manager instance is deployed.
- If these persistent volumes are to be created automatically, ensure that a dynamic provisioner is configured for the storage class you want to use. See data storage requirements for information about storage systems supported by Event Endpoint Management.
Important: When you create persistent volumes, ensure that the Access mode is set to ReadWriteOnce for the volume.
To use persistent storage, configure the storage properties in your EventEndpointManagement custom resource.
Note: If you intend to back up your Event Manager instance, consider a storage class that supports CSI snapshotting.
Planning for security
Before you install Event Endpoint Management, decide how to authenticate users and how to secure the Event Endpoint Management network endpoints.
User authentication
To authenticate users of the Event Endpoint Management UI, you can choose from the following options:
- LOCAL: Define a list of users and passwords locally in your Event Endpoint Management environment.
- OIDC: Use an existing OIDC-compatible security provider that is available in your environment.
- INTEGRATION_KEYCLOAK: Use an IBM Integration Software installation on the same cluster to manage users and roles.
To modify your authentication configuration, see managing access
Endpoint TLS configuration
TLS is used to secure your Event Manager and Event Gateway endpoints. The Event Endpoint Management operator and cert-manager can generate default self-signed TLS certificates for you, or you can configure your own custom certificates to secure the endpoints.
To secure Event Manager endpoints, use one of the following configurations, which are listed in order of complexity to configure (from simplest to most complex):
- Operator-configured CA: The operator creates a self-signed CA certificate that is used to generate all the other required certificates. This configuration is the default.
- Custom UI certificate: Provide a secret that contains the TLS certificate that you want Event Endpoint Management UI users to see when they log in to the UI. For more information, see custom UI certificates.
- Custom CA certificate: Provide a secret that contains a certificate authority (CA) certificate, which is used to generate the Event Manager server certificate. See Custom CA certificate.
- Custom certificate: Provide a secret that contains a CA certificate, server certificate, and a key that has the required DNS names for accessing the Event Manager. See Custom CA and leaf certificates.
To secure your Event Gateway endpoint on Kubernetes and OpenShift platforms, you must either create a Kubernetes secret that contains your CA certificate, server certificate, and key, or provide these as separate PEM files.
To secure a Docker Event Gateway endpoint, you must provide a CA certificate, server certificate, and key as separate PEM files.
For more information about configuring and managing endpoint security, see configuring TLS.
Event Gateway deployment planning
Deciding which Event Gateway deployment type to use
Deciding which method to use for your gateway deployment depends on the location of your Kafka clusters and Event Manager.
If the Kafka cluster is located in a different environment from your Event Manager, then to minimize latency it is recommended to install a gateway as a Docker container or Kubernetes Deployment in the same environment as the Kafka cluster, or as close as possible.
If the Kafka cluster is located in the same environment as your Event Manager, then it is recommended to install the operator-managed gateway, so that the Event Endpoint Management operator monitors and maintains your gateway.
Key points:
- To minimize latency, locate gateways as close as possible to the Kafka cluster.
- You are responsible for monitoring and upgrading the gateways. When Event Endpoint Management is upgraded, the Event Endpoint Management UI displays an alert for you to upgrade the gateways.
Event Gateway hostnames
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.
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.
Licensing
Licensing tracking as part of an IBM Integration Software deployment is either based on Virtual Processing Cores (VPCs) or Monthly API Calls (usage-based license) depending on the purchased license. If you are using an Event Automation license, VPCs are the only option.
For more information about available licenses, chargeable components, and tracking license usage, see the licensing reference.
FIPS compliance
Event Endpoint Management can be implemented in a Federal Information Processing Standards (FIPS) compliant manner.
For more information about requirements, configuring, and limitations of setting up Event Endpoint Management in a FIPS-compliant manner, see Enabling FIPS.