Fleet model
UMKIM operates a multi-cluster fleet from one hub.
| Layer | Responsibility |
|---|---|
| Hub | K3s, OCM, Harbor, console, WireGuard, and optional edge services |
| Site | A FleetSite logical location with edge.ingress[], optional hubGateway, and jumphost |
| Cluster | An independent K3s data plane represented by FleetClusterJoin and OCM ManagedCluster |
| App | A FleetApp Helm release on a cluster the operator selects |
| CLI | umkim for authenticated site, ingress, cluster, storage, node, and chart operations |
The hub is infrastructure, not a workload ManagedCluster. Each workload cluster runs its own K3s server and is managed by OCM after it joins.
Each workload cluster belongs to one site. The management site represents the hub, so workload clusters must use a separate registry site.
Sites declare named ingress entries (port_forward, reverse_proxy) and may enable hubGateway for hub-fronted public URLs. Clusters bind to an entry with ingressId. Outbound-only reachability via the hub WireGuard overlay is one supported pattern, not the only topology.
After a cluster is Ready, install an OCI chart with FleetApp onto the cluster you name. Capability filters (umkim cluster candidates --require …, console Clusters filters) help narrow Ready clusters; there is no placement engine and no DCM catalog.
Cluster delete defaults to detach: hub-managed resources are removed while K3s and workloads on the spoke are preserved.
The model does not itself guarantee application availability, isolation, or external reachability. Validate the selected storage, network, ingress, and recovery design for every deployment.