04-04 06:31 阅读 257

9 个值得考虑的开源云原生项目

随着使用容器开发应用程序变得越来越流行，云原生应用程序也开始普及起来。根据其定义：

云原生技术用于开发一类特别的应用程序，这类应用程序通过容器中的服务构建，然后按照微服务的形式部署，并通过 DevOps 敏捷流程以及可持续交付工作流在弹性基础设施上进行管理。

上述描述包括了云原生应用程序中四个不可或缺的要素:

容器化
微服务
DevOps
持续集成和交付（CI/CD）

尽管这些技术有着截然不同的历史，但它们相辅相成，并且在很短的时间内催生了云原生应用程序及其工具集的指数性增长。这张云原生计算基金会（cloud native Computing Foundation，CNCF）的信息图展示了当今云原生应用程序生态的规模和范围。

云原生计算基金会项目

这张图片只是一个开始。正如 node.js 的发明引发了无数 JavaScript 工具的爆炸式增长一样，容器技术的流行也开启了云原生应用程序的指数增长。

好消息是已经有几个组织开始监督这些项目并将它们连接起来。一个是开放容器计划（Open Containers Initiative，OCI），这是一个轻量级、开放的治理结构（或项目），在 Linux 基金会的支持下产生，其明确的目的就是围绕容器格式和运行时创建开放的行业标准。另一个是 CNCF，一个致力于云计算普及化和可持续化的开源软件组织。

除了围绕云原生应用程序构建社区以外，CNCF 还帮助项目建立了治理结构。CNCF 提出了成熟度级别的概念：沙箱、孵化和毕业。这些级别分别对应下图中的创新者、早期采用者和早期大众。

CNCF 项目成熟等级

CNCF 对每个成熟等级都有详细的标准（为方便读者，我们将在下面详细讲解）。一个正在孵化或毕业的项目需要技术监督委员会（TOC）三分之二的投票。

沙箱阶段

要想进入沙箱阶段，一个项目必须至少有两个 TOC 赞助人。详细过程请参阅 CNCF 沙箱指南 1.0 版本。

孵化阶段

注意：我们期望从孵化阶段开始对项目进行全面的尽职调查。

要进入孵化阶段，项目首先必须满足沙箱阶段的要求，此外：

记录至少有三个独立的最终用户在生产中成功使用了该项目，并且技术委员会认定其具有足够的质量和范围。

有一定数量的提交者。提交者的定义是具有提交权限的人，即可以对项目部分或整体接收贡献的人。

展示项目的提交和合并贡献持续稳定增长。

由于这些度量标准可能因为项目的类型、范围和大小而有很大的差异，因此对于项目是否满足这些标准，TOC 具有最终决定权。

毕业阶段

要从沙箱或孵化阶段毕业，或者要加入一个新项目作为毕业项目，该项目必须满足孵化阶段的所有标准，另外还要加上：

至少有来自两个组织的提交者。

实现并维护了核心基础设施倡议的最佳实践徽章。

已经完成了一个独立的第三方安全审计，公布结果的范围和质量类似于下面的例子（包括关键漏洞的修复）：

https://github.com/envoyproxy/envoy#security-audit

所有的关键漏洞都需要在毕业前得到修复。

采用 CNCF 行为守则。

明确定义项目治理和提交者流程。这最好放在一个 goverance.md 文件中，并引用一个 OWNERS.md 文件来显示当前提交者和历史提交者。

至少在主要仓库提供一个项目采用者的公开列表（例如，项目网站上的 ADOPTERS.md 或公司徽标）。

获得技术选择委员会的绝对多数选票进入毕业阶段。如果项目能够证明足够成熟，它们可以尝试直接从沙箱移动到毕业。项目可以无限期地保持孵化状态，但通常预计会在两年内毕业。

值得考虑的九个项目

虽然不可能涵盖上图中所有的 CNCF 项目，但我将介绍九个最有趣的开源项目，这些项目有的已经毕业，有的仍在孵化阶段。

读者可通过该视频教程来详细浏览这些项目。

毕业项目

毕业项目被认为是成熟的（已经被许多组织采用）并且必须遵守 CNCF 的指导方针。以下是三个最受欢迎的开源 CNCF 毕业项目。请注意，其中一些描述直接摘自项目网站或稍作编辑。

Kubernetes

在谈论云原生应用程序的时候怎么能忘记 Kubernetes？由 Google 发明的 Kubernetes 无疑是最著名的容器编排平台，它也是一个开源工具。

什么是容器编排平台？基本上，一个容器引擎本身可以用来管理几个容器。然而，当面对数以千计的容器和数以百计的服务时，管理这些容器就变得超级复杂。这时候容器引擎就有了用武之地。容器编排引擎通过自动化容器的部署、管理、网络和可用性来帮助扩展容器。

Docker Swarm 和 Mesosphere Marathon 是其它两个容器编排引擎，但可以肯定地说，Kubernetes 成为了赢家（至少目前是这样）。Kubernetes 也催生了像 OKD 这样的容器即服务平台（Container-as-a-Service，CaaS）。OKD 是 Kubernetes 的 Origin 社区发行版，并提供对 RedHat OpenShift 的支持。

