Is this a good idea to host java jar files on ConfigMap when we want to extend a JVM classpath?
Normally the application itself is baked into docker image but extending it(via plugin jar etc.) requires either attaching volume, copying the jar file to the volume and and restart the pod but you need a volume to do that. The other option is to put directly the jar into ConfigMap as binary object and restart the pod. The latter seems easier and faster and it should work for small size jar files.
It looks like a workaround to put jar into the config maps. Try another solution.
Why can not you pack this dependency on docker image?
You can use a init container as pointed by @reegnz
The docs of this feature are here:
https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-initialization/
No, ConfigMaps are designed for metadata only. In fact etcd (the default key/value store in kubernetes) object size is capped at 1MB.
What you could do is host the jars in a different service and have an init container download the files before the java service starts.
