Skip to main content

3 posts tagged with "yurthub"

View All Tags

· 7 min read
rambohe

image

OpenYurt如何解决边缘自治问题

想要实现将 Kubernetes 系统延展到边缘计算场景,那么边缘节点将通过公网和云端连接,网络连接有很大不可控因素,可能带来边缘业务运行的不稳定因素,这是云原生和边缘计算融合的主要难点之一。

解决这个问题,需要使边缘侧具有自治能力,即当云边网络断开或者连接不稳定时,确保边缘业务可以持续运行。在 OpenYurt 中,该能力由 yurt-controller-manager 和 YurtHub 组件提供。

1)Yurthub架构

在之前的文章中,我们详细介绍了YurtHub 组件的能力。其架构图如下:

image YurtHub是一个带有数据缓存功能的“透明网关”,和云端网络断连状态下,如果节点或者组件重启,各个组件(kubelet/kube-proxy 等)将从 YurtHub 中获取到业务容器相关数据,有效解决边缘自治的问题。这也意味着我们需要实现一个轻量的带数据缓存能力的反向代理。

2)第一想法

实现一个缓存数据的反向代理,第一想法就是从 response.Body 中读取数据,然后分别返回给请求 client 和本地的 Cache 模块。伪代码如下:

func HandleResponse(rw http.ResponseWriter, resp *http.Response) {
bodyBytes, _ := ioutil.ReadAll(resp.Body)
go func() {
// cache response on local disk
cacher.Write(bodyBytes)
}

// client reads data from response
rw.Write(bodyBytes)
}

当深入思考后,在 Kubernetes 系统中,上述实现会引发下面的问题:

  • 问题 1:流式数据需要如何处理(如: K8s 中的 watch 请求),意味 ioutil.ReadAll() 一次调用无法返回所有数据。即如何可以返回流数据同时又缓存流数据。

  • 问题 2:同时在本地缓存数据前,有可能需要对传入的 byte slice 数据先进行清洗处理。这意味着需要修改 byte slice,或者先备份 byte slice 再处理。这样会造成内存的大量消耗,同时针对流式数据,到底申请多大的 slice 也不好处理。

3) 优雅实现探讨

针对上面的问题,我们将问题逐个抽象,可以发现更优雅的实现方法。

  • 问题 1:如何对流数据同时进行读写

针对流式数据的读写(一边返回一边缓存),如下图所示,其实需要的不过是把 response.Body(io.Reader) 转换成一个 io.Reader 和一个 io.Writer。或者说是一个 io.Reader 和 io.Writer 合成一个 io.Reader。这很容易就联想到 Linux 里面的 Tee 命令。

image

而在 Golang 中 Tee 命令是实现就是 io.TeeReader,那问题 1 的伪代码如下:

func HandleResponse(rw http.ResponseWriter, resp *http.Response) {
// create TeeReader with response.Body and cacher
newRespBody := io.TeeReader(resp.Body, cacher)

// client reads data from response
io.Copy(rw, newRespBody)
}

通过 TeeReader 的对 Response.Body 和 Cacher 的整合,当请求 client 端从 response.Body 中读取数据时,将同时向 Cache 中写入返回数据,优雅的解决了流式数据的处理。

  • 问题 2:如何在缓存前先清洗流数据

如下图所示,缓存前先清洗流数据,请求端和过滤端需要同时读取 response.Body(2 次读取问题)。也就是需要将 response.Body(io.Reader) 转换成两个 io.Reader。

image

也意味着问题 2 转化成:问题 1 中缓存端的 io.Writer 转换成 Data Filter 的 io.Reader。其实在 Linux 命令中也能找到类似命令,就是管道。因此问题 2 的伪代码如下:

func HandleResponse(rw http.ResponseWriter, resp *http.Response) {
pr, pw := io.Pipe()
// create TeeReader with response.Body and Pipe writer
newRespBody := io.TeeReader(resp.Body, pw)
go func() {
// filter reads data from response
io.Copy(dataFilter, pr)
}

// client reads data from response
io.Copy(rw, newRespBody)
}

通过 io.TeeReader 和 io.PiPe,当请求 client 端从 response.Body 中读取数据时,Filter 将同时从 Response 读取到数据,优雅的解决了流式数据的 2 次读取问题。

YurtHub实现

最后看一下 YurtHub 中相关实现,由于 Response.Body 为 io.ReadCloser,所以实现了 dualReadCloser。同时 YurtHub 可能也面临对 http.Request 的缓存,所以增加了 isRespBody 参数用于判定是否需要负责关闭 response.Body。

