对于云原生化改造，大部分传统企业可能还在初步摸索阶段，但围绕着Kubernetes的技术生态已经越来越丰富和完善，可应用的场景也逐渐增多。本文，InfoQ有幸采访了Rancher Labs联合创始人及CEO梁胜，探讨Rancher在云原生时代的技术思考。

云原生

2017 年末，Google 在过去十年编织全世界最先进的容器化基础设施经验，最终帮助 Kubernetes 项目取得关键领导地位，并将 CNCF 这个以“云原生”为关键词的组织和生态推向巅峰。根据 CNCF 的定义（V1.0），云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

通俗理解，所谓“云原生”，实际上就是在定义一条能够让应用最大程度利用云的能力、发挥云的价值的最佳路径。在这条路径上，脱离了“应用”这个载体，“云原生”就无从谈起；容器技术，则是将这个理念落地、将软件交付的革命持续进行下去的重要手段之一。

然而，即便如今的Kubernetes项目获得了如此多关注，但以此为基础的云原生整个生态体系还没有得到开发者的广泛青睐，梁胜在采访中表示，从概念上来说，云原生已经被广大开发者普遍接受，但总体而言，开发者对于技术的成熟度及稳定性仍存在信心不足等问题，还需要一段时间的发展以及推广。从今年的情况看来，KubeCon的参会者逐年累增，侧面反映了技术成长很快，关注的开发者也越来越多。

此外，技术的发展需要与应用场景相结合。梁胜表示，在大型互联网公司比如阿里，Kubernetes的应用已经非常普遍，大量云原生的场景给了Kubernetes用武之地，但传统企业的很多应用场景，没办法在短时间内基于Kubernetes进行重构，因此发展会相对缓慢。在这种情况下，即便整个云原生平台都准备就绪，但在应用重构之前，企业也无法真正体会到云原生平台的优势，对于传统企业而言更为尤甚。而目前的容器平台尚没有办法真正做到免运维，当应用场景扩展到家用电器甚至偏远地区的某个边缘节点，技术人员将难以对其进行把控。云厂商已尝试在这一方向上发力，通过大量的自动化工具提高整体效率，但目前看来依旧有很长的路要走。

Kubernetes

在容器的发展过程中，Kubernetes是一个非常重要的项目，它提出了一整套容器化设计模式和对应的控制模型，从而明确了如何真正以容器为核心构建能够真正跟开发者对接起来的应用交付和开发范式。

过往一年，也有很多围绕着Kubernetes展开的讨论，比如Kubernetes的复杂性问题等。尽管这个项目已经成长了五年，并取得了很好的发展，但大部分企业和开发者还是会在Kubernetes项目上花费大量精力。而从另一角度出发，即使如今CNCF的原生技术图谱已经十分庞大，在梁胜看来，暂时还没有哪个项目的重要程度可以与Kubernetes对等，在Kubernetes上可以做的事情还有很多。言外之意，对Kubernetes的技术探索在未来一段时间内还将持续进行下去。

梁胜表示，首先，Kubernetes在设计之初是一种大集群的概念，将所有机器都变成一个大集群来管理，这一理念来源于谷歌大规模集群管理器Borg，这样的设计思想让用户无需关注资源管理的问题，并且实现了跨多个数据中心的资源利用率最大化。随着Kubernetes技术的应用及发展，我们发现真正的企业用户，特别是基于云平台使用Kubernetes的用户，大部分都是多集群的状态，集群数量可以达到十几个甚至几百个，且大多分布在不同的地方，甚至使用不同的发行版和云平台。Rancher一直致力于解决生产环境中企业用户可能面临的基础设施不同的困境，改善Kubernetes原生UI易用性不佳以及学习曲线陡峭的问题。

其次，目前大部分企业对于Kubernetes的探索主要集中在云或者数据中心上，近两年，边缘节点上的Kubernetes也有了不同程度的进展，边缘计算有着非常多的、值得探索的应用场景，比如智慧城市中就包含着大量边缘计算的应用场景。这些边缘节点产生的数据同样需要收集处理，但由于部分边缘节点的位置比较偏僻而导致带宽不是很高，必须在本地处理数据，这也是Kubernetes值得关注和探索的一个重要方向。

