Re: Tipps fürs Lifecylemanagement von Containerimages

Moin,

On Wed Mar 11, 2026 at 9:52 PM CET, N. Schwirz wrote:
> Welche Erfahrungen habt ihr bisher mit der Gestaltung von Lebenszyklen
> von Images gemacht? Wenn Nutzer ein bestimmtes Containerimage mit
> bestimmten Tags wollen, ist es ja schnell in der Containerregistry
> bereit gestellt. Doch wie werde ich veraltete/ nicht mehr verwendete
> Images wieder los, wenn sie die entsprechenden Nutzer nicht selbst
> wieder l=C3=B6schen? Macht es vielleicht Sinn, Jedes Tag oder wenigstens
> jedes Containerimage mit einem Ablaufdatum zu versehen? W=C3=A4re eine
> regelm=C3=A4=C3=9Fige Brauche-ich-noch Best=C3=A4tigung durch Nutzer bess=
er?

Oh hey, mein Fachgebiet.

Quelle: Ich bin Lead-Developer und Service-Owner f=C3=BCr (unter anderem)
eine selbstentwickelte Registry. <https://github.com/sapcc/keppel>

Was auf jeden Fall stimmt, ist, dass man darauf vorbereitet sein muss,
dass Nutzer ihre Images selbst nicht l=C3=B6schen. Das passiert faktisch ni=
e.

F=C3=BCr unsere eigenen Repos haben wir GC-Policies in der Form: (aus dem
Ged=C3=A4chtnis, aus didaktischen Gr=C3=BCnden leicht vereinfacht)

- L=C3=B6sche alle ungetaggten Images, die =C3=A4lter als 3h sind
- Sch=C3=BCtze alle Images, die als /.*latest/ getaggt sind
- Sch=C3=BCtze die f=C3=BCnf neuesten Images pro Repo (nach Push-Timestamp)
- L=C3=B6sche alle Images, die l=C3=A4nger als 28 Tage nicht gepullt wurden

Hierbei gewinnt pro Image die erste passende Regel in der pr=C3=A4sentierte=
n
Reihenfolge. Mit der letzten Regel sch=C3=BCtzen wir alle Images, die aktiv
im Einsatz sind, weil Audit-Prozesse alle Images von aktiven Containern
regelm=C3=A4=C3=9Fig auf bekannte Sicherheitsl=C3=BCcken untersuchen. Also =
anstatt der
expliziten "Brauche-ich-noch-Best=C3=A4tigung" reicht halt aktiver Einsatz =
in
einem Kubernetes-Cluster. Das ist kein perfektes System, weil Images
auch woanders eingesetzt werden k=C3=B6nnen, sei es auf Workstations oder i=
n
CI-Pipelines. Aber es ist im Gro=C3=9Fen und Ganzen gut genug.

Das alles ist empirisch ausreichend, um das Wachstum der Image-Menge auf
sinnvolle Ma=C3=9Fe zu begrenzen (f=C3=BCr unsere Organisationseinheit mit =
mehreren
hundert Entwicklern und Admins sind wir bei Gr=C3=B6=C3=9Fenordnung 10k-20k=
 Images).
Eventuell muss ich irgendwann mal die "sch=C3=BCtze die f=C3=BCnf neuesten
Images"-Regel fallen lassen, aber ich glaube, dass die der wesentliche
Grund ist, dass es auch mit dem Usecase "Image l=C3=A4uft nur auf
Workstations oder in CI-Pipelines" gut geht, weil dort meistens die
neuesten Images eingesetzt werden.

F=C3=BCr die Accounts von Kunden trifft das alles nat=C3=BCrlich nicht zu. =
Da
l=C3=B6sen wir das Problem haupts=C3=A4chlich dadurch, dass Storage Geld ko=
stet
und die Kunden damit zumindest ein bisschen einen Anreiz haben, sich
ebenfalls GC-Policies einzurichten. Wir haben einen automatischen Alarm,
wenn Kunden mehr als 100k Images haben, und initiieren dann aktiv eine
Kommunikation von unserer Seite, sofern die Kunden noch keine
GC-Policies eingerichtet sind oder die Policies nicht optimal formuliert
sind. Das wird meistens dankend angenommen.

Hope that helps.

Sch=C3=B6ne Gr=C3=BC=C3=9Fe
Stefan