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

随着使用容器开发应用程序的实践越来越流行，云原生应用程序也正在兴起。根据 定义

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

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

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

尽管这些技术有着非常不同的历史，但它们彼此互补，并在短时间内导致云原生应用程序和工具集惊人的指数级增长。这个云原生计算基金会 (CNCF) 信息图显示了当今云原生应用程序生态系统的规模和广度。

图片来源：

^{云原生计算基金会应用程序}

我的意思是，看看那个！这仅仅是个开始。正如 NodeJS 的创建引发了无休止的 JavaScript 工具的爆发一样，容器技术的普及启动了云原生应用程序的指数级增长。

好消息是，有几个组织负责监督并将这些点连接在一起。一个是开放容器计划 (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 项目，但我将介绍九个最有趣的毕业和孵化开源项目。

我还创建了这个视频教程来演示这些项目。

毕业项目

毕业项目被认为是成熟的——被许多组织采用——并且必须遵守 CNCF 的指导方针。以下是三个最受欢迎的开源 CNCF 毕业项目。（请注意，其中一些描述是从项目网站改编和重用的。）

Kubernetes

啊，Kubernetes。在不提及 Kubernetes 的情况下，我们怎么能谈论云原生应用程序呢？Kubernetes 由 Google 发明，无疑是最著名的基于容器的应用程序的容器编排平台，它也是一个开源工具。

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

Docker Swarm 和 Mesosphere Marathon 是其他容器编排引擎，但可以肯定地说 Kubernetes 赢得了这场竞赛（至少目前是这样）。Kubernetes 也催生了容器即服务 (CaaS) 平台，例如 OKD，Kubernetes 的 Origin 社区发行版，为 Red Hat OpenShift 提供支持。

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

Prometheus

Prometheus 是 2012 年在 SoundCloud 构建的开源系统监控和警报工具包。从那时起，许多公司和组织都采用了 Prometheus，并且该项目拥有非常活跃的开发人员和用户社区。它现在是一个独立的开源项目，独立于公司维护。

图片来源：

^{Prometheus 的架构}

思考 Prometheus 最简单的方法是可视化一个需要 24 小时/天、365 天/年运行的生产系统。没有哪个系统是完美的，并且有一些技术可以减少故障（称为容错系统）。但是，如果出现问题，最重要的是尽快识别出来。这就是像 Prometheus 这样的监控工具派上用场的地方。Prometheus 不仅仅是一个容器监控工具，但它在云原生应用程序公司中最受欢迎。此外，包括 Grafana 在内的其他开源监控工具也利用了 Prometheus。

开始使用 Prometheus 的最佳方法是查看其 GitHub 仓库。在本地运行 Prometheus 很简单，但是您需要安装容器引擎。您可以在 Prometheus 网站上访问详细文档。

Envoy

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

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

服务网格应用程序有许多替代方案，例如 Uber 的 Linkerd（下面讨论）和 Istio。Istio 通过部署为 Sidecar 并利用 Mixer 配置模型来扩展 Envoy Proxy。Envoy 的主要功能是

• 所有“基本”功能（与控制平面（如 Istio）配对时）都包含在内
• 在负载下运行时，低至 99% 的百分位延迟
• 充当 L3/L4 过滤器，核心提供许多开箱即用的 L7 过滤器
• 支持 gRPC 和 HTTP/2（上游/下游）
• 它是 API 驱动的，并支持动态配置和热重载
• 非常注重指标收集、追踪和整体可观察性

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

孵化项目

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

rkt

rkt，发音为“rocket”，是一个 Pod 原生容器引擎。它具有用于在 Linux 上运行容器的命令行界面 (CLI)。从某种意义上说，它与其他容器（如 Podman、Docker 和 CRI-O）类似。

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

Jaeger

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

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

Jaeger 是 Uber 构建的开源技术。您可以在其网站上找到 详细文档，并在 GitHub 上找到其 源代码。

Linkerd

与 Lyft 的 Envoy Proxy 一样，Uber 开发了 Linkerd 作为开源解决方案，以在生产级别维护其服务。在某些方面，Linkerd 就像 Envoy，因为两者都是服务网格工具，旨在提供平台范围的可观察性、可靠性和安全性，而无需配置或代码更改。

但是，两者之间存在一些细微的差异。虽然 Envoy 和 Linkerd 都充当代理，并且可以报告连接的服务，但 Envoy 并非设计为 Kubernetes Ingress 控制器，而 Linkerd 是。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 使用了它。

您可以通过遵循其文档中的 快速入门指南或其 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 运行时工具的运行时
• 使用 containers/image 的镜像管理
• 使用 containers/storage 的镜像层存储和管理
• 通过容器网络接口 (CNI) 提供网络支持

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

我是否遗漏了有趣的开源云原生项目？请在评论中告诉我。