开发和实施云原生（容器优先）软件的检查清单。

许多年来，单体应用是实现业务需求的标准企业架构。但是，当云基础设施开始以规模和速度为业务加速，这种情况就发生了重大变化。应用架构也发生了转变，以适应云原生应用和 微服务、无服务器 以及事件驱动的服务，这些服务运行在跨混合云和多云平台的不可变的基础设施上。

云原生与 Kubernetes 的联系

根据 云原生计算基金会 （CNCF） 的说法：

“云原生技术使企业能够在现代动态环境中建立和运行可扩展的应用，如公共云、私有云和混合云。容器、服务网格、微服务、不可变的基础设施和声明式 API 就是这种方法的典范。”

“这些技术使松散耦合的系统具有弹性、可管理和可观察性。与强大的自动化相结合，它们使工程师能够以最小的工作量频繁地、可预测地进行重要的改变。”

像 Kubernetes 这样的容器编排平台允许 DevOps 团队建立不可变的基础设施，以开发、部署和管理应用服务。现在，快速迭代的速度与业务需求相一致。构建容器以在 Kubernetes 中运行的开发人员需要一个有效的地方来完成。

云原生软件的要求

创建云原生应用架构需要哪些能力，开发人员将从中获得哪些好处？

虽然构建和架构云原生应用的方法有很多，但以下是一些需要考虑的部分：

• 运行时： 它们更多是以容器优先或/和 Kubernetes 原生语言编写的，这意味着运行时会如 Java、Node.js、Go、Python 和 Ruby。
• 安全： 在多云或混合云应用环境中部署和维护应用时，安全是最重要的，应该是环境的一部分。
• 可观察性： 使用 Prometheus、Grafana 和 Kiali 等工具，这些工具可以通过提供实时指标和有关应用在云中的使用和行为的更多信息来增强可观察性。
• 效率： 专注于极小的内存占用、更小的构件大小和快速启动时间，使应用可跨混合/多云平台移植。
• 互操作性： 将云原生应用与能够满足上述要求的开源技术相结合，包括 Infinispan、MicroProfile、Hibernate、Kafka、Jaeger、Prometheus 等，以构建标准运行时架构。
• DevOps/DevSecOps： 这些方法论是为持续部署到生产而设计的，与最小可行产品 （MVP） 一致，并将安全作为工具的一部分。

让云原生具体化

云原生似乎是一个抽象的术语，但回顾一下定义并像开发人员一样思考可以使其更加具体。为了使云原生应用获得成功，它们需要包括一长串定义明确的组成清单。

你是如何规划云原生应用的设计的？在评论中分享你的想法。

via: https://opensource.com/article/20/1/cloud-native-software

作者：Daniel Oh 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

在微服务环境中，服务网格为开发和运营提供了好处。

很多开发者不知道为什么要关心 服务网格 Service Mesh 。这是我在开发者见面会、会议和实践研讨会上关于云原生架构的微服务开发的演讲中经常被问到的问题。我的回答总是一样的：“只要你想简化你的微服务架构，它就应该运行在 Kubernetes 上。”

关于简化，你可能也想知道，为什么分布式微服务必须设计得如此复杂才能在 Kubernetes 集群上运行。正如本文所解释的那样，许多开发人员通过服务网格解决了微服务架构的复杂性，并通过在生产中采用服务网格获得了额外的好处。

什么是服务网格？

服务网格是一个专门的基础设施层，用于提供一个透明的、独立于代码的 （polyglot） 方式，以消除应用代码中的非功能性微服务能力。

为什么服务网格对开发者很重要

当开发人员将微服务部署到云时，无论业务功能如何，他们都必须解决非功能性微服务功能，以避免级联故障。这些功能通常可以体现在服务发现、日志、监控、 韧性 resiliency 、认证、 弹性 elasticity 和跟踪等方面。开发人员必须花费更多的时间将它们添加到每个微服务中，而不是开发实际的业务逻辑，这使得微服务变得沉重而复杂。

随着企业加速向云计算转移，服务网格 可以提高开发人员的生产力。Kubernetes 加服务网格平台不需要让服务负责处理这些复杂的问题，也不需要在每个服务中添加更多的代码来处理云原生的问题，而是负责向运行在该平台上的任何应用（现有的或新的，用任何编程语言或框架）提供这些服务。那么微服务就可以轻量级，专注于其业务逻辑，而不是云原生的复杂性。

为什么服务网格对运维很重要

