This repo contains an in-progress prototype of some of the foundational aspects of V2 of Kubernetes Federation. The prototype builds on the sync controller (a.k.a. push reconciler) from Federation v1 to iterate on the API concepts laid down in the brainstorming doc and further refined in the architecture doc. Access to both documents is available to members of the kubernetes-sig-multicluster google group.

Kubefed is configured with two types of information:

• Type configuration declares which API types Kubefed should handle
• Cluster configuration declares which clusters Kubefed should target

Propagation refers to the mechanism that distributes resources to federated clusters.

Type configuration has three fundamental concepts:

• Templates define the representation of a resource common across clusters
• Placement defines which clusters the resource is intended to appear in
• Overrides define per-cluster field-level variation to apply to the template

These three abstractions provide a concise representation of a resource intended to appear in multiple clusters. They encode the minimum information required for propagation and are well-suited to serve as the glue between any given propagation mechanism and higher-order behaviors like policy-based placement and dynamic scheduling.

These fundamental concepts provide building blocks that can be used by higher-level APIs:

• Status collects the status of resources distributed by Kubefed across all federated clusters
• Policy determines which subset of clusters a resource is allowed to be distributed to
• Scheduling refers to a decision-making capability that can decide how workloads should be spread across different clusters similar to how a human operator would

Take a look at our user guide if you are interested in using Kubefed.

Take a look at our development guide if you are interested in contributing.

Participation in the Kubernetes community is governed by the Kubernetes Code of Conduct.