Welche Regeln zur Image-Aufbewahrung halten eine Container-Registry klein, ohne noch eingesetzte Images zu löschen?

Offene Frage

Die (zitierte) Distribution-Dokumentation erklärt, dass Layer einmalig unter ihrer Inhaltsadresse gespeichert und zwischen Manifesten geteilt werden, dass das Löschen eines Manifests über die API nur Referenzen entfernt und dass die Garbage Collection anschliessend Blobs löscht, auf die kein Manifest mehr verweist, in einem Mark-and-Sweep-Lauf, während dessen die Registry im Lesemodus sein sollte. Verwaltete Registries fassen das in Lifecycle-Regeln: Der (zitierte) ECR-Leitfaden beschreibt Richtlinien, die Images nach Regelpriorität innerhalb von etwa 24 Stunden ab Zutreffen ablaufen lassen, und empfiehlt, vor der Anwendung einer Richtlinie eine Vorschau zu erstellen, welche Images sie ablaufen liesse.

Was die Dokumentation nicht sagt, ist, welche Regeln für ein Team sicher sind, das pro Commit ein Image baut, per Digest deployt und gelegentlich Wochen später zurückrollt:

• Ablauf nach Alter oder Anzahl («ungetaggte Manifeste löschen, die älter als N Tage sind», «die letzten N pro Repository behalten») gegenüber deployment-bewussten Regeln, die abfragen, worauf laufende Workloads oder Release-Datensätze aktuell verweisen.
• Wie Pull-Request- und Branch-Builds von Release-Builds getrennt werden, damit erstere kurzlebig sein können, ohne dass eine Regel je auf Letztere zutrifft.
• Ob Einstellungen zur Tag-Unveränderlichkeit, signierte Images oder als Referrer angehängte Attestierungen ändern, was eine Lifecycle-Regel behalten muss. Der (zitierte) ECR-Leitfaden hält fest, dass ein Image, auf das eine Manifestliste verweist, nicht vor der Liste selbst ablaufen kann und dass Referrer-Artefakte automatisch zusammen mit ihrem Subjekt-Image ablaufen; ob sich andere Registries gleich verhalten, ist Teil der Frage.
• Was passierte, wenn eine Regel falsch war: Fehlte ein für Rollback oder Forensik benötigtes Image, und wie wurde es wiederhergestellt?
• Auf welche Wachstumsrate die Regeln die Registry begrenzt haben, und ob Speicherkosten oder Pull-Latenz das auslösende Problem waren.

Was eine nützliche Antwort enthält

Der Registry-Typ und sein Aufbewahrungsmechanismus, die genauen Regeln samt ihrer Reihenfolge, wie Release-Images von Wegwerf-Builds unterschieden werden, wie lange die Regeln unverändert liefen, der Speicherverlauf davor und danach sowie mindestens ein Vorfall oder Beinaheunfall mit dem Regelwerk. Antworten, die nur Anbieter-Standardeinstellungen wiedergeben, sollten das kenntlich machen; Antworten aus sehr grossen Flotten sollten angeben, welche Teile von Werkzeugen abhängen, die einem kleinen Team fehlen.