这并没有回答为什么运维团队需要关心在 Kubernetes 上运行云原生微服务的服务网格。因为运维团队必须确保在 Kubernetes 环境上的大型混合云和多云上部署新的云原生应用的强大安全性、合规性和可观察性。

服务网格由一个用于管理代理路由流量的控制平面和一个用于注入 边车 Sidecar 的数据平面组成。边车允许运维团队做一些比如添加第三方安全工具和追踪所有服务通信中的流量，以避免安全漏洞或合规问题。服务网格还可以通过在图形面板上可视化地跟踪指标来提高观察能力。

如何开始使用服务网格

对于开发者和运维人员，以及从应用开发到平台运维来说，服务网格可以更有效地管理云原生功能。

你可能想知道从哪里开始采用服务网格来配合你的微服务应用和架构。幸运的是，有许多开源的服务网格项目。许多云服务提供商也在他们的 Kubernetes 平台中提供 服务网格。

你可以在 CNCF Service Mesh Landscape 页面中找到最受欢迎的服务网格项目和服务的链接。

via: https://opensource.com/article/21/3/service-mesh

作者：Daniel Oh 选题：lujun9972 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

云原生时代的华为，不但打造了迅猛发展的云服务业务，也为自己的云服务打造了新“引擎”。

云原生时代的容器引擎的变化

随着“云原生”逐渐从一个流行词变成了一个不那么新鲜的技术基座。以 Kubernetes 为代表的容器编排技术、以 Docker、Containerd 占据主要份额的容器引擎，云原生技术也在不断的迭代升级中日益发展成熟。

据 Sysdig 2019 年的容器使用报告统计，全球整体容器市场规模以高达 30% 的速度增长，容器的规模、密度愈加扩大。在企业内部的容器规模方面，9% 的企业用户容器规模已经达到 5000 以上；在容器密度方面，与 2018 年相比，每台主机中的容器密度提高了 100%，从 15 个增加到了 30 个，其中最大节点密度已经达到 250 个。

而在这一切的背后，容器技术在某些场景中也呈现了一些不足，比如：

• 在资源敏感环境，或需要部署高密度容器节点时，容器对基础设施的资源占用会急剧升高；
• 当大规模应用拉起或遇到突发流量时，并发速度可能成为了瓶颈。

因此，主流的 Docker 等容器引擎在特定用例下，看起来有一些力不从心，因此一些针对某种用例进行过专门优化的容器引擎技术这些年纷纷入场。比如说，以 Kata Container 为代表的专门针对容器隔离性不够严格而设计的安全容器技术；以 Container Linux 为代表的专门针对重型应用而设计的系统容器；以 iSula 为代表的专门针对资源受限的边缘计算和 IoT 环境设计的轻量级容器技术。

这里，让我们来看一个源自于摄像头场景中的轻量级容器引擎。

来自摄像头的容器引擎

说起来你可能不信，一个摄像头里面居然还能有容器引擎。

起初，华为为了在智能摄像头上达到快速、简单切换算法应用部署的功能，经过技术研究，他们决定使用容器来实现所需的功能。

一开始，技术团队考虑对开源容器引擎 Docker 进行轻量化改造，对其裁剪和精简化、去除不需要的功能、优化组件结构等，甚至还对 Go 语言环境的编译进行了优化。但是，由于要运行在端侧的嵌入式设备上，这种裁剪和压榨资源的做法所能取得的效果有限。

在这种情况下，针对端侧和 IoT 环境，华为的 iSula 容器团队做了一个大胆的决定，使用 C/C++ 来量身打造一套轻量级的容器引擎！这真是一个大胆而充满勇气的决定。要知道，随着容器技术时代被 Docker 的出现而引爆，开发 Docker 所使用的 Go 语言就成为容器技术领域的首选，几乎所有的容器技术的组件和框架，都是采用 Go 语言开发的。而要使用 C/C++ 语言全新开发一个容器引擎，面临着所有基础组件，甚至一些开发语言缺乏的特性都需要另行解决。比如说，在 C 语言中要解析容器技术中普遍使用 JSON 数据，而 C 语言并没有 Go 语言等现代编程语言内置的反射机制，这就需要自行实现一个合理的 JSON 数据解析引擎。

2017 年，iSula 容器团队开始了重新开发一个容器引擎的计划。

旁白：iSula 是中南美洲亚马逊丛林中的一种非常强大的蚂蚁，被称为“子弹蚁”，因为被它咬一口，犹如被子弹打到那般疼痛，它是世界上最强大的昆虫之一。

