Strimzi Operator

Functionality

Overview

Strimzi is an open source Kubernetes Operator that can deploy and maintain Kafka clusters (Zookeeper and Broker). More on Strimzi

Axual Operator

Axual Platform works with the Strimzi Operator without any modifications, although in earlier versions of the platform the axual-operator was used that was a fork of Strimzi with a few additions. One major (optional) difference present is the use of the Principal Chain Builder in multi tenancy clusters.

Please also refer to the Strimzi Documentation to understand how to manage a Kafka cluster with Strimzi.

The Helm charts used to deploy Kafka are developed in-house by Axual. Not all functionality of Strimzi is currently available through these Helm charts.

Operator Pod

After an installation of the Strimzi Operator, an Operator Pod will start on Kubernetes that does any deployments, modifications and reparations of Strimzi resources on the cluster.

Example use

If you want to quickly deploy a Kafka cluster on Kubernetes, follow a Strimzi quick start guide.

Interactions

Strimzi Operator does not provide an API, it works by running a reconciliation loop on a regular interval that checks the state of Strimzi managed resources.

Rolling Restart Of Nodes

Do not restart nodes directly in Kubernetes, Strimzi will handle a rolling restart of Pods for Kafka, Zookeeper or StrimziConnect resources. For example:

kubectl annotate Kafka <name> strimzi.io/manual-rolling-update=true

kubectl annotate KafkaConnect <name> strimzi.io/manual-rolling-update=true

Do not kill Kafka Pods directly via kubectl, graceful terminations ensure replications etc are done properly.

Installation

To install the Strimzi Operator, Kubernetes cluster admin permissions are required.

Helm Charts

The Helm installation of Strimzi is documented here.

Configuration

Logging

Logs will we created by the strimzi Operator Pod that can be configured as described here.

Metrics

The Strimzi Operator Pod does not expose any metrics.

Security

Principal Chain Builder

Kafka’s PrincipalBuilder uses the Distinguished Name (DN) of a certificate to identify a principal. In case you are installing Axual in a multi-tenant environment, you may have different CAs for different tenants. These different CAs can issue a certificate with the same DN: this implies that the DN does not uniquely identify a principal. This can result in a principal accessing resources of a tenant it should not be authorized to access.

By using the principal chain to identify the principal instead of the DN, you can safely use certificates to identify a principal across different tenants on the same Kafka cluster.

So, for example, with the Kafka PrincipalBuilder we could have the following principal:

CN=app,O=Axual,C=NL

Using the principal chain mechanism, instead, the principal would be:

[0] CN=RootCA, [1] CN=Intermediate1, [2] CN=AppCert,O=MyOrg,C=NL

which uniquely identifies the principal.

In case you want to enable principal chain based ACL authentication, you need to provide the custom principal builder class.

kafka:
  fullName: "kafka-local"
  kafka:
    config:
      default.replication.factor: 1
      min.insync.replicas: 1
      principal.builder.class: io.axual.security.auth.SslPrincipalBuilder

In order for the above to work, you will need to provide a (Axual-provided) broker image that contains that class as part of the class path. The default strimzi base images do not support this feature out of the box.