Chapter 1. Configuration overview
AMQ Streams simplifies the process of running Apache Kafka in an OpenShift cluster.
This guide describes how to configure and manage an AMQ Streams deployment.
1.1. Configuring custom resources
Use custom resources to configure your AMQ Streams deployment.
You can use custom resources to configure and create instances of the following components:
- Kafka clusters
- Kafka Connect clusters
- Kafka MirrorMaker
- Kafka Bridge
- Cruise Control
You can also use custom resource configuration to manage your instances or modify your deployment to introduce additional features. This might include configuration that supports the following:
- Securing client access to Kafka brokers
- Accessing Kafka brokers from outside the cluster
- Creating topics
- Creating users (clients)
- Controlling feature gates
- Changing logging frequency
- Allocating resource limits and requests
- Introducing features, such as AMQ Streams Drain Cleaner, Cruise Control, or distributed tracing.
The Custom resource API reference describes the properties you can use in your configuration.
1.2. Using ConfigMaps to add configuration
Use ConfigMap
resources to add specific configuration to your AMQ Streams deployment. ConfigMaps use key-value pairs to store non-confidential data. Configuration data added to ConfigMaps is maintained in one place and can be reused amongst components.
ConfigMaps can only store configuration data related to the following:
- Logging configuration
- Metrics configuration
- External configuration for Kafka Connect connectors
You can’t use ConfigMaps for other areas of configuration.
When you configure a component, you can add a reference to a ConfigMap using the configMapKeyRef
property.
For example, you can use configMapKeyRef
to reference a ConfigMap that provides configuration for logging. You might use a ConfigMap to pass a Log4j configuration file. You add the reference to the logging
configuration.
Example ConfigMap for logging
spec: # ... logging: type: external valueFrom: configMapKeyRef: name: my-config-map key: my-config-map-key
To use a ConfigMap for metrics configuration, you add a reference to the metricsConfig
configuration of the component in the same way.
ExternalConfiguration
properties make data from a ConfigMap (or Secret) mounted to a pod available as environment variables or volumes. You can use external configuration data for the connectors used by Kafka Connect. The data might be related to an external data source, providing the values needed for the connector to communicate with that data source.
For example, you can use the configMapKeyRef
property to pass configuration data from a ConfigMap as an environment variable.
Example ConfigMap providing environment variable values
apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaConnect metadata: name: my-connect spec: # ... externalConfiguration: env: - name: MY_ENVIRONMENT_VARIABLE valueFrom: configMapKeyRef: name: my-config-map key: my-key
If you are using ConfigMaps that are managed externally, use configuration providers to load the data in the ConfigMaps. For more information on using configuration providers, see Chapter 3, Loading configuration values from external sources.
1.2.1. Naming custom ConfigMaps
AMQ Streams creates its own ConfigMaps and other resources when it is deployed to OpenShift. The ConfigMaps contain data necessary for running components. The ConfigMaps created by AMQ Streams must not be edited.
Make sure that any custom ConfigMaps you create do not have the same name as these default ConfigMaps. If they have the same name, they will be overwritten. For example, if your ConfigMap has the same name as the ConfigMap for the Kafka cluster, it will be overwritten when there is an update to the Kafka cluster.
1.3. Configuring listeners to connect to Kafka brokers
Listeners are used for client connection to Kafka brokers. AMQ Streams provides a generic GenericKafkaListener
schema with properties to configure listeners through the Kafka
resource.
The GenericKafkaListener
provides a flexible approach to listener configuration. You can specify properties to configure internal listeners for connecting within the OpenShift cluster or external listeners for connecting outside the OpenShift cluster.
Each listener is defined as an array in the Kafka
resource. You can configure as many listeners as required, as long as their names and ports are unique. You can configure listeners for secure connection using authentication.
1.3.1. Configuring internal listeners
Internal listeners connect clients to Kafka brokers within the OpenShift cluster. An internal
type listener configuration uses a headless service and the DNS names given to the broker pods.
You might need to join your OpenShift network to an outside network. In which case, you can configure an internal
type listener (using the useServiceDnsDomain
property) so that the OpenShift service DNS domain (typically .cluster.local
) is not used.
You can also configure a cluster-ip
type of listener that exposes a Kafka cluster based on per-broker ClusterIP
services. This is a useful option when you can’t route through the headless service or you wish to incorporate a custom access mechanism. For example, you might use this listener when building your own type of external listener for a specific Ingress controller or the OpenShift Gateway API.
1.3.2. Configuring external listeners
Configure external listeners to handle access to a Kafka cluster from networks that require different authentication mechanisms.
You can configure external listeners for client access outside an OpenShift environment using a specified connection mechanism, such as a loadbalancer or route.
1.3.3. Providing listener certificates
You can provide your own server certificates, called Kafka listener certificates, for TLS listeners or external listeners which have TLS encryption enabled. For more information, see Kafka listener certificates.
If you scale your Kafka cluster while using external listeners, it might trigger a rolling update of all Kafka brokers. This depends on the configuration.
1.4. Document Conventions
User-replaced values
User-replaced values, also known as replaceables, are shown in italics with angle brackets (< >). Underscores ( _ ) are used for multi-word values. If the value refers to code or commands, monospace
is also used.
For example, in the following code, you will want to replace <my_namespace>
with the name of your namespace:
sed -i 's/namespace: .*/namespace: <my_namespace>/' install/cluster-operator/*RoleBinding*.yaml