转载

君子和而不同 -- 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知识