0.7.0 (Work in progess - expected September 2018)
Add support for SASL SCRAM-SHA authentication
Support for authentication using SASL SCRAM-SHA should be added to the already supported TLS Client Authentication.
Strimzi and Kafka updates
Strimzi should make it possible to smoothly handle updates from one Kafka version to another.
Make it possible to automatically rotate certficates when they reach expiration.
0.6.0 (August 2018)
Custom Resource Definitions support for Topic Operator
The Topic Operator uses Custom Resource Definitions (CRDs) instead of ConfigMaps.
Add support for encryption to Kafka Connect
Add support for encryption and authentication for Kafka Connect.
Add support for authentication and authorization
In order to use Strimzi for production workloads, it has to be possible to secure the cluster. This should include:
- Authentication using TLS client authentication
0.5.0 (July 2018)
Add support for Kubernetes Affinity and Tolerations
Using Kubernetes Affinity and Tolerations, users can manage scheduling of Kafka, Zookeeper and Kafka Connect pods into nodes.
Custom Resource Definitions support for Cluster Operator
The Cluster Operator uses Custom Resource Definitions (CRDs) instead of ConfigMaps.
Add support for TLS encryption
All traffic between Kafka brokers, Zookeeper nodes and Topic Operator is now encrypted using TLS.
0.4.0 (May 2018)
Improve configuration possibilities for Kafka and Kafka Connect
Currently, Strimzi gives the user only limited possibilities to configure Kafka and Kafka Connect. Only a few configuration options are exposed and user configurable. Users should have more freedom to fine-tune Kafka and Kafka Connect configuration according to their exact needs.
Add support for Kubernetes resource request and limits
All Strimzi deployments are currently running without any resource requests and limits (see Kubernetes documentation for more details). A possibility to configure resource limits and requests should be added to the Cluster Controller component.
Accessing Kafka from the outside of Kubernetes/OpenShift
Currently, the Kafka deployment is accessible only from within the same Kubernetes/OpenShift cluster in which it is deployed. In some scenarios it will be necessary to access it from the outside.
Support for automated cluster balancing
During the lifecycle of the Kafka cluster it can happen that it becomes unbalanced. Some nodes are hosting very heavy topics (i.e. busy topics with a lot of traffic) while other nodes are idle most of the time hosting less busy topics. An automated cluster balancer should continuously monitor the cluster state and balance it (re-distribute the topics) when needed to make sure that the load is optimally distributed across all cluster nodes.
Service broker support
The Cluster Operator should be able to work as a Service Broker.
Integration with other protocols
Allow to access Kafka using different protocols such as HTTP, AMQP or MQTT.