Chapter 4. Preparing for your AMQ Streams deployment
Prepare for a deployment of AMQ Streams by completing any necessary pre-deployment tasks. Take the necessary preparatory steps according to your specific requirements, such as the following:
- Ensuring you have the necessary prerequisites before deploying AMQ Streams
- Downloading the AMQ Streams release artifacts to facilitate your deployment
- Pushing the AMQ Streams container images into your own registry (if required)
- Setting up admin roles to enable configuration of custom resources used in the deployment
To run the commands in this guide, your cluster user must have the rights to manage role-based access control (RBAC) and CRDs.
4.1. Deployment prerequisites Copy linkLink copied to clipboard!
To deploy AMQ Streams, you will need the following:
An OpenShift 4.11 to 4.14 cluster.
AMQ Streams is based on Strimzi 0.38.x.
-
The
occommand-line tool is installed and configured to connect to the running cluster.
4.2. Operator deployment best practices Copy linkLink copied to clipboard!
Potential issues can arise from installing more than one AMQ Streams operator in the same OpenShift cluster, especially when using different versions. Each AMQ Streams operator manages a set of resources in an OpenShift cluster. When you install multiple AMQ Streams operators, they may attempt to manage the same resources concurrently. This can lead to conflicts and unpredictable behavior within your cluster. Conflicts can still occur even if you deploy AMQ Streams operators in different namespaces within the same OpenShift cluster. Although namespaces provide some degree of resource isolation, certain resources managed by the AMQ Streams operator, such as Custom Resource Definitions (CRDs) and roles, have a cluster-wide scope.
Additionally, installing multiple operators with different versions can result in compatibility issues between the operators and the Kafka clusters they manage. Different versions of AMQ Streams operators may introduce changes, bug fixes, or improvements that are not backward-compatible.
To avoid the issues associated with installing multiple AMQ Streams operators in an OpenShift cluster, the following guidelines are recommended:
- Install the AMQ Streams operator in a separate namespace from the Kafka cluster and other Kafka components it manages, to ensure clear separation of resources and configurations.
- Use a single AMQ Streams operator to manage all your Kafka instances within an OpenShift cluster.
- Update the AMQ Streams operator and the supported Kafka version as often as possible to reflect the latest features and enhancements.
By following these best practices and ensuring consistent updates for a single AMQ Streams operator, you can enhance the stability of managing Kafka instances in an OpenShift cluster. This approach also enables you to make the most of AMQ Streams’s latest features and capabilities.
As AMQ Streams is based on Strimzi, the same issues can also arise when combining AMQ Streams operators with Strimzi operators in an OpenShift cluster.
4.3. Downloading AMQ Streams release artifacts Copy linkLink copied to clipboard!
To use deployment files to install AMQ Streams, download and extract the files from the AMQ Streams software downloads page.
AMQ Streams release artifacts include sample YAML files to help you deploy the components of AMQ Streams to OpenShift, perform common operations, and configure your Kafka cluster.
Use oc to deploy the Cluster Operator from the install/cluster-operator folder of the downloaded ZIP file. For more information about deploying and configuring the Cluster Operator, see Section 6.2, “Deploying the Cluster Operator”.
In addition, if you want to use standalone installations of the Topic and User Operators with a Kafka cluster that is not managed by the AMQ Streams Cluster Operator, you can deploy them from the install/topic-operator and install/user-operator folders.
AMQ Streams container images are also available through the Red Hat Ecosystem Catalog. However, we recommend that you use the YAML files provided to deploy AMQ Streams.
4.4. Pushing container images to your own registry Copy linkLink copied to clipboard!
Container images for AMQ Streams are available in the Red Hat Ecosystem Catalog. The installation YAML files provided by AMQ Streams will pull the images directly from the Red Hat Ecosystem Catalog.
If you do not have access to the Red Hat Ecosystem Catalog or want to use your own container repository, do the following:
- Pull all container images listed here
- Push them into your own registry
- Update the image names in the installation YAML files
Each Kafka version supported for the release has a separate image.
| Container image | Namespace/Repository | Description |
|---|---|---|
| Kafka |
| AMQ Streams image for running Kafka, including:
|
| Operator |
| AMQ Streams image for running the operators:
|
| Kafka Bridge |
| AMQ Streams image for running the AMQ Streams Kafka Bridge |
| AMQ Streams Drain Cleaner |
| AMQ Streams image for running the AMQ Streams Drain Cleaner |
4.5. Creating a pull secret for authentication to the container image registry Copy linkLink copied to clipboard!
The installation YAML files provided by AMQ Streams pull container images directly from the Red Hat Ecosystem Catalog. If an AMQ Streams deployment requires authentication, configure authentication credentials in a secret and add it to the installation YAML.
Authentication is not usually required, but might be requested on certain platforms.
Prerequisites
- You need your Red Hat username and password or the login details from your Red Hat registry service account.
You can use your Red Hat subscription to create a registry service account from the Red Hat Customer Portal.
Procedure
Create a pull secret containing your login details and the container registry where the AMQ Streams image is pulled from:
oc create secret docker-registry <pull_secret_name> \ --docker-server=registry.redhat.io \ --docker-username=<user_name> \ --docker-password=<password> \ --docker-email=<email>Add your user name and password. The email address is optional.
Edit the
install/cluster-operator/060-Deployment-strimzi-cluster-operator.yamldeployment file to specify the pull secret using theSTRIMZI_IMAGE_PULL_SECRETenvironment variable:apiVersion: apps/v1 kind: Deployment metadata: name: strimzi-cluster-operator spec: # ... template: spec: serviceAccountName: strimzi-cluster-operator containers: # ... env: - name: STRIMZI_IMAGE_PULL_SECRETS value: "<pull_secret_name>" # ...The secret applies to all pods created by the Cluster Operator.
4.6. Designating AMQ Streams administrators Copy linkLink copied to clipboard!
AMQ Streams provides custom resources for configuration of your deployment. By default, permission to view, create, edit, and delete these resources is limited to OpenShift cluster administrators. AMQ Streams provides two cluster roles that you can use to assign these rights to other users:
-
strimzi-viewallows users to view and list AMQ Streams resources. -
strimzi-adminallows users to also create, edit or delete AMQ Streams resources.
When you install these roles, they will automatically aggregate (add) these rights to the default OpenShift cluster roles. strimzi-view aggregates to the view role, and strimzi-admin aggregates to the edit and admin roles. Because of the aggregation, you might not need to assign these roles to users who already have similar rights.
The following procedure shows how to assign a strimzi-admin role that allows non-cluster administrators to manage AMQ Streams resources.
A system administrator can designate AMQ Streams administrators after the Cluster Operator is deployed.
Prerequisites
- The AMQ Streams Custom Resource Definitions (CRDs) and role-based access control (RBAC) resources to manage the CRDs have been deployed with the Cluster Operator.
Procedure
Create the
strimzi-viewandstrimzi-admincluster roles in OpenShift.oc create -f install/strimzi-adminIf needed, assign the roles that provide access rights to users that require them.
oc create clusterrolebinding strimzi-admin --clusterrole=strimzi-admin --user=user1 --user=user2