Image Automation

Table of Contents

Zielsetzung
Architektur
Komponenten
Update-Ablauf
CloudNativePG
Architekturprinzipien
Betrieb
Einschränkungen

Die Aktualisierung von Container-Images erfolgt über die Flux Image Automation Controller.

Zielsetzung

Container-Images sollen automatisch innerhalb definierter Versionskanäle aktualisiert werden.

Die Plattform verwendet ein gemeinsames GitOps-Repository für mehrere Kubernetes-Cluster.

Änderungen an Image-Tags dürfen nur von einer Instanz durchgeführt werden, um konkurrierende Git-Änderungen und Rebase-Konflikte zu vermeiden.

Architektur

Die Image Automation besteht aus drei Komponenten:

ImageRepository
ImagePolicy
ImageUpdateAutomation

Die Komponenten übernehmen unterschiedliche Aufgaben:

Komponente

Aufgabe

ImageRepository

Ermittlung verfügbarer Image-Tags

ImagePolicy

Definition zulässiger Versionskanäle

ImageUpdateAutomation

Aktualisierung von GitOps-Manifests

Komponenten

ImageRepository

Ein ImageRepository beschreibt ein Container-Repository, das regelmäßig auf neue Versionen überprüft wird.

Beispiel:

apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageRepository
metadata:
  name: immich-server
spec:
  image: ghcr.io/immich-app/immich-server
  interval: 1h

ImagePolicy

Eine ImagePolicy definiert den zulässigen Upgrade-Kanal eines Images.

Beispiel für PostgreSQL 18:

apiVersion: image.toolkit.fluxcd.io/v1
kind: ImagePolicy
metadata:
  name: immich-server
  namespace: flux-system
spec:
  imageRepositoryRef:
    name: immich-server
  policy:
    semver:
      range: v3.x

Eine Policy beschreibt einen Versionskanal und nicht eine konkrete Anwendung.

ImageUpdateAutomation

Die ImageUpdateAutomation aktualisiert Manifeste anhand der durch die Policies ermittelten Zielversionen.

Beispiel:

apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
  name: flux-system
spec:
  update:
    path: ./
    strategy: Setters

Update-Ablauf

Der Aktualisierungsprozess erfolgt in mehreren Schritten:

Flux scannt die konfigurierten ImageRepositories.
Die ImagePolicies bestimmen die zulässigen Zielversionen.
Die ImageUpdateAutomation aktualisiert die betroffenen Setter.
Flux erstellt einen Commit im Git-Repository.
Die Flux-Instanzen der Cluster reconciliieren die Änderungen.
Die betroffenen Workloads werden aktualisiert.

CloudNativePG

Für CloudNativePG werden ImagePolicies pro Versionskanal und nicht pro Anwendung definiert.

Ungünstig:

cnpg-romm
cnpg-immich
cnpg-securo

Architekturprinzipien

Zentrale Git-Mutationen

Änderungen am Git-Repository erfolgen ausschließlich über eine zentrale ImageUpdateAutomation.

Vorteile:

Keine Commit-Konflikte
Keine konkurrierenden Rebase-Vorgänge
Nachvollziehbare Änderungen
Vereinfachte Fehlersuche

Wiederverwendbare Policies

Policies beschreiben Versionskanäle und keine Anwendungen.

Vorteile:

Weniger Konfiguration
Einheitliches Upgrade-Verhalten
Geringerer Wartungsaufwand

Trennung von Discovery und Deployment

Die Ermittlung neuer Versionen und die Verteilung von Änderungen sind voneinander getrennt.

Die Image Automation aktualisiert ausschließlich Git.

Die Bereitstellung der Änderungen erfolgt weiterhin durch FluxCD während des normalen Reconciliation-Prozesses.

Betrieb

Status prüfen

kubectl get imagerepositories -A

kubectl get imagepolicies -A

kubectl get imageupdateautomations -A

Aktuelle Zielversion anzeigen

kubectl describe imagepolicy cnpg-postgresql-18 -n flux-system

Letzte Ausführung prüfen

kubectl describe imageupdateautomation flux-system -n flux-system

Einschränkungen

Es existiert nur ein Git-Schreibpfad für automatische Änderungen.
Ein Ausfall der Image Automation verhindert temporär automatische Image-Updates.
Bestehende Deployments und Reconciliations bleiben davon unberührt.
Nach Wiederherstellung werden ausstehende Änderungen automatisch nachgezogen.