导读:OpenYurt 是阿里巴巴开源的云边协同一体化架构,与同类开源方案相比,OpenYurt 拥有可实现边缘计算全场景覆盖的能力。在之前的一篇文章中,我们介绍了 OpenYurt 是如何在弱网和断网场景下实现边缘自治的。本文作为 OpenYurt 系列文章的第四篇,我们将着重介绍 OpenYurt 的另一个核心能力——云边通信,以及相关组件 Yurttunnel。
使用场景
反向通道
-
在管控组件所在网络内,部署 proxy server。
-
proxy server 对外开放一个公网可以访问的 IP。
-
在每个 region 部署个 agent,并通过 server 的公网 IP 与 server 建立长连接。
-
管控组件对边缘节点的访问请求都将转发致 proxy server。
-
proxy server 再将请求通过对应的长连接发往目标节点。
图二
ANP 并非开箱即用
-
如何转发云端节点的请求 -- 反向通道正常工作的一个前提是,管控节点发往边缘节点的请求必须先经过 proxy server。对于 Kubernetes 1.16 + 版本,KAS 能借由 EgressSelector 将发往节点的请求先发往指定的 proxy server。但对于 1.16 以前的版本,KAS 及其他管控组件(Prometheus 和 metrics server)只能直接访问节点,而不能绕道 proxy server。可以预见的是,部分用户在短期内,仍将使用 1.16 以前的版本,并且 Prometheus 和 metrics server 等管控组件在短期内也没有支持 EgressSelector 的计划。因此,我们要解决的第一个问题是,如何将管控组件发往节点的请求转发致 proxy server。
-
如何确保 server 副本覆盖所有的 region -- 在生产环境中,一个边缘集群常常包含上万个节点,并同时服务上百名用户,如果一个集群只有一个 proxy server, 那么,一旦 proxy server 出现故障,所有用户都将无法对位于边缘节点上的 pod 进行操作。因此,我们必须同时部署多个 proxy server 副本以保证集群高可用。同时,proxy server 的工作负荷将随着访问流量的增大而增大,用户的访问延时也势必增加。因此在部署 proxy server 时,我们还需考虑如何对 proxy server 进行水平拓展,以应对高并发场景。一个应对单点故障和高并发场景的经典解决方案是,部署多个 proxy server 副本,并使用负载均衡进行流量分发。然而在 OpenYurt 场景下,对于 KAS 发来的任意请求,LoadBalancer (LB) 会转发给哪个 server 副本是不可控的,因此,需要解决的第二个问题是,如何保证每个 server 副本都能与所有的 agent 建立连接。
-
如何将请求转发给正确的 agent -- 在运行过程中,proxy server 在收到请求后,需根据请求的 destination IP,将请求转发至位于对应 network region 内的 agent。然而,ANP目前的实现,假设所有的节点都位于一个网络空间内, server 会随机挑选一个 agent 转发请求。因此,我们需要解决的第三个问题是,如何将请求正确地转发给指定的 agent。
-
如何解除组件对节点证书的依赖 -- 在运行时,我们需要为 server 提供一套 TLS 证书,以实现 server 与 KAS,server 与 agent 间的安全通信。同时,我们也需要为 agent 准备一套 TLS client 证书,用以建立 agent 和 server 间的 gRPC 信道。ANP 目前的实现,要求 server 必须和 KAS 部署在同一个节点上,并且在启动时挂载节点 volume 共享 KAS tls 证书。同样,agent 也需要在启动时挂载 volume 共享 kubelet tls 证书。这无形中降低了部署的灵活性,造成了组建对节点证书的强依赖,在有些情况下,用户可能希望将 server 部署在非 KAS 所在节点上。因此,另一个需要关注的问题是,如何解除组件对节点证书的依赖。
如何缩小 Tunnel 带宽 -- ANP 的一个核心设计思想,是使用 gRPC 封装 KAS 所有对外 HTTP 请求。这里选择 gRPC,主要是看重其对流(stream)的支持和清晰的接口规范,此外,强类型的客户端和服务器端可以有效减少运行时错误,提高系统稳定性。然而,我们也发现,相较于直接使用 TCP 协议,采用 ANP 也会带来额外的开销增加带宽。从产品层面考虑,Tunnel 流量走的是公网,带宽的增加也意味着用户成本的增加。因此,一个非常重要的问题是,在提高系统稳定性的同时,我们是否也能缩小带宽?
Yurttunnel 设计解析
1. 制定 DNAT 规则转发云端节点的请求
2. 动态获取 Server 副本数
-
在启动 yurttunnel server 时,我们会将副本数(serverCount)传入每个 server 副本中,并且为每个副本指定一个 server ID;
-
agent 连接 LB 后,LB会随机选择一个 server 副本并让其与 agent 建立长连接;
-
与此同时,server 会通过该通道向 agent 返回一个 ACK package,这个 package 中将包含 serverCount 和 serverID;
-
agent 通过解析 ACK package,可以获悉 server 副本的个数,并在本地记录已连接的 serverID;
-
如果 agent 发现,本地连接的 server 副本数小于 serverCount,则会再次向 LB 发送连接请求,直至本地记录的 serverID 数与 server Count 数一致为止。
3. 为 ANP 添加代理策略
在 OpenYurt 的网络模型下,边缘节点分布在不同的 network region 中,随机选择的 agent 可能无法将请求转发至位于其他 region 内的节点上。因此我们不得不修改 ANP server 底层代理转发的逻辑。然而,根据长期的经验,我们相信,proxy server 支持不同的代理策略,例如,将请求转发至指定数据中心,region,或者指定主机,是一个较为通用的需求。经过和 ANP 社区开发者讨论,我们决定重构 ANP 管理 agent 连接的接口,允许用户根据需求实现新的代理策略,并计划将该 feature 最终合入上游代码库。目前重构工作仍在进行中,在 Yurttunnel 第一个开源版本中,我们暂时采用以下配置:
-
在每个边缘节点上部署一个 agent。
-
agent 在 server 处登记时,使用 agent 所在节点的 IP 作为 agentID。
-
server 在转发请求时,通过匹配请求目标 IP 和 agentID,将请求转发至对应的 agent。
4. 动态申请安全证书
5. 压缩 Tunnel 带宽,节约成本
Yurttunnel 系统架构
Yurttunnel Server - 负责将 apiserver,prometheus,metrics server 等管控组件发往节点的请求,转发至对应的 agent。具体包括以下子组件:
-
ANP Proxy Server - 对 ANP gRPC server 的封装,负责管理与 Yurttunnel Agent 之间的长连接,并转发请求。 -
Iptable Manager - 修改管控节点的 DNAT 规则,以确保管控组件的请求能被转发至 Yurttunnel Server。 -
Cert Manager - 为 Yurttunnel Server 生成 TLS 证书。 -
Request Interceptor - 将 KAS 对节点的 HTTP 请求封装到符合 ANP 规则的 gRPC 包里。
-
Yurttunnel Agent - 与 Yurttunnel Server 主动建立连接,并将 Yurttunnel Server 发来的请求转发给 Kubelet。具体包括两个子组件: -
ANP Proxy Agent - 对 ANP gRPC agent 的封装,相较于上游,我们额外加入了 gzip compressor 以压缩数据。 -
Cert Manager - 为 Yurttunnel Agent 生成 TLS 证书。
-
Yurttunnel Server Service - 通常是一个 SLB,负责将管控组件发来的请求分发给合适的 Yurttunnel Server 副本,保证 Yurttunnel 的高可用和负载均衡。
总结与展望
文章转载自阿里巴巴云原生。点击这里阅读原文了解更多。
:参加2020北美KubeCon + CloudNativeCon虚拟大会,免费注册!
扫描二维码联系我们!
CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。请长按以下二维码进行关注。
本文分享自微信公众号 - CNCF(lf_cncf)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。
来源:oschina
链接:https://my.oschina.net/u/4254704/blog/4711649