Loopback Integration

The Polycrate API can type Kubernetes clusters as kind=loopback and mirror metadata from the external Loopback cluster management platform, including ID mapping, reconciliation, prerequisites and the differences from generic clusters.

Loopback Integration

Overview

Loopback is an external cluster management platform. The Polycrate API can type Loopback clusters and mirror metadata (Kubernetes version, status, certificate rotation). This is an API integration, not a variant of the ayedo Kubernetes distro (distro = k3s-server / k8s-1.27).

The CLI fetches kubeconfigs for all cluster types with polycrate k8s sync-kubeconfigs — Kubeconfig synchronization.

Without the Loopback integration, production Loopback clusters would appear as kind=generic and, for example, trigger false certificate alerts (Loopback rotates Kubernetes certificates automatically – the Polycrate logic for "certificate expires soon" must not apply here).

K8sCluster kind=loopback

When creating or importing a Kubernetes cluster, you can now select loopback as the kind under Kubernetes → Cluster → New.

Property Meaning
Typing Cluster is explicitly marked as Loopback-managed
Certificate alerts "Certificate expires soon" notices are suppressed, because Loopback rotates automatically
Versioning Kubernetes version and Loopback-internal version are taken from the Loopback API
Status Loopback lifecycle status (e.g. running, updating) feeds into the cluster status

When loopback instead of generic?

Scenario Recommended kind
Cluster runs on the Loopback platform loopback
On-prem cluster with its own control plane generic
Managed Kubernetes (EKS/GKE/AKS) respective provider kind
Local development (Kind/Minikube) see note below

ID mapping to Loopback

So that a Polycrate K8sCluster can be linked to the corresponding Loopback object, Polycrate maintains three ID fields on the cluster:

Field Meaning
loopback_org_id Reference to the associated Loopback organization
loopback_project_id Reference to the Loopback project
loopback_cluster_id Reference to the actual Loopback cluster

The linking usually happens automatically based on names and slugs (Polycrate organization → Loopback organization, cluster name → Loopback cluster). You can manually override the IDs in the cluster detail if names differ.

Reconciliation

A periodic sync task (Celery) fetches the current state from the Loopback API for all kind=loopback clusters and updates:

  • Kubernetes version
  • Loopback-internal version (for update availability banners)
  • Status fields and lifecycle

If the link is missing, a notice is shown in the cluster detail (e.g. "Loopback organization cannot be resolved").

Prerequisites & configuration

  1. Store Loopback credentials in System Config → Integration → Loopback (endpoint + API token)
  2. In the organization that operates Loopback clusters, at least one Polycrate organization must exist whose name matches the Loopback organization (or set loopback_org_id manually)
  3. Create clusters with kind=loopback – IDs are resolved automatically

Important differences from generic

Behavior generic loopback
Certificate expiry warning Active Suppressed (auto-rotation)
Kubernetes version From kubeconfig From Loopback API
Update banner Community release stream Loopback-specific updates
ID mapping none 3-level (org/project/cluster)

See also