# EdgeX over Kubernetes: Enabling Container Orchestration in EdgeX
## 4 EdgeX over Kubernetes
### Implementation of EdgeX over Kubernetes  
The implementation of EoK is discussed in detail bellow. First, microservices in EdgeX Foundry use the Docker Compose YAML file structure, and its specification structure is different from that of Kubernetes, although both use the same YAML extension. For example, in Docker Compose YAML, a service can be classified  
Figure 1: Schematic illustrations of the concepts of (**a**) EdgeX Foundry and (**b**) EdgeX over Kubernetes. according to whether the _volumes_ or _depends_on_ field is used. The _volumes_ field configures storage, so it can specify a key (volume name)-value (actual path) pair in the Docker Compose YAML structure. The _depends_on_ field expresses dependencies between services, i.e., it is a start/stop order between services. For example, if service Y and service Z declare the _depends_on_ field with service A, services Y and Z must start before service A starts; service A cannot start before services Y and Z. Moreover, service A will terminate before services Y and Z. It is important to note that the YAML structures of Docker Compose and Kubernetes have incompatible fields; Docker Compose fields must be converted to Kubernetes fields to make EdgeX Foundry work similarly on Kubernetes in Eok. The _volumes_ field in Docker Compose can be easily replaced with the _Volume_ field of Kubernetes as they work the same. However, because Kubernetes does not define the _depends_on_ field, we add _readinessProbe_ and _livenessProbe_ to the Kubernetes YAML file. The _readinessProbe_ and _livenessProbe_ fields are container diagnostic tools that _kublet_ periodically executes. The _readinessProbe_ investigates whether a pod is ready to process the request or not. If the probe's diagnosis returns success, i.e., if the pod is prepared to process the requests, Kubernetes allocates an IP to the pod and enables communication. However, if the pod is not ready, the pod IP is removed from the endpoints of all other services. The _livenessProbe_ checks the pod's operating status; if the pod does not operate properly, the _livenessProbe_ handles the pod according to the _RestartPolicy_ (_Always_, _OnFailure_, _Never_) written in the YAML file (i.e., _PodSpec_). To this end, the _livenessProbe_ restarts a pod after a certain period if the pod starts before necessary pods start and the pod fails to start, and the _readinessProbe_ checks if the pod can handle requests. If so, the pod successfully starts, and Kubernetes allocates an IP to the pod. Therefore, the settings of the two fields (_readinessProbe_ and _livenessProbe_) operate similarly to those of the _depends_on_ field and make all EdgeX-Foundry-related pods start smoothly on Kubernetes. Moreover, EdgeX node must set the Kubernetes _Service_ on several microservices. For example, the _Command_ pod in the _Core Services_ layer handles user requests from outside the cluster. In this case, the _Command_ pod should be a _NodePort_ Service for communicating with the outside. Then, users can send requests to EdgeX nodes. Other pods, such as pods in _Supporting Services_ layer, can be set as _ClusterIP_ Service as they communicate with other pods in the same cluster. Figure 2 shows the proposed Eok architecture, denoting the worker node that has deployed EdgeX Foundry as an EdgeX node. The EdgeX Foundry microservices are deployed successfully in the EdgeX node through Kubernetes. It is interesting to note that not only is EdgeX Foundry deployed, but _kube-proxy_ and _kublet_ are also deployed successfully in an EdgeX node. EdgeX node acts as a worker node in the Kubernetes cluster by combining kublet and kube-proxy components. EdgeX node maintains and manages the microservices by reporting the operational status to the master node through kublet. In addition, it can communicate with pods in other EdgeX nodes in the same cluster through kube-proxy. Through _etcd_, we can check the data of an EdgeX node in a cluster, and _kube-scheduler_ assigns new device services or device services that must be updated to the desired EdgeX node.