# Federation In a Cloud computing environment, services can operate at different range levels: within the same host (Host, Node), spanning hosts within the same available zone (Available Zone), crossing zones within the same region (Region), served from the same Cloud service providers, or even across different cloud platforms. The design of Kubernetes (often referred to as K8s) is aimed at handling a single cluster in the same region because performance within a region can meet K8s's threshold for scheduling and connections between computation storage. However, the concept of clustering Federation is designed to offer services from K8s clusters that cross regions and service providers. Each Federation comes equipped with its distributed storage, API Server, and Controller Manager. Users are able to register K8s Clusters to a Federation's API Server. When users create or modify API objects through the Federation's API Server, the Federation API Server will create a replica of the same API object in all its registered sub K8s Clusters. When serving business requests, K8s Federation first balances the load among its own sub Clusters. For requests directed to a specific K8s Cluster, it follows the same scheduling pattern as when the K8s Cluster operates independently, providing internal load balancing within that K8s Cluster. Load balancing between Clusters is realized through domain service load balancing. ![](https://4011040894-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LDAOok5ngY4pc1lEDes-1972196547%2Fuploads%2Fgit-blob-6daf307f21f7f5d963bf3c1326f8739de4349809%2Ffederation-service%20\(2\).png?alt=media) All designs aim to reduce impact on existing K8s Cluster mechanisms. Thus, each individual K8s Cluster does not need an additional outer layer of K8s Federation, which implies that existing K8s code and mechanisms do not need to be altered due to Federation functionality. ![](https://4011040894-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LDAOok5ngY4pc1lEDes-1972196547%2Fuploads%2Fgit-blob-5ef7106553526600f00defcea78cf7a24ef1a42e%2Ffederation%20\(6\).png?alt=media) Federation mainly consists of three components: * federation-apiserver: similar to kube-apiserver but provides REST API across clusters * federation-controller-manager: like the kube-controller-manager, but ensures synchronization across multiple cluster states * kubefed: a command line tool for managing Federation The code for Federation is maintained at . The next section delves into the steps of deploying Federation, which includes downloading kubefed and kubectl, initializing a main cluster, customizing DNS, deploying on physical machinery and, customizing etcd storage. Once the Federation is deployed, you can use it by registering clusters other than the main cluster using the `kubefed join` command, query registered kubernetes clusters list, use annotation `federation.alpha.kubernetes.io/cluster-selector` for new object selection as of version 1.7+, and implement policy-based scheduling. Try utilizing the Federation by deploying resources such as Federated ConfigMap, Federated Service, Federated DaemonSet, and more! Ending the Federation operation is also possible by removing the cluster or the Federation. With technological advancement making cross-region, cross-service operations a reality, Federation is increasingly becoming an intrinsic part of K8s operations. It's time to embrace the future of digital transformation with Federation - at your fingertips! For further information, check out [Kubernetes federation](https://kubernetes.io/blog/2018/12/12/kubernetes-federation-evolution/) and [kubefed](https://github.com/kubernetes-sigs/kubefed). --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://kubernetes.feisky.xyz/en/concepts/components/federation.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.