关于腾讯云: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 边缘容器微信沟通群

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