Quarkus: Improve Kubernetes experience

[geoand]

From @cescoffier :

Here are some improvements that may be interesting to have:

• Config analysis:
  Print somewhere in the console or in a generated descriptor the main configuration key that needs to be overridden: database url, MP rest client, Kafka broker location... Each extension should be able to contribute to this set.

• Config map:
  Generate a config map file with the configuration from my first point, and extend the descriptor with the adequate "env" section (with the right indentation as I wasted maybe one hour to fix this crap)

• Display BIG warning about hard coded value (bulkhead, timeout...)

• Image name and versioning
  This is the tricky part, how to version the image. We cannot really use latest, as you don't really know when it's going to be seen (stopping rolling update, editing conf is a hack). We may want to do something with $VERSION-000x where x is the "build" number. Not sure how practical it would be.

• Generate the descriptor in the user space (and not in wiring-classes). So, the user can edit it. That would mean that the extension is a one-shot, or generate a second file if the first file has been edited.

• Ability to add custom label to all object.

[geoand]

• Config analysis: That is an great point! I really like it!

• Config map: I like this one

• Not sure I understand the hardcoded values point. Can you explain a little more?

• Not really sure we can do much about this, but worth checking out

• The descriptor has changed location - it is now at target/kubernetes

• Labels can now be added with the latest changes @iocanel has made - basically the extension has been overhauled to be make things completely configurable via properties

[geoand]

From @cescoffier about bulkhead and timeout:

That's my crusade against broken fault tolerance. People do something like @Bulkhead(5) or @Timeout(1000), but this depends on your environment. Bulkhead limts the outbound concurrency without knowing the capacity (number of instance for example) of the called service. Timeout depends on the network topology and latency.

[loicmathieu]

• Config map: what's difficult with generating a ConfigMap is that not everything should be overriden at runtime. I understand that your first point will try to guess what's needed to be overriden but it really depends on the user. For exemple I don't use ConfigMap for mp-rest-client URL as the target service is deployed in k8s on thd same namespace, so I use k8s service name that are stable accross all my envs (one env = one namespace). And then I use a single ConfigMap with env variables in it that I defines in my pod using envFrom ...

• Image name and versioning: I don't understand the issue, if you use imagePullPolicy: always you can use whatever you want as the version (latest, the pom.xml version, ...) as the image will always be pulled (in fact, not realy, if it didn't change k8s will not pull it again: k8s will first do comparison of the image SHA1). So I always use the same image version as the pom.xml one.

[jclingan]

This is somewhat of a duplicate issue I opened a while ago. Great minds think alike, but I'd like to mention that a PM brought it up first :-)