所幸的是，虽然拦路虎众多，但是这些付出是有丰厚回报的，采用 C/C++ 开发的容器引擎，也因此具有了 Docker 所不具有的一些优势。相比 Golang 编写的 Docker，使用 C/C++ 实现的 iSula 容器引擎，具有轻、灵、巧、快等特点，不受硬件规格和架构的限制，底噪开销更小，可应用领域更为广泛。在严苛的资源要求环境下，轻量模式下的 iSulad 本身占用资源极低（< 15M），再结合上特殊的轻量化镜像，可以达成极致的资源占用效果。

2018 年，iSula 开始在华为内部的部分产品上使用。2019 年，华为决定将 iSula 开源出来，让开源社区和 iSula 共同发展，因此针对 CRI 接口进行了一次大范围的重构和补全后，与 openEuler 操作系统一并开源发布。

新造的轮子野心大

以 2019 年的统计数据看，容器引擎领域中，Docker 占据了 80% 左右的份额，但是随着 Docker 引擎自身的发展不明朗，以及容器引擎规范的标准化，出现了更多的容器引擎竞争者。这其中，iSula 作为一个悄悄发展了 3 年的轻量级容器引擎，已经迭代到了 2.0 版本，并凭借其“轻快易灵”的优势，逐渐显露出了更大的“野心”。

在智能摄像头资源的端侧大显身手之后，iSula 容器团队决定将它更进一步。得益于 iSula 所打下的良好基础，iSula 团队认为这个引擎具备更大的潜力，可以发展为通用的端、边、云平台一体的容器引擎，提供统一的架构设计来满足云、IoT、边缘计算等多个场景的应用。

虽然由于发展时间较短，加之其起源于端侧场景，目前 iSula 还没有大规模地应用在云计算集群方面，但是从与 iSula 团队沟通了解到，他们对下一步将其推广至更广泛的云计算集群领域充满信心。按照他们的说法，鉴于华为优质的软件开发质量品控，以及社区对 iSula 特有优势的青睐，它的发展值得期许。

当然，事物总是具有两面性，iSula 在取得“轻快易灵”的独特优势的同时，其使用 C/C++ 作为开发语言，也对 iSula 的快速发展带来了一些影响。因为我们知道，合格甚至优秀的 C/C++ 程序员是有多么的难得，这也造成了 iSula 项目开源后，社区贡献者数量和参与的贡献难以取得大的突破。

鉴于此，据 iSula 团队内部消息，他们正在计划将 iSula 逐渐迁移到 Rust 语言来实现，目前已经有部分模块采用 Rust 开发。Rust 作为近些年来一个明星级的系统编程语言，已经在系统编程语言方面显露出来取代 C/C++ 的潜力。如果能够顺利地平滑过渡到 Rust 语言，想必对 iSula 的开发进展、软件质量和社区参与程度，有着积极的作用。

何以轻快易灵？

iSula 是全量的容器软件栈，包括了引擎、网络、存储、工具集与容器操作系统；而 iSulad 作为其中轻量化的容器引擎，可以为多种场景提供灵活、稳定、安全的底层支撑。

根据 iSulad 的设计目标和实现情况，它具有轻、快、易、灵等优势。

iSulad 之轻

iSulad 的第一个使用场景是在端侧设备上，这自然要求这个容器引擎具有轻量级资源占用的特性。再结合为端侧设备特殊定制的轻量化镜像，它可以达成极致的资源占用的效果。

除了在端侧环境，在通用场景下，iSulad 也具有不错的轻量化表现。利用轻量化的 LXC 运行时以及极其轻量的 monitor 进程，这简化了整个调用链路。

iSulad 之快

顺理成章的，采用 C/C++ 语言实现的 iSulad，自然具备运行速度快、底噪低等特性。再加上 iSulad 独特的架构设计，除了启动容器部分需要通过 fork/exec 的方式，其他部分均使用调用函数库的方式加快执行速度。

iSulad 之易

在对 CRI 接口进行了大范围的重构和补全后，iSulad 已经能在相当程度上兼容标准化的容器规范和工具，让使用者的使用习惯和应用迁移变得轻松。

为了使开发者迁移方便，iSulad 在开发一系列迁移工具，以帮助开发者将自己的应用平滑迁移到 iSulad 上来。甚至据透露，iSulad 还会支持热迁移，能更便捷的迁移开发者的应用。

iSulad 之灵

iSulad 还针对不同的使用场景提供了不同的模式，可以根据需要灵活配置切换注重性能的性能模式和注重资源占用的轻模式。

