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 false. Of course, disabling TLS is possible only for loadbalancer and nodeport listeners. With OpenShift 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 validityDays property. 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 renewalDays property.

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.

Certificates renewal

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 KafkaMirrorMaker resource:

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: ".*"

The KafkaMirrorMaker resource allows you to define the consumer and producer configuration for connecting to the source and target cluster. The 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 KafkaConnect resource).

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!

Conclusion

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!