Chapter 6. Using Strimzi Operators
Chapter 6. Using Strimzi Operators Use the Strimzi operators to manage your Kafka cluster, and Kafka topics and users. 6.1. Using the Cluster Operator The Cluster Operator is used to deploy a Kafka cluster and other Kafka components. For information on deploying the Cluster Operator, see Deploying the Cluster Operator . 6.1.1. Cluster Operator configuration You can configure the Cluster Operator using supported environment variables, and through its logging configuration. The environment variables relate to container configuration for the deployment of the Cluster Operator image. For more information on image configuration, see, Section 13.1.6, " image " . STRIMZI_NAMESPACE A comma-separated list of namespaces that the operator should operate in. When not set, set to empty string, or set to * , the Cluster Operator will operate in all namespaces. The Cluster Operator deployment might use the OpenShift Downward API to set this automatically to the namespace the Cluster Operator is deployed in. Example configuration for Cluster Operator namespaces env: - name: STRIMZI_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace STRIMZI_FULL_RECONCILIATION_INTERVAL_MS Optional, default is 120000 ms. The interval between periodic reconciliations, in milliseconds. STRIMZI_OPERATION_TIMEOUT_MS Optional, default 300000 ms. The timeout for internal operations, in milliseconds. This value should be increased when using AMQ Streams on clusters where regular OpenShift operations take longer than usual (because of slow downloading of Docker images, for example). STRIMZI_ZOOKEEPER_ADMIN_SESSION_TIMEOUT_MS Optional, default 10000 ms. The session timeout (in milliseconds) for the Cluster Operator's ZooKeeper admin client. This value should be increased if ZooKeeper requests from the Cluster Operator are regularly failing due to timeout issues. There is a maximum allowed session time set on the ZooKeeper server side via the maxSessionTimeout config. By default this session max value is 20 times the default tickTime (whose default is 2000) therefore 40000 ms. If you require a higher timeout, you will need to change the maxSessionTimeout ZooKeeper server config value. STRIMZI_OPERATIONS_THREAD_POOL_SIZE Optional, default 10 The worker thread pool size, which is used for various asynchronous and blocking operations that are run by the cluster operator. STRIMZI_OPERATOR_NAMESPACE The name of the namespace where the AMQ Streams Cluster Operator is running. Do not configure this variable manually. Use the OpenShift Downward API. env: - name: STRIMZI_OPERATOR_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace STRIMZI_OPERATOR_NAMESPACE_LABELS Optional. The labels of the namespace where the AMQ Streams Cluster Operator is running. Namespace labels are used to configure the namespace selector in network policies to allow the AMQ Streams Cluster Operator to only have access to the operands from the namespace with these labels. When not set, the namespace selector in network policies is configured to allow access to the AMQ Streams Cluster Operator from any namespace in the OpenShift cluster. env: - name: STRIMZI_OPERATOR_NAMESPACE_LABELS value: label1=value1,label2=value2 STRIMZI_LABELS_EXCLUSION_PATTERN Optional, default regex pattern is ^app.kubernetes.io/(?!part-of).* . Specifies the regex exclusion pattern used to filter labels propagation from the main custom resource to its subresources. The labels exclusion filter is not applied to labels in template sections such as spec.kafka.template.pod.metadata.labels . env: - name: STRIMZI_LABELS_EXCLUSION_PATTERN value: "^key1.*" STRIMZI_CUSTOM_{COMPONENT_NAME}_LABELS Optional. One or more custom labels to apply to all the pods created by the {COMPONENT_NAME} custom resource. The Cluster Operator labels the pods when the custom resource is created or is reconciled. Environment variables exist for the following components: KAFKA KAFKA_CONNECT KAFKA_CONNECT_BUILD ZOOKEEPER ENTITY_OPERATOR KAFKA_MIRROR_MAKER2 KAFKA_MIRROR_MAKER CRUISE_CONTROL KAFKA_BRIDGE KAFKA_EXPORTER STRIMZI_CUSTOM_RESOURCE_SELECTOR Optional. Specifies label selector used to filter the custom resources handled by the operator. The operator will operate only on those custom resources which will have the specified labels set. Resources without these labels will not be seen by the operator. The label selector applies to Kafka , KafkaConnect , KafkaBridge , KafkaMirrorMaker , and KafkaMirrorMaker2 resources. KafkaRebalance and KafkaConnector resources will be operated only when their corresponding Kafka and Kafka Connect clusters have the matching labels. env: - name: STRIMZI_CUSTOM_RESOURCE_SELECTOR value: label1=value1,label2=value2 STRIMZI_KAFKA_IMAGES Required. This provides a mapping from Kafka version to the corresponding Docker image containing a Kafka broker of that version. The required syntax is whitespace or comma separated <version> = <image> pairs. For example 3.0.0=registry.redhat.io/amq7/amq-streams-kafka-30-rhel8:2.1.0, 3.1.0=registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.1.0 . This is used when a Kafka.spec.kafka.version property is specified but not the Kafka.spec.kafka.image in the Kafka resource. STRIMZI_DEFAULT_KAFKA_INIT_IMAGE Optional, default registry.redhat.io/amq7/amq-streams-rhel8-operator:2.1.0 . The image name to use as default for the init container started before the broker for initial configuration work (that is, rack support), if no image is specified as the kafka-init-image in the Kafka resource. STRIMZI_KAFKA_CONNECT_IMAGES Required. This provides a mapping from the Kafka version to the corresponding Docker image containing a Kafka connect of that version. The required syntax is whitespace or comma separated <version> = <image> pairs. For example 3.0.0=registry.redhat.io/amq7/amq-streams-kafka-30-rhel8:2.1.0, 3.1.0=registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.1.0 . This is used when a KafkaConnect.spec.version property is specified but not the KafkaConnect.spec.image . STRIMZI_KAFKA_MIRROR_MAKER_IMAGES Required. This provides a mapping from the Kafka version to the corresponding Docker image containing a Kafka mirror maker of that version. The required syntax is whitespace or comma separated <version> = <image> pairs. For example 3.0.0=registry.redhat.io/amq7/amq-streams-kafka-30-rhel8:2.1.0, 3.1.0=registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.1.0 . This is used when a KafkaMirrorMaker.spec.version property is specified but not the KafkaMirrorMaker.spec.image . STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE Optional, default registry.redhat.io/amq7/amq-streams-rhel8-operator:2.1.0 . The image name to use as the default when deploying the topic operator, if no image is specified as the Kafka.spec.entityOperator.topicOperator.image in Kafka resource. STRIMZI_DEFAULT_USER_OPERATOR_IMAGE Optional, default registry.redhat.io/amq7/amq-streams-rhel8-operator:2.1.0 . The image name to use as the default when deploying the user operator, if no image is specified as the Kafka.spec.entityOperator.userOperator.image in the Kafka resource. STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE Optional, default registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.1.0 . The image name to use as the default when deploying the sidecar container which provides TLS support for the Entity Operator, if no image is specified as the Kafka.spec.entityOperator.tlsSidecar.image in the Kafka resource. STRIMZI_IMAGE_PULL_POLICY Optional. The ImagePullPolicy which will be applied to containers in all pods managed by AMQ Streams Cluster Operator. The valid values are Always , IfNotPresent , and Never . If not specified, the OpenShift defaults will be used. Changing the policy will result in a rolling update of all your Kafka, Kafka Connect, and Kafka MirrorMaker clusters. STRIMZI_IMAGE_PULL_SECRETS Optional. A comma-separated list of Secret names. The secrets referenced here contain the credentials to the container registries where the container images are pulled from. The secrets are used in the imagePullSecrets field for all Pods created by the Cluster Operator. Changing this list results in a rolling update of all your Kafka, Kafka Connect, and Kafka MirrorMaker clusters. STRIMZI_KUBERNETES_VERSION Optional. Overrides the OpenShift version information detected from the API server. Example configuration for OpenShift version override env: - name: STRIMZI_KUBERNETES_VERSION value: | major=1 minor=16 gitVersion=v1.16.2 gitCommit=c97fe5036ef3df2967d086711e6c0c405941e14b gitTreeState=clean buildDate=2019-10-15T19:09:08Z goVersion=go1.12.10 compiler=gc platform=linux/amd64 KUBERNETES_SERVICE_DNS_DOMAIN Optional. Overrides the default OpenShift DNS domain name suffix. By default, services assigned in the OpenShift cluster have a DNS domain name that uses the default suffix cluster.local . For example, for broker kafka-0 : <cluster-name> -kafka-0. <cluster-name> -kafka-brokers. <namespace> .svc. cluster.local The DNS domain name is added to the Kafka broker certificates used for hostname verification. If you are using a different DNS domain name suffix in your cluster, change the KUBERNETES_SERVICE_DNS_DOMAIN environment variable from the default to the one you are using in order to establish a connection with the Kafka brokers. STRIMZI_CONNECT_BUILD_TIMEOUT_MS Optional, default 300000 ms. The timeout for building new Kafka Connect images with additional connectots, in milliseconds. This value should be increased when using AMQ Streams to build container images containing many connectors or using a slow container registry. STRIMZI_NETWORK_POLICY_GENERATION Optional, default true . Controls whether AMQ Streams generates network policy resources. Network policies allow connections between Kafka components. Set this environment variable to false to disable network policy generation. You might do this, for example, if you want to use custom network policies. Custom network policies allow more control over maintaining the connections between components. STRIMZI_DNS_CACHE_TTL Optional, default 30 . Number of seconds to cache successful name lookups in local DNS resolver. Any negative value means cache forever. Zero means do not cache. This can be useful to avoid connection errors due to long caching policies being applied. STRIMZI_FEATURE_GATES Optional. Enables or disables features and functionality controlled by feature gates . 6.1.1.1. Logging configuration by ConfigMap The Cluster Operator's logging is configured by the strimzi-cluster-operator ConfigMap . A ConfigMap containing logging configuration is created when installing the Cluster Operator. This ConfigMap is described in the file install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml . You configure Cluster Operator logging by changing the data field log4j2.properties in this ConfigMap . To update the logging configuration, you can edit the 050-ConfigMap-strimzi-cluster-operator.yaml file and then run the following command: oc create -f install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml Alternatively, edit the ConfigMap directly: oc edit configmap strimzi-cluster-operator To change the frequency of the reload interval, set a time in seconds in the monitorInterval option in the created ConfigMap . If the ConfigMap is missing when the Cluster Operator is deployed, the default logging values are used. If the ConfigMap is accidentally deleted after the Cluster Operator is deployed, the most recently loaded logging configuration is used. Create a new ConfigMap to load a new logging configuration. Note Do not remove the monitorInterval option from the ConfigMap. 6.1.1.2. Restricting Cluster Operator access with network policy The Cluster Operator can run in the same namespace as the resources it manages, or in a separate namespace. By default, the STRIMZI_OPERATOR_NAMESPACE environment variable is configured to use the OpenShift Downward API to find which namespace the Cluster Operator is running in. If the Cluster Operator is running in the same namespace as the resources, only local access is required, and allowed by AMQ Streams. If the Cluster Operator is running in a separate namespace to the resources it manages, any namespace in the OpenShift cluster is allowed access to the Cluster Operator unless network policy is configured. Use the optional STRIMZI_OPERATOR_NAMESPACE_LABELS environment variable to establish network policy for the Cluster Operator using namespace labels. By adding namespace labels, access to the Cluster Operator is restricted to the namespaces specified. Network policy configured for the Cluster Operator deployment #... env: # ... - name: STRIMZI_OPERATOR_NAMESPACE_LABELS value: label1=value1,label2=value2 #... 6.1.1.3. Periodic reconciliation Although the Cluster Operator reacts to all notifications about the desired cluster resources received from the OpenShift cluster, if the operator is not running, or if a notification is not received for any reason, the desired resources will get out of sync with the state of the running OpenShift cluster. In order to handle failovers properly, a periodic reconciliation process is executed by the Cluster Operator so that it can compare the state of the desired resources with the current cluster deployments in order to have a consistent state across all of them. You can set the time interval for the periodic reconciliations using the [STRIMZI_FULL_RECONCILIATION_INTERVAL_MS] variable. 6.1.1.4. Provisioning Role-Based Access Control (RBAC) For the Cluster Operator to function it needs permission within the OpenShift cluster to interact with resources such as Kafka , KafkaConnect , and so on, as well as the managed resources, such as ConfigMaps , Pods , Deployments , StatefulSets and Services . Such permission is described in terms of OpenShift role-based access control (RBAC) resources: ServiceAccount , Role and ClusterRole , RoleBinding and ClusterRoleBinding . In addition to running under its own ServiceAccount with a ClusterRoleBinding , the Cluster Operator manages some RBAC resources for the components that need access to OpenShift resources. OpenShift also includes privilege escalation protections that prevent components operating under one ServiceAccount from granting other ServiceAccounts privileges that the granting ServiceAccount does not have. Because the Cluster Operator must be able to create the ClusterRoleBindings , and RoleBindings needed by resources it manages, the Cluster Operator must also have those same privileges. 6.1.1.5. Delegated privileges When the Cluster Operator deploys resources for a desired Kafka resource it also creates ServiceAccounts , RoleBindings , and ClusterRoleBindings , as follows: The Kafka broker pods use a ServiceAccount called cluster-name -kafka When the rack feature is used, the strimzi- cluster-name -kafka-init ClusterRoleBinding is used to grant this ServiceAccount access to the nodes within the cluster via a ClusterRole called strimzi-kafka-broker When the rack feature is not used and the cluster is not exposed via nodeport, no binding is created The ZooKeeper pods use a ServiceAccount called cluster-name -zookeeper The Entity Operator pod uses a ServiceAccount called cluster-name -entity-operator The Topic Operator produces OpenShift events with status information, so the ServiceAccount is bound to a ClusterRole called strimzi-entity-operator which grants this access via the strimzi-entity-operator RoleBinding The pods for KafkaConnect resource uses a ServiceAccount called cluster-name -cluster-connect The pods for KafkaMirrorMaker use a ServiceAccount called cluster-name -mirror-maker The pods for KafkaMirrorMaker2 use a ServiceAccount called cluster-name -mirrormaker2 The pods for KafkaBridge use a ServiceAccount called cluster-name -bridge 6.1.1.6. ServiceAccount The Cluster Operator is best run using a ServiceAccount : Example ServiceAccount for the Cluster Operator apiVersion: v1 kind: ServiceAccount metadata: name: strimzi-cluster-operator labels: app: strimzi The Deployment of the operator then needs to specify this in its spec.template.spec.serviceAccountName : Partial example of Deployment for the Cluster Operator apiVersion: apps/v1 kind: Deployment metadata: name: strimzi-cluster-operator labels: app: strimzi spec: replicas: 1 selector: matchLabels: name: strimzi-cluster-operator strimzi.io/kind: cluster-operator template: # ... Note line 12, where the strimzi-cluster-operator ServiceAccount is specified as the serviceAccountName . 6.1.1.7. ClusterRoles The Cluster Operator needs to operate using ClusterRoles that gives access to the necessary resources. Depending on the OpenShift cluster setup, a cluster administrator might be needed to create the ClusterRoles . Note Cluster administrator rights are only needed for the creation of the ClusterRoles . The Cluster Operator will not run under the cluster admin account. The ClusterRoles follow the principle of least privilege and contain only those privileges needed by the Cluster Operator to operate Kafka, Kafka Connect, and ZooKeeper clusters. The first set of assigned privileges allow the Cluster Operator to manage OpenShift resources such as StatefulSets , Deployments , Pods , and ConfigMaps . Cluster Operator uses ClusterRoles to grant permission at the namespace-scoped resources level and cluster-scoped resources level: ClusterRole with namespaced resources for the Cluster Operator apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-cluster-operator-namespaced labels: app: strimzi rules: - apiGroups: - "rbac.authorization.k8s.io" resources: # The cluster operator needs to access and manage rolebindings to grant Strimzi components cluster permissions - rolebindings verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "rbac.authorization.k8s.io" resources: # The cluster operator needs to access and manage roles to grant the entity operator permissions - roles verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "" resources: # The cluster operator needs to access and delete pods, this is to allow it to monitor pod health and coordinate rolling updates - pods # The cluster operator needs to access and manage service accounts to grant Strimzi components cluster permissions - serviceaccounts # The cluster operator needs to access and manage config maps for Strimzi components configuration - configmaps # The cluster operator needs to access and manage services and endpoints to expose Strimzi components to network traffic - services - endpoints # The cluster operator needs to access and manage secrets to handle credentials - secrets # The cluster operator needs to access and manage persistent volume claims to bind them to Strimzi components for persistent data - persistentvolumeclaims verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "kafka.strimzi.io" resources: # The cluster operator runs the KafkaAssemblyOperator, which needs to access and manage Kafka resources - kafkas - kafkas/status # The cluster operator runs the KafkaConnectAssemblyOperator, which needs to access and manage KafkaConnect resources - kafkaconnects - kafkaconnects/status # The cluster operator runs the KafkaConnectorAssemblyOperator, which needs to access and manage KafkaConnector resources - kafkaconnectors - kafkaconnectors/status # The cluster operator runs the KafkaMirrorMakerAssemblyOperator, which needs to access and manage KafkaMirrorMaker resources - kafkamirrormakers - kafkamirrormakers/status # The cluster operator runs the KafkaBridgeAssemblyOperator, which needs to access and manage BridgeMaker resources - kafkabridges - kafkabridges/status # The cluster operator runs the KafkaMirrorMaker2AssemblyOperator, which needs to access and manage KafkaMirrorMaker2 resources - kafkamirrormaker2s - kafkamirrormaker2s/status # The cluster operator runs the KafkaRebalanceAssemblyOperator, which needs to access and manage KafkaRebalance resources - kafkarebalances - kafkarebalances/status verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "core.strimzi.io" resources: # The cluster operator uses StrimziPodSets to manage the Kafka and ZooKeeper pods - strimzipodsets - strimzipodsets/status verbs: - get - list - watch - create - delete - patch - update - apiGroups: # The cluster operator needs the extensions api as the operator supports Kubernetes version 1.11+ # apps/v1 was introduced in Kubernetes 1.14 - "extensions" resources: # The cluster operator needs to access and manage deployments to run deployment based Strimzi components - deployments - deployments/scale # The cluster operator needs to access replica sets to manage Strimzi components and to determine error states - replicasets # The cluster operator needs to access and manage replication controllers to manage replicasets - replicationcontrollers # The cluster operator needs to access and manage network policies to lock down communication between Strimzi components - networkpolicies # The cluster operator needs to access and manage ingresses which allow external access to the services in a cluster - ingresses verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "apps" resources: # The cluster operator needs to access and manage deployments to run deployment based Strimzi components - deployments - deployments/scale - deployments/status # The cluster operator needs to access and manage stateful sets to run stateful sets based Strimzi components - statefulsets # The cluster operator needs to access replica-sets to manage Strimzi components and to determine error states - replicasets verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "" resources: # The cluster operator needs to be able to create events and delegate permissions to do so - events verbs: - create - apiGroups: # Kafka Connect Build on OpenShift requirement - build.openshift.io resources: - buildconfigs - buildconfigs/instantiate - builds verbs: - get - list - watch - create - delete - patch - update - apiGroups: - networking.k8s.io resources: # The cluster operator needs to access and manage network policies to lock down communication between Strimzi components - networkpolicies # The cluster operator needs to access and manage ingresses which allow external access to the services in a cluster - ingresses verbs: - get - list - watch - create - delete - patch - update - apiGroups: - route.openshift.io resources: # The cluster operator needs to access and manage routes to expose Strimzi components for external access - routes - routes/custom-host verbs: - get - list - watch - create - delete - patch - update - apiGroups: - policy resources: # The cluster operator needs to access and manage pod disruption budgets this limits the number of concurrent disruptions # that a Strimzi component experiences, allowing for higher availability - poddisruptionbudgets verbs: - get - list - watch - create - delete - patch - update The second includes the permissions needed for cluster-scoped resources. ClusterRole with cluster-scoped resources for the Cluster Operator apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-cluster-operator-global labels: app: strimzi rules: - apiGroups: - "rbac.authorization.k8s.io" resources: # The cluster operator needs to create and manage cluster role bindings in the case of an install where a user # has specified they want their cluster role bindings generated - clusterrolebindings verbs: - get - list - watch - create - delete - patch - update - apiGroups: - storage.k8s.io resources: # The cluster operator requires "get" permissions to view storage class details # This is because only a persistent volume of a supported storage class type can be resized - storageclasses verbs: - get - apiGroups: - "" resources: # The cluster operator requires "list" permissions to view all nodes in a cluster # The listing is used to determine the node addresses when NodePort access is configured # These addresses are then exposed in the custom resource states - nodes verbs: - list The strimzi-kafka-broker ClusterRole represents the access needed by the init container in Kafka pods that is used for the rack feature. As described in the Delegated privileges section, this role is also needed by the Cluster Operator in order to be able to delegate this access. ClusterRole for the Cluster Operator allowing it to delegate access to OpenShift nodes to the Kafka broker pods apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-kafka-broker labels: app: strimzi rules: - apiGroups: - "" resources: # The Kafka Brokers require "get" permissions to view the node they are on # This information is used to generate a Rack ID that is used for High Availability configurations - nodes verbs: - get The strimzi-topic-operator ClusterRole represents the access needed by the Topic Operator. As described in the Delegated privileges section, this role is also needed by the Cluster Operator in order to be able to delegate this access. ClusterRole for the Cluster Operator allowing it to delegate access to events to the Topic Operator apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-entity-operator labels: app: strimzi rules: - apiGroups: - "kafka.strimzi.io" resources: # The entity operator runs the KafkaTopic assembly operator, which needs to access and manage KafkaTopic resources - kafkatopics - kafkatopics/status # The entity operator runs the KafkaUser assembly operator, which needs to access and manage KafkaUser resources - kafkausers - kafkausers/status verbs: - get - list - watch - create - patch - update - delete - apiGroups: - "" resources: - events verbs: # The entity operator needs to be able to create events - create - apiGroups: - "" resources: # The entity operator user-operator needs to access and manage secrets to store generated credentials - secrets verbs: - get - list - watch - create - delete - patch - update The strimzi-kafka-client ClusterRole represents the access needed by the components based on Kafka clients which use the client rack-awareness. As described in the Delegated privileges section, this role is also needed by the Cluster Operator in order to be able to delegate this access. ClusterRole for the Cluster Operator allowing it to delegate access to OpenShift nodes to the Kafka client based pods apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-kafka-client labels: app: strimzi rules: - apiGroups: - "" resources: # The Kafka clients (Connect, Mirror Maker, etc.) require "get" permissions to view the node they are on # This information is used to generate a Rack ID (client.rack option) that is used for consuming from the closest # replicas when enabled - nodes verbs: - get 6.1.1.8. ClusterRoleBindings The operator needs ClusterRoleBindings and RoleBindings which associates its ClusterRole with its ServiceAccount : ClusterRoleBindings are needed for ClusterRoles containing cluster-scoped resources. Example ClusterRoleBinding for the Cluster Operator apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: strimzi-cluster-operator labels: app: strimzi subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-cluster-operator-global apiGroup: rbac.authorization.k8s.io ClusterRoleBindings are also needed for the ClusterRoles needed for delegation: Example ClusterRoleBinding for the Cluster Operator for the Kafka broker rack-awareness apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: strimzi-cluster-operator-kafka-broker-delegation labels: app: strimzi # The Kafka broker cluster role must be bound to the cluster operator service account so that it can delegate the cluster role to the Kafka brokers. # This must be done to avoid escalating privileges which would be blocked by Kubernetes. subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-kafka-broker apiGroup: rbac.authorization.k8s.io and Example ClusterRoleBinding for the Cluster Operator for the Kafka client rack-awareness apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: strimzi-cluster-operator-kafka-client-delegation labels: app: strimzi # The Kafka clients cluster role must be bound to the cluster operator service account so that it can delegate the # cluster role to the Kafka clients using it for consuming from closest replica. # This must be done to avoid escalating privileges which would be blocked by Kubernetes. subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-kafka-client apiGroup: rbac.authorization.k8s.io ClusterRoles containing only namespaced resources are bound using RoleBindings only. apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: strimzi-cluster-operator labels: app: strimzi subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-cluster-operator-namespaced apiGroup: rbac.authorization.k8s.io apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: strimzi-cluster-operator-entity-operator-delegation labels: app: strimzi # The Entity Operator cluster role must be bound to the cluster operator service account so that it can delegate the cluster role to the Entity Operator. # This must be done to avoid escalating privileges which would be blocked by Kubernetes. subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-entity-operator apiGroup: rbac.authorization.k8s.io 6.1.2. Configuring the Cluster Operator with default proxy settings If you are running a Kafka cluster behind a HTTP proxy, you can still pass data in and out of the cluster. For example, you can run Kafka Connect with connectors that push and pull data from outside the proxy. Or you can use a proxy to connect with an authorization server. Configure the Cluster Operator deployment to specify the proxy environment variables. The Cluster Operator accepts standard proxy configuration ( HTTP_PROXY , HTTPS_PROXY and NO_PROXY ) as environment variables. The proxy settings are applied to all AMQ Streams containers. The format for a proxy address is http://IP-ADDRESS:PORT-NUMBER . To set up a proxy with a name and password, the format is http://USERNAME:PASSWORD@IP-ADDRESS:PORT-NUMBER . Prerequisites This procedure requires use of an OpenShift user account which is able to create CustomResourceDefinitions , ClusterRoles and ClusterRoleBindings . Use of Role Base Access Control (RBAC) in the OpenShift cluster usually means that permission to create, edit, and delete these resources is limited to OpenShift cluster administrators, such as system:admin . Procedure To add proxy environment variables to the Cluster Operator, update its Deployment configuration ( install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml ). Example proxy configuration for the Cluster Operator apiVersion: apps/v1 kind: Deployment spec: # ... template: spec: serviceAccountName: strimzi-cluster-operator containers: # ... env: # ... - name: "HTTP_PROXY" value: "http://proxy.com" 1 - name: "HTTPS_PROXY" value: "https://proxy.com" 2 - name: "NO_PROXY" value: "internal.com, other.domain.com" 3 # ... 1 Address of the proxy server. 2 Secure address of the proxy server. 3 Addresses for servers that are accessed directly as exceptions to the proxy server. The URLs are comma-separated. Alternatively, edit the Deployment directly: oc edit deployment strimzi-cluster-operator If you updated the YAML file instead of editing the Deployment directly, apply the changes: oc create -f install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml Additional resources Host aliases Designating AMQ Streams administrators 6.1.3. Configuring FIPS mode in the Cluster Operator Federal Information Processing Standards (FIPS) are standards for computer security and interoperability. When running AMQ Streams on a FIPS-enabled OpenShift cluster, the OpenJDK used in AMQ Streams container images will automatically switch to FIPS mode. This prevents AMQ Streams from running on the cluster. When you deploy AMQ Streams to the cluster, you will see errors similar to the following: If you want to run AMQ Streams on your FIPS-enabled cluster, you can disable the OpenJDK FIPS mode by setting the FIPS_MODE environment variable to disabled in the deployment configuration for the Cluster Operator. The AMQ Streams deployment won't be FIPS compliant, but the AMQ Streams operators as well as all of its operands will be able to run on the FIPS-enabled OpenShift cluster. Procedure To disable the FIPS mode in the Cluster Operator, update its Deployment configuration ( install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml ) and add the FIPS_MODE environment variable. Example FIPS configuration for the Cluster Operator apiVersion: apps/v1 kind: Deployment spec: # ... template: spec: serviceAccountName: strimzi-cluster-operator containers: # ... env: # ... - name: "FIPS_MODE" value: "disabled" 1 # ... 1 Disables the FIPS mode. Alternatively, edit the Deployment directly: oc edit deployment strimzi-cluster-operator If you updated the YAML file instead of editing the Deployment directly, apply the changes: oc apply -f install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml Additional resources What are Federal Information Processing Standards (FIPS) 6.2. Using the Topic Operator When you create, modify or delete a topic using the KafkaTopic resource, the Topic Operator ensures those changes are reflected in the Kafka cluster. The Deploying and Upgrading AMQ Streams on OpenShift guide provides instructions to deploy the Topic Operator: Using the Cluster Operator (recommended) Standalone to operate with Kafka clusters not managed by AMQ Streams 6.2.1. Kafka topic resource The KafkaTopic resource is used to configure topics, including the number of partitions and replicas. The full schema for KafkaTopic is described in KafkaTopic schema reference . 6.2.1.1. Identifying a Kafka cluster for topic handling A KafkaTopic resource includes a label that defines the appropriate name of the Kafka cluster (derived from the name of the Kafka resource) to which it belongs. For example: apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: topic-name-1 labels: strimzi.io/cluster: my-cluster The label is used by the Topic Operator to identify the KafkaTopic resource and create a new topic, and also in subsequent handling of the topic. If the label does not match the Kafka cluster, the Topic Operator cannot identify the KafkaTopic and the topic is not created. 6.2.1.2. Kafka topic usage recommendations When working with topics, be consistent. Always operate on either KafkaTopic resources or topics directly in OpenShift. Avoid routinely switching between both methods for a given topic. Use topic names that reflect the nature of the topic, and remember that names cannot be changed later. If creating a topic in Kafka, use a name that is a valid OpenShift resource name, otherwise the Topic Operator will need to create the corresponding KafkaTopic with a name that conforms to the OpenShift rules. Note For information on the requirements for identifiers and names in OpenShift, refer to Object Names and IDs . 6.2.1.3. Kafka topic naming conventions Kafka and OpenShift impose their own validation rules for the naming of topics in Kafka and KafkaTopic.metadata.name respectively. There are valid names for each which are invalid in the other. Using the spec.topicName property, it is possible to create a valid topic in Kafka with a name that would be invalid for the Kafka topic in OpenShift. The spec.topicName property inherits Kafka naming validation rules: The name must not be longer than 249 characters. Valid characters for Kafka topics are ASCII alphanumerics, . , _ , and - . The name cannot be . or .. , though . can be used in a name, such as exampleTopic. or .exampleTopic . spec.topicName must not be changed. For example: apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: topic-name-1 spec: topicName: topicName-1 1 # ... 1 Upper case is invalid in OpenShift. cannot be changed to: apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: topic-name-1 spec: topicName: name-2 # ... Note Some Kafka client applications, such as Kafka Streams, can create topics in Kafka programmatically. If those topics have names that are invalid OpenShift resource names, the Topic Operator gives them a valid metadata.name based on the Kafka name. Invalid characters are replaced and a hash is appended to the name. For example: apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: mytopic---c55e57fe2546a33f9e603caf57165db4072e827e spec: topicName: myTopic # ... 6.2.2. Topic Operator topic store The Topic Operator uses Kafka to store topic metadata describing topic configuration as key-value pairs. The topic store is based on the Kafka Streams key-value mechanism, which uses Kafka topics to persist the state. Topic metadata is cached in-memory and accessed locally within the Topic Operator. Updates from operations applied to the local in-memory cache are persisted to a backup topic store on disk. The topic store is continually synchronized with updates from Kafka topics or OpenShift KafkaTopic custom resources. Operations are handled rapidly with the topic store set up this way, but should the in-memory cache crash it is automatically repopulated from the persistent storage. 6.2.2.1. Internal topic store topics Internal topics support the handling of topic metadata in the topic store. __strimzi_store_topic Input topic for storing the topic metadata __strimzi-topic-operator-kstreams-topic-store-changelog Retains a log of compacted topic store values Warning Do not delete these topics, as they are essential to the running of the Topic Operator. 6.2.2.2. Migrating topic metadata from ZooKeeper In releases of AMQ Streams, topic metadata was stored in ZooKeeper. The new process removes this requirement, bringing the metadata into the Kafka cluster, and under the control of the Topic Operator. When upgrading to AMQ Streams 2.1, the transition to Topic Operator control of the topic store is seamless. Metadata is found and migrated from ZooKeeper, and the old store is deleted. 6.2.2.3. Downgrading to an AMQ Streams version that uses ZooKeeper to store topic metadata If you are reverting back to a version of AMQ Streams earlier than 1.7, which uses ZooKeeper for the storage of topic metadata, you still downgrade your Cluster Operator to the version, then downgrade Kafka brokers and client applications to the Kafka version as standard. However, you must also delete the topics that were created for the topic store using a kafka-admin command, specifying the bootstrap address of the Kafka cluster. For example: oc run kafka-admin -ti --image=registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.1.0 --rm=true --restart=Never -- ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi-topic-operator-kstreams-topic-store-changelog --delete && ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi_store_topic --delete The command must correspond to the type of listener and authentication used to access the Kafka cluster. The Topic Operator will reconstruct the ZooKeeper topic metadata from the state of the topics in Kafka. 6.2.2.4. Topic Operator topic replication and scaling The recommended configuration for topics managed by the Topic Operator is a topic replication factor of 3, and a minimum of 2 in-sync replicas. apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: my-topic labels: strimzi.io/cluster: my-cluster spec: partitions: 10 1 replicas: 3 2 config: min.insync.replicas: 2 3 #... 1 The number of partitions for the topic. 2 The number of replica topic partitions. Currently, this cannot be changed in the KafkaTopic resource, but it can be changed using the kafka-reassign-partitions.sh tool. 3 The minimum number of replica partitions that a message must be successfully written to, or an exception is raised. Note In-sync replicas are used in conjunction with the acks configuration for producer applications. The acks configuration determines the number of follower partitions a message must be replicated to before the message is acknowledged as successfully received. The Topic Operator runs with acks=all , whereby messages must be acknowledged by all in-sync replicas. When scaling Kafka clusters by adding or removing brokers, replication factor configuration is not changed and replicas are not reassigned automatically. However, you can use the kafka-reassign-partitions.sh tool to change the replication factor, and manually reassign replicas to brokers. Alternatively, though the integration of Cruise Control for AMQ Streams cannot change the replication factor for topics, the optimization proposals it generates for rebalancing Kafka include commands that transfer partition replicas and change partition leadership. 6.2.2.5. Handling changes to topics A fundamental problem that the Topic Operator needs to solve is that there is no single source of truth: both the KafkaTopic resource and the Kafka topic can be modified independently of the Topic Operator. Complicating this, the Topic Operator might not always be able to observe changes at each end in real time. For example, when the Topic Operator is down. To resolve this, the Topic Operator maintains information about each topic in the topic store. When a change happens in the Kafka cluster or OpenShift, it looks at both the state of the other system and the topic store in order to determine what needs to change to keep everything in sync. The same thing happens whenever the Topic Operator starts, and periodically while it is running. For example, suppose the Topic Operator is not running, and a KafkaTopic called my-topic is created. When the Topic Operator starts, the topic store does not contain information on my-topic, so it can infer that the KafkaTopic was created after it was last running. The Topic Operator creates the topic corresponding to my-topic, and also stores metadata for my-topic in the topic store. If you update Kafka topic configuration or apply a change through the KafkaTopic custom resource, the topic store is updated after the Kafka cluster is reconciled. The topic store also allows the Topic Operator to manage scenarios where the topic configuration is changed in Kafka topics and updated through OpenShift KafkaTopic custom resources, as long as the changes are not incompatible. For example, it is possible to make changes to the same topic config key, but to different values. For incompatible changes, the Kafka configuration takes priority, and the KafkaTopic is updated accordingly. Note You can also use the KafkaTopic resource to delete topics using a oc delete -f KAFKA-TOPIC-CONFIG-FILE command. To be able to do this, delete.topic.enable must be set to true (default) in the spec.kafka.config of the Kafka resource. Additional resources Downgrading AMQ Streams Producer configuration tuning and data durability Scaling cluster and partition reassignment Cruise Control for cluster rebalancing 6.2.3. Configuring a Kafka topic Use the properties of the KafkaTopic resource to configure a Kafka topic. You can use oc apply to create or modify topics, and oc delete to delete existing topics. For example: oc apply -f <topic-config-file> oc delete KafkaTopic <topic-name> This procedure shows how to create a topic with 10 partitions and 2 replicas. Before you start It is important that you consider the following before making your changes: Kafka does not support making the following changes through the KafkaTopic resource: Changing topic names using spec.topicName Decreasing partition size using spec.partitions You cannot use spec.replicas to change the number of replicas that were initially specified. Increasing spec.partitions for topics with keys will change how records are partitioned, which can be particularly problematic when the topic uses semantic partitioning . Prerequisites A running Kafka cluster configured with a Kafka broker listener using TLS authentication and encryption . A running Topic Operator (typically deployed with the Entity Operator ). For deleting a topic, delete.topic.enable=true (default) in the spec.kafka.config of the Kafka resource. Procedure Prepare a file containing the KafkaTopic to be created. An example KafkaTopic apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: orders labels: strimzi.io/cluster: my-cluster spec: partitions: 10 replicas: 2 Tip When modifying a topic, you can get the current version of the resource using oc get kafkatopic orders -o yaml . Create the KafkaTopic resource in OpenShift. oc apply -f TOPIC-CONFIG-FILE 6.2.4. Configuring the Topic Operator with resource requests and limits You can allocate resources, such as CPU and memory, to the Topic Operator and set a limit on the amount of resources it can consume. Prerequisites The Cluster Operator is running. Procedure Update the Kafka cluster configuration in an editor, as required: oc edit kafka MY-CLUSTER In the spec.entityOperator.topicOperator.resources property in the Kafka resource, set the resource requests and limits for the Topic Operator. apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: # Kafka and ZooKeeper sections... entityOperator: topicOperator: resources: requests: cpu: "1" memory: 500Mi limits: cpu: "1" memory: 500Mi Apply the new configuration to create or update the resource. oc apply -f <kafka_configuration_file> 6.3. Using the User Operator When you create, modify or delete a user using the KafkaUser resource, the User Operator ensures those changes are reflected in the Kafka cluster. The Deploying and Upgrading AMQ Streams on OpenShift guide provides instructions to deploy the User Operator: Using the Cluster Operator (recommended) Standalone to operate with Kafka clusters not managed by AMQ Streams For more information about the schema, see KafkaUser schema reference . Authenticating and authorizing access to Kafka Use KafkaUser to enable the authentication and authorization mechanisms that a specific client uses to access Kafka. For more information on using KafkUser to manage users and secure access to Kafka brokers, see Securing access to Kafka brokers . 6.3.1. Configuring the User Operator with resource requests and limits You can allocate resources, such as CPU and memory, to the User Operator and set a limit on the amount of resources it can consume. Prerequisites The Cluster Operator is running. Procedure Update the Kafka cluster configuration in an editor, as required: oc edit kafka MY-CLUSTER In the spec.entityOperator.userOperator.resources property in the Kafka resource, set the resource requests and limits for the User Operator. apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: # Kafka and ZooKeeper sections... entityOperator: userOperator: resources: requests: cpu: "1" memory: 500Mi limits: cpu: "1" memory: 500Mi Save the file and exit the editor. The Cluster Operator applies the changes automatically. 6.4. Configuring feature gates AMQ Streams operators support feature gates to enable or disable certain features and functionality. Enabling a feature gate changes the behavior of the relevant operator and introduces the feature to your AMQ Streams deployment. Feature gates have a default state of either enabled or disabled . To modify a feature gate's default state, use the STRIMZI_FEATURE_GATES environment variable in the operator's configuration. You can modify multiple feature gates using this single environment variable. Specify a comma-separated list of feature gate names and prefixes. A + prefix enables the feature gate and a - prefix disables it. Example feature gate configuration that enables FeatureGate1 and disables FeatureGate2 env: - name: STRIMZI_FEATURE_GATES value: +FeatureGate1,-FeatureGate2 6.4.1. ControlPlaneListener feature gate The ControlPlaneListener feature gate has a default state of enabled . Use the ControlPlaneListener feature gate to change the communication paths used for inter-broker communications within your Kafka cluster. In AMQ Streams, control plane traffic consists of controller connections that maintain the desired state of the Kafka cluster. Data plane traffic mainly consists of data replication between the leader broker and the follower brokers. When ControlPlaneListener is enabled, control plane traffic goes through a dedicated control plane listener on port 9090. Data plane traffic continues to use the internal listener on port 9091. Using control plane listeners might improve performance because important controller connections, such as partition leadership changes, are not delayed by data replication across brokers. Disabling the ControlPlaneListener feature gate To disable the ControlPlaneListener feature gate, specify -ControlPlaneListener in the STRIMZI_FEATURE_GATES environment variable in the Cluster Operator configuration. When the ControlPlaneListener feature gate is disabled, control plane and data plane traffic go through the same internal listener on port 9091. This was the default behavior before the feature gate was introduced. Important The ControlPlaneListener feature gate must be disabled when upgrading from or downgrading to AMQ Streams 1.7 and earlier versions. 6.4.2. ServiceAccountPatching feature gate The ServiceAccountPatching feature gate has a default state of enabled . By default, the Cluster Operator reconciles service accounts and updates them when needed. For example, you can change service account labels and annotations after the operands are already created. To disable service account patching, disable the ServiceAccountPatching feature gate. Disabling the ServiceAccountPatching feature gate To disable the ServiceAccountPatching feature gate, specify -ServiceAccountPatching in the STRIMZI_FEATURE_GATES environment variable in the Cluster Operator configuration. 6.4.3. UseStrimziPodSets feature gate The UseStrimziPodSets feature gate has a default state of disabled . Currently, AMQ Streams relies on StatefulSets to create and manage pods for the ZooKeeper and Kafka clusters. AMQ Streams creates the StatefulSet and OpenShift creates the pods according to the StatefulSet definition. When a pod is deleted, OpenShift is responsible for recreating it. The use of StatefulSets has the following limitations: Pods are always created or removed based on their index numbers All pods in the StatefulSet need to have a similar configuration Changing storage configuration for the Pods in the StatefulSet is complicated The UseStrimziPodSets feature gate introduces a resource for managing pods called StrimziPodSet . When the feature gate is enabled, this resource is used instead of the StatefulSets. AMQ Streams handles the creation and management of pods instead of OpenShift. Using StrimziPodSets instead of StatefulSets provides more control over the functionality. Enabling the UseStrimziPodSets feature gate To enable the UseStrimziPodSets feature gate, specify +UseStrimziPodSets in the STRIMZI_FEATURE_GATES environment variable in the Cluster Operator configuration. Important The UseStrimziPodSets feature gate must be disabled when downgrading to AMQ Streams 2.0 and earlier versions. 6.4.4. Feature gate releases Feature gates have three stages of maturity: Alpha - typically disabled by default Beta - typically enabled by default General Availability (GA) - typically always enabled Alpha stage features might be experimental or unstable, subject to change, or not sufficiently tested for production use. Beta stage features are well tested and their functionality is not likely to change. GA stage features are stable and should not change in the future. Alpha and beta stage features are removed if they do not prove to be useful. The ControlPlaneListener feature gate moved to beta stage in AMQ Streams 2.0. The ServiceAccountPatching feature gate moved to beta stage in AMQ Streams 2.0. The UseStrimziPodSets feature gate is currently at the alpha stage. Note Feature gates might be removed when they reach GA. This means that the feature was incorporated into the AMQ Streams core features and can no longer be disabled. Table 6.1. Feature gates and the AMQ Streams versions when they moved to alpha, beta, or GA Feature gate Alpha Beta GA ControlPlaneListener 1.8 2.0 - ServiceAccountPatching 1.8 2.0 - UseStrimziPodSets 2.1 - - If a feature gate is enabled, you may need to disable it before upgrading or downgrading from a specific AMQ Streams version. The following table shows which feature gates you need to disable when upgrading or downgrading AMQ Streams versions. Table 6.2. Feature gates to disable when upgrading or downgrading AMQ Streams Disable Feature gate Upgrading from AMQ Streams version Downgrading to AMQ Streams version ControlPlaneListener 1.7 and earlier 1.7 and earlier UseStrimziPodSets - 2.0 and earlier 6.5. Monitoring operators using Prometheus metrics AMQ Streams operators expose Prometheus metrics. The metrics are automatically enabled and contain information about: Number of reconciliations Number of Custom Resources the operator is processing Duration of reconciliations JVM metrics from the operators Additionally, we provide an example Grafana dashboard. For more information about Prometheus, see the Introducing Metrics to Kafka in the Deploying and Upgrading AMQ Streams on OpenShift guide.
env: - name: STRIMZI_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace env: - name: STRIMZI_OPERATOR_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace env: - name: STRIMZI_OPERATOR_NAMESPACE_LABELS value: label1=value1,label2=value2 env: - name: STRIMZI_LABELS_EXCLUSION_PATTERN value: "^key1.*" env: - name: STRIMZI_CUSTOM_RESOURCE_SELECTOR value: label1=value1,label2=value2 env: - name: STRIMZI_KUBERNETES_VERSION value: | major=1 minor=16 gitVersion=v1.16.2 gitCommit=c97fe5036ef3df2967d086711e6c0c405941e14b gitTreeState=clean buildDate=2019-10-15T19:09:08Z goVersion=go1.12.10 compiler=gc platform=linux/amd64 <cluster-name> -kafka-0. <cluster-name> -kafka-brokers. <namespace> .svc. cluster.local create -f install/cluster-operator/050-ConfigMap-strimzi-cluster-operator.yaml edit configmap strimzi-cluster-operator # env: # - name: STRIMZI_OPERATOR_NAMESPACE_LABELS value: label1=value1,label2=value2 # apiVersion: v1 kind: ServiceAccount metadata: name: strimzi-cluster-operator labels: app: strimzi apiVersion: apps/v1 kind: Deployment metadata: name: strimzi-cluster-operator labels: app: strimzi spec: replicas: 1 selector: matchLabels: name: strimzi-cluster-operator strimzi.io/kind: cluster-operator template: # apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-cluster-operator-namespaced labels: app: strimzi rules: - apiGroups: - "rbac.authorization.k8s.io" resources: # The cluster operator needs to access and manage rolebindings to grant Strimzi components cluster permissions - rolebindings verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "rbac.authorization.k8s.io" resources: # The cluster operator needs to access and manage roles to grant the entity operator permissions - roles verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "" resources: # The cluster operator needs to access and delete pods, this is to allow it to monitor pod health and coordinate rolling updates - pods # The cluster operator needs to access and manage service accounts to grant Strimzi components cluster permissions - serviceaccounts # The cluster operator needs to access and manage config maps for Strimzi components configuration - configmaps # The cluster operator needs to access and manage services and endpoints to expose Strimzi components to network traffic - services - endpoints # The cluster operator needs to access and manage secrets to handle credentials - secrets # The cluster operator needs to access and manage persistent volume claims to bind them to Strimzi components for persistent data - persistentvolumeclaims verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "kafka.strimzi.io" resources: # The cluster operator runs the KafkaAssemblyOperator, which needs to access and manage Kafka resources - kafkas - kafkas/status # The cluster operator runs the KafkaConnectAssemblyOperator, which needs to access and manage KafkaConnect resources - kafkaconnects - kafkaconnects/status # The cluster operator runs the KafkaConnectorAssemblyOperator, which needs to access and manage KafkaConnector resources - kafkaconnectors - kafkaconnectors/status # The cluster operator runs the KafkaMirrorMakerAssemblyOperator, which needs to access and manage KafkaMirrorMaker resources - kafkamirrormakers - kafkamirrormakers/status # The cluster operator runs the KafkaBridgeAssemblyOperator, which needs to access and manage BridgeMaker resources - kafkabridges - kafkabridges/status # The cluster operator runs the KafkaMirrorMaker2AssemblyOperator, which needs to access and manage KafkaMirrorMaker2 resources - kafkamirrormaker2s - kafkamirrormaker2s/status # The cluster operator runs the KafkaRebalanceAssemblyOperator, which needs to access and manage KafkaRebalance resources - kafkarebalances - kafkarebalances/status verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "core.strimzi.io" resources: # The cluster operator uses StrimziPodSets to manage the Kafka and ZooKeeper pods - strimzipodsets - strimzipodsets/status verbs: - get - list - watch - create - delete - patch - update - apiGroups: # The cluster operator needs the extensions api as the operator supports Kubernetes version 1.11+ # apps/v1 was introduced in Kubernetes 1.14 - "extensions" resources: # The cluster operator needs to access and manage deployments to run deployment based Strimzi components - deployments - deployments/scale # The cluster operator needs to access replica sets to manage Strimzi components and to determine error states - replicasets # The cluster operator needs to access and manage replication controllers to manage replicasets - replicationcontrollers # The cluster operator needs to access and manage network policies to lock down communication between Strimzi components - networkpolicies # The cluster operator needs to access and manage ingresses which allow external access to the services in a cluster - ingresses verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "apps" resources: # The cluster operator needs to access and manage deployments to run deployment based Strimzi components - deployments - deployments/scale - deployments/status # The cluster operator needs to access and manage stateful sets to run stateful sets based Strimzi components - statefulsets # The cluster operator needs to access replica-sets to manage Strimzi components and to determine error states - replicasets verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "" resources: # The cluster operator needs to be able to create events and delegate permissions to do so - events verbs: - create - apiGroups: # Kafka Connect Build on OpenShift requirement - build.openshift.io resources: - buildconfigs - buildconfigs/instantiate - builds verbs: - get - list - watch - create - delete - patch - update - apiGroups: - networking.k8s.io resources: # The cluster operator needs to access and manage network policies to lock down communication between Strimzi components - networkpolicies # The cluster operator needs to access and manage ingresses which allow external access to the services in a cluster - ingresses verbs: - get - list - watch - create - delete - patch - update - apiGroups: - route.openshift.io resources: # The cluster operator needs to access and manage routes to expose Strimzi components for external access - routes - routes/custom-host verbs: - get - list - watch - create - delete - patch - update - apiGroups: - policy resources: # The cluster operator needs to access and manage pod disruption budgets this limits the number of concurrent disruptions # that a Strimzi component experiences, allowing for higher availability - poddisruptionbudgets verbs: - get - list - watch - create - delete - patch - update apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-cluster-operator-global labels: app: strimzi rules: - apiGroups: - "rbac.authorization.k8s.io" resources: # The cluster operator needs to create and manage cluster role bindings in the case of an install where a user # has specified they want their cluster role bindings generated - clusterrolebindings verbs: - get - list - watch - create - delete - patch - update - apiGroups: - storage.k8s.io resources: # The cluster operator requires "get" permissions to view storage class details # This is because only a persistent volume of a supported storage class type can be resized - storageclasses verbs: - get - apiGroups: - "" resources: # The cluster operator requires "list" permissions to view all nodes in a cluster # The listing is used to determine the node addresses when NodePort access is configured # These addresses are then exposed in the custom resource states - nodes verbs: - list apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-kafka-broker labels: app: strimzi rules: - apiGroups: - "" resources: # The Kafka Brokers require "get" permissions to view the node they are on # This information is used to generate a Rack ID that is used for High Availability configurations - nodes verbs: - get apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-entity-operator labels: app: strimzi rules: - apiGroups: - "kafka.strimzi.io" resources: # The entity operator runs the KafkaTopic assembly operator, which needs to access and manage KafkaTopic resources - kafkatopics - kafkatopics/status # The entity operator runs the KafkaUser assembly operator, which needs to access and manage KafkaUser resources - kafkausers - kafkausers/status verbs: - get - list - watch - create - patch - update - delete - apiGroups: - "" resources: - events verbs: # The entity operator needs to be able to create events - create - apiGroups: - "" resources: # The entity operator user-operator needs to access and manage secrets to store generated credentials - secrets verbs: - get - list - watch - create - delete - patch - update apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-kafka-client labels: app: strimzi rules: - apiGroups: - "" resources: # The Kafka clients (Connect, Mirror Maker, etc.) require "get" permissions to view the node they are on # This information is used to generate a Rack ID (client.rack option) that is used for consuming from the closest # replicas when enabled - nodes verbs: - get apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: strimzi-cluster-operator labels: app: strimzi subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-cluster-operator-global apiGroup: rbac.authorization.k8s.io apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: strimzi-cluster-operator-kafka-broker-delegation labels: app: strimzi The Kafka broker cluster role must be bound to the cluster operator service account so that it can delegate the cluster role to the Kafka brokers. This must be done to avoid escalating privileges which would be blocked by Kubernetes. subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-kafka-broker apiGroup: rbac.authorization.k8s.io apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: strimzi-cluster-operator-kafka-client-delegation labels: app: strimzi The Kafka clients cluster role must be bound to the cluster operator service account so that it can delegate the cluster role to the Kafka clients using it for consuming from closest replica. This must be done to avoid escalating privileges which would be blocked by Kubernetes. subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-kafka-client apiGroup: rbac.authorization.k8s.io apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: strimzi-cluster-operator labels: app: strimzi subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-cluster-operator-namespaced apiGroup: rbac.authorization.k8s.io apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: strimzi-cluster-operator-entity-operator-delegation labels: app: strimzi The Entity Operator cluster role must be bound to the cluster operator service account so that it can delegate the cluster role to the Entity Operator. This must be done to avoid escalating privileges which would be blocked by Kubernetes. subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-entity-operator apiGroup: rbac.authorization.k8s.io apiVersion: apps/v1 kind: Deployment spec: # template: spec: serviceAccountName: strimzi-cluster-operator containers: # env: # - name: "HTTP_PROXY" value: "http://proxy.com" 1 - name: "HTTPS_PROXY" value: "https://proxy.com" 2 - name: "NO_PROXY" value: "internal.com, other.domain.com" 3 # edit deployment strimzi-cluster-operator create -f install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml Exception in thread "main" io.fabric8.kubernetes.client.KubernetesClientException: An error has occurred. Caused by: java.security.KeyStoreException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_SESSION_READ_ONLY Caused by: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_SESSION_READ_ONLY apiVersion: apps/v1 kind: Deployment spec: # template: spec: serviceAccountName: strimzi-cluster-operator containers: # env: # - name: "FIPS_MODE" value: "disabled" 1 # edit deployment strimzi-cluster-operator apply -f install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: topic-name-1 labels: strimzi.io/cluster: my-cluster apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: topic-name-1 spec: topicName: topicName-1 1 # apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: topic-name-1 spec: topicName: name-2 # apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: mytopic---c55e57fe2546a33f9e603caf57165db4072e827e spec: topicName: myTopic # run kafka-admin -ti --image=registry.redhat.io/amq7/amq-streams-kafka-31-rhel8:2.1.0 --rm=true --restart=Never -- ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi-topic-operator-kstreams-topic-store-changelog --delete && ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi_store_topic --delete apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: my-topic labels: strimzi.io/cluster: my-cluster spec: partitions: 10 1 replicas: 3 2 config: min.insync.replicas: 2 3 # apiVersion: kafka.strimzi.io/v1beta2 kind: KafkaTopic metadata: name: orders labels: strimzi.io/cluster: my-cluster spec: partitions: 10 replicas: 2 apply -f TOPIC-CONFIG-FILE edit kafka MY-CLUSTER apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: # Kafka and ZooKeeper sections entityOperator: topicOperator: resources: requests: cpu: "1" memory: 500Mi limits: cpu: "1" memory: 500Mi apply -f <kafka_configuration_file> edit kafka MY-CLUSTER apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka spec: # Kafka and ZooKeeper sections entityOperator: userOperator: resources: requests: cpu: "1" memory: 500Mi limits: cpu: "1" memory: 500Mi env: - name: STRIMZI_FEATURE_GATES value: +FeatureGate1,-FeatureGate2