Fleet model
Three console layers sit on top of one physical hub:
| Layer | Examples | Purpose |
|---|---|---|
| Site | management, site-a |
Logical datacenter: exposure, WAN endpoints, DNS zone definitions |
| Cluster | workload spokes | OCM ManagedCluster: capabilities, domain_bindings, ingress overrides |
| Infrastructure | Hub inventory host | Physical hub: K3s, DCM, Harbor, Console — not an OCM cluster |
Design principles
Section titled “Design principles”| Principle | Implementation |
|---|---|
| Multi-cluster fleet | Each cluster runs its own K3s server (k3s_standalone: true) |
| OCM management plane | Hub clusteradm init; spokes clusteradm join |
| Hub-delivered workloads | OCM ManifestWork (namespace = target cluster name) |
| Autonomous data plane | API on management LAN; registry fallback after Harbor mirror |
| DCM placement | Control plane on hub; service providers on spokes |
| Greenfield clusters | FleetClusterJoin + fleet-site-controller |
| Sites | Registry FleetSite; workloads carry fleet.site label |
Site membership
Section titled “Site membership”Each OCM cluster belongs to exactly one site via label fleet.site=<siteId>. Site API returns derived clusters[] from that label. Do not create workload clusters on the management site.
Edge registry
Section titled “Edge registry”Per-cluster ingress state lives in fleet-system/fleet-edge-clusters. On greenfield hubs, fleet-site-controller creates this ConfigMap when FCJ reaches Ready, with annotation fleet.umkim.com/console-managed: "true".