# Vendor-Agnostic Reconfiguration of Kubernetes Clusters in Cloud Federations
## 2 Background
### Kubernetes Cluster Federation  
The native management capabilities of Kubernetes are still at a single-cluster level. Different Kubernetes clusters are independent and do not have a direct connection. A cluster federation can interconnect and package these separate clusters to appear as a single logical cluster to top-level users. In Kubernetes, we have many frameworks to enable cluster federations. The official implementation of multicluster management platform evolved from KubeFed V1 to KubeFed V2 [19]. Moreover, the recent Open Cluster Management (OCM) framework [20], which delegates the management overhead part to the managed clusters [21], reduces the performance overhead of the host cluster. All of these platforms use a similar Master-Slave architecture. The multicluster management framework that this paper is based on is KubeFed V2, maintained and developed by the SIG-Multicluster team. KubeFed provides the essential building block for more complex use cases of federated clusters. KubeFed V2 uses the Custom Resource Definition (CRD) API in combination with the Operator pattern to improve the flexibility and extensibility of KubeFed v1 [19]. Figure 2 presents the architecture of the KubeFed cluster federation.  
Using KubeFed, a cluster federation consists of two types of clusters: Host cluster and Member Cluster:  
* **Host Cluster** is a Kubernetes cluster where the KubeFed Control Plane resides. It extends the API server with KubeFed APIs and deploys KubeFed controller managers. KubeFed controllers can access the credentials of managed member clusters and communicate with their API servers. Users create and manage federated resources through the KubeFed API, and KubeFed controllers propagate the changes of federated resources to the corresponding member clusters according to the specification provided by the user. The KubeFed admission webhook is responsible for validating the federated resources, such as when we want to create a federated custom resource object; the webhook will only allow it if all member cluster support this custom resource. In addition, a host cluster can also become a member cluster at the same time;
* **Member Clusters** are the place where workloads and resources are actually deployed in the cluster federation. It is no different from normal clusters. It does not know anything about the other member clusters and the presence of the host cluster. Kubefed Controllers in the host cluster are like any other ordinary clients of the member cluster's API server;KubeFed is not the silver bullet that enables all cluster federation use cases. Kubefed itself considers only the propagation and placement of resources for member clusters [22]. For example, suppose we create a FederatedDeployment resource in the Host Cluster. In that case, KubeFed controllers will create regular deployment resources in the corresponding member clusters according to the configuration of member clusters and federated resource requirements [23]. To implement more complex application scenarios, we must integrate external services and middleware. For example, we use an external DNS service to achieve cross-cluster service access and discovery as this is not available in Kubefed [23]. From the perspective of Kubefed itself, we only have one host cluster making it a single point of failure and performance bottleneck. This problem gave birth research on decentralized host clusters [24].