github.com/jingruilea/kubeedge@v1.2.0-beta.0.0.20200410162146-4bb8902b3879/docs/modules/edge/edged.md (about) 1 # EdgeD 2 3 ## Overview 4 5 EdgeD is an edge node module which manages pod lifecycle. It helps user to deploy containerized workloads or applications at the edge node. Those workloads could perform any operation from simple telemetry data manipulation to analytics or ML inference and so on. Using `kubectl` command line interface at the cloud side, user can issue commands to launch the workloads. 6 7 Docker container runtime is currently supported for container and image management. In future other runtime support shall be added, like containerd etc., 8 9 There are many modules which work in tandom to achive edged's functionalities. 10 11  12 13 *Fig 1: EdgeD Functionalities* 14 15 ## Pod Management 16 17 It is handles for pod addition, deletion and modification. It also tracks the health of the pods using pod status manager and pleg. 18 Its primary jobs are as follows: 19 20 - Receives and handles pod addition/deletion/modification messages from metamanager. 21 - Handles separate worker queues for pod addition and deletion. 22 - Handles worker routines to check worker queues to do pod operations. 23 - Keeps separate cache for config map and secrets respectively. 24 - Regular cleanup of orphaned pods 25 26  27 28 *Fig 2: Pod Addition Flow* 29 30  31 32 *Fig 3: Pod Deletion Flow* 33 34  35 36 *Fig 4: Pod Updation Flow* 37 38 ## Pod Lifecycle Event Generator 39 40 This module helps in monitoring pod status for edged. Every second, using probe's for liveness and readiness, it updates the information with pod status manager for every pod. 41 42  43 44 *Fig 5: PLEG at EdgeD* 45 46 ## CRI for edged 47 48 Container Runtime Interface (CRI) – a plugin interface which enables edged to use a wide variety of container runtimes, without the need to recompile and also support multiple runtimes like docker, containerd, cri-o etc 49 50 #### Why CRI for edge? 51 Currently kubeedge edged supports only docker runtime using the legacy dockertools. 52 + CRI support for multiple container runtime in kubeedge is needed due to below mentioned factors 53 + Include CRI support as in kubernetes kubelet to support containerd, cri-o etc 54 55 + Continue with docker runtime support using legacy dockertools until CRI support for the same is available i.e. support 56 for docker runtime using dockershim is not considered in edged 57 + Support light weight container runtimes on resource constrained edge node which are unable to run the existing docker runtime 58 + Support multiple container runtimes like docker, containerd, cri-o etc on the edge node. 59 + Support for corresponding CNI with pause container and IP will be considered later 60 + Customer can run light weight container runtime on resource constrained edge node that cannot run the existing docker runtime 61 + Customer has the option to choose from multiple container runtimes on his edge platform 62 63  64 65 *Fig 6: CRI at EdgeD* 66 67 ## Secret Management 68 69 At edged, Secrets are handled separately. For its operations like addition, deletion and modifications; there are separate set of config messages or interfaces. 70 Using these interfaces, secrets are updated in cache store. 71 Below flow diagram explains the message flow. 72 73  74 75 *Fig 7: Secret Message Handling at EdgeD* 76 77 Also edged uses MetaClient module to fetch secret from Metamanager (if available with it) else cloud. Whenever edged queries for a new secret which Metamanager doesn't has, the request is forwared to cloud. Before sending the response containing the secret, it stores a copy of it and send it to edged. 78 Hence the subsequent query for same secret key will be responded by Metamanger only, hence reducing the response delay. 79 Below flow diagram shows, how secret is fetched from metamanager and cloud. The flow of how secret is saved in metamanager. 80 81  82 83 *Fig 8: Query Secret by EdgeD* 84 85 ## Probe Management 86 87 Probe management creates to probes for readiness and liveness respectively for pods to monitor the containers. Readiness probe helps by monitoring when the pod has reached to running state. Liveness probe helps in monitoring the health of pods, if they are up or down. 88 As explained earlier, PLEG module uses its services. 89 90 91 ## ConfigMap Management 92 At edged, ConfigMap are also handled separately. For its operations like addition, deletion and modifications; there are separate set of config messages or interfaces. 93 Using these interfaces, configMaps are updated in cache store. 94 Below flow diagram explains the message flow. 95 96  97 98 *Fig 9: ConfigMap Message Handling at EdgeD* 99 100 Also edged uses MetaClient module to fetch configmap from Metamanager (if available with it) else cloud. Whenever edged queries for a new configmaps which Metamanager doesn't has, the request is forwared to cloud. Before sending the response containing the configmaps, it stores a copy of it and send it to edged. 101 Hence the subsequent query for same configmaps key will be responded by Metamanger only, hence reducing the response delay. 102 Below flow diagram shows, how configmaps is fetched from metamanager and cloud. The flow of how configmaps is saved in metamanager. 103 104  105 106 *Fig 10: Query Configmaps by EdgeD* 107 108 ## Container GC 109 110 Container garbage collector is an edged routine which wakes up every minute, collecting and removing dead containers using the specified container gc policy. 111 The policy for garbage collecting containers we apply takes on three variables, which can be user-defined. MinAge is the minimum age at which a container can be garbage collected, zero for no limit. MaxPerPodContainer is the max number of dead containers any single pod (UID, container name) pair is allowed to have, less than zero for no limit. MaxContainers is the max number of total dead containers, less than zero for no limit as well. Generally, the oldest containers are removed first. 112 113 ## Image GC 114 115 Image garbage collector is an edged routine which wakes up every 5 secs, collects information about disk usage based on the policy used. 116 The policy for garbage collecting images we apply takes two factors into consideration, HighThresholdPercent and LowThresholdPercent. Disk usage above the high threshold will trigger garbage collection, which attempts to delete unused images until the low threshold is met. Least recently used images are deleted first. 117 118 ## Status Manager 119 120 Status manager is as an independent edge routine, which collects pods statuses every 10 seconds and forwards this information with cloud using metaclient interface to the cloud. 121 122  123 124 *Fig 11: Status Manager Flow* 125 126 ## Volume Management 127 128 Volume manager runs as an edge routine which brings out the information of which volume(s) are to be attached/mounted/unmounted/detached based on pods scheduled on the edge node. 129 130 Before starting the pod, all the specified volumes referenced in pod specs are attached and mounted, Till then the flow is blocked and with it other operations. 131 132 ## MetaClient 133 134 Metaclient is an interface of Metamanger for edged. It helps edge to get configmap and secret details from metamanager or cloud. 135 It also sends sync messages, node status and pod status towards metamanger to cloud.