想要入门，请访问 Kubernetes 的 GitHub 代码库，并从 Kubernetes 文档页面访问其文档和学习资源。

Prometheus

Prometheus 是 SoundCloud 在 2012 年开发的一个开源系统监控和警报工具包。从那时起，许多公司和组织就采用了 Prometheus。该项目有一个非常活跃的开发者和用户社区，它现在是一个独立的开源项目，独立于公司之外由社区进行维护。

Prometheus 的架构

理解 Prometheus 最简单的方法就是把它想象成一个每年 365 天，每天 24 小时都在运转的生产系统。没有哪个系统是完美的，有技术可以减少故障（称为容错系统）。然而，如果发生问题，最重要的事情是尽快定位问题。这时候，类似 Prometheus 这样的监控工具就可以派上用场了。

Prometheus 不仅仅是一个容器监控工具，它在云原生应用程序公司中也非常受欢迎。此外，包括 Grafana 在内的其他开源监控工具也都使用 Prometheus。

入门 Prometheus 最好的方法就是查看它的 GitHub 库。在本地运行 Prometheus 很容易，但是你需要安装一个容器引擎。Prometheus 的网站上有关于这方面的详细文档。

Envoy

Envoy（或 Envoy Proxy）是一个为云原生应用程序设计的开源边缘和服务代理。它由 Lyft 创建，是一个专门为单一服务和应用程序设计的高性能 C++ 分布式代理，还是一个专为大型微服务网状架构设计的通信总线和通用数据平面。Envovy 基于对 Nginx、HAProxy、硬件负载平衡器和云负载平衡器等解决方案的学习，与每个应用程序一起运行，通过以一种与平台无关的方式提供通用功能来实现网络抽象。

当基础设施中所有的服务流量流经 Envoy 网格时，可以很容易地在一个地方通过一致的可观察性来图形化问题区域、调整总体性能以及添加底层功能。基本上，Envoy Proxy 是一种服务网格工具，可以帮助组织为生产环境构建容错系统。

服务网格应用程序有很多替代品，比如 Uber 的 Linkerd （下面讨论）和 Istio 。Istio 通过部署为 Sidecar 并利用 Mixer 配置模型来扩展 Envoy Proxy。值得注意的特点有：

包括所有的基本功能（例如同 Istio 控制平面配对时）
工作负载低，在规模化扩展时将近百分之九十九的延迟处于负载不足
核心层作为 L3/L4 过滤器，提供了许多 L7 过滤器
支持 gRPC 和 HTTP/2（上游 / 下游）
由 API 驱动，支持动态配置和热重载
侧重于度量的收集、跟踪和整体可观察性

想要理解 Envoy、证明它的能力并实现其全部优点，需要在运行生产级环境方面具有丰富的经验。更多详细内容可以参阅文档，也可以访问它的 GitHub 代码库。

孵化项目

以下是六个最受欢迎的开源 CNCF 孵化项目。

Rkt

Rkt 的发音是”rocket（火箭）”，它是一个 pod 原生容器引擎。它有一个在 Linux 上运行容器的命令行界面（CLI）。在某种意义上，它同其它容器类似，如 Podman 、Docker 和 CRI-O。

Rkt 最初由 CoreOS 开发（后来被 RedHat 收购），你可以在官网上找到详细的文档，也可以在 GitHub 上访问源代码。

Jaeger

Jaeger 是一个面向云原生应用程序的开源端到端分布式跟踪系统。在某种程度上，它是一个像 Prometheus 一样的监控解决方案。但是它又是不同的，因为它的使用场景可以扩展到：

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

Jaeger 是一项由 Uber 开发的开源技术。你可以在官网上找到详细的文档，也可以在 GitHub 上找到源代码。

Linkerd

就像 Lyft 的 Envoy Proxy 一样，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 Charts”来定义、安装和升级即便是非常复杂的 Kubernetes 应用程序。Helm 并不是管理包的唯一方法；另一个流行的概念是 Kubernetes Operators ，Red Hat OpenShift 4 正是使用这个概念。

你可以按照 Helm 文档的快速指南或者 GitHub 入门来试用 Helm。

Etcd

Etcd 是可靠的分布式键值存储项目，可用于存储分布式系统中最关键的数据。它的主要特点如下：

定义明确、面向用户的 API（gRPC）
自动 TLS，可选的客户端证书身份验证
速度快（每秒 10000 次写入）
可靠性（使用 Raft 来分发）

Etcd 被用作 Kubernetes 和其它许多技术的默认内置数据存储。也就是说，它很少独立运行或作为一个单独的服务运行；相反，它利用了集成到 Kubernetes 和 OKD/OpenShift 的服务或其它服务。还有一个 Etcd Operators 来管理它的生命周期并解锁其 API 管理功能。

你可以通过 Etcd 文档了解更多信息，并在 GitHub 上访问其源代码。

CRI-O

CRI-O 是一个遵守开放容器倡议（OCI）的 Kubernetes 运行时接口实现。CRI-O 的功能包括：

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

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