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
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
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
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!