Zum Inhalt

Loopback Integration

Überblick

Loopback ist die Cluster-Management-Plattform von ayedo, über die ein Großteil der produktiven Kubernetes-Cluster bereitgestellt und betrieben wird. Polycrate integriert mit Loopback, um Cluster, die dort verwaltet werden, sauber zu typisieren und deren Metadaten (Kubernetes-Version, Status, Rotation) in Polycrate zu spiegeln.

Ohne Loopback-Integration würden produktive Loopback-Cluster als kind=generic erscheinen und z. B. falsche Zertifikats-Alarme auslösen (Loopback rotiert Kubernetes-Zertifikate automatisch – die Polycrate-Logik für "Zertifikat läuft bald ab" darf hier nicht greifen).

K8sCluster kind=loopback

Beim Anlegen oder Importieren eines Kubernetes-Clusters können Sie unter Kubernetes → Cluster → New als kind jetzt loopback auswählen.

Eigenschaft Bedeutung
Typisierung Cluster wird explizit als Loopback-gemanagt markiert
Zertifikats-Alerts "Certificate expires soon"-Hinweise werden unterdrückt, weil Loopback automatisch rotiert
Versionierung Kubernetes-Version und Loopback-interne Version werden aus der Loopback-API übernommen
Status Loopback-Lifecycle-Status (z. B. running, updating) fließt in den Cluster-Status ein

Wann loopback statt generic?

Szenario Empfohlener kind
Cluster läuft auf Loopback-Plattform loopback
On-Prem-Cluster mit eigener Control-Plane generic
Managed Kubernetes (EKS/GKE/AKS) jeweiliger Provider-Kind
Lokale Entwicklung (Kind/Minikube) siehe Hinweis unten

Lokale Entwicklung / Evaluation

Für reine Evaluations- und Entwicklungs-Setups gibt es ergänzend kind=loopback nicht als "Self-Service"-Modus – nutzen Sie hier generic oder lokale Testsysteme.

ID-Mapping zu Loopback

Damit ein Polycrate-K8sCluster mit dem entsprechenden Loopback-Objekt verknüpft werden kann, pflegt Polycrate drei ID-Felder auf dem Cluster:

Feld Bedeutung
loopback_org_id Referenz auf die zugehörige Loopback-Organisation
loopback_project_id Referenz auf das Loopback-Projekt
loopback_cluster_id Referenz auf den eigentlichen Loopback-Cluster

Die Verknüpfung geschieht in der Regel automatisch anhand von Namen und Slugs (Polycrate-Organisation → Loopback-Organisation, Cluster-Name → Loopback-Cluster). Sie können die IDs im Cluster-Detail manuell überschreiben, falls Namen voneinander abweichen.

Reconciliation

Ein periodischer Sync-Task (Celery) holt für alle kind=loopback-Cluster den aktuellen Zustand aus der Loopback-API und aktualisiert:

  • Kubernetes-Version
  • Loopback-interne Version (für Update-Availability-Banner)
  • Status-Felder und Lebenszyklus

Bei fehlender Verknüpfung wird ein Hinweis im Cluster-Detail angezeigt (z. B. "Loopback-Organisation nicht auflösbar").

Voraussetzungen & Konfiguration

  1. Loopback-Credentials in System Config → Integration → Loopback hinterlegen (Endpoint + API-Token)
  2. In der Organisation, die Loopback-Cluster betreibt, muss mindestens eine Polycrate-Organisation vorhanden sein, deren Name zur Loopback-Organisation passt (oder loopback_org_id manuell setzen)
  3. Cluster mit kind=loopback anlegen – IDs werden automatisch aufgelöst

Wichtige Unterschiede zu generic

Verhalten generic loopback
Zertifikatsablauf-Warnung Aktiv Unterdrückt (Auto-Rotation)
Kubernetes-Version Aus Kubeconfig Aus Loopback-API
Update-Banner Community-Release-Stream Loopback-spezifische Updates
ID-Mapping keins 3-stufig (org/project/cluster)

Siehe auch