作者

作者李騰飛，騰訊容器技術研發工程師，騰訊雲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/superedge/blob/main/CHANGELOG/CHANGELOG-0.5.md] 開源，歡迎大家體驗。我們也會持續提升 Tunnel 的能力，適用更加複雜的邊緣網路場景，也歡迎對邊緣計算感興趣的公司、組織及個人一起共建 SuperEdge 邊緣容器專案。

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！