最后，Kubernetes虽然已经发展得相对成熟，但在开发人员的推广上还存在一定问题，Kubernetes技术的复杂性问题大家均有目共睹，没有经历过专业培训的开发人员可能较难上手，这是需要持续优化迭代的地方。如今，Service Mesh、Istio等新技术的出现让Kubernetes生态得到了进一步扩充，这些都是值得花费精力探究的内容。

梁胜指出，有些应用场景比较适合进行容器化改造，比如无状态的应用、对可伸缩性要求比较高的应用和对快速迭代开发要求较高的应用。而其他的应用场景，如中台和前台的应用比较无状态并有伸缩性要求，后端应用实际上状态比较多，这些有状态应用在容器化方面的进展则比较缓慢。

边缘计算

随着5G的标准化工作越来越完善，边缘计算得到了长足的发展，这是很多企业都存在切实需求的一环。从Kubernetes的角度看，边缘计算是一个非常复杂的问题，但从Rancher的角度来讲，梁胜表示，Rancher定义下的边缘计算是一个非常小的计算中心和数据中心。传统的数据中心要么是云，要么是机房。对于部分企业客户而言，他们存在在地铁站、风力发电站、收银机等地方部署终端并进行数据分析计算的需求，如果统一在中央云节点进行计算，带宽需求比较高，网络和数据可靠性也将是很大的问题，在边缘节点直接进行计算是最为可靠便捷的计算方式。

因此，梁胜认为，边缘计算在未来存在很多发展机会。基于此，Rancher开源了轻量级Kubernetes发行版k3s和业界首个Kubernetes操作系统k3OS。k3s是一个轻量级的Kubernetes发行版，专为在资源有限的环境中运行Kubernetes的研发和运维人员设计，满足在边缘计算环境中运行在x86、ARM64和ARMv7处理器上的小型、易于管理的Kubernetes集群日益增长的需求；k3OS是业界首个专为Kubernetes而生的极轻量操作系统，资源消耗极低，操作极简，秒级启动，能大大简化在低资源计算环境中的Kubernetes操作，提高Kubernetes运维的安全性，全面赋能边缘计算场景，这是一对在边缘计算场景的完美搭档。

Rancher云原生实践

如果企业对云原生的概念表示认可，并希望可以进行云原生改造，就需要在技术选型上花费大量时间。在过去对于云原生技术的探索过程中，Rancher向开源社区贡献了轻量级的Kubernetes发行版k3S、基于Kubernetes的极简MicroPaaS平台Rio、业界首个Kubernetes操作系统k3OS、支持多个Kubernetes集群之间的跨集群网络连接项目Submariner和为Kubernetes集群提供分布式块存储的云原生解决方案Longhorn。

为了减少运行Kubernetes所需内存，k3s开发团队主要专注于以下四个方面的主要变化：

删除旧的、非必须的代码：K3s不包括任何默认禁用的Alpha功能或者过时的功能，原有的API组件目前仍运行于标准部署当中。除此之外，Rancher还删除了所有非默认许可控制器，in- tree云提供商和存储驱动程序，但允许用户添加任何他们需要的驱动程序。
整合正在运行的打包进程：为了节省RAM，k3s将通常在Kubernetes管理服务器上运行的多流程合并为单个流程。还将在工作节点上运行的kubelet、kubeproxy和flannel代理进程组合成一个进程。
使用containerd代替Docker作为运行时的容器引擎：通过用containderd替换Docker，k3s能够显著减少运行时占用空间，删除libnetwork、swarm、Docker存储驱动程序和其他插件等功能。
除了 etcd 之外，引入 SQLite 作为可选的数据存储：在k3s中添加了SQLite作为可选的数据存储，从而为etcd提供了一个轻量级的替代方案。该方案不仅占用了较少的内存，而且大幅简化了操作。

而在k3OS中，Kubernetes集群配置和底层的OS配置都使用同样的语法方式，这种方式类似Kubernetes中的CRD。如此一来，研发人员和运维人员将可以同时安装和升级k3s及底层操作系统。与此同时，k3OS还将让研发人员和运维人员能真正从“基础设施即代码（infrastructure-as-code）”模式当中受益，从而实现可靠的、可重复的集群部署。这种操作方法将大大简化管理员的使用体验，同时也让k3s在低配的计算环境中保持安全性。

