Strimzi Kafka Resource Generator
A Strimzi KafkaTopic and
KafkaUser. The cluster label is what makes the
operator act on them at all.
kafka-resources.yaml
updates as you typeCommon mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Omitting the cluster label on a KafkaTopic or KafkaUser
Without strimzi.io/cluster the operator does not associate the resource with a cluster and simply ignores it. Nothing happens and nothing is logged as an error.
Instead:Set the label on every KafkaTopic and KafkaUser.
Setting broker config the operator manages
Listeners, storage, rack and several others are owned by the operator. Values set in config are rejected or overwritten.
Instead:Use the CR's own sections for those.
Editing topics with kafka-topics instead of the CR
The topic operator reconciles from the KafkaTopic resource, so a manual change is reverted on the next reconcile.
Instead:Change the CR. It is the source of truth once the operator is running.
Two things Strimzi does that have no error message
A missing label and a principal nobody wrote an ACL for.
The strimzi.io/cluster label is the whole mechanism
The operator watches for resources carrying a label naming its cluster. Without it, or with a typo, kubectl reports the object created and the operator never looks at it. There is no event, no status condition and no error: the topic simply does not exist in Kafka while the KafkaTopic exists in Kubernetes.
A Kafka topic name is not a Kubernetes object name
Kubernetes object names are DNS labels: lowercase, no dots, no underscores. Kafka topic names allow all three. That is why spec.topicName exists separately from metadata.name, and it means kubectl get kafkatopic can show a name that is not the topic name.
With TLS the principal is the distinguished name
A KafkaUser with TLS authentication gets a certificate, and the principal derived from it is CN=<name> rather than the plain name. Every ACL has to match that, and ssl.principal.mapping.rules on the broker decides whether it is shortened. An mTLS client that authenticates perfectly and is authorised for nothing is almost always this.
min.insync.replicas equal to replicas breaks operator upgrades
Strimzi performs rolling updates routinely, for its own version upgrades as well as yours. A topic with min.insync.replicas equal to its replica count stops accepting acks=all writes the moment one broker is taken down, so the configuration that looks safest in review is the one that makes every operator action an outage.
The operator can revert changes made outside it
Strimzi's topic operator reconciles, so a change made directly with kafka-configs.sh can be undone, or can leave the resource and the topic disagreeing. Pick one place to make changes and treat the other as read-only.