乐趣区

关于腾讯云:SuperEdge-高可用云边隧道有哪些特点

jiezi

作者

作者李腾飞，腾讯容器技术研发工程师，腾讯云 TKE 后盾研发，SuperEdge 外围开发成员。

背景

在边缘集群中，边缘端和云端为单向网络，云端无奈被动连贯边缘端，常见的解决方案是边缘端被动和云端（tunnel server）建设长连贯，云端通过长连贯将申请转发到边缘端。在云端隧道 server 实例扩容后须要思考新增的实例对已有的边缘端长连贯转发的影响。出于零碎稳定性的思考，能通过云边隧道采集到边缘端的监控信息。

社区计划 ANP

隧道云端 Server 主动扩缩容

ANP 次要用于代理转发 apiserver 的申请，架构图如下图所示:

ANP 的 server 仅反对单实例，如果是多实例会存存在以问题，上面依据多实例的架构图进行阐明：

  • ANP Agent 须要和所有的 ANP Server 实例建设长连贯。
  • ANP Server 扩容之后，反对接入的 ANP Agent 的规模不会减少

节点监控

ANP 我的项目次要针对 K8s 1.16 版本公布的个性 EgressSelector，在这个个性中 apiserver 会首先应用 HTTP CONNECT 办法建设隧道，而后通过隧道把申请边缘端的申请发送到 ANP Server，ANP Server 通过与 ANP Agent 建设的长连贯，把申请发送到边缘端。业界罕用的监控采集组件 Prometheus 是不反对 EgressSelector 个性的，因而应用 ANP 我的项目是无奈反对节点监控的。

SuperEdge 云边隧道（tunnel）计划

SuperEdge 云边隧道 tunnel 在方案设计时应用 DNS 做边缘节点的注册核心，注册核心存储的是 tunnel-edge 的 ID 和 tunnel-edge 连贯到 tunnel-cloud 的 podIp，在做 apiserver 到边缘端申请转发时能够依据注册核心的 ID 将申请转发到边缘端连贯到的 tunnel cloud 的 pod 上，具体架构图如下所示：

上图中的 apiserver 组件能够是云端其余组件，比方 Prometheus，上面别离从主动扩缩容和节点监控对 tunnel 的应用场景做进一步的阐明。

tunnel cloud 的主动扩缩容（HPA）

在多实例的场景下比照 ANP 我的项目，tunnel 具备以下的劣势：

  • tunnel-edge 只需和一个 tunnel-cloud 实例长连贯即可。apiserver 依据 tunnel-dns 的存储的 tunnel-edge 的 ID 和 tunnel-cloud pod 的映射关系确定申请的 tunnel-cloud pod , 而后再把申请转发到 tunnel-edge。
  • tunnel-cloud 扩容之后，tunnel-cloud 反对接入的 tunnel-edge 的数目会减少。

自定义主动扩缩容策略

tunnel-cloud 除了依据内存和 CPU 的应用状况主动扩缩容之外，还能够依据与 tunnel-cloud 建设长连贯的边缘节点的个数实现主动扩缩容，架构图如下：

  • prometheus 从 tunnel-cloud 的 pod 采集 metrics
{
      "__name__": "tunnel_cloud_nodes",
      "instance": "172.31.0.10:6000",
      "job": "tunnel-cloud-metrics",
      "kubernetes_namespace": "edge-system",
      "kubernetes_pod_name": "tunnel-cloud-64ff7d9c9d-4lljh"
    }
  • prometheus-adapter 向 apiserver 注册 Custom Metrics API 的扩大 apiserver
{
  "kind": "APIResourceList",
  "apiVersion": "v1",
  "groupVersion": "custom.metrics.k8s.io/v1beta1",
  "resources": [
    {
      "name": "namespaces/nodes_per_pod",
      "singularName": "","namespaced": false,"kind":"MetricValueList","verbs": ["get"]
    },
    {
      "name": "pods/nodes_per_pod",
      "singularName": "","namespaced": true,"kind":"MetricValueList","verbs": ["get"]
    }
  ]
}
  • prometheus-adapter 将 metrics 转化为 pod 度量指标 
{
    "describedObject":{
        "kind":"Pod",
        "namespace":"edge-system",
        "name":"tunnel-cloud-64ff7d9c9d-vmkxh",
        "apiVersion":"/v1"
    },
    "metricName":"nodes_per_pod",
    "timestamp":"2021-07-14T10:19:37Z",
    "value":"1",
    "selector":null
}
  • 配置自定义 HPA
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: tunnel-cloud
  namespace: edge-system
