UMKIM

One hub. Independent K3s clusters. Placement and edge routes that stay under your control.

Install the management plane once. Register sites, bootstrap workload clusters over WireGuard, and ship catalog apps through DCM — without turning spokes into agents of the hub data plane.

UMKIM fleet architectureHUBK3s · OCM · DCM · HarborConsole · fleet-site · fleet-edgenot a ManagedClusterWireGuard overlaySITE AFleetSite · DNS zones · exposureCluster (K3s + OCM)FleetClusterJoin → ReadyCluster (K3s + OCM)providers · ManifestWorkSITE BFleetSite · placement regionCluster (K3s + OCM)spoke Traefik NodePortApp via FleetAppRoutehub Traefik → overlay → spoke

What it is

UMKIM is an Ansible-driven multi-cluster fleet. The hub runs Open Cluster Management, the DCM control plane, Harbor, Traefik, and the fleet console. Each workload cluster is its own K3s server, joined over an overlay and managed with ManifestWork.

  • Hub

    K3s + OCM + DCM + Harbor + console + fleet-site / fleet-edge controllers

  • Site

    FleetSite — logical datacenter: DNS zones, WAN exposure, placement region

  • Cluster

    FleetClusterJoin → ManagedCluster — standalone K3s, WireGuard /32, providers

  • Edge

    FleetAppRoute stitches public hostnames to spoke NodePorts via hub or site paths

What you can do with it

Patterns the PoC explores today — with clear limits on what is shipped versus intended.

  • Independent K3s data planes

    Each workload cluster runs its own K3s server (not a hub agent). Day-2 management (placement, routes, catalog) still goes through the hub. Full hub-independent operation after detach is an intent, not a finished product story.

  • One hub hostname with active–backup

    Hub-routed apps can place on a primary and standby cluster; Traefik biases traffic to theactive cluster (standby failover). Active–active across clusters is planned, not implemented.

  • Catalog deploys + OCI Helm import

    Seeded demo items and an optional companion catalog cover curated apps. Operators can alsoImport Helm chart from OCI (oci:// on Harbor, docker.io, quay, or ghcr) into the DCM catalog and deploy through the same wizard. A polished app-store catalog remains longer-term intent.

  • Auto-configure from a downloaded bundle

    Cluster join issues a bootstrap tarball: download the bundle on the node and the cluster auto-configures enrollment (WireGuard, OCM join path, and related bootstrap steps) instead of hand-wiring every spoke.

Operator path

Greenfield path: hub once, then sites and clusters from the console.

  1. Install the hub

    ./scripts/install-hub.sh — WireGuard, OCM, Harbor images, DCM, console, controllers.

  2. Create a registry site

    Console Sites → Create (not the seeded management site).

  3. Join a workload cluster

    FleetClusterJoin issues a bootstrap tarball; nodes enroll, then Provision runs OCM join.

  4. Install providers and deploy

    k8s / helm / kubevirt providers, then Catalog → Deploy with FleetAppRoute routing.

Read the getting started guide →

Stack

Pinned pieces you will actually run — see docs for the full version matrix.

  • K3s

    Independent servers per cluster; Calico CNI; Flannel off on hub

  • OCM

    clusteradm hub init / join; ManifestWork for platform and providers

  • WireGuard

    Fleet overlay for hub → spoke NodePorts and enrollment

  • DCM

    Catalog, Rego placement, service providers on spokes

  • Harbor

    Hub registry; fleet/* images for controllers and providers

Architecture overview → · Concepts in the docs →