Polycrate CLI 0.29.17¶

Release-Datum: 8. Februar 2026
Typ: Feature-Release

Highlights¶

Diese Version bringt label-basierte K8sApp Discovery fuer Endkunden-Apps, Endpoint-K8sApp-Assoziation fuer praezisere Downtime Detection, einen umfassenden Stale-Sweep fuer alle Discovery-Controller und einen kritischen Fix fuer das CheckConfig Mapping bei API-managed Endpoints.

Artefakte¶

Docker Images¶

docker pull cargo.ayedo.cloud/library/polycrate:0.29.17

CLI Downloads¶

Installation & Update¶

polycrate update 0.29.17

-> Installationsanleitung

Neue Features¶

Label-basierte K8sApp Discovery¶

Neuer Discovery-Mechanismus: Pods mit dem Label k8sapps.polycrate.io/name werden als externe K8sApps erkannt und automatisch mit der Polycrate API synchronisiert. Endkunden koennen ihre eigenen Applikationen registrieren, ohne die Polycrate CLI zu nutzen.

Verwendung:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-namespace
spec:
  template:
    metadata:
      labels:
        k8sapps.polycrate.io/name: my-app
    spec:
      containers:
        - name: app
          image: my-registry/my-app:latest

Regeln:

• Label-Wert muss innerhalb eines Namespaces eindeutig sein
• Mehrere Pods mit gleichem Label = 1 K8sApp (mehrere Replicas)
• Cross-Namespace-Konflikte (gleicher Name in >1 Namespace) werden ignoriert
• Secret-basierte Apps haben Vorrang (keine Doppelregistrierung)
• Standardmaessig aktiviert (label_discovery_enabled: true)

-> Operator-Dokumentation

Endpoint-K8sApp-Assoziation¶

Endpoints aus der Ingress Discovery werden mit K8sApps verknuepft, wenn das Ingress-Objekt das Label k8sapps.polycrate.io/name traegt. Die Zuordnung wird im Endpoint CR Status gespeichert und an die API uebermittelt.

Verwendung:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app-ingress
  labels:
    k8sapps.polycrate.io/name: my-app
spec:
  rules:
    - host: my-app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app
                port:
                  number: 80

Dies ermoeglicht spaeter praezisere Downtime Detection pro K8sApp.

-> Operator-Dokumentation

Stale-Sweep fuer alle Discovery-Controller¶

Neuer periodischer Cleanup-Mechanismus fuer alle 5 Discovery-Controller. Verwaiste Custom Resources (deren Source-Objekt nicht mehr existiert) werden automatisch aufgeraeumt - sowohl die CRs als auch die zugehoerigen API-Objekte.

Abgedeckte Szenarien:

• Source-Objekt manuell geloescht (Ingress, Secret, Velero Backup, cert-manager Certificate)
• K8sApp deinstalliert (action_name=uninstall + action_status=success) -- Meta-Secret wird automatisch bereinigt
• Label-basierte K8sApp ohne aktive Pods -- CR wird geloescht
• Operator war nicht laufend bei Source-Loeschung (Safety-Net)

Konfiguration:

endpoint_discovery:
  stale_cleanup_minutes: 10  # Default: 10

app_discovery:
  stale_cleanup_minutes: 10

-> Operator-Dokumentation

Bugfixes¶

API Endpoint CheckConfig Mapping Fix¶

Kritischer Fix: HTTP-spezifische Endpoint-Spec-Felder (ignore_tls_errors, method, user_agent, follow_redirect, max_redirects, alert_tls_expiry) werden jetzt korrekt aus der API-Antwort in die Kubernetes Endpoint CRD uebertragen.

Behoben:

• ignore_tls_errors: true hatte keine Wirkung bei API-managed Endpoints
• K8sCluster API Endpoints mit self-signed Zertifikaten schlugen mit TLS_CERT_UNTRUSTED_CA fehl
• Alle CheckConfig-Felder werden jetzt in buildAPIEndpointCR() und mergeAPIEndpointSpec() gemappt

Inventory-Check Entfernung¶

Die periodischen "Existiert das API-Objekt noch?" GET-Requests wurden aus allen Sync-Controllern (Backup, BackupSchedule, Endpoint, Certificate) entfernt. Dies reduziert die API-Last erheblich (N GET-Requests pro Reconciliation-Zyklus eliminiert).

Der Stale-Sweep und die Finalizer-basierte Cleanup-Logik decken alle Cleanup-Szenarien ab.

Aktive CR-Deletion bei Source-Loeschung¶

Endpoint und K8sApp Discovery loeschen ihre CRs jetzt aktiv in handleDeletion(), statt auf Kubernetes Garbage Collection zu vertrauen. Dies stellt sicher, dass CRs sofort aufgeraeumt werden, wenn der Operator bei der Source-Loeschung laeuft.

polycrate-operator Block¶

Der polycrate-operator Block wurde auf Version 0.3.32 aktualisiert:

polycrate pull cargo.ayedo.cloud/ayedo/k8s/polycrate-operator
polycrate run polycrate-operator deploy

Neue Features im Block:

• Label-basierte K8sApp Discovery (label_discovery_enabled Config)
• Stale-Sweep fuer alle Discovery-Controller (stale_cleanup_minutes Config)
• Endpoint-K8sApp-Assoziation
• CheckConfig Mapping Fix

Migration¶

Keine Breaking Changes. Alle neuen Features sind standardmaessig aktiviert und rueckwaertskompatibel:

• label_discovery_enabled ist standardmaessig true
• stale_cleanup_minutes hat einen Default von 10 Minuten
• Bestehende CRs werden beim naechsten Sync-Zyklus automatisch aktualisiert

Changelog¶

• NEU: Label-basierte K8sApp Discovery (k8sapps.polycrate.io/name Pod Label)
• NEU: Endpoint-K8sApp-Assoziation via Ingress Label
• NEU: Stale-Sweep fuer alle 5 Discovery-Controller (Endpoints, K8sApps, Backups, Certificates)
• NEU: Aktive CR-Deletion bei Source-Loeschung (statt Garbage Collection)
• NEU: K8sApp Uninstall+Success Erkennung mit automatischer Meta-Secret Bereinigung
• NEU: Konfigurierbare stale_cleanup_minutes pro Discovery-Controller (Default: 10)
• FIX: CheckConfig Mapping (ignore_tls_errors, method, user_agent, etc.) auf CRD
• FIX: API-zugewiesene Endpoints werden nicht vom Stale-Sweep betroffen
• ENTFERNT: Inventory-Check GET-Requests aus allen Sync-Controllern (API-Last reduziert)

-> Alle Releases