Strimzi

Roadmap

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.

Certificate rotation

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:

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.

Future releases

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.