前言

SuperEdge(https://github.com/superedge/... 是Kubernetes原生的边缘容器计划，它将Kubernetes弱小的容器治理能力扩大到边缘计算场景中，针对边缘计算场景中常见的技术挑战提供了解决方案，如：单集群节点跨地区、云边网络不牢靠、边缘节点位于NAT网络等。这些能力能够让利用很容易地部署到边缘计算节点上，并且牢靠地运行，能够帮忙您很不便地把散布在各处的计算资源放到一个Kubernetes集群中治理，包含但不限于：边缘云计算资源、公有云资源、现场设施，打造属于您的边缘PaaS平台。Superedge反对所有Kubernetes资源类型、API接口、应用形式、运维工具，无额定的学习老本，也兼容其余云原生我的项目，如：Promethues，使用者能够联合其余所需的云原生我的项目一起应用。我的项目由以下公司独特发动：腾讯、Intel、VMware、虎牙直播、寒武纪、首都在线和美团。

Superedge中的ServiceGroup性能能够便捷地在共属同一个集群的不同机房或区域中各自部署一组服务，只须要应用ServiceGroup提供的DeploymentGrid和ServiceGrid两种资源，即可不便地将服务别离部署到这些节点组中，保障各区域服务数量及容灾，并进行服务流量管控，使得各个服务间的申请在本机房或本地区外部即可实现，防止服务跨地区拜访。

在最新公布的SuperEdge release 0.2.0版本中：SuperEdge扩大了有状态利用类型，引入了对应StatefulSets的StatefulSetGrid，不便有状态利用在多地区的独立部署和扩大；流量区域自治能力相应也反对了StatefulSets常配对的Headless Service；同时新增了依照地区进行灰度的性能，也即各NodeUnit内独立部署的workload版本能够不同。

有状态利用的反对

反对StatefulSets

最新版本的Superedge中，ServiceGroup反对了有状态利用StatefulSets。除了放弃和原生StatefulSets字段的完全一致、不便已有利用革新、无需放心同步社区最新个性的同时，也持续放弃了ServiceGroup的外围个性，能便捷地在一个集群中的多个地区进行边缘利用的独立部署和对立运维。

如下图所示，一个CDN集群须要在zone-1和zone-2两个地区的机房内各残缺部署一套StatefulSets利用，然而两个地区网络不互通

此时能够在云端部署下发如下格局的StatefulSetGrid

apiVersion: superedge.io/v1kind: StatefulSetGridmetadata:spec:  gridUniqKey: <NodeLabel Key>  <statefulset-template>

即可不便地在两个机房内主动部署对应的StatefulSets：StatefulSets-zone-1, StatefulSets-zone-2；同时保障云端与边缘端利用的强统一，批改云端资源即可同步到边端。

同时其中的拓扑key，也即gridUniqKey能够自行定义，相较于社区目前实现的三种抉择："kubernetes.io/hostname"，"topology.kubernetes.io/zone"以及"topology.kubernetes.io/region"，应用起来更加灵便。

另外，当该CDN集群纳管了新区域的机房时，无需在新的机房内手动部署StatefulSets，ServiceGroup会主动在该新增地区内部署一套独立的StatefulSets，极大中央便了边缘有状态利用的部署和运维。

流量区域自治能力反对Headless Service

因为地区之间的网络限度，不同地区的机房并不互通，ServiceGroup提出了ServiceGrid的概念，无需在各个地区都部署一个对应本地workload的Service。只需部署ServiceGrid资源，生成的一个Service就会对应所有地区的workload，但在各地区内拜访Service时可能保障流量的后端只限度在本地区内，保障了流量的区域自治能力。

对于StatefulSets而言，其每个Pod的名称都是有序且固定的，因为这个个性，常常和Headless Service搭配起来应用。Headless Service对应的每一个Endpoints都会有一个固定的对应的DNS域名，Pod之间能够互相拜访，集群也能够独自拜访指定的Pod。

针对这个特点，StatefulSetGrid反对应用Headless Service的形式进行拜访，如下所示：

StatefulSetGrid提供屏蔽NodeUnit的对立Headless Service拜访模式： {StatefulSetGrid}-{0..N-1}.{ServiceGrid}-svc.ns.svc.cluster.local，上述拜访会对应理论各个NodeUnit的具体Pod： {StatefulSetGrid}-{NodeUnit}-{0..N-1}.{ServiceGrid}-svc.ns.svc.cluster.local。

举个例子，部署如下的StatefulsetGrid和ClusterIP为None的ServiceGrid

apiVersion: superedge.io/v1kind: StatefulSetGridmetadata:  name: statefulsetgrid-demo  namespace: defaultspec:  gridUniqKey: zone  template:    selector:      matchLabels:        appGrid: echo    serviceName: "servicegrid-demo-svc"    replicas: 3    template:      metadata:        labels:          appGrid: echo      spec:        terminationGracePeriodSeconds: 10        containers:        - image: superedge/echoserver:2.2          name: echo          ports:          - containerPort: 8080            protocol: TCP          env:            - name: NODE_NAME              valueFrom:                fieldRef:                  fieldPath: spec.nodeName            - name: POD_NAME              valueFrom:                fieldRef:                  fieldPath: metadata.name            - name: POD_NAMESPACE              valueFrom:                fieldRef:                  fieldPath: metadata.namespace            - name: POD_IP              valueFrom:                fieldRef:                  fieldPath: status.podIP          resources: {}
apiVersion: superedge.io/v1kind: ServiceGridmetadata:  name: servicegrid-demo  namespace: defaultspec:  gridUniqKey: zone  template:    selector:      appGrid: echo    ports:    - protocol: TCP      port: 80      targetPort: 8080    clusterIP: None

如上资源会创立出一个名为servicegrid-demo-svc的Service，同时在各地区创立名为statefulsetgrid-demo-的StatefulSets。

每个NodeUnit内通过雷同的Headless Service只会拜访本组内的Pod。也即，对于NodeUnit：zone-1来说，会拜访statefulsetgrid-demo-zone-1(StatefulSets)对应的Pod；而对于NodeUnit：zone-2来说，会拜访statefulsetgrid-demo-zone-2(StatefulSets)对应的Pod。

# execute on zone-1 nodeunit[~]# curl statefulsetgrid-demo-0.servicegrid-demo-svc.default.svc.cluster.local|grep "pod name"        pod name:       statefulsetgrid-demo-zone-1-0[~]# curl statefulsetgrid-demo-1.servicegrid-demo-svc.default.svc.cluster.local|grep "pod name"        pod name:       statefulsetgrid-demo-zone-1-1[~]# curl statefulsetgrid-demo-2.servicegrid-demo-svc.default.svc.cluster.local|grep "pod name"        pod name:       statefulsetgrid-demo-zone-1-2...# execute on zone-2 nodeunit[~]# curl statefulsetgrid-demo-0.servicegrid-demo-svc.default.svc.cluster.local|grep "pod name"        pod name:       statefulsetgrid-demo-zone-2-0[~]# curl statefulsetgrid-demo-1.servicegrid-demo-svc.default.svc.cluster.local|grep "pod name"        pod name:       statefulsetgrid-demo-zone-2-1[~]# curl statefulsetgrid-demo-2.servicegrid-demo-svc.default.svc.cluster.local|grep "pod name"        pod name:       statefulsetgrid-demo-zone-2-2

因为Kube-Proxy不会解决Headless Service，所以之前通过wrapper代理Kube-Proxy的形式行不通。

这里设计新增了statefulset-grid-daemon组件，该组件依据StatefulSets构建和更新对应的{StatefulSetGrid}-{0..N-1}.{StatefulSetGrid}-svc.ns.svc.cluster.local DNS A record，联合CoreDns的Host plugins，使得statefulset-grid-daemon能够增加原来CoreDns不存在的domain record，并且失效。

灰度性能

基于零碎稳定性和疾速业务迭代的思考，许多团队应用了服务灰度公布的形式，也就是并非一次性将服务公布到全副的地区，而是只公布指定的几个地区，通过验证没有问题后再全量公布；抑或是进行A/B Test，可能同时存在v1、v2、v3等多个版本的实例，依据理论反馈和比照抉择更为适宜的版本进行全量公布。

在边缘场景中，还会存在一个集群纳管的不同地区的机房须要部署不同版本应用程序的状况。比方一条高速公路上不同省份段的摄像头，都须要独立部署利用，该利用具备A,B,C等多种性能，能够通过利用的启动参数进行管制。但因为路线跨多省，不同省份的摄像头须要的性能不同，有的只须要A性能，有的只须要B性能，也即有不同地区部署不同利用的需要。这种场景下，也须要用到灰度的性能。

最新版SuperEdge的ServiceGroup反对了灰度性能，同时因为ServiceGroup的地区属性，DeploymentGrid和StatefulSetGrid均反对依照NodeUnit进行地区维度的灰度。

所有地区应用雷同的版本

这种状况应用雷同的template创立workload，则无需增加任何额定字段

应用不同的template创立workload

反对template中蕴含image, replicas等在内的任意字段的灰度

apiVersion: superedge.io/v1kind: DeploymentGridmetadata:  name: deploymentgrid-demo  namespace: defaultspec:  defaultTemplateName: test1  gridUniqKey: zone  template:    replicas: 1    selector:      matchLabels:        appGrid: echo    strategy: {}    template:      metadata:        creationTimestamp: null        labels:          appGrid: echo      spec:        containers:        - image: superedge/echoserver:2.2          name: echo  templatePool:    test1:      replicas: 2      selector:        matchLabels:          appGrid: echo      strategy: {}      template:        metadata:          creationTimestamp: null          labels:            appGrid: echo        spec:          containers:          - image: superedge/echoserver:2.5            name: echo    test2:      replicas: 3      selector:        matchLabels:          appGrid: echo      strategy: {}      template:        metadata:          creationTimestamp: null          labels:            appGrid: echo        spec:          containers:          - image: superedge/echoserver:2.3            name: echo            ports:            - containerPort: 8080              protocol: TCP            env:              - name: NODE_NAME                valueFrom:                  fieldRef:                    fieldPath: spec.nodeName  templates:    zone1: test1    zone2: test2

templatePool代表待用的template实例列表，templates代表template和NodeUnit的对应关系。这个例子中，NodeUnit zone1地区将会应用名为test1的 template，NodeUnit zone2地区将会应用名为test2的 template，其余NodeUnit地区将会应用defaultTemplateName中指定的template，这里指定的是test1 template，如果defaultTemplateName不指定或者指定为default，则应用spec.template中的模板。更多字段和性能阐明能够查看文档介绍

另外针对由ServiceGroup生成的各地区workload可能存在的负载不同状况，能够针对各地区workload别离设置不同的HPA策略，replicas字段不会被强制更新。

总结

以后ServiceGroup已具备罕用的边缘利用治理能力，也在多个理论业务场景中利用落地，取得业务宽泛认可。咱们依然会持续演进，提供更多有意义的能力，也欢送对边缘计算感兴趣的公司、组织及集体一起共建Superedge边缘容器我的项目。

欢送退出Superedge边缘容器微信沟通群

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！