另外，作为一个具有支持全场景容器环境的引擎，iSulad 也支持了多种不同的容器形态，它内置了支持系统容器、安全容器和普通容器以及轻量化容器的支持。

iSula 和 openEuler

iSula 是华为的 openEuler 开源社区旗下的项目之一，因此这个项目也是根植于 openEuler 系统的。这对于推动 openEuler 在企业级应用的发展具有积极意义。

不过，作为一个野心勃勃的容器引擎来说，必然不会将自己局限在某个特定操作系统之上。根据 iSula 团队的信息，目前 iSula 在 openEuler 系统上具有一些独特的优势，但是该团队也在做将 iSula 向其它 Linux 系统迁移的工作，这涉及到内核的一些特殊特性和补丁，需要得到 Linux 主线内核的支持和与内核开发者社区的沟通。

推动云原生的新引擎

毋庸置疑，容器计算已经成为云计算领域的主流。无论你是否愿意，考虑将企业的传统计算环境和古典虚拟机环境迁移到以容器计算为代表的现代云计算平台，已经是大部分 CTO 和架构师们需要迫切考虑的工作了。

而华为开源的 iSula 容器引擎，相比 Docker，是一种新的容器解决方案，它提供了统一的架构设计来满足 CT 和 IT 领域的不同需求。这匹崭露头角的新黑马，是华为攻略云原生领域的新引擎之一。

无需去历数华为在云原生领域做了多少事情，这个崭露头角的 iSula 容器引擎只是华为云这辆快车上的一枚新引擎，它将会同其它开源组件将华为云带到什么高度，让我们拭目以待。

每周关注开源社区和行业趋势。

我在一家采用开源软件开发模型的企业软件公司任高级产品营销经理，我的一部分职责是为产品营销人员、经理和其他相关人定期发布有关开源社区、市场和业界发展趋势的更新。以下是该更新中我和他们最喜欢的几篇文章。

《随着云原生计算的兴起，它和代码一样在改变文化》

• 文章链接

现在是围绕一套云原生计算的共同原则进行行业整合的时候了，因为许多企业已经意识到，他们最初进入云计算的回报有限。国际数据公司去年的一项调查发现，80% 的受访者曾将工作负载从公有云环境遣返到企业内部，平均而言，他们预计在未来两年内将一半的公有云应用转移到私有场所。

分析：在云端的第一次运行主要是大量的“提升和转移”尝试，以提取工作负载并将其投放到云端。第二次运行将涉及更多的工作，以确定转移什么以及如何转移，但随着开发人员对理所当然的事情越来越满意，最终应该会带来更多价值。

《为什么云原生基础设施的自动化是所有参与者的胜利》

• 文章链接

开发的圣杯是创建和维护安全的应用程序，产生强大的投资回报率和满意的客户。但如果这种开发不是高效、高速和可扩展的，那么这个圣杯很快就会变得遥不可及。如果你发现自己对当前的基础设施有更高的期望，那么可能是时候考虑云原生了。它不仅可以检查所有这些机器，而且为云原生基础设施进行自动化可以提高效率和结果。

分析：我还要补充一点，如果没有大量的自动化，真正采用云原生方法是不可能的；涉及的移动部件数量太多，不可能用人的头脑来处理。

《Linkerd 案例研究：满足安全要求、减少延迟和从 Istio 迁移》

• 文章链接

最后，Subspace 分享了其使用 Linkerd 提供“光速”多人游戏的经验。虽然在超低延迟环境中使用服务网状物起初似乎有悖常理，但 Subspace 发现 Linkerd 的战略使用实际上降低了总延迟 —— 服务网状物是如此轻巧，以至于它增加的最小延迟被它通过可观察性降低的延迟所掩盖。简而言之，Linkerd 的这一独特用例使 Subspace 在运营结果上获得了巨大的净收益。阅读完整的用户故事。

分析：我听说过这样一个观点：你并不能真正降低一个系统的复杂性，你只是把它抽象化，改变它的接触对象。似乎对延迟也有类似的观察：如果你仔细选择你接受延迟的地方，你可以因此减少系统中其他地方的延迟。

一位高层管理人员解释了 IBM 的“重要支点”，以赢得开发者、初创企业和合作伙伴的青睐，这是其从微软等竞争对手手中赢得混合云市场计划的一部分

• 文章链接

蓝色巨人正在转向一个新的战略，专注于建立一个由开发者、合作伙伴和初创公司组成的生态系统。“我们的服务组织无法接触到所有客户。获取这些客户的唯一方法是激活一个生态系统。”

