Strimzi Capability Assessment
Purpose: For platform engineers, provides Strimzi feature matrix, gap analysis, and version support evaluation.
Overview
Strimzi is the Kubernetes operator selected for openCenter Managed Kafka. This document evaluates Strimzi's capabilities against the requirements defined in ADR-004's Kafka blueprint specification. The assessment covers CRD coverage, lifecycle management, security, observability, and air-gap compatibility.
CRD Feature Matrix
| CRD | Status | openCenter Use |
|---|
Kafka | Stable (v1beta2) | Core — defines broker cluster, listeners, storage, TLS, auth |
KafkaTopic | Stable (v1beta2) | Core — declarative topic management via Entity Operator |
KafkaUser | Stable (v1beta2) | Core — client identity, authentication, ACL authorization |
KafkaConnect | Stable (v1beta2) | Deferred — not in v1 blueprint |
KafkaMirrorMaker2 | Stable (v1beta2) | Deferred — DR replication add-on |
KafkaBridge | Stable (v1beta2) | Not planned — HTTP bridge not in scope |
KafkaRebalance | Stable (v1beta2) | Future — partition rebalancing for capacity management |
KafkaNodePool | GA (v1beta2) | Future — mixed node types for tiered storage |
Lifecycle Management Capabilities
| Capability | Supported | Notes |
|---|
| Rolling upgrades (Kafka version) | Yes | Broker-by-broker restart with configurable strategy |
| Rolling upgrades (Strimzi operator) | Yes | Operator upgrade triggers broker reconciliation |
| Scaling brokers up | Yes | Add replicas, Strimzi handles partition reassignment |
| Scaling brokers down | Partial | Requires manual partition reassignment before removal |
| Storage expansion | Yes | PVC resize supported (storage class must allow expansion) |
| Storage migration | No | Changing storage class requires cluster recreation |
| Rollback after failed upgrade | Manual | Revert the Kafka CR to previous version; Strimzi rolls back brokers |
Security Capabilities
| Requirement | Strimzi Support | openCenter Fit |
|---|
| TLS in transit (broker-to-broker) | Yes — automatic via ClusterCA | Meets requirement |
| TLS in transit (client-to-broker) | Yes — per-listener TLS config | Meets requirement |
| mTLS client authentication | Yes — via KafkaUser with type: tls | Primary auth method |
| SCRAM-SHA-512 authentication | Yes — via KafkaUser with type: scram-sha-512 | Secondary auth method |
| OAuth 2.0 authentication | Yes — via listener config | Available for Keycloak integration |
| ACL authorization | Yes — via KafkaUser authorization.acls | Meets requirement |
| OPA authorization | Yes — external authorizer plugin | Not planned for v1 |
| Certificate rotation | Yes — automatic renewal before expiry | Meets requirement |
| Custom CA integration | Yes — bring your own CA certificates | Available if needed |
| Network policies | Partial — Strimzi generates basic policies | Supplemented by openCenter Kyverno policies |
Observability Capabilities
| Capability | Supported | Notes |
|---|
| JMX Prometheus exporter | Yes | Built-in sidecar, configured via metricsConfig in Kafka CR |
| Broker metrics | Yes | Standard Kafka JMX MBeans exported |
| ZooKeeper metrics | Yes | JMX exporter on ZooKeeper pods |
| Entity Operator metrics | Yes | Operator-level metrics |
| Cruise Control metrics | Yes | Available when Cruise Control is enabled |
| Log output format | JSON or plain | Configurable via logging in Kafka CR |
| Distributed tracing | Yes | OpenTelemetry support via interceptors |
Air-Gap Compatibility
| Requirement | Assessment |
|---|
| Container images from known registries | Yes — all images from quay.io/strimzi/ |
| No runtime internet dependencies | Yes — operator and brokers run fully offline |
| Image count per deployment | ~6 images (operator, kafka, zookeeper, entity-operator, bridge, init) |
| Helm chart for operator | Yes — strimzi/strimzi-kafka-operator chart |
| Offline Helm install | Yes — chart can be pulled and stored in Harbor |
| CRD installation | Bundled with operator Helm chart |
All Strimzi images can be mirrored through Harbor using openCenter-AirGap. The operator does not phone home or require external API access.
Version Support Matrix
| Strimzi Version | Kafka Versions Supported | Kubernetes Versions | Status |
|---|
| 0.40.x | 3.6.x, 3.7.x | 1.25–1.30 | Current |
| 0.39.x | 3.6.x, 3.7.x | 1.25–1.29 | Supported |
| 0.38.x | 3.5.x, 3.6.x | 1.23–1.28 | End of life |
openCenter pins to a tested Strimzi + Kafka version pair. Upgrades follow a validated path: non-prod first, then production with a maintenance window. The supported version matrix is published with each blueprint release.
Gap Analysis
| Gap | Impact | Mitigation |
|---|
| No built-in backup for topic data | Customer data protection requires external tooling or MirrorMaker2 | Document as customer responsibility in base; offer DR add-on |
| Scaling down requires manual partition reassignment | Operational complexity for capacity reduction | Document runbook; automate with Cruise Control in future |
| ZooKeeper mode still default | KRaft (ZooKeeper-less) mode is available but not GA in all Strimzi versions | Plan migration to KRaft when Strimzi declares it stable |
| No built-in schema registry | Schema governance requires separate component | Planned as Q4 add-on (Apicurio or Confluent Schema Registry) |
| Network policy generation is basic | Does not cover all openCenter isolation requirements | Supplement with Kyverno-generated NetworkPolicies |
Evaluation Summary
Strimzi meets the core requirements for openCenter Managed Kafka v1:
- Stable CRDs for Kafka, KafkaTopic, and KafkaUser
- Rolling upgrades with configurable strategy
- TLS and authentication built into the operator lifecycle
- JMX metrics export for Prometheus integration
- Full air-gap compatibility with no runtime internet dependencies
- Active community with regular releases and security patches
The gaps (topic data backup, ZooKeeper dependency, schema registry) are addressed through the blueprint's shared responsibility model and the planned add-on roadmap.