<p>I try to use the Kubernetes API to read metadata via annotations from container images. The metadata is applicable to every instance of the respecting image and is needed in order to run any resulting container properly. Following this SO <a href="https://stackoverflow.com/questions/45599353/get-docker-image-labels-from-kubernetes-api">question</a> it is not possible to read Docker image labels from the kubernetes API directly.</p>
<p>My next thought was to use custom annotations added to the image manifest, although this seems to be a pretty hacky solution for such a &quot;simple&quot; task. Anyway if I add the annotations to the manifest using docker, I see no way to read them from the Kubernetes API.</p>
<p>I think I am on the completely wrong track here. This seems to be a rather simple task which other people likely have implemented already...anyway I cannot find any further information regarding this. Is it really that hard to read image metadata via kubernetes before deploying a container of that image?</p>
<p>Thanks in advance for any help!</p>
<p>Edit:</p>
<p>The reason I am asking is because I want to grant the containers of specific images access to specific serial USB devices (e.g. FTDI232) on diverse host systems. Since I have no idea which path (e.g. /dev/ttyUSB0) will be assigned to the USB devices, I wrote a program that is monitoring USB devices and, in case an appropriate device is plugged in or gets plugged in, creates the container and passes it the corresponding path. From inside the container I want to access the serial device via a static, non-changing path (e.g. /dev/FTDI232)</p>

teawolf
<p>Yes. The K8s API is limited when it comes to this, I believe the abstractions for container image metadata are at lower level and probably left out for a reason.  You can always look at the <a href="https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/" rel="nofollow noreferrer">CRI spec</a> to see what's supported (note that the doc is out of date so you might have to look at the code).</p>
<p>If the end goal is to use Kubernetes to run your workloads it sounds like the more feasible route here is just to write a script that reads that image manifest outside Kubernetes and create the manifest files that you need to run your workloads after (based on that metadata) and then finally apply it to your cluster.</p>
<p>If you are using a common container image registry you could also write something that pulls the images from that registry to just pick metadata and metadata changes.</p>