分析：越来越多的公司开始接受这样的理念：有些客户的问题，他们没有帮助就无法解决。也许这可以减少从每个单独客户身上赚到的钱，因为它扩大了更广泛地参与更多问题空间的机会。

希望你喜欢这个列表，下周再见。

via: https://opensource.com/article/20/7/cloud-native-expanding-and-more-industry-trends

作者：Tim Hildred 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

工作中用了容器？熟悉这些出自云原生计算基金会的项目吗？

随着用容器来开发应用的实践变得流行，云原生应用也在增长。云原生应用的定义为：

“云原生技术用于开发使用打包在容器中的服务所构建的应用程序，以微服务的形式部署，并通过敏捷的 DevOps 流程和持续交付工作流在弹性基础设施上进行管理。”

这个定义提到了构成云原生应用的不可或缺的四个元素：

1. 容器
2. 微服务
3. DevOps
4. 持续集成和持续交付 (CI/CD)

尽管这些技术各有各自独特的历史，但它们之间却相辅相成，在短时间内实现了云原生应用和工具的惊人的指数级增长。这个云原生计算基金会（CNCF）信息图呈现了当今云原生应用生态的规模和广度。

云原生计算基金会项目

我想说，瞧着吧！这仅仅是一个开始。正如 NodeJS 的出现引发了无数的 JavaScript 工具的爆炸式增长一样，容器技术的普及也推动了云原生应用的指数增长。

好消息是，有几个组织负责监管并将这些技术连接在一起。 其中之一是 开放容器倡议 Open Containers Initiative （OCI），它是一个轻量级的、开放的治理机构（或项目），“它是在 Linux 基金会的支持下形成的，其明确目的是创建开放的行业标准的容器格式和运行时。” 另一个是 CNCF，它是“一个致力于使云原生计算普及和可持续发展的开源软件基金会”。

通常除了围绕云原生应用建立社区之外，CNCF 还帮助项目围绕其云原生应用建立结构化管理。CNCF 创建了成熟等级的概念（沙箱级、孵化级或毕业级），分别与下图中的“创新者”、“早期采用者”和“早期大量应用”相对应。

CNCF 项目成熟等级

CNCF 为每个成熟等级制定了详细的标准（为方便读者而列在下面）。获得技术监督委员会（TOC）三分之二的同意才能转为孵化或毕业级。

沙箱级

要想成为沙箱级，一个项目必须至少有两个 TOC 赞助商。 有关详细过程，请参见《CNCF 沙箱指南 v1.0》。

孵化级

注：孵化级是我们期望对项目进行全面的尽职调查的起点。

要进入孵化级，项目除了满足沙箱级的要求之外还要满足：

• 证明至少有三个独立的最终用户已成功将其用于生产，且 TOC 判断这些最终用户具有足够的质量和范围。
• 提交者的数量要合理。提交者定义为具有提交权的人，即可以接受部分或全部项目贡献的人。
• 显示出有大量持续提交和合并贡献。
• 由于这些指标可能会根据项目的类型、范围和大小而有很大差异，所以 TOC 有权决定是否满足这些标准的活动水平。

毕业级

要从沙箱或孵化级毕业，或者要使一个新项目作为已毕业项目加入，项目除了必须满足孵化级的标准外还要满足：

• 至少有两个来自组织的提交者。
• 已获得并保持了“核心基础设施计划最佳实践徽章”。
• 已完成独立的第三方安全审核，并发布了具有与以下示例类似的范围和质量的结果（包括已解决的关键漏洞）：https://github.com/envoyproxy/envoy#security-audit，并在毕业之前需要解决所有关键的漏洞。
• 采用《CNCF 行为准则》。
• 明确规定项目治理和提交流程。最好将其列在 GOVERNANCE.md 文件中，并引用显示当前提交者和荣誉提交者的 OWNERS.md 文件。
• 至少有一个主仓的项目采用者的公开列表（例如，ADOPTERS.md 或项目网站上的徽标）。
• 获得 TOC 的绝大多数票，进入毕业阶段。如果项目能够表现出足够的成熟度，则可以尝试直接从沙箱级过渡到毕业级。项目可以无限期保持孵化状态，但是通常预计它们会在两年内毕业。

值得关注的 9 个项目

本文不可能涵盖所有的 CNCF 项目，我将介绍最有趣的 9 个毕业和孵化的开源项目。

我也创建了视频材料来介绍这些项目。

毕业项目

毕业的项目被认为是成熟的，已被许多组织采用的，并且严格遵守了 CNCF 的准则。以下是三个最受欢迎的开源 CNCF 毕业项目。（请注意，其中一些描述来源于项目的网站并被做了改编。）

