Switch from init container to sidecar, with Kafka 1.1.0#167
Conversation
for future dynamic config support. Can be evaluated manually now (with Kafka 1.1.0) by exec to config pod and edit of server.properties there. If the init container is slow, which is unlikely, kafka will crash loop until server.properties exists and upon existence start normally.
|
Maybe we'd be better off with init an init script using We'd have to change how we gracefully handle zone lookup failures in the default script, but we could simplify the sed checking at the end. |
Created #168. I'm merging this now to 4.x so we can base testing on it. The only drawback I can see now is that I tend to get restarts=1 in pod listings, because init involving kubectl is slower than Kafka JVM start. |
solsson
changed the title
|
To clarify: This PR did not introduce any support for actually changing any config dynamically, beyond what an upgrade to Kafka 1.1 does. It only recognizes that Updating Broker Configs is part broker-level. Annotations and labels may play a part here, as with Zookeeper. It's quite likely that the init script can be reduced in scope, because #78 can now be implemented (and customized) in a way that is persistent in ZooKeeper and takes precedence over server.properties.
@StevenACoffman Do you have ideas on the direction here? |
kubernetes/kubernetes#62078 (comment) would probably solve that together with:
|
1 participant
... to set the stage for some kind of tooling around Kafka 1.1+ dynamic config. I'm particularily interested in runtime listeners reconfiguration, to better support out-of-cluster use cases such as #78.