Consider the following when planning your installation of Event Endpoint Management.
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 whenever you want your data to be saved in the event of a restart, set up persistent storage.
- Consider the options for securing your deployment.
Sample deployments for Event Manager
A number of sample configurations are available when installing Event Endpoint Management on which you can base your deployment. These range from smaller deployments for non-production development or general experimentation 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:
If you are installing in the IBM Cloud Pak for Integration UI, you can select the following sample configurations:
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, using ephemeral storage and local authentication.
This example provides a starter deployment that can be used if you simply want to try Event Endpoint Management with a minimum resource footprint. This example is deployed with no 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 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
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, using OIDC authentication with keycloak, using provided CA and custom 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 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
Overview: A development Event Manager instance with no persistence, local authentication, and configuration options for the API Connect integration.
This example is suitable for testing a starter deployment of Event Manager that can be configured to integrate with API Connect.
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 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 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 required for storage. Event Endpoint Management stores
data in JSON format. The amount of data 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,
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, this must be done by the cluster administrator before installing Event Endpoint Management. These will then be claimed from a central pool when the Event Manager instance is deployed.
- If these persistent volumes are to be created automatically, ensure 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 creating persistent volumes ensure 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 Cloud Pak for Integration 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.
Deciding which gateway deployment type to use
Which gateway deployment method to use 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 your gateway is monitored and maintained by the Event Endpoint Management operator.
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.
Licensing
Licensing tracking as part of a IBM Cloud Pak for Integration 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.