Kubernetes（希腊语“舵手”）

Kubernetes! 说起云原生应用，怎么能不提 Kubernetes 呢？ Google 发明的 Kubernetes 无疑是最著名的基于容器的应用程序的容器编排平台，而且它还是一个开源工具。

什么是容器编排平台？通常，一个容器引擎本身可以管理几个容器。但是，当你谈论数千个容器和数百个服务时，管理这些容器变得非常复杂。这就是容器编排引擎的用武之地。容器编排引擎通过自动化容器的部署、管理、网络和可用性来帮助管理大量的容器。

Docker Swarm 和 Mesosphere Marathon 也是容器编排引擎，但是可以肯定地说，Kubernetes 已经赢得了这场比赛（至少现在是这样）。Kubernetes 还催生了像 OKD 这样的容器即服务（CaaS）平台，它是 Kubernetes 的 Origin 社区发行版，并成了 Red Hat OpenShift 的一部分。

想开始学习，请访问 Kubernetes GitHub 仓库，并从 Kubernetes 文档页面访问其文档和学习资源。

Prometheus（普罗米修斯）

Prometheus 是 2012 年在 SoundCloud 上构建的一个开源的系统监控和告警工具。之后，许多公司和组织都采用了 Prometheus，并且该项目拥有非常活跃的开发者和用户群体。现在，它已经成为一个独立的开源项目，独立于公司之外进行维护。

Prometheus 的架构

理解 Prometheus 的最简单方法是可视化一个生产系统，该系统需要 24（小时）x 365（天）都可以正常运行。没有哪个系统是完美的，也有减少故障的技术（称为容错系统），但是，如果出现问题，最重要的是尽快发现问题。这就是像 Prometheus 这样的监控工具的用武之地。Prometheus 不仅仅是一个容器监控工具，但它在云原生应用公司中最受欢迎。此外，其他开源监视工具，包括 Grafana，都借助了 Prometheus。

开始使用 Prometheus 的最佳方法是下载其 GitHub 仓库。在本地运行 Prometheus 很容易，但是你需要安装一个容器引擎。你可以在 Prometheus 网站上查看详细的文档。

Envoy（使者）

Envoy（或 Envoy 代理）是专为云原生应用设计的开源的边缘代理和服务代理。由 Lyft 创建的 Envoy 是为单一服务和应用而设计的高性能的 C++ 开发的分布式代理，同时也是为由大量微服务组成的服务网格架构而设计的通信总线和通用数据平面。Envoy 建立在 Nginx、HAProxy、硬件负载均衡器和云负载均衡器等解决方案的基础上，Envoy 与每个应用相伴（并行）运行，并通过提供平台无关的方式提供通用特性来抽象网络。

当基础设施中的所有服务流量都经过 Envoy 网格时，很容易就可以通过一致的可观测性来可视化问题域，调整整体性能，并在单个位置添加基础功能。基本上，Envoy 代理是一个可帮助组织为生产环境构建容错系统的服务网格工具。

服务网格应用有很多替代方案，例如 Uber 的 Linkerd（下面会讨论）和 Istio。Istio 通过将其部署为 Sidecar 并利用了 Mixer 的配置模型，实现了对 Envoy 的扩展。Envoy 的显著特性有：

• 包括所有的“ 入场筹码 table stakes （LCTT 译注：引申为基础必备特性）”特性（与 Istio 这样的控制平面组合时）
• 带载运行时 99% 数据可达到低延时
• 可以作为核心的 L3/L4 过滤器，提供了开箱即用的 L7 过滤器
• 支持 gRPC 和 HTTP/2（上行/下行）
• 由 API 驱动，并支持动态配置和热重载
• 重点关注指标收集、跟踪和整体可监测性

要想了解 Envoy，证实其能力并实现其全部优势，需要丰富的生产级环境运行的经验。你可以在其详细文档或访问其 GitHub 仓库了解更多信息。

孵化项目

下面是六个最流行的开源的 CNCF 孵化项目。

rkt（火箭）

rkt, 读作“rocket”，是一个 Pod 原生的容器引擎。它有一个命令行接口用来在 Linux 上运行容器。从某种意义上讲，它和其他容器如 Podman、Docker 和 CRI-O 相似。

rkt 最初是由 CoreOS （后来被 Red Hat 收购）开发的，你可以在其网站上找到详细的文档，以及在 GitHub 上访问其源代码。

Jaeger（贼鸥）

