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

对于云原生化改造，大部分传统企业可能还在初步摸索阶段，但围绕着 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 家知名企业客户。