君子和而不同 — KENC边缘容器技术访谈

KENC边缘容器和集中容器、边缘主机有什么区别?

我们采访了以下几个人:

架构师——胖哥

胖哥是一个罕见的真·全栈工程师架构设计师,谈架构能说跪CTO,写Code能写服实习生,做review能调教老Coder。

KENC容器做产品设计的思想基石,主要是胖哥提炼出边缘和常规场景的IT架构本质区别,而这些区别是用户的技术决策人认可的。胖哥想跟各位工程师聊四点内容:

一、边缘计算并不属于C/S架构,而是创新的C-E-S架构。Edge的职能上更像在模拟Client的运行环境,但精英IT男都来自Server环境,因此Edge端是客户端的工作界限加上服务器的工作界面。

二、分布式系统必须跪诵CAP圣训,P(可分区性)是边缘计算的根基不容置疑。一般业务场景是放弃C(一致性)保住A(可用性),个别情况是放弃A(可用性)保证C(一致性)。

三、边缘计算是IT架构技术几十年不遇之大变革,这对实职架构师是最大的挑战,也是最广阔的沃土。架构技术几十年没变革了,我们终于看到了新大陆。只有研发去推进的边缘计算只能做成本压缩,架构师要推进边缘计算做业务创新。

四、我认可KENC提出的边缘架构五大设计原则,但我精简成了三条

a) Edge应用依赖计算和联网能力,但松耦合、轻逻辑甚至无状态。计算和联网是边缘应用的核心能力,这是不会有疑问的;边缘架构要覆盖成百上千个低标准IDC,做逻辑定就是锁死群集,做状态保持就是合理怠工,架构师要去做逻辑拆分和业务容错,这才有可能组合出提供商用SLA的网络服务。

b) 边缘应用从资源负载上有三个特点:“大公网IO” 、 “低延迟”、“高算力负载”。完美的边缘应用会匹配上述三个需求,也意味着旧的CS架构run不起来这些应用——比如云游戏。如果只满足两个需求的边缘应用,一般是旧业务迁移立刻就能展示出边缘应用的效果。如果是只满足一个资源需求的边缘应用,中心迁移到边缘的难度很大动力不足。

c) 边缘节点之间要彼此独立,应用内部也减少依赖,这样才能保持快速,但这也就无法保证实时一致性了,只能向最终状态一致做妥协。应用上边缘就是为了节省5-50ms的延迟,用CPU实时计算速度最快,读写复制内存也还行,同pod不同进程做监听就慢下来了,读写硬盘的速度就比5G慢了,和同节点不同pod的程序通讯有内网延迟,要访问远端应用就要靠非实时缓存来提速了。

研发总监——阿东

阿东是一个朝气蓬勃的Golang-er,他是个聪明勤奋的标准IT男,是容器团队的主心骨,乐观的表情总能兑现坚实的承诺。

阿东并不沉迷于造轮子的炫技,面对边缘容器开发需求,他更愿意学习通用技术和开源方案的精髓,他认为继承这些思想才是对前行者的尊重。

研发细则涉密太多,笔者将阿东的信息反复脱敏后,KENC边缘容器群集师承了如下技术

a) 对KVM、Container、Windows沙盒、LXC和Cgroup技术的深入研究,确认用容器做虚拟化载体,就足够支撑现阶段的Linux边缘应用了。

b) 对容器编排技术复习和拆解,移植到边缘场景并不是照抄,各种监听器、触发器和调度器要做轻巧简化和重载优化,还要和PM争执旧用法该继承还是改革。

c) 对各类开源容器管理平台进行代码审查和部署优化,阿东最终选择了自己主导的Wayne项目,不仅仅是代码更熟悉,更是看重其权限控制和多集群管理能力,并贴合边缘场景的管理需求进行二次开发。

如果只是“继承”,就容易变成“集成”,而只懂集成的研发团队都会同质化,所以金山云技术体系为KENC研发团队开放了功能宝库,让我们对边缘场景进行大量的功能延伸扩展。

a) 标准容器首推使用应用层LB接入,同层LB能轻便灵活的掌握业务;但KENC容器使用三层网关四层LB来接入用户,低层LB对上层应用不敏感,对未知应用层协议的支持会齐全很多;等到5G应用场景很明确了,KENC才会推出应用层LB。我们知道边缘计算的价值在公网传输,所以网关和LB的性能压测和稳定性,都是当做核心竞争力来研发测试的。

b) KENC容器绝不是要模拟成云主机,在边缘上移植云主机比全新上容器更简单,但客户在边缘用云主机是先易后难,我们选择的容器有接入成本,虽有先苦必能后甜。很多大客户能维护上万台服务器,但他们的经验来自“可靠核心机房”+“多团队协作”,只有CDN视频云有在几百个边缘节点上跑着上千个进程的经验,而大客户的创新团队是很难协调其他团队做边缘化改造,5G和边缘创新团队就更缺乏系统和网络的技术支持了。KENC提供的不是容器,而是基于容器的抽象管理平台。

c) 研发团队认同架构师的判断,边缘容器更像是在模拟客户端而非服务器端。所以边缘容器对应用的支持很灵活,应用程序要监听什么端口、要主动出网访问都可以支持;但存储配置是向家用电脑看齐的,KENC存储没必要像服务器存储那么重,但也将存储的生命周期和算力解耦。今年晚些时候,我们的GPU容器会上线,不同内核版本的容器会分池,Windows容器和Kata容器的支持都会越来越好。

运维总监——大鹏

大鹏是个典型的万能运维、合格的SRE、两手都硬的DevOPS。他很少和研发争执,什么系统都能维护好;但经常和产品甚至客户掰扯,因为他发现边缘计算的性能指标不好做。

KENC照抄CDN的性能要求太高,因为CDN能应用层容错;而照抄云主机的性能要求太低,因为核心云服务重点保证一致性。大鹏将边缘容器的性能分为五大要素:

a) 计算和存储性能: CPU内存的虚拟化开销,正常损耗就不能超过5%;CPU适度超分但要小心转码应用,绝对不搞内存超分;GPU和RISC-V以透传为主;引入潮汐应用和自用小碎容器填充空闲资源。

b) 内网性能: 胖哥在架构分析时,希望边缘应用减少不同pod的业务通讯,但KENC的内网性能仍然很重要。Pod到网关、LB、PaaS都要走SDN内网,其延迟必须控制在0.5ms以内,其每秒包量也要能满足正常业务、隔离syn-flood。

c) 存储性能: 容器存储是个难题,没有驱动也没有文件系统支持,一个进程和一个文件夹之间很难做性能描述;好在客户多硬盘也多,大鹏哥的监控铁军比任何软件优化都灵敏。

d) 公网连通性: 边缘计算都是单线和三线机房,其公网联通性考核不能像BGP机房那样严格,甚至不同区域的单线机房网络环境都不一样,这些信息都要及时同步给客户。

e) 单点和整体可用性: KENC运维经常和客户进行边缘平台的可用性评估,这一个要结合用户场景需求无法标准化的工作。用户工程师需要找个可以对等沟通的工程师,对边缘系统的单点和整体可用性进行冗余规划和监控容错。

KENC团队里没有庸人,我们也在快速成长,大家都会成长成阿东、大鹏甚至胖哥。我们带着诚意带着热情做出来KENC容器,希望它能够帮客户实现边缘应用的新突破

欢迎关注我们的微信公众号,每天学习Go知识

君子和而不同 -- KENC边缘容器技术访谈

原文 

https://studygolang.com/articles/28656

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 君子和而不同 — KENC边缘容器技术访谈

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址