“虽然Kubernetes可以安装在任何的Linux发行版上，但将Kubernetes与底层操作系统分开进行系统补丁或升级的话，操作会很复杂。系统服务中的错误配置或安全漏洞，可能会危及到整个Kubernetes集群。而k3OS的用户永远不必担心计划外的操作系统升级，只需一步即可将安全补丁应用于整个软件堆栈。”梁胜解释道：“作为Linux系统和Kubernetes发行版的组合，相较于业界所有Kubernetes安装，在k3OS上运行的k3s拥有最小的攻击面，以及最简单的升级过程。”

Rio则是Rancher今年发布的第三个全新的Kubernetes轻量级项目，由一些Kubernetes自定义资源、一个可选的CLI和一个集群中运行的控制器组成，在集群中运行Rio，与在集群中运行其他应用的方法及体验并没有什么不同。传统的PaaS平台，向用户承诺了一系列理想功能，从以往表现上看，PaaS平台一直难以为用户提供真正优质的使用体验，通常是重量级并难以运行的，在企业中需要有大型专用项目来部署它们，还需有专门的团队对其进行管理。PaaS用户经常发现平台有太多的规范和限制，它们可能适用于特定的工作流程，但这未必是开发人员所熟悉的工作流程。

Rio来自Rancher的一系列项目（k3s、k3OS），这些项目均专注于轻量级、简单且灵活的基于Kubernetes的项目。Rio的所有功能都经过专门设计，用户可以直接使用默认设置来快速运行和使用Rio，当然也可以根据实际需要来进行灵活的配置、替换或禁用。如果只想使用Rio当中的一个功能，可以只使用这一功能并忽略其余功能。总结来说，Rio是一个和Kubernetes生态系统紧密结合、并从中汲取了大量资源的平台。

这些项目的共同点在于保证稳定性的同时，还做到了极其轻量。

梁胜强调，在项目轻量级的情况下，安全性并非最关键的问题，Rancher解决的最大问题是运维难题。传统的技术开发流程对运维提出了较高要求，企业需要配备专门的团队负责实施，Kubernetes自身的复杂性也让很多互联网企业必须设置一个专门的团队做安全、可靠方面的工作，Rancher花费了大量的精力将系统运维简单化，并向无运维的方向靠拢，整体设计思想或者侧重点与传统的基于云、基于机房、基于数据中心的场景不大一样。

作为基于 Kubernetes 的开源企业级容器管理平台，Rancher 对于 CI/CD 管道解决方案也有自身的考量。对于用户而言，大部分企业用户或者互联网用户已经设好了 CI/CD 的管道，甚至有很大的 CI/CD 的平台。这也就意味着 Rancher 无需提供内置的 CI/CD 解决方案，用户在使用 Rancher 的过程中，可以直接调用 Kubernetes API 接口和自己的 CI/CD 管道或平台进行对接。

随着 Rancher 的使用不断普及，针对还没有构建自己的企业级 CI/CD 平台的用户，Rancher 构建了一个简单易用的 CI/CD 管道：Rancher pipeline。这套解决方案的最大特点是简单易用，用户无需从头开始使用其他工具设置 CI/CD 流水线。Rancher pipeline 在灵活性和功能上来说略为简单，但它可以使很多用户，特别是现在还没有 CI/CD 平台的用户，很快地享受到 CI/CD 的好处。

如果再往下走，RancherOS是用来运行Docker的量身定制的操作系统，就好像k3OS是运行Kubernetes的操作系统。

除此之外，围绕Kubernetes生态，Rancher打造了分布式块存储解决方案Longhorn，现已捐献给CNCF，该项目的主要功能是云原生存储。另一方面，Submariner是跨集群网络连接项目，目前也已被K8s社区接受。

总而言之，一直以来，Rancher都非常具有开源情怀。而云原生时代正需要大量有着开源精神的开发者积极参与社区共建，才有可能让整个生态取得更好的发展。

嘉宾简介：

梁胜，Rancher Labs 联合创始人及 CEO，是 Java 语言 J2SE 平台核心组件 JNI（Java Native Interface）的作者，领导设计和开发了 Java 语言最为核心的 JVM。2014 年 9 月，梁胜创立 Rancher Labs 并担任 CEO，为全球企业客户提供容器企业级落地的解决方案。截止目前，Rancher Labs 已获得三轮累计超过 4亿元人民币的融资，在全球拥有超过 25000 家知名企业客户。

创作场景

梁胜：Rancher 的 Kubernetes 思考及云原生实践