# Vendor-Agnostic Reconfiguration of Kubernetes Clusters in Cloud Federations
## 9 Conclusions
### Summary of our Feature Compatibility Management Approach  
The main objective of this paper is to incept a unified and vendor-agnostic feature compatibility management approach for Kubernetes cluster federations.  
First, we have described detailed vendor-agnostic reconfiguration tactics for three problematic configuration manifests: (i) a privileged Daemonset to modify the Kubelet-Configuration manifest, (ii) using a dynamic admission webhook server and a CRD for replacing deprecated APIs of the control plane and (iii) a privileged Daemonset to modify the Kubelet configuration file to make it run in CNI mode and a configured CNI plugin to route packets without overlay mode so control plane-to-pod communication works correctly.  
Second, we have designed and implemented an autonomic controller that can automatically detect incompatible features and apply one of the relevant vendor-agnostic reconfiguration tactics. This controller takes the declarative management approach to feature compatibility management where users can specify the desired features that all clusters in a federation should support through our extended API _Featureconfig_ in the host cluster of a federation. Then, the controller runs an iteration of a control loop that monitors if the desired features are supported for all member clusters and executes the vendor-agnostic feature reconfiguration tactics for the unsupported features. This approach allows cluster administators to manage feature compatibility of member clusters like managing any Kubernetes resources, hereby reducing error-prone imperative operations and improving productivity.  
Third, we have evaluated our approach according to the research questions proposed in Section 7.1.  
* _Question 1_: _What is the performance overhead of reconfigured features during normal operation of cloud-native applications compared to native features supported by Kubernetes?_ We have found that the performance overhead of applications that run on a cluster with our reconfigured features is close to a cluster that is configured using the official documentation.
* _Question 2_: _What is the disruption impact on running applications when reconfiguring?_ When reconfiguring incompatible features, our approach brings a disruption impact on running applications, especially when reconfiguring CNI network plugins. By analyzing the resource usage of nodes, we hypothesize the reason for this could be that the image pulling and container creation process occupy a significant amount of network and computing resources on host machines. Additionally, while reconfiguring the Calico CNI plugin and KubeletConfiguration, the procedure of restarting the Kubelet may cause pods with readiness or liveness probes to become inaccessible through their exposed services for a while.
* _Question 3_: _What is the time to reconfigure features in a newly created cluster without any application running?_ We have evaluated the reconfiguration time for three relevant features and found that all features could be reconfigured within 100 seconds. It is worth noting that the controller takes significantly less time to reconfigure the CNI network plugin than GKE's proprietary interface that restarts all worker nodes and gradually migrates Pods by restarting them on the new nodes.  
Therefore, we conclude that our approach is best applied in one of the three following use cases: (i) when starting up K8s clusters across different vendors, (ii) when optional K8s features of already deployed clusters must be activated as quickly as possibly and temporary disruption to running applications on these clusters can be tolerated or (iii) when proprietary customization interfaces do not allow to activate the desired optional feature.