SuperEdge 如何支持多地域 StatefulSets 及灰度

前言

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/v1
kind: StatefulSetGrid
metadata:
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/v1
kind: StatefulSetGrid
metadata:
  name: statefulsetgrid-demo
  namespace: default
spec:
  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/v1
kind: ServiceGrid
metadata:
  name: servicegrid-demo
  namespace: default
spec:
  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/v1
kind: DeploymentGrid
metadata:
  name: deploymentgrid-demo
  namespace: default
spec:
  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边缘容器微信沟通群

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

本文转自网络，版权归原作者所有，原文链接：https://segmentfault.com/a/1190000039881076
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！