Jaeger 是一个开源的端到端的分布式追踪系统，适用于云端应用。在某种程度上，它是像 Prometheus 这样的监控解决方案。但它有所不同，因为其使用场景有所扩展：

• 分布式事务监控
• 性能和延时优化
• 根因分析
• 服务依赖性分析
• 分布式上下文传播

Jaeger 是一项 Uber 打造的开源技术。你可以在其网站上找到详细文档，以及在 GitHub 上找到其源码。

Linkerd

像创建 Envoy 代理的 Lyft 一样，Uber 开发了 Linkerd 开源解决方案用于生产级的服务维护。在某些方面，Linkerd 就像 Envoy 一样，因为两者都是服务网格工具，旨在提供平台级的可观测性、可靠性和安全性，而无需进行配置或代码更改。

但是，两者之间存在一些细微的差异。 尽管 Envoy 和 Linkerd 充当代理并可以通过所连接的服务进行上报，但是 Envoy 并不像 Linkerd 那样被设计为 Kubernetes Ingress 控制器。Linkerd 的显著特点包括：

• 支持多种平台（Docker、Kubernetes、DC/OS、Amazon ECS 或任何独立的机器）
• 内置服务发现抽象，可以将多个系统联合在一起
• 支持 gRPC、HTTP/2 和 HTTP/1.x请 求和所有的 TCP 流量

你可以在 Linkerd 网站上阅读有关它的更多信息，并在 GitHub 上访问其源码。

Helm（舵轮）

Helm 基本上就是 Kubernetes 的包管理器。如果你使用过 Apache Maven、Maven Nexus 或类似的服务，你就会理解 Helm 的作用。Helm 可帮助你管理 Kubernetes 应用程序。它使用“Helm Chart”来定义、安装和升级最复杂的 Kubernetes 应用程序。Helm 并不是实现此功能的唯一方法；另一个流行的概念是 Kubernetes Operators，它被 Red Hat OpenShift 4 所使用。

你可以按照其文档中的快速开始指南或 GitHub 指南来试用 Helm。

Etcd

Etcd 是一个分布式的、可靠的键值存储，用于存储分布式系统中最关键的数据。其主要特性有：

• 定义明确的、面向用户的 API（gRPC）
• 自动 TLS，可选的客户端证书验证
• 速度（可达每秒 10,000 次写入）
• 可靠性（使用 Raft 实现分布式）

Etcd 是 Kubernetes 和许多其他技术的默认的内置数据存储方案。也就是说，它很少独立运行或作为单独的服务运行；相反，它以集成到 Kubernetes、OKD/OpenShift 或其他服务中的形式来运作。还有一个 etcd Operator 可以用来管理其生命周期并解锁其 API 管理功能：

你可以在 etcd 文档中了解更多信息，并在 GitHub上访问其源码。

CRI-O

CRI-O 是 Kubernetes 运行时接口的 OCI 兼容实现。CRI-O 用于各种功能，包括：

• 使用 runc（或遵从 OCI 运行时规范的任何实现）和 OCI 运行时工具运行
• 使用容器/镜像进行镜像管理
• 使用容器/存储来存储和管理镜像层
• 通过容器网络接口（CNI）来提供网络支持

CRI-O 提供了大量的文档，包括指南、教程、文章，甚至播客，你还可以访问其 GitHub 页面。

我错过了其他有趣且开源的云原生项目吗？请在评论中提醒我。

via: https://opensource.com/article/19/8/cloud-native-projects

作者：Bryant Son 选题：lujun9972 译者：messon007 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

云原生 （ Cloud Native ） 绝对算的上是热词一个，但是，对于绝大多数的企业，甚至是绝大多数的互联网企业来说，却从来没有动手实践过云原生。无他，现在的云原生实践成本太高。

企业面临的云原生困境

云原生很好，弹性拓展、容错性好、易于管理、便于观察，但是，云原生的优势对应的是其高昂的实现和落地成本。对于绝大多数企业来说，想要在自己的企业中应用云原生绝非我们说的那么简单。云原生整个生态中包含了大量的软件设备、硬件基础设施、开发运维成本等，对于绝大多数的企业来说，绝非易事。

对于不少企业来说，其核心是自己的业务逻辑，而非处理容器编排、自动化测试、微服务等，企业的需求只是让自己的业务可以更加的平稳、高性能的运转，服务好自己的客户，解决客户的问题，赚取收益。

