We are delighted to announce the new Strimzi 0.9.0 release with some new features!

Annotate and label the cluster resources

This feature really shows the engagement that the Strimzi team has with the community! A lot of Strimzi users started to have the need to add labels and annotations to the different resources created by the Cluster Operator like StatefulsSets, Pods and so on. It was driven by a better coexistence with other “frameworks” like Istio or Cilium and better configuration of things like Prometheus. With this new release, it’s now possible to use the new template property under the kafka and zookeeper properties in the Kafka resource in order to do that. It’s available for Kafka Connect and Kafka Mirror Maker deployments as well.

Here’s an example snippet that add a few labels and annotations to Kafka related Pods and Services.

apiVersion: kafka.strimzi.io/v1alpha1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    ...
    pods:
      metadata:
        labels:
          key1: label1
          key2: label2
        annotations:
          key1: annotation1
          key2: annotation2
    service:
      metadata:
        labels:
          key1: label1
        annotations:
          key1: annotation1
    ...

Plan rolling updates on CA certificate renewal

In most cases, the Cluster Operator only updates your Kafka or Zookeeper clusters in response to changes to the corresponding Kafka resource. This enables you to plan when to apply changes to a Kafka resource to minimize the impact on Kafka client applications.

However, some updates to your Kafka and Zookeeper clusters can happen without any corresponding change to the Kafka resource. For example, the Cluster Operator will need to perform a rolling restart if a CA (Certificate Authority) certificate that it manages is close to expiry.

While a rolling restart of the pods should not affect availability of the service (assuming correct broker and topic configurations), it could affect performance of the Kafka client applications. Maintenance time windows allow you to schedule such spontaneous rolling updates of your Kafka and Zookeeper clusters to start at a convenient time. If maintenance time windows are not configured for a cluster then it is possible that such spontaneous rolling updates will happen at an inconvenient time, such as during a predictable period of high load.

You configure maintenance time windows by entering an array of strings in the new Kafka.spec.maintenanceTimeWindows. Each string is a cron expression interpreted as being in UTC (Coordinated Universal Time, which for practical purposes is the same as Greenwich Mean Time).

Here’s an example snippet that define a single maintenance time window.

apiVersion: kafka.strimzi.io/v1alpha1
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    ...
  zookeeper:
    ...
  maintenanceTimeWindows:
  - "* * 0-1 ? * SUN,MON,TUE,WED,THU *"
  ...

The above example snippet configures a single maintenance time window that starts at midnight and ends at 01:59am (UTC), on Sundays, Mondays, Tuesdays, Wednesdays, and Thursdays. The Kafka and Zookeeper nodes rolling update, due to a CA certificate renewal, will start only if the above condition is satisfied during the Cluster Operator reconciliation.

… and many more

Other features were included in this new release, the most important ones:

• Updated the provided Docker images to the Apache Kafka 2.0.1 version
• Added support for TransactionalID in the KafkaUser resource

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!