Skip to content

feat: Route workloads to city locations via distributed scheduling#107

Open
scotwells wants to merge 1 commit into
docs/issue-85-karmada-federation-designfrom
feat/federated-deployment-scheduling
Open

feat: Route workloads to city locations via distributed scheduling#107
scotwells wants to merge 1 commit into
docs/issue-85-karmada-federation-designfrom
feat/federated-deployment-scheduling

Conversation

@scotwells
Copy link
Copy Markdown
Contributor

@scotwells scotwells commented May 18, 2026

Summary

Workloads targeting a city location are now automatically routed to the correct physical site, and their status is surfaced back to the platform in real time. Previously, a single central scheduler made all placement decisions; this distributes that responsibility across regional clusters so each site can operate independently.

When you deploy a workload to a city, the platform now routes it to the right physical site based on the city code, reports instance health and readiness back without any manual steps, and continues operating even if other parts of the control plane are temporarily unreachable.

Nothing changes for users — city-code targeting, instance visibility, and the existing API all work exactly as before.

Design: #106

Test plan

  • New workload deployed → routed to correct city → instance status visible on control plane within one reconcile cycle
  • Deleting a workload cleans up all federated resources
  • City-specific routing policies are created and removed as deployments come and go
  • Instance status propagates correctly through the full scheduling chain
  • Full end-to-end federation test (workload creation → site placement → instance projection)

Closes #85

@scotwells scotwells force-pushed the feat/federated-deployment-scheduling branch from 0c0d8df to 134086f Compare May 19, 2026 21:10
@scotwells scotwells changed the title feat: federated deployment scheduling across POP cells feat: Route workloads to city locations via distributed scheduling May 20, 2026
@scotwells scotwells force-pushed the feat/federated-deployment-scheduling branch 2 times, most recently from 6dc43ed to 6e9a268 Compare May 20, 2026 21:53
Workloads targeting a city location are now automatically routed to the
correct physical site via a Karmada-based federation layer. Each POP cell
operates independently, instance health is surfaced back to the control
plane in real time, and the platform remains available even when parts of
the control plane are temporarily unreachable.

Controllers added:
- WorkloadDeploymentFederator: replicates WDs into Karmada and manages
  PropagationPolicies per city code
- InstanceProjector: mirrors Instance write-backs from Karmada into the
  project namespace on the control plane

ResourceInterpreterCustomization deployed at config time teaches Karmada
how to aggregate replica counts and conditions across POP cells.

Operator flags --enable-management-controllers and --enable-cell-controllers
allow each deployment to opt into only the controllers it needs.

Includes a 6-test Chainsaw e2e suite covering federation, deletion cascade,
propagation policy lifecycle, instance projection, instance write-back, and
the full end-to-end chain.

Resolves #85

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@scotwells scotwells force-pushed the feat/federated-deployment-scheduling branch from 6e9a268 to 492eb6c Compare May 20, 2026 22:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants