KubeEdge 如何构建适应边缘网络的安全可信隧道

今年中国香港 KubeCon 我提交的 Session《KubeEdge 如何构建适应边缘网络的安全可信隧道》有幸被选中。这次 Session 由我和 n-hop 的资深红帽认证架构师 Clement Richard 一起分享。

演讲内容主要分为四大块：

1. 介绍边缘网络场景下遇到的需求以及挑战；

2. 介绍 KubeEdge 对外连接服务的安全性；

3. 介绍 KubeEdge 的可信控制流隧道；

4. 由 Clement Richard 带来网络编码的相关介绍，以及在 KubeEdge 中的应用实践。

需求背景介绍

我们拿一个具备代表性的边缘场景“车联网”来呈现边缘网络的需求，类似的物联网、智能家居、无人机等都有相似的需求影子。

车载系统是动态的以及开放的。我们知道在汽车被使用的时候是在移动的，此时汽车可能处于弱网环境或者网络切换，导致数据传输过程中网络传输质量变差，网络断断续续，以及可能长时间处于离线状态，如在隧道中。在此情况下车机应用要能正常运行，就需要应用适应这些弱网和离线环境。另外，车与车、车与物的互联才能形成“车联网”，我们知道汽车是不太可能拥有固定 IP 的，因此需要车与车之间能通过类似 p2p 的连接方式进行互联。

安全以及隐私也很重要，首先车与车的互联就需要数据传输的安全防护，特别是控制类指令的交互接口，如果不具备安全性会有极大的交通安全隐患。车载中的数据包含了用户隐私数据，不能将用户隐私数据暴露出去，需要有脱敏的处理。关于隐私部分，可能大部分还需要用户应用处理。不过对于模型训练场景，KubeEdge 社区的 AI 项目 Sedna 能通过联邦学习来应对，联邦学习将数据在边端训练后只上传训练后的模型参数到云端进行合并，大家感兴趣的可以去 Github KubeEdge 组的 Sedna 项目了解详情。

网络带宽成本高，移动网络的传输速率本身是有限的，车载产生的数据上报的处理会相当频繁，以及汽车是海量的，如果同时传数据到云端或者基站边缘云，对云端的网络带宽要求也是极高的。因此，需要用相应的压缩算法对数据进行压缩然后选择性合并传输，在云端解压及拆解。

最终，我们将需求提炼为：边缘网络的异构性质使得在边缘端实现有服务质量的应用变得更加困难，其中具有代表性的就是 5G 流量或者 WIFI。用户需要一个能够支持弱网环境以及提供安全保障的边缘计算平台来帮助用户运维业务应用。其中面临的挑战有：

• 通信安全；

• 对弱网络环境的适应能力；

• 高吞吐量、低延迟和可靠性的网络通讯。

02

KubeEdge 网络通讯
双向 TLS 保障

KubeEdge 通过统一的两种方式获取服务端和客户端证书做双向认证，分别是 K8s 的 CRS 签发证书和子签证书。所有外部的服务通讯都使用双向 tls 证书保障通讯安全。

• 边端 EdgeCore 先通过 Token 调用证书服务获取证书，此接口没有 tls 认证，但是通过 token 来保障服务认证安全性；

• EdgeHub 和 TunnelClient 分别作为控制平面隧道和流数据隧道连接到云上 CloudHub 和 TunnelServer；

• MetaServer 提供本地 K8s 资源接口，边端 Pod 可以在离线时通过此服务获取节点中资源（Pod，ConfigMap，Device 等），客户端证书由 K8s CSR 生成；

• CloudHub 使用 K8s APIServer 的客户端 tls 证书连接 API Server，list/watch KubeEdge 关注的资源；

• Stream 使用 Kubelet Client 的证书劫持 API Server 到 Kubelet 的流量，处理 exec, logs, metrics 等流接口；

• API Server 用自签证书或者 K8s CSR 生成的证书访问 Admission，给 KubeEdge 的 CRD 资源进行复杂准入校验；

• 用户通过 Router 节点发起云边消息代理，mqtt 或者 http 消息。

如果想要支持国密算法， 也有相应的解决方案。经调研，Golang 的标准 tls 包不支持扩展国密算法，因此如果需要通过源码支持国密算法，其工作量是非常大的，需要对各种类型的服务端源码重写 tls 握手认证的部分，因此我们觉得选择一个支持国密算法的代理服务是个不错的选择。

正如刚提到的，源码 tls 是不支持国密算法的，因此与 k8s 的相关流量都无法支持国密认证，能支持国密算法的服务分别有：hub 隧道，http 服务，stream 隧道，以及 router 服务。选择一个支持国密算法的代理服务器部署在云端，然后客户端先通过国密证书调用到代理服务器，然后代理服务器将证书转为原证书后调用相应的服务。国内有一些基于 nginx 做扩展的开源 web 服务原生支持国密 tls，就比如 TEngine。

03

KubeEdge
可靠安全的 Hub 隧道

KubeEdge 的控制流即是由 CloudHub 和 EdgeHub 来实现的，在此简称 Hub 隧道，我们来看下 Hub 通道的整体构成。

在 CloudCore 中，EdgeController 和 DeviceController 它们 Watch API Server 来获取它们关注的资源下发到指定边缘节点，并且获取边缘节点上报的资源状态来进行更新。这种方式能减轻 API Server 的负载，使 KubeEdge 的集群能接入更多的节点和 Pod。SyncController 会记录发送到 Edge 资源最新的 resourceVersion，当 CloudCocre 重启时会发送最新的信息，以免发送旧消息。KubeEdge 遵循 Kubernetes 最终的一致性的设计原则，因此，只要消息是最新消息，边缘节点重复接收相同消息不是问题。因此，KubeEdge 采用了至少一次的传输保障方式。   

Hub 隧道使用消息队列的机制相互通讯，MessageDispatcher 负载分发消息到相应的 NodeMessageQueue，CloudHub 从 NodeMessageQueue 获取消息发送到边缘节点，消息处理会有 ack 来做保障，最多重试 5 次，消息成功会将最新的 resourceVersion 更新到 objectSync，失败会丢弃，synccontroller 会按 resourceVersion 与 k8s 最新的资源对比来选择删除或者重试。

Hub 消息隧道可以选择使用 QUIC 协议使其在弱网有更好的性能。KubeEdge Hub 隧道在云端支持同时开放两种协议 Websocket 和 QUIC，节点可按需求选择一种协议接入。

QUIC 是 Google 制定的一种基于 UDP 的低时延、可靠的互联网传输层协议。Google 为其研发了优秀的重传算法和拥塞控制算法。在互联网长距离传输并且存在丢包的网络环境，QUIC 的表现相较于 TCP 有着成倍的提升。其核心特性有：

• 0-RTT 建立连接，传输层使用了 UDP，减少了 1 个 RTT 三次握手的延迟。加密协议采用了 TLS 协议的最新版本 TLS 1.3，TLS1.3 允许客户端无需等待 TLS 握手完成就开始发送应用程序数据的操作，可以支持 1 RTT 和 0RTT。对于 QUIC 协议，客户端第一次建连的握手协商需 1-RTT，而已建连的客户端重新建连可以使用之前协商好的缓存信息来恢复 TLS 连接，仅需 0-RTT 时间。因此 QUIC 建连时间大部分 0-RTT、极少部分 1-RTT。

• 无队头阻塞的多路复用，QUIC 的流与流之间完全隔离的，互相没有时序依赖。如果某个流出现丢包，不会阻塞其他流数据的传输和应用层处理，所以这个方案并不会造成队首阻塞，多路复用的效果也更好。

• 连接迁移，比如你用手机使用蜂窝网络参加远程会议，当你把网络切换到 WLAN 时，会议客户端会立马重连，视频同时出现一瞬间的卡顿。这是因为 TCP 采用四元组（包括源 IP、源端口、目标地址、目标端口）标识一个连接，在网络切换时，客户端的 IP 发生变化，TCP 连接被瞬间切断然后重连。QUIC 的连接迁移就是当四元组中任一值发生变化时，连接依旧能保持，不中断业务，这是因为它用一个（一般是 64 位随机数）ConnectionID 标识连接，这样即使源的 IP 或端口发生变化，只要 ConnectionID 一致，连接都可以保持，不会发生切断重连。

• 可扩展性，QUIC 核心逻辑都在用户态，能灵活的修改连接参数、替换拥塞算法、更改传输行为。而 TCP 核心实现在内核态，改造需要修改内核并且进行系统重启，成本极高。

• 前向纠错（FEC），QUIC 支持前向纠错，弱网丢包环境下，动态的增加一些 FEC 数据包，可以减少重传次数，提升传输效率。

上图中，图 1 是 TCP 和 QUIC 的连接延迟对比，得益于 QUIC 对 RTT 的优化，QUIC 的连接速度比 TCP 降低一倍。后面 3 张图是对比 TPC 和 QUIC 分别在 5%、15%、30%丢包率场景下的对比，横坐标表示丢包时延，纵坐标用百分比表示指定时延下的样本数量，曲线收敛速度越快，落在较低时延范围的样本数量越多，时延表现越好。

我们知道 k8s 的 kubelet 提供了节点鉴权能力，启用特性后（api-server启动参数设置--authorization-mode=Node）kubelet 访问 api-server的接口会添加限制，主要有：

• 只能读取 services、endpoints、nodes、pods 以及与绑定到节点的 pod 相关的 Secret、ConfigMap、PVC 以及 PV；

• 写入操作支持操作事件，以及在开启 NodeRestriction 准入插件限制的情况下，kubelet 只能修改自己的节点以及绑定到自身的 Pod。

KubeEdge 因为使用了自己的隧道，因此无法使用原生的 Kubelet 节点鉴权功能，不过我们基于 K8s 的节点鉴权功能实现了 KubeEdge 的节点鉴权特性。首先经过 hub 隧道的请求会先经由 KubeEdge 自己实现的 Authorizer 来过滤 KubeEdge CRD 的操作行为，一些节点类资源也做了节点只能访问绑定到自身的资源的限制，如设备。然后访访问 api-server 时，会使用通过 roundtrip 包装的客户端，由这个 roundtrip 来统一实现节点鉴权的请求头的注入，请求头有记录组的 system:nodes 固定值以及记录节点名称的 system:node:<nodename>，最终交给 k8S 处理节点鉴权。

04

网络编码强化
KubeEdge

接着，由 Clement Richard 分享了网络编码对 KubeEdge 的强化。

网络编码本身是一个不太被认可的老概念。在上世纪 90 年代末，杨荣文教授试图证明，分组交换(通常被称为路由)是实现网络容量(在数学意义上)的最佳方式。在这个过程中，他发现单靠路由无法达到这种最佳网络容量，如果我们允许在网络中的中间节点进行计算，我们可以达到理论上的最大吞吐量。这种网络上的计算被称为“网络编码”。注意，网络编码不应与套接字编程、P4 和这类其他东西混淆。

25 年后的今天，网络编码领域的研究依然活跃。经过对现实世界用例的研究开发，我们意识到网络编码所承诺的大量收益依赖于协议，特别是一个能够感知网络编码层的协议。

通过网络编码技术，传输吞吐量可以在数十甚至数百跳后保持不变。n-hop 开源了网络传输工具 BATS，BATS 是一种颠覆性通信技术，可以在任何物理层上显著提高有损多跳网络的吞吐量，无论是短距离无线(如蓝牙、Wi-Fi、ZigBee)、中距离无线(如 LTE)、远程无线(如用于卫星通信的 VSAT)、水下通信(如声学、光学)还是电力线通信。广泛的应用程序可以从 BATS 中受益。特别值得一提的是，BATS 已成功应用于香港政府的智能灯柱试验系统。

CloudCore 和 EdgeCore 之间的 Kube 边缘同步只依赖于一个隧道。KubeEdge 的隧道组件使用 Websocket 或 QUIC 进行隧道。QUIC 试图为 UDP 带来可靠性，它本身是对网络的一个很好的增强，但它仍然存在丢包的问题。BATS 协议可以与 QUIC 一起使用，通过利用网络编码技术减少延迟、抖动的影响并最大限度地提高带宽，从而提高该隧道的性能。BATS 协议是一个灵活的传输层，它可以以多种方式与 KubeEdge 隧道一起使用。

今年的北美 KubeCon 这几天正在盐湖城召开，「DaoCloud 道客」首席运营官张红兵也将会在这场大会上带来关于 KubeEdge 的最新分享，敬请关注吧！

 本文作者 

「DaoCloud 道客」高级软件工程师

热门推荐

            

访问以下网址，或点击文末【阅读原文】立即体验

文章转载自道客船长。点击这里阅读原文了解更多。

CNCF概况（幻灯片）

扫描二维码联系我们！

CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux  Foundation，是非营利性组织。 

CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。请关注CNCF微信公众号。