// https://github.com/openyurtio/openyurt/blob/master/pkg/yurthub/util/util.go#L156
// NewDualReadCloser create an dualReadCloser object
func NewDualReadCloser(rc io.ReadCloser, isRespBody bool) (io.ReadCloser, io.ReadCloser) {
pr, pw := io.Pipe()
dr := &dualReadCloser{
rc: rc,
pw: pw,
isRespBody: isRespBody,
}

return dr, pr
}

type dualReadCloser struct {
rc io.ReadCloser
pw *io.PipeWriter
// isRespBody shows rc(is.ReadCloser) is a response.Body
// or not(maybe a request.Body). if it is true(it's a response.Body),
// we should close the response body in Close func, else not,
// it(request body) will be closed by http request caller
isRespBody bool
}

// Read read data into p and write into pipe
func (dr *dualReadCloser) Read(p []byte) (n int, err error) {
n, err = dr.rc.Read(p)
if n > 0 {
if n, err := dr.pw.Write(p[:n]); err != nil {
klog.Errorf("dualReader: failed to write %v", err)
return n, err
}
}

return
}

// Close close two readers
func (dr *dualReadCloser) Close() error {
errs := make([]error, 0)
if dr.isRespBody {
if err := dr.rc.Close(); err != nil {
errs = append(errs, err)
}
}

if err := dr.pw.Close(); err != nil {
errs = append(errs, err)
}

if len(errs) != 0 {
return fmt.Errorf("failed to close dualReader, %v", errs)
}

return nil
}

在使用 dualReadCloser 时,可以在 httputil.NewSingleHostReverseProxy 的 modifyResponse() 方法中看到。代码如下:

// https://github.com/openyurtio/openyurt/blob/master/pkg/yurthub/proxy/remote/remote.go#L85
func (rp *RemoteProxy) modifyResponse(resp *http.Response) error {rambohe-ch, 10 months ago: • hello openyurt
// 省略部分前置检查
rc, prc := util.NewDualReadCloser(resp.Body, true)
go func(ctx context.Context, prc io.ReadCloser, stopCh <-chan struct{}) {
err := rp.cacheMgr.CacheResponse(ctx, prc, stopCh)
if err != nil && err != io.EOF && err != context.Canceled {
klog.Errorf("%s response cache ended with error, %v", util.ReqString(req), err)
}
}(ctx, prc, rp.stopCh)

resp.Body = rc
}

总结

OpenYurt 于 2020 年 9 月进入 CNCF 沙箱后,持续保持了快速发展和迭代,在社区同学一起努力下,目前已经开源的能力有:

  • 边缘自治
  • 边缘单元化管理
  • 云边协同运维
  • 一键式无缝转换能力

原文链接

· 10 min read
rambohe

导读:OpenYurt 自开源以来,以非侵入式的架构设计融合云原生和边缘计算两大领域,引起了不少行业内同学的关注。阿里云推出开源项目 OpenYurt,一方面是把阿里云在云原生边缘计算领域的经验回馈给开源社区,另一方面也希望加速云计算向边缘延伸的进程,并和社区共同探讨未来云原生边缘计算架构的统一标准。 本文主要介绍了 OpenYurt 中组件 YurtHub 的扩展能力。

OpenYurt介绍

阿里云边缘容器服务上线 1 年后,正式开源了云原生边缘计算解决方案 OpenYurt,跟其他开源的容器化边缘计算方案的区别在于:OpenYurt 秉持 Extending your native Kubernetes to edge 的理念,对 Kubernetes 系统零修改,并提供一键式转换原生 Kubernetes 为 openyurt,让原生 K8s 集群具备边缘集群能力。

同时随着 OpenYurt 的持续演进,也一定会继续保持如下发展理念:

  • 非侵入式增强 K8s

  • 保持和云原生社区主流技术同步演进

YurtHub架构说明

前面的文章中,我们介绍了 OpenYurt 的边缘自治能力,重点解读了其中的组件 YurtHub。其架构图如下: OpenYurt组件YurtHub构架图:

image

与Kubernetes设计理念契合,YurtHub的优势之一是,非常容易扩展出更多的能力。

YurtHub的拓展能力

1)边缘网络自治

首先介绍一下何谓边缘网络自治:即在边缘和云端网络断连时,不管是业务容器重启,或是边缘节点重启等,边缘业务的跨节点通信可以持续工作或是自动恢复。

在OpenYurt中,实现边缘自治需要解决如下的问题(以flannel vxlan overlay网络为例):

  • 问题 1: 节点上的网络配置可以自治,kube-proxy 的 iptables / ipvs 规则,flannel 的 fdb / arp / route 配置,coredns 的域名解析等网络配置,在节点重启后可以自动恢复,否则边缘跨节点通信将无法持续;
  • 问题 2: 业务容器 IP 保持不变,因为和云端网络断连状态下容器 IP 变化将无法通知到其他节点;
  • 问题 3: vtep(vxlan tunnel endpoint) 的 mac 地址保持不变,原因和容器 IP 保持不变类似。