对于这些企业来说，他们希望能够被云原生赋能，但又无法支撑起高昂的落地费用和维护成本，毕竟，看起来云原生所使用的各种组件都已经开源，企业都可以免费使用，但免费使用不意味着好用。作为云原生容器编排的首选工具，Kubernetes 的学习成本很高且安装部署极为复杂，更不用说云原生还需要配合各种组件搭配使用，还要和网络、存储等基础设施配合使用，学习成本，使用成本极高。

对于企业来说，亟需一款能够帮助他们解决云原生基础部署和配置的产品，帮助他们抹平云原生落地场景下所需的各项应用，打通网络、存储等基础设施，让云原生变得开箱即用。

QKE —— 极简的云原生方案

青云QingCloud很早就感知了这个问题，并在 2018 年开发了 KubeSphere ，解决了云原生组件落地的使用和管理问题，让更多的开发者从学习 Kubernetes 的命令中解脱出来，借助 KubeSphere 的 GUI 来完成各项管理控制操作。

为了帮助企业快速稳定地落地云原生，青云又推出了 QKE （QingCloud KubeSphere Engine） 服务，是在青云QingCloud公有云上提供的 KubeSphere 容器服务，整合了来自青云公有云的计算、网络、存储资源，彻底抹平云原生落地的成本。

QKE 是基于青云QingCloud 数年的基础设施研发经验而来的，青云有自己的网络产品、存储产品，在 SDN 、存储方面有着大规模云平台经验和应用，可以很好的解决企业所需要的弹性拓展等问题。 QKE 基于 KubeSphere 提供的 Kubernetes 的标准接口，对接了青云的各项基础设施，可以让企业可以更加轻松的完成基础设施的调用和配置，为开发者屏蔽掉底层的基础设施、运维问题，更加专注于应用本身的日常开发、运维等工作。

同时，由于 QKE 是基于 KubeSphere 提供的，QKE 也支持了构建多云和混合云环境，只需要简单的配置，就可以将公有云中的 QKE 和部署在客户私有云或其他云环境的 KubeSphere 整合在一起，轻松的构建一整套高可用、高性能的云原生应用架构。

如何在 10 分钟内构建云原生方案？

QKE 的使用十分简单，对于绝大多数人来说，都可以在 10 分钟内构建出一套完整的云原生运行平台方案。

1、准备工作

创建 QKE 服务之前，需要创建相应的私有网络和 VPC ，以方便后续构建 QKE 云原生集群使用。

此外，还需要创建一个 API Key，用以后续 QKE 帮助你自动调整网络及存储相关的配置。

这样就完成了基础的准备工作

2、选择配置

准备工作完成后，就可以开始选择 QKE 所需的配置了。

根据实际的情况，选择所需的配置、私有网络、计费方式等。

再选择 QKE 所使用的 API KEY 和对应的公网 IP ，就可以点击创建了。

3、创建成功

点击创建后，会自动进入到 QKE 的管理控制台中。在这里可以看到 QKE 帮助开发者自动创建好了所需要的集群。

4、体验管理控制台

点击确认后，稍等几分钟，当看到所有的节点都变为活跃状态，就说明集群已经正常运行，就可以开始体验 QKE 提供的管理控制台了。

点击 QKE 集群详情页的 “KubeSphere 控制台链接” 标签页，找到其中的 KubeSphere 控制台地址，并使用账号 [email protected] ，密码 P@88w0rd 即可登录到 KubeSphere 上，享受来自 KubeSphere 提供的 CI/CD、微服务管理、集群运维管理等功能。

整个 QKE 创建的过程流畅，一气呵成，十分钟，就可以轻松的部署一个 QKE 集群，十分的方便。

QKE ：开源与云的完美结合

开源社区的兴盛近几年有目共睹，但开源社区的最大问题在于，过于理想化和技术化，这使得整个产品在可用性、产品化方面举步维艰。QKE 的出现是一个很好的开源与云计算的结合。

一方面， QKE 可以借助开源项目 KubeSphere ，吸收来自开源社区的优秀创意和修改，让用户体验得到提升，用户能力得到拓展。

另一方面，QKE 基于云计算构建，可以让开源产品得以产品化，让过去难以落地的云原生现在触手可及。对于一些技术能力储备没有那么充沛的企业来说，也可以轻松用上云原生方案，享受云原生带来的企业和商业价值。

总结

QKE 的出现，是开源的一小步，更是云原生的一大步。对于开源来说，产品化的路径被打通，后人可以借鉴。从云原生来说，QKE 的出现让过去需要数十个人，数人日的工作，被缩短为 10 分钟，大大的提升了云原生普及的可能。