# Vendor-Agnostic Reconfiguration of Kubernetes Clusters in Cloud Federations
## 2 Background
### Basics of Kubernetes
#### 2.1.2 Kubernetes Architecture  
Kubernetes (K8s), based on Google's internal large-scale container management tool Borg [15], has become the mainstream container orchestration tool in the industry. Kubernetes adopts a declarative configuration management approach [16], where built-in or extended controllers monitor and adjust the actual state of the cluster to a set of desired states specified by the user. To understand the internal operation principle of Kubernetesand better introduce the mechanism of tactics and controllers as explained in Section 5, we first introduce the Master-Slave architecture of Kubernetes (Figure 1) and the functionality of each component. A Kubernetes cluster consists of two kinds of nodes: Control Plane and Worker Nodes [17]. The Control Plane node is the brain of the Kubernetes cluster and is responsible for coordinating the workload and resources of the entire cluster. On Control Plane, we usually run four core components: API server, Scheduler, Controller Managers, and etcd database:  
* **API server** is the central point of communication among the components of the cluster. It exposes various RESTful APIs, through which worker node agents, controllers, users and applications can create, query or update cluster and application resources. These APIs are an abstraction of the actual resources deployed. Here, we introduce the APIs resources that are used in this paper: **- Pod** is the atomic unit of deployment in Kubernetes, consisting of one or more tightly coupled containers. A pod can be thought of as a virtual host for containers, and all containers in it share the same Linux network namespace and cgroup parent; **- Deployment** represents a set of pod replicas managed by the Deployment controller. We can specify the desired number of replicas and the updating strategy in the Deployment API. The Deployment controller will enforce our specification; **- Daemonset** represents a pod that should be deployed on every node of the cluster, and every node should only have one copy of the pod; **- Service** is an API resource that specifies a stable network access point behind a set of volatile pods; **- Custom Resource Definition (CRD), customresource** represents extended API resources in the API server. We can use this API to introduce new custom APIs;
* **etcd Database** is a key-value database that stores the desired and actual states of all API resource objects. After the API server receives the client's request, it will query or update the corresponding resource states in the etcd database [18];
* **Controller Manager, controller** contains many built-in controllers that implement control loops to manage resources of various built-in API types like Deployments and Services. For example, the Deployment Controller monitors the actual number of replicas of pods in a Deployment and performs actions to make it match the desired number as described by users;
* **Scheduler** is responsible for placing pods on the appropriate worker nodes based on the node states and the requirements of the pods. Figure 1: Kubernetes cluster architecture. Worker nodes are physical or virtual machines where actual workloads run. They are registered in the cluster and thus managed by the control plane. A worker node comprises four main components: Kubelet, Kube-Proxy, Container Runtime and Network Plugin:  
* **Container Runtime** is responsible for container image pulling/pushing to and from a central container registry as well as the creation, execution and resource monitoring of containers;
* **Network Plugin** is responsible for creating a virtual network bridge on each node of the cluster and configuring routing rules on each node to manage the connectivity between containers;
* **Kube-Proxy** is a clusterwide load balancer that exposes a pool of pods to external clients via a stable Service IP, which is created via a Service API object.