gridUniqKey值与NodeGroup的label key对应，也即ServiceGroup是与NodeGroup一一对应，而NodeGroup对应多个NodeUnit，同时NodeGroup中的每一个NodeUnit都会部署ServiceGroup对应deployment，这些deployment(deploymentgridName-NodeUnit命名)通过nodeSelector亲和性固定某个NodeUnit上，并通过服务拓扑感知限制在该NodeUnit内访问
分布式健康检查边缘计算场景下，边缘节点与云端的网络环境十分复杂，连接并不可靠，在原生Kubernetes集群中，会造成apiserver和节点连接的中断，节点状态的异常，最终导致pod的驱逐和endpoint的缺失，造成服务的中断和波动，具体来说原生Kubernetes处理如下：
失联的节点被置为ConditionUnknown状态，并被添加NoSchedule和NoExecute的taints
失联的节点上的pod被驱逐，并在其他节点上进行重建
失联的节点上的pod从Service的Endpoint列表中移除
因此，边缘计算场景仅仅依赖边端和apiserver的连接情况是不足以判断节点是否异常的，会因为网络的不可靠造成误判，影响正常服务。而相较于云端和边缘端的连接，显然边端节点之间的连接更为稳定，具有一定的参考价值，因此superedge提出了边缘分布式健康检查机制。该机制中节点状态判定除了要考虑apiserver的因素外，还引入了节点的评估因素，进而对节点进行更为全面的状态判断。通过这个功能，能够避免由于云边网络不可靠造成的大量的pod迁移和重建，保证服务的稳定
具体来说，主要通过如下三个层面增强节点状态判断的准确性：
每个节点定期探测其他节点健康状态
集群内所有节点定期投票决定各节点的状态
云端和边端节点共同决定节点状态
而分布式健康检查最终的判断处理如下：
节点最终状态 云端判定正常 云端判定异常节点内部判定正常 正常 不再调度新的pod到该节点(NoSchedule taint)
节点内部判定异常 正常 驱逐存量pod；从Endpoint列表摘除pod；不再调度新的pod到该节点
边缘自治
对于边缘计算的用户来说，他们除了想要享受Kubernetes自身带来的管理运维的便捷之外，同时也想具备弱网环境下的容灾能力，具体来说，如下：
节点即使和master失联，节点上的业务能继续运行
保证如果业务容器异常退出或者挂掉，kubelet 能继续拉起
还要保证节点重启后，业务能继续重新被拉起来
用户在厂房内部署的是微服务，需要保证节点重启后，同一个厂房内的微服务可以访问
而对于标准的Kubernentes，如果节点断网失联并且发生异常重启的行为后，现象如下：
失联的节点状态置为ConditionUnknown状态
失联的节点上的业务进程异常退出后，容器可以被拉起
失联的节点上的 Pod IP 从 Endpoint 列表中摘除
失联的节点发生重启后，容器全部消失不会被拉起
superedge自研的边缘自治就是为了解决上述问题的，具体来说边缘自治能达到如下效果：
节点会被置为ConditionUnknown状态，但是服务依旧可用(pod不会被驱逐以及从endpoint列表中剔除)
多节点断网情况下，Pod 业务正常运行，微服务能力正常提供
多节点断网情况下并重启后，Pod 会被重新拉起并正常运行
多节点断网情况下并重启后，所有的微服务可以被正常访问
其中，对于前两点来说可以通过上述介绍的分布式健康检查机制来实现，而后续两点可以通过lite-apiserver，网络快照以及DNS解决方案实现，如下：
lite-apiserver机制superedge通过在边端加了一层镜像lite-apiserver组件，使得所有边端节点对于云端kube-apiserver的请求，都会指向lite-apiserver组件：
而lite-apiserver其实就是个代理，缓存了一些kube-apiserver请求，当遇到这些请求而且与apiserver不通的时候就直接返回给client：
总的来说：对于边缘节点的组件，lite-apiserver提供的功能就是kube-apiserver，但是一方面lite-apiserver只对本节点有效，另一方面资源占用很少。在网络通畅的情况下，lite-apiserver组件对于节点组件来说是透明的；而当网络异常情况，lite-apiserver组件会把本节点需要的数据返回给节点上组件，保证节点组件不会受网络异常情况影响
网络快照