spec:
  minReplicas: 1
  maxReplicas: 10
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: tunnel-cloud
  metrics:
    - type: Pods
      pods:
        metric:
          name: nodes_per_pod
        target:
          averageValue: 300       #均匀每个 pod 连贯的边缘节点的个数，超过这个数目就会触发扩容
          type: AverageValue

节点监控计划

节点监控次要采集边缘节点 kubelet 的 metrics 和 node-exporter 采集到的硬件、零碎指标。在部署 Prometheus 时配置 pod 的 dns 指向 tunnel-dns，Prometheus 应用节点名拜访边缘节点上的 kubelet 和 node-exporter，tunnel-dns 会把节点名解析为边缘节点的 tunnel-edge 连贯的 tunnel-cloud 的 podIp，Prometheus 依据 podIp 拜访 tunnel-cloud（其中获取 kubelet 的 metrics 拜访的是 10250 端口，申请 node-exporter 拜访的 9100 端口），tunnel-cloud 通过长连贯隧道将申请转发到 tunnel-edge，由 tunnel-edge 向 kubelet 和 node-exporter 发动申请，整个流程的框图如下所示：

  • 配置 Prometheus 的 DNS 指向 tunnel-dns
dnsConfig:
  nameservers:
    - <tunnel-dns 的 clusterip>
  options:
    - name: ndots
      value: "5"
  searches:
    - edge-system.svc.cluster.local
    - svc.cluster.local
    - cluster.local
dnsPolicy: None
  • 配置 Prometheus 应用节点名拜访 kubelet 和 node-exporter
- job_name: node-cadvisor
  kubernetes_sd_configs:
    - role: node
  scheme: https
  tls_config:
    insecure_skip_verify: true
  relabel_configs:
    - source_labels: [__meta_kubernetes_node_name]
      regex: (.+)
      target_label: __address__
      replacement: ${1}:10250
    - source_labels: [__meta_kubernetes_node_name]
      regex: (.+)
      target_label: __metrics_path__
      replacement: /metrics/cadvisor
    - source_labels: [__address__]
      target_label: "unInstanceId"
      replacement: "none"
- job_name: node-exporter
  kubernetes_sd_configs:
    - role: node
  scheme: https
  tls_config:
    insecure_skip_verify: true
  relabel_configs:
    - source_labels: [__meta_kubernetes_node_name]
      regex: (.+)
      target_label: __address__
      replacement: ${1}:9100
    - source_labels: [__meta_kubernetes_node_name]
      regex: (.+)
      target_label: __metrics_path__
      replacement: /metrics
    - source_labels: [__address__]
      target_label: "unInstanceId"
      replacement: "none"

总结和瞻望

SuperEdge 的云边隧道计划（tunnel）相比社区的 ANP 计划，具备以下的特点：

  • 反对主动扩缩容
  • 反对了 Prometheus 采集节点监控数据
  • SSH 登录边缘节点
  • 反对 TCP 转发

当然咱们也会持续欠缺 tunnel 的能力，使其可能满足更多场景的需要，依据社区小伙伴的反馈，接下来 tunnel 组件会反对以下性能：

  • 反对从云端拜访边缘端的 service 和边缘端拜访云端的 service
  • 反对 EgressSelector 个性

单干与开源

云边隧道的反对云端 server 主动扩缩容和节点监控新个性曾经在 SuperEdge release 0.5.0 [https://github.com/superedge/…] 开源，欢送大家体验。咱们也会继续晋升 Tunnel 的能力，实用更加简单的边缘网络场景，也欢送对边缘计算感兴趣的公司、组织及集体一起共建 SuperEdge 边缘容器我的项目。

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

退出移动版