从问题 1 可以看出,必须解决 kube-proxy / flannel / coredns 等组件的自治,才能实现网络配置的自治。如果之前边缘自治是采用重构 kubelet 来实现的话,要实现边缘网络自治就会碰到很大的麻烦,如果强行把重构的 kubelet 自治能力移植到各个网络组件 (kube-proxy / flannel / coredns),也对整个架构将是噩梦。

在 OpenYurt 中因为 YurtHub 的独立性,kube-proxy / flannel / coredns 等网络组件轻松使用 YurtHub 来实现网络配置的自治能力。因为 YurtHub 缓存了 service 等网络配置资源在 local storage,即使断网并且节点重启,网络组件仍然可以获得断网前的 object 状态以及相应的配置信息。如下图所示:

image

问题 2,3 和 Kubernetes core 无关,主要涉及到 cni 插件和 flanneld 的增强,后续文章中再详细介绍。

2)多云端地址支持

公有云上的 Kubernetes 高可用部署时,多实例 kube-apiserver 前面一般都挂了一个 SLB,但是在专有云场景下或者边缘计算场景下,节点需要通过多个云端地址来访问。比如:

  • 专有云场景:因为没有 SLB 服务,用户需要在云端通过 VIP 方式来自行实现 kube-apiserver 的负载均衡,或者像 kubespray 那样在每个节点上部署一个 nginx 来实现多云端地址的访问;
  • 边缘计算场景: 考虑到边缘和云端之间网络的稳定性和安全性要求,某些场景下用户也通过专线和公网两种方式和云端通信,比如优先采用专线,当专线故障时能自动切换到公网通信。

YurtHub正式考虑到了上述的需求,支持多云端地址访问。云端地址的负载均衡模式可以选择:

  • rr(round-robin):轮转模式,默认选择该模式;

  • priority: 优先级模式,高优先级地址故障后才使用低优先级地址。

具体可以参照 YurtHub 的 LB 模块,如下图所示:

image

3)节点维度的云端流控

对于一个分布式系统来说,流控都是一个无法回避的问题。原生 Kubernetes 从集群视角在 kube-apiserver 中以及从访问者视角在 client-go 库中封装了流量管控,在边缘计算场景下,client-go 的流量管控既分散又对业务有一定侵入,显然不能很好的解决流控问题。

YurtHub 在边缘可以接管不论是系统组件还是业务容器对云端访问的流量,可以很好的解决节点维度的云端流控问题。目前 YurtHub 的流控配置是:单节点上对云端的并发请求数超过 250 个时,将拒绝新的请求。

4)节点证书轮转管理

Kubernetes 已经支持节点证书自动轮换,即当节点证书快过期前,kubelet 会自动向云端申请新的节点证书。但是在边缘计算场景下,很有可能因为边缘和云端网络的断连,造成 kubelet 将无法完成证书的轮换。证书过期后即使和云端网络连接恢复,节点证书也可能无法自动轮换,并造成 kubelet 的频繁重启。

YurtHub 在接管节点和云端通信流量时,同时也可以接管节点的证书管理。这样既解决了各类安装工具对节点证书的管理的不一致,也解决了证书过期后网络再恢复时的证书轮换问题。另外目前 YurtHub 还是 kubelet 共享节点证书,YurtHub 的独立节点证书管理功能将在近期开源。

5)其他

YurtHub 除了前面介绍的扩展能力,还有很多有价值的能力,在此也简单介绍:

  • 节点多租隔离管理:在具备多租隔离能力的 Kubernetes 集群中,假定节点归属于某个租户,那么 YurtHub 将可以确保节点上所有云端请求都只返回节点所属租户的资源。比如说 list service 将只返回该租户的 service。而这种多租隔离能力不需要其他组件做任何修改。当然如果要实现集群内的多租隔离,需要配合相应的多组 CRD 等,详细可以参照项目kubernetes-sigs/multi-tenancy
  • 集群间节点迁移:某些场景下,边缘节点需要从集群 A 迁移到集群 B,常规操作是先从集群 A 下线,然后再次接入集群 B,最后在集群 B 部署节点上的应用。因为 YurtHub 对节点流量以及节点证书的接管,可以直接对 YurtHub 注入集群B的信息,让节点无损迁移到集群 B;
  • 通过域名访问云端kube-apiserver等等一些其他功能。

总结

