红帽全球峰会此内容没有您所选择的语言版本。
Chapter 6. Preparing for your Streams for Apache Kafka deployment
Prepare for a deployment of Streams for Apache Kafka 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 Streams for Apache Kafka
- Considering operator deployment best practices
- Pushing the Streams for Apache Kafka container images into your own registry (if required)
- Creating a pull secret for authentication to the container image registry
- 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.
6.1. Deployment prerequisites
To deploy Streams for Apache Kafka, you will need the following:
An OpenShift 4.16–4.20 cluster.
Streams for Apache Kafka is based on Strimzi 0.48.x.
-
The
occommand-line tool is installed and configured to connect to the running cluster.
6.2. Planning your Cluster Operator deployment
To support a stable and reliable Streams for Apache Kafka deployment, follow the best practices in this section. Run a single Cluster Operator per OpenShift cluster, choose an appropriate watch strategy, and isolate components within watched namespaces to reduce the risk of conflicts and unexpected behavior.
6.2.1. Avoiding deployment conflicts
A single operator is capable of managing multiple Kafka clusters across different namespaces. Deploying multiple instances of the Cluster Operator, particularly with different versions, introduces the following risks:
- Resource conflicts
- Conflicts over cluster-scoped resources like Custom Resource Definitions (CRDs) and ClusterRoles, leading to unpredictable behavior. This conflict occurs even when the operators are deployed in separate namespaces.
- Version incompatibility
- Different operator versions can create compatibility issues with the Kafka clusters they manage. New Streams for Apache Kafka releases may introduce features, bug fixes, or other changes that are not backward-compatible.
Approach to avoid risks
To avoid these risks, the recommended approach to deploying the Cluster Operator is as follows:
- Run a single Cluster Operator
- Deploy only one Cluster Operator per OpenShift cluster.
- Consider a dedicated namespace
- Install the Cluster Operator in its own namespace, separate from the Kafka components it manages. This separation is most useful when the operator is configured to watch multiple namespaces, but it can also help prevent uncontrolled growth of resources in a single namespace.
- Keep everything updated
- Regularly update Streams for Apache Kafka and the version of Kafka it manages so that you have the latest features, bug fixes, and enhancements.
6.2.2. Choosing namespace watch options
You configure the Cluster Operator to watch for changes to Kafka resources in specific namespaces.
You can configure the operator to watch:
Choosing to watch a specific list of multiple namespaces can have the biggest impact on performance due to increased processing overhead. To optimize performance, the recommended modes are to either watch a single namespace for focused monitoring or all namespaces for a comprehensive view of the entire cluster.
6.2.3. Isolating components in watched namespaces
After deploying the Cluster Operator, it begins watching specified namespaces for changes to Kafka resources. To reduce risks and maintain reliability, isolate component types within each watched namespace. Each namespace should contain only one instance of a given component type, such as one Kafka cluster, to avoid the following types of issues:
- Conflicting resource names
- Ambiguity in access management
- Topic and user name collisions
- Unpredictable behavior during upgrades or recovery
As Streams for Apache Kafka is based on Strimzi, the same issues can also arise when combining Streams for Apache Kafka operators with Strimzi operators in an OpenShift cluster.
6.3. Pushing container images to your own registry
Container images for Streams for Apache Kafka are available in the Red Hat Ecosystem Catalog. The installation YAML files provided by Streams for Apache Kafka 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.
6.3.1. Streams for Apache Kafka container images
| Container image | Namespace/Repository | Description |
|---|---|---|
| Kafka |
| Images for running Kafka components, including:
|
| Operator |
| Images for running the Streams for Apache Kafka operators:
|
| Kafka Bridge |
| Image for running the Streams for Apache Kafka Bridge |
| Streams for Apache Kafka Drain Cleaner |
| Image for running the Streams for Apache Kafka Drain Cleaner |
| Streams for Apache Kafka Proxy |
| Images for running the Streams for Apache Kafka Proxy |
| Streams for Apache Kafka Console |
| Images for running the Streams for Apache Kafka Console |
The installation YAML files provided by Streams for Apache Kafka pull container images directly from the Red Hat Ecosystem Catalog. If a Streams for Apache Kafka 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 Streams for Apache Kafka 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_SECRETSenvironment 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.
6.5. Designating Streams for Apache Kafka administrators
Streams for Apache Kafka 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. Streams for Apache Kafka provides two cluster roles that you can use to assign these rights to other users:
-
strimzi-viewallows users to view and list Streams for Apache Kafka resources. -
strimzi-adminallows users to also create, edit or delete Streams for Apache Kafka 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 Streams for Apache Kafka resources.
A system administrator can designate Streams for Apache Kafka administrators after the Cluster Operator is deployed.
Prerequisites
- The Streams for Apache Kafka admin deployment files, which are included in the Streams for Apache Kafka deployment files.
- The Streams for Apache Kafka 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
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}