Comment # 8 on bug 1213786 from Egbert Eich

It looks like we only publish containers for the latest version of kubernetes
sub-packages - ie, once kubernetes1.N becomes available, we stop publishing
containers for kubernetes1.N-1 sub-packages while upstream seems to support
multiple versions of kubernetes.
This explains why 
    registry.opensuse.org/kubic/kube-apiserver:v1.24.16
    registry.opensuse.org/kubic/kube-controller-manager:v1.24.16
    registry.opensuse.org/kubic/kube-scheduler:v1.24.16
    registry.opensuse.org/kubic/kube-proxy:v1.24.16
and for this matter any kubernetes subpackages of kubernetes beyond 1.24.3.

To mitigate this, we most likely need to have separate versioned container
packages 
like:
 openSUSE:Containers:Tumbleweed/kubic-kube-apiserver-image1.N
   with:
         <package name="kubernetes1.N-apiserver"/>
 openSUSE:Containers:Tumbleweed/kube-controller-manager1.N
   with:
         <package name="kubernetes1.N-controller-manager"/>
 openSUSE:Containers:Tumbleweed/kubic/kube-scheduler1.N
   with:
        <package name="kubernetes1.N-scheduler"/>
 openSUSE:Containers:Tumbleweed/kube-proxy1.N
   with:
        <package name="kubernetes1.N-proxy"/>
Also the currently 'unversioned' dependency package would be required 'per
version'.
An easier way would be to not announce the latest 'upstream' versions through 
https://kubic.opensuse.org/release/stable-1.<N>.txt but the latest for which a
container is available. However, if the later releases were security-related,
this may not be the way to go.
Unfortunately. right now, the efforts to maintain separate code stream of
kubernetes are largely in vain as the registry does not require the needed
containers. It would still allow users to build their own containers - but who
would seriously consider that?