Broker config as a Kafka CR
server.properties translated into the Strimzi resource, with what Strimzi manages itself
num.partitions=6 min.insync.replicas=2 log.retention.hours=168
Turn a server.properties into Strimzi resources, splitting the settings the operator owns from the ones that belong in spec.kafka.config. An operator-owned key in the config block is rejected rather than merged, which is the part worth knowing before applying anything.
The output is two KafkaNodePool resources and one
Kafka resource, which is the shape current Strimzi wants.
The disk and retention calculator on this site sizes the storage figure.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Convert. Nothing leaves this tab.
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
server.properties translated into the Strimzi resource, with what Strimzi manages itself
num.partitions=6 min.insync.replicas=2 log.retention.hours=168
Listener and storage settings the operator owns, which cannot be set in config
listeners=PLAINTEXT://:9092 log.dirs=/var/lib/kafka num.partitions=12
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Strimzi owns listeners, storage and rack. Settings it manages are rejected or overwritten.
Instead:Use the CR's own listeners section.
Topics are separate KafkaTopic resources. Broker defaults do not retroactively change existing topics.
Instead:Manage topics as their own resources.
Strimzi generates and rotates its own CA and certificates. Hand-placed files are replaced.
Instead:Let the operator manage them, or supply a custom CA the documented way.
The Strimzi operator generates listeners, storage, authorization and certificates from the resource. Putting one of those settings in the config block is rejected, not merged, so knowing which is which is most of the conversion.
listeners, advertised.listeners and everything under listener. come from spec.kafka.listeners. log.dirs comes from spec.kafka.storage. authorizer.class.name and super.users come from spec.kafka.authorization. Every ssl. and sasl. setting comes from the listener definitions, because the operator runs its own CA and issues the certificates. broker.id is assigned per pod. Supply any of these in spec.kafka.config and the operator refuses the resource, which is better than silently overriding you but only if you know why.
# rejected in spec.kafka.config
listeners -> spec.kafka.listeners
log.dirs -> spec.kafka.storage
authorizer.class.name -> spec.kafka.authorization
super.users -> spec.kafka.authorization.superUsers
ssl.keystore.location -> managed by the operator's CA
broker.id -> assigned per pod Recent Strimzi models brokers and controllers as KafkaNodePool resources with a roles list, alongside one Kafka resource carrying the shared configuration, and it wants the node-pools and kraft annotations enabled. The output here is two pools and one Kafka resource for that reason: a single Kafka resource with a replicas field is the older ZooKeeper-era shape.
The operator creates __consumer_offsets and __transaction_state using the replication factors in spec.kafka.config. If those exceed the broker count the topics cannot be created, and the cluster comes up looking healthy until the first consumer group tries to commit. The replication factor of an existing internal topic cannot be raised afterwards without a reassignment, so this is much cheaper to get right before first start.
Strimzi runs a CA and gives every broker and every KafkaUser a certificate, renewing them on a schedule. That is why no ssl. path belongs in the config: a keystore location you supply would be generated over. To bring your own CA you replace the operator's CA Secrets rather than configuring paths, which is a different operation from what a properties file expresses.
Listener and storage values in the output are working defaults rather than translations of yours, because those are structured fields with no properties equivalent to derive from: a listener in Strimzi has a name, a type and an authentication block, not a URL. Everything the operator does not own is copied into spec.kafka.config verbatim, and everything it does own is listed at the bottom with the field that replaces it.