通过上述的扩展能力可以看出:

  • YurtHub 不仅仅是边缘节点上的带有数据缓存能力的反向代理,而且对 Kubernetes 节点应用生命周期管理加了一层新的封装,提供边缘计算所需要的核心管控能力;
  • YurtHub 不仅仅适用于边缘计算场景,其实还可以作为节点侧的一个常备组件,适用于使用 Kubernetes 的任意场景。相信这也会驱动 YurtHub 向更高性能,更高稳定性发展。

原文链接

· 7 min read
rambohe

image

导读:OpenYurt 开源两周以来,以非侵入式的架构设计融合云原生和边缘计算两大领域,引起了不少行业内同学的关注。阿里云推出开源项目 OpenYurt,一方面是把阿里云在云原生边缘计算领域的经验回馈给开源社区,另一方面也希望加速云计算向边缘延伸的进程,并和社区共同探讨未来云原生边缘计算架构的统一标准。 本文将详细介绍OpenYurt的边缘自治能力的设计细节。

边缘自治特性

1)特性介绍

将 Kubernetes 系统延展到边缘计算场景,边缘节点将通过公网和云端连接,从公网的不稳定性以及成本等因素考虑,边缘要求断网状态或者弱网状态下边缘业务可以持续运行。我们从 Gartner 的边缘计算报告中提到的边缘计算诉求中,边缘自治也是主要诉求之一: image

从 Kubernetes 系统架构来看,主要因为 Slave Agent(Kubelet) 中的容器信息保存在内存中,断网状态下因为无法从云端获取业务数据,如果节点或者 Kubelet 重启,将无法进行业务容器恢复。 image

2)边缘自治需要解决的问题

因此边缘自治在Kubernetes系统里,需要解决下面的问题:

  • 问题 1:节点异常或重启时,内存数据丢失,网络断连时业务容器无法恢复;

  • 问题 2:网络长时间断连,云端控制器对业务容器进行驱逐;

  • 问题 3:长时间断连后网络恢复时,边缘和云端数据的一致性保障。

问题1的解决方案1

重构 kubelet 组件,复用或者参考 kubelet 的 checkpoint 功能,持久化容器业务数据到本地磁盘,网络断连状态下利用本地缓存数据实现业务恢复。 image 该方案经过重构 kubelet,成功解决边缘自治的需求,具备如下优点:

  • 通过重构 kubelet,方便在 kubelet 中集成对端设备的管理能力;

  • 通过重构 kubelet,可以对 kubelet 进行轻量化改造。此优点但是也意味着原生 kubelet 功能缺失的问题。

但是也有如下不足:

  • 可维护性差: 侵入式修改 kubelet core,跟随社区版本升级非常困难,熟悉kubelet的同学都会有同感,kubelet 组件由于直接负责计算,存储,网络交互,所以其代码结构和逻辑异常复杂。因此持续维护一个深度修改过的 kubelet 的工作量可想而知;

  • 可扩展性差: 因为自治能力直接做到重构的 kubelet 组件中,这样边缘节点如果其他组件(如网络组件)想复用边缘自治能力将面临重复造轮子的境地;

  • 场景耦合更深: 例如在 kubelet 重构中增加了 IOT 设备管理,将可能使 kubelet 和 IOT 场景深度耦合。

问题1的解决方案2(OpenYurt使用方案)

在边缘节点上增加 web 缓存及请求代理 hub(取名为 YurtHub,商业产品中名为 edge-hub),边缘侧组件(kubelet)和云端通信将经由该组件。YurtHub 相当于带有数据缓存功能的”透明网关“,和云端网络断连状态下,如果节点或者 kubelet 重启,将从 YurtHub 中获取到业务容器相关数据,有效解决边缘自治的问题

image

相比解决方案1,有如下优势:

  • kubelet 零修改,意味原生 kubelet 能力天然具备,同时跟随 Kubernetes 版本升级零负担;

  • 可扩展性强,节点其他组件轻松复用 YurtHub;

  • 与 Kubernetes 设计理念契合,YurtHub 非常容易扩展出更多的能力。

当然 OpenYurt 的解决方案,也会面临如下的问题:原生 kubelet 比较 high-weight,在资源紧张场景下应用会比较挑战。目前商业产品中节点规格推荐 2U4G 起步。

问题2的解决方案

该问题正是通过开源组件 yurt-controller-manager 中的 Node Controller 来解决的。如 github 主页介绍所示: image

问题3的解决方案

Kubernetes 系统中,用户是通过云端对边缘进行管控的(如应用部署,升级,扩缩容等),因此当边缘和云端网络断联时,边缘节点将不会从云端同步用户对节点的管控操作,因此断网期间,只要 YurtHub 保持本地缓存数据和断网时刻一致(即断网期间边缘缓存数据不更新),而网络恢复时,再从云端同步最新数据即可。

原文链接