We are delighted to announce the new Strimzi 0.8.0 release with many awesome new features!
Access your Kafka cluster from outside—without TLS
The previous release added the ability to access your Kafka cluster from the outside.
So, Kafka clients could exchange messages even if they were not running on the same Kubernetes or OpenShift cluster as the Kafka deployment.
Previously, the TLS protocol needed to be enabled on the client side because all the provided
listeners could only be accessed through encryption.
With this new release, all the
listeners have TLS enabled by default but you can choose to disable it by setting the
tls property to
Of course, disabling TLS is possible only for
route, the traffic is sneaked through with TLS passthrough and that is why it has to always use TLS.
Here’s an example snippet that exposes the Kafka cluster using
loadbalancer with TLS disabled:
apiVersion: kafka.strimzi.io/v1alpha1 kind: Kafka metadata: name: my-cluster spec: kafka: ... listeners: external: type: loadbalancer tls: false ...
Handle certificate renewal and expiry
The cluster CA and clients CA certificates are only valid for a limited time period, known as the validity period which is defined as the number of days since the certificate was generated.
For auto-generated certificates, you can now configure the validity period by setting the
Manually-installed CA certificates should have their own validity period defined.
When a CA certificate expires, the certificates that it has signed will fail validation, even if they were previously valid. This means that, when replacing a CA certificate, you must also replace all other certificates signed by it. When the replacement of a CA certificate is in progress, it is necessary for peers to trust certificates signed by either the old or the new CA. This ensures the continued operation of the cluster.
To allow the renewal of CA certificates without a loss of service, the Cluster Operator will initiate certificate renewal before the old CA certificates expire.
It is possible to configure the renewal period by setting the
Here’s an example snippet that defines auto-generated certificates validity and renewal period:
apiVersion: kafka.strimzi.io/v1alpha1 kind: Kafka metadata: name: my-cluster spec: kafka: ... clusterCA: generateCertificateAuthority: true validityDays: 730 renewalDays: 60 clientsCA: generateCertificateAuthority: true validityDays: 365 renewalDays: 15 ...
The renewal period is measured backwards, from the expiry date of the current certificate.
A new operator in town: Mirror Maker!
The Strimzi operators family has a new baby: the Kafka Mirror Maker Operator.
Apache Kafka Mirror Maker is a component of the Apache Kafka project which provides data “mirroring” between Kafka clusters. The Mirror Maker consumes messages from a source cluster and republishes those messages to a target cluster. Source and target clusters don’t need to be both deployed by Strimzi and running in the same Kubernetes/OpenShift cluster where the Mirror Maker itself is running.
With this new release, the Cluster Operator is now able to deploy one or more Mirror Maker replicas thanks to the new
KafkaMirrorMaker native resource.
Here’s an example snippet that defines a
apiVersion: kafka.strimzi.io/v1alpha1 kind: KafkaMirrorMaker metadata: name: my-mirror-maker spec: replicas: 1 consumer: bootstrapServers: my-source-cluster-kafka-bootstrap:9092 groupId: my-source-group-id producer: bootstrapServers: my-target-cluster-kafka-bootstrap:9092 whitelist: ".*"
KafkaMirrorMaker resource allows you to define the
producer configuration for connecting to the source and target cluster.
whitelist property specifies the list of topics that the Kafka Mirror Maker has to mirror from the source to the target.
It allows any regular expression from the simplest case with a single topic name to complex patterns.
For example, you can mirror topics A and B using “A|B” or all topics using “*”.
Of course, Kafka Mirror Maker can connect to clusters which have TLS protocol enabled and use authentication (TLS client authentication or SCRAM-SHA-512).
It is possible to specify trusted TLS certificates and authentication client certificate or credentials in the
KafkaMirrorMaker resource as well (as it already happens for
Here’s an example snippet that defines a
KafkaMirrorMaker resource for connecting to TLS enabled cluster and TLS client authentication:
apiVersion: kafka.strimzi.io/v1alpha1 kind: KafkaMirrorMaker metadata: name: my-mirror-maker spec: replicas: 1 consumer: bootstrapServers: my-source-cluster-kafka-bootstrap:9093 groupId: my-source-group-id tls: trustedCertificates: - secretName: my-source-secret certificate: ca.crt authentication: type: tls certificateAndKey: secretName: my-source-secret certificate: public.crt key: private.key producer: bootstrapServers: my-target-cluster-kafka-bootstrap:9093 tls: trustedCertificates: - secretName: my-target-secret certificate: ca.crt authentication: type: tls certificateAndKey: secretName: my-target-secret certificate: public.crt key: private.key whitelist: ".*"
Other Kafka Mirror Maker configuration properties can be found at the official documentation.
… and many more
Other features were included in this new release, the most important ones:
- Better support for TLS hostname verification for external connections
- Triggering rolling update / pod deletion manually
Of course, bug fixes are there as well!
This release represents another really huge milestone for this open source project. You can refer to the release changes log to get more information.
What are you waiting for? Engage with the community and help us to improve the Strimzi project for running your Kafka cluster on Kubernetes/OpenShift!