Project: Shifu (Provisioning / Automation & Configuration)
File: design-shifuController.md

- - - - - - - - - - - - *shifuController's main responsibility is to manage the lifecycle of deviceShifu*. *shifuController reacts to edgeDevice and edgeNode events sent by apiServer by creating/deleting the corresponding deviceShifu* instances. Since *shifuController can run either on the cloud or on the edge, shifuController* needs to consume as less memory as possible. Preferably the memory print for *shifuController* is under 100MB. Being the control plane of *shifu, shifuController* needs to be highly available. This is achieved by using and . *shifuController* offloads its persistent store to etcd (or any Kubernetes backend persistent store) and become truly stateless. *shifuController* should always require minimum privileges to reduce potential interference with other micro-services and maintain a high security standard. *shifud* is a , which is managed by Kubernetes. *shifuController only manages deviceShifu, not edgeDevice nor edgeNode*. *shifuController as a , manages the whole lifecycle of deviceShifu* deployments through . *shifuController will internally cache the current network topology by maintaining an . This adjacency list is called edgeMap. In the future, edgeMap* will be used to render topology visualizations for the developer/operator. Whenever *shifuController receives an edgeDevice connect event, shifuController* will: 1.1 Schedule: Determine where to place the pending *deviceShifu*. 1.1.1 If the *edgeDevice is connected to a specific edgeNode, then the deviceShifu will be scheduled on that edgeNode*. 1.1.2 If the *edgeDevice is connected to the cluster network, then the deviceShifu* will be scheduled based on below priorities (subject to change): a. Location proximity: If location info is available, then the *deviceShifu will be placed on the edgeNode closest to the edgeDevice*. b. Resource availability: The *deviceShifu will be placed on the edgeNode* with highest available memory. 1.2 Compose: Compile all computed info and compose the corresponding *deviceShifu* deployment object. 1.3 Create: 1.3.1 Create the *deviceShifu deployment by submitting the request to apiServer*. 1.3.2 Expose the newly created *deviceShifu* as a Kubernetes Service. 1.4 Add: Add the *edgeDevice to

Whenever *shifuController receives an edgeDevice disconnect event, shifuController* will: 2.1 Remove: Remove the *edgeDevice from edgeMap*. 2.2 Delete: 2.2.1 Delete the *deviceShifu deployment by submitting the request to apiServer*. 2.2.2 Delete the *deviceShifu*'s corresponding Kubernetes service. Whenever *shifuController receives an edgeNode create event, shifuController* will: 1.1 Add: Add the *edgeNode to edgeMap*. Whenever *shifuController receives an edgeNode delete event, shifuController* will: 2.1 Delete: Delete the *edgeNode from edgeMap*. Collect: *shifuController will periodically collect resource information on edgeNodes*. This information will be used by *edgeMap* for visualization purposes. reschedule purposes, see below. Reschedule: *shifuController will reschedule deviceShifu* on following events: *shifuController finds a better place for a given deviceShifu* according to the scheduling algorithm stated above. *edgeNode becomes unavailable. Whenever an edgeNode becomes unavailable, shifuController will try to reschedule all the deviceShifu instances on that edgeNode to other edgeNodes* in a best-effort manner. *deviceShifu object is a bundle of a Kubernetes deployment and a Kubernetes service for an edgeDevice managed by shifuController. Users should NOT manage deviceShifu* by themselves. Below is a sample *deviceShifu* deployment yaml for a basic thermometer: ``` apiVersion: apps/v1 kind: Deployment metadata: labels: app: edgedevice-thermometer-deployment name: edgedevice-thermometer-deployment namespace: deviceshifu spec: replicas: 1 selector: matchLabels: app: edgedevice-thermometer-deployment template: metadata: labels: app: edgedevice-thermometer-deployment spec: containers: image: edgehub/deviceshifu-http-http:v0.0.1 name: deviceshifu-http ports: containerPort: 8080 volumeMounts: name: edgedevice-config mountPath: "/etc/edgedevice/config" readOnly: true env: name: EDGEDEVICE_NAME value: "edgedevice-thermometer" name: EDGEDEVICE_NAMESPACE value: "devices" volumes: name: edgedevice-config configMap: name: thermometer-configmap-0.0.1 serviceAccountName: edgedevice-mockdevice-sa ``` ``` apiVersion: v1 kind: Service metadata: labels: app: edgedevice-thermometer-deployment name: edgedevice-thermometer namespace: deviceshifu spec: ports: port: 80 protocol: TCP targetPort: 8080 selector: app: edgedevice-thermometer-deployment type: LoadBalancer ``` [Architectural diagram here] *edgeMap* is implemented as an adjacency list. Below are the definitions within the adjacency list: ```edgeVertex```: an *edgeNode or an edgeDevice* ```edgeLink``` type of connection between two ```edgeVertex```. For example, Ethernet or USB. *edgeVertex* is a node in a linked list. Below are the fields within the the node: ```vertexType```: *edgeNode or edgeDevice* ```neighborVertex```: the immediate neighbor of the current vertex ```neighborLinkType```: the connection type between the current *edgeVertex* and ```neighborVertex```