如何构建 Kubernetes 原生云边高效协同网络？

使用场景

在应用的部署和运维过程中，用户常常需要获取应用的日志，或直接登录到应用的运行环境中进行调试。在 Kubernetes 环境中，我们通常使用 kubectl log，kubectl exec 等指令来实现这些需求。如下图所示，在 kubectl 请求链路上， kubelet 将扮演服务器端，负责处理由 kube-apiserver(KAS) 转发来的请求，这就要求 KAS 和 kubelet 之间需要存在一条网络通路，允许 KAS 主动访问 kubelet。

图一：kubectl 执行流程

然而，在边缘计算场景中，边缘节点常位于本地专有网络中，这虽然保证了边缘节点的安全，但也造成位于云端管控节点的 KAS 无法直接访问位于边缘节点的 kubelet。因此，为了支持通过云端节点对边缘端应用进行运维操作，我们必须在云、边之间建立反向运维通道。

反向通道

Yurttunnel 是 OpenYurt 近期开源的一个重要组件，用来解决云边通信问题。反向通道是解决跨网络通信的一种常见方式，而 Yurttunnel 的本质就是一个反向通道。一个边缘集群下属的节点常位于不同的 network region 中，而位于同一个 region 内的节点之间是可以相互通信的，因此在设置反向通道时，我们只需保证在每个 region 内设置一个与 proxy server 相连的 agent 即可（如下图所示）。具体包括以下几个步骤：

• 在管控组件所在网络内，部署 proxy server。
• proxy server 对外开放一个公网可以访问的 IP。
• 在每个 region 部署个 agent，并通过 server 的公网 IP 与 server 建立长连接。
• 管控组件对边缘节点的访问请求都将转发致 proxy server。
• proxy server 再将请求通过对应的长连接发往目标节点。
  

图二

在 Yurttunnel 中，我们选择使用上游项目 apiserver-network-proxy(ANP) 来实现 server 和 agent 间的通信。ANP 是基于 kubernetes 1.16 Alpha 新功能 EgressSelector 开发，意在实现 Kubernetes 集群组件的跨 intranet 通信（例如，master 位于管控 VPC，而 kubelet 等其他组件位于用户 VPC）。

读者可能会好奇，既然 OpenYurt 是基于 ACK@Edge 开源的，而在生产环境中， ACK@Edge 的云边运维通道使用的是自研组件 tunnellib，那为什么在开源版本里我们要选用一个新的组件呢？ 这里不得不再次提到 OpenYurt 的核心设计理念 “Extend upstream Kubernetes to Edge”。

诚然，tunnellib 经过了复杂线上环境的考验，组件性能稳定，但我们更希望能与上游保持最大的技术公约数，让 OpenYurt 的用户体验更接近原生 Kubernetes ；同时，在 ACK@Edge 的开发和运维过程中，我们发现，边缘集群的许多需求也同样存在于其他场景中（例如，大多数云厂商也需要实现节点跨网络通信），并且运维通道的传输效率也能进一步优化（4.5章将详述优化过程）。因此，秉承开放分享、平等普惠的开源精神，我们希望能将开发和运维过程中积累的的宝贵经验在上游社区与更多的开发者分享。

ANP 并非开箱即用

然而 ANP 项目仍处于起步阶段，