Hi Jiří, Why can't you run it from another Pod? You should be able to specify --bootstrap-server and point it to the brokers to connect to. You can also pass further properties to it using the --command-config option. It should be also possible to use it from the Admin API <https://kafka.apache.org/36/javadoc/org/apache/kafka/clients/admin/Admin.html#updateFeatures(java.util.Map,org.apache.kafka.clients.admin.UpdateFeaturesOptions)> directly from anywhere if needed.
But there is indeed no way to manage this declaratively in the Kafka properties file as it was possible with inter.broker.protocol.version. It also works a bit differently than the inter.broker.protocol.version worked before KRaft: * I think it does more checking whether all nodes in the cluster support the version etc. * You can't really downgrade it easily (at least not safely). So maybe it is better you cannot just change some environment variables as that might result in crash-looping pods. Jakub On Thu, Oct 19, 2023 at 2:58 PM Soukal, Jiří <j.sou...@quadient.com.invalid> wrote: > Hello all, > Final step of the upgrade procedure is to run command like: > > "./bin/kafka-features.sh upgrade --metadata 3.6" > > In the Kubernetes world, which works in the desired state configuration > (yamls and its the upper level abstractions), this is quite complicated. > > The first thing I tried to find is if I can call it from another kafka pod > while specifying a server to connect to, however it is not possible. It > needs to be run from withing the running kafka pod. This leads to executing > to the pod or running the kubectl exec (e.g. kubectl exec kafka-0 -n cloud > -- bin/kafka-configs.sh ... ) > > However, this command is also imperative instead of declarative. > > Question: Is there another approach? E.g. driving the metadata version via > ENV variable or file configuration? > > It seems like it was designed without Kubernetes world in mind. >
