2019年最受欢迎的9个顶级云原生开源项目

使用容器吗？来熟悉一下云原生计算基金会上的这些项目。

随着使用容器开发应用程序的实践越来越流行，云本地应用程序也在不断增加。根据定义：

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

该描述包括四个元素，这些元素与云原生应用程序是一体的：

1. 容器

2. 微服务

3. DevOps

4. 持续集成和持续交付（CI/CD）

尽管这些技术有着非常独特的历史，但它们相互补充得很好，并在短时间内导致云原生应用程序和工具集的指数级增长。这张云原生计算基金会（CNCF）的信息图表显示了云原生应用生态系统的大小和广度。

云原生计算基金会项目图

我是说，看看这个！这只是一个开始。正如Node.JS的创建引发了无休止的JavaScript工具的爆炸，容器技术的流行开始了云本地应用程序的指数级增长。

好消息是有几个组织负责监督和连接这些点。一个是开放容器联盟（OCI），它是一个轻量级的开放式治理结构（或项目），在Linux基金会的支持下形成的。OCI目的是围绕容器格式和运行时间创建开放的工业标准。另一个是CNCF，“一个开源软件基金会致力于使云原生计算普及和可持续。”

除了一般围绕云本机应用程序构建社区之外，CNCF还帮助项目围绕其云本机应用程序建立结构化治理。CNCF创建了成熟度级别“沙盒”、“孵化”或“毕业”的概念，与下图中的创新者、早期采用者和早期多数层相对应。

CNCF成熟度模型

1）沙盒阶段

要在沙盒中被接受，一个项目必须至少有两个TOC发起人。详细流程请参见CNCF Sandbox Guidelines v1.0。

2）孵化阶段

注：孵化水平是我们希望对项目进行全面尽职调查的点。

要进入孵化阶段，项目必须满足沙盒阶段的要求，并加上：

• 记录至少三个独立的最终用户在生产中成功使用，根据TOC的判断，这些用户具有足够的质量和范围

• 有一个合理的提交者数量。提交者定义为具有commit bit的人，即可以通过对项目的部分或全部的代码提交贡献的人

• 显示出持续不断的代码提交和代码合并数据流

• 由于这些指标可能因项目的类型、范围和规模而显著不同，因此TOC对足以满足这些标准的活动水平有最终判断

3）毕业阶段

能从“沙盒”或者“孵化”达到“毕业”阶段的项目，或者一个直接就进入到“毕业”阶段的项目，项目必须符合孵化阶段标准，以及如下条件：

• 拥有来自至少两个组织的代码提交者

• 已经实现并维护了核心基础设施计划最佳实践徽章

• 已完成独立的第三方安全审计，其结果发布的范围和质量与以下示例类似（包括已解决的列举在https://github.com/envoyproxy/envoy#security-audit的关键漏洞）并且所有关键的问题都需要在“毕业”前解决

• 适应CNCF执行准则

• 明确定义项目治理和提交者流程。这最好在governance.md文件中列出，并参考owners.md文件，显示当前和退休的提交者

• 至少有一个项目采用者的公开列表（例如，Adopters.md或项目网站上的logo）

• 获得TOC的绝大多数选票，项目进入“毕业”阶段。如果项目能够显示出足够的成熟度，那么它们可以尝试直接从“沙盒”直接跳跃到“毕业”。项目可以无限期地保持在“孵化”状态，但通常预计在两年内达到“毕业”阶段

9个值得考虑的项目

尽管不可能在一篇文章中涵盖所有CNCF项目，我还是想要列举9个有趣的处于“毕业”阶段和“孵化”阶段的开源项目。

项目	License	简介
Kubernetes	Apache 2.0	容器编排平台
Prometheus	Apache 2.0	系统和服务监控工具
Envoy	Apache 2.0	服务代理
rkt	Apache 2.0	Pod原生容器引擎
Jaeger	Apache 2.0	分布式跟踪系统
Linkerd	Apache 2.0	透明的service mesh
Helm	Apache 2.0	Kubernetes 包管理
Etcd	Apache 2.0	分布式key-value 存储
CRI-O	Apache 2.0	轻量级Kubernetes运行时间管理

一、毕业的项目

“毕业”阶段项目被许多组织认为是成熟的，必须遵守CNCF的指导方针。以下是三个最流行的开源CNCF毕业项目。（请注意，其中一些描述是从项目的网站上改编和重用的。）

1、Kubernetes

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

什么是容器编排平台？基本上，一个独立的容器引擎可以管理几个容器。然而，当您谈论数千个容器和数百个服务时，管理这些容器变得非常复杂。这就是容器引擎的切入点。容器编排引擎通过自动化容器的部署、管理、联网和可用性来帮助扩展容器。

Docker Swarm 和 Mesosphere Marathon是另外两种容器编排引擎，但是我们可以很放心地说Kubernetes在竞争中胜出。Kubernetes还催生了Container-as-a-Service (CaaS) 平台，比如：OKD。最初的Kubernetes社区发布版，激发RedHat的OpenShift。

可以从阅读Kubernetes的Github仓库开始，在Kubernetes Documents站点网页访问文档学习资源。

2、Prometheus

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

Prometheus架构

了解Prometheus最简单的方法是设想一个生产系统，它需要每天24小时，每年365天工作。没有一个系统是完美的，也有一些技术可以减少故障（称为容错系统）。但是，如果出现问题，最重要的是尽快识别它。这就是Prometheus这样的监控工具的用武之地。Prometheus不仅仅是一个容器监控工具，它在云原生应用程序公司中最受欢迎。此外，其它开源监控工具，包括Grafana，可以对接Prometheus。

开始Prometheus最好的办法是访问它的GitHub代码仓库，本地运行Prometheus是很容易的，但是必须提前有一个容器引擎。用户可以在Prometheus的官网获取更详细文档。

3、Envoy

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

当一个基础设施中的所有服务流量都通过一个Envoy mesh流动时，通过一致的可观测性，调整整体性能，并在一个地方添加底层特性，就可以很容易地观察问题区域。基本上，Envoy Proxy是一个Service Mesh工具，帮助组织为生产环境构建容错系统。

ServiceMesh应用程序有许多替代方案，例如Uber的Linkerd（下面讨论）和Isito。Istio通过部署为Sidecar并利用Mixer配置模型来扩展Envoy Proxy。Envoy的显著特点是：

• 包含所有该支持的功能（当搭配控制平面，如Istio的时候）

• 在负载情况下消耗资源量很低

• 在其核心处充当L3/L4过滤，并且可以提供许多不可思议的L7过滤

• 支持GRPC和HTTP/2（上游/下游）

• 它是API驱动的，支持动态配置和热重加载

• 重点关注度量收集、跟踪和整体可观测性

想要了解Envoy更多，发挥它的能力，并实现其全部优势，用户需要在运行生产级环境方面有丰富的经验。访问Envoy的GitHub代码仓库，阅读文档，用户可以了解更详细信息。

二、“孵化”阶段项目

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

1、rkt

rkt，发音为“rocket”，是一种pod-native引擎。它有一个命令行界面（cli），用于在Linux上运行容器。在某种意义上，它类似于其他容器，如：Podman、Docker和CRI-O。

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

2、Jaeger

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

• 分布式事务监视

• 性能和延迟优化

• 根本原因分析

• 服务依赖性分析

• 分布式上下文传播

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

3、Linkerd

与Envoy Proxy的Lyft一样，Uber将Linkerd开发为一个开源解决方案，以将其服务保持在生产级别。在某些方面，Linkerd就像Envoy一样，因为两者都是Service Mesh工具，用以在不需要配置或代码更改的情况下提供平台范围的可观测性、可靠性和安全性。

然而，两者之间有一些细微的差别。虽然Envoy和Linkerd作为代理，可以在连接的服务上报告，但Envoy并不像Linkerd那样被设计成Kubernetes入口控制器。Linkerd的显著特点包括：

• 支持多种平台（Docker、Kubernetes、DC/OS、Amazon ECS或任何单机）

• 用于统一多个系统的内置服务发现抽象

• 支持GRPC、HTTP/2和HTTP/1.x请求以及所有TCP通信

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

4、Helm

Helm基本上是Kubernetes的包管理器。如果您使用过ApacheMaven、MavenNexus或类似的服务，您将了解Helm的目的。Helm帮助您管理Kubernetes应用程序。它使用“helm charts”定义、安装和升级最复杂的Kubernetes应用程序。Helm并不是实现这一点的唯一方法；另一个流行的概念是KubernetesOperators，它由RedHat Openshift4使用。

您可以按照文档中的快速入门指南（https://github.com/helm/helm）或Github指南来尝试Helm。

5、Etcd

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

• 定义明确、面向用户的API（gRPC）

• 具有可选客户端证书身份验证的自动TLS

• 速度（以每秒10000次写入为基准）

• 可靠性（采用Raft分布式）

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

您可以在ETCD的文档中了解更多信息，并在Github上访问其源代码。

6、CRI-O

CRI-O是一个开放容器联盟（OCI）兼容的Kubernetes运行时接口的实现。CRI-O用于各种功能，包括：

• 运行时使用runc（或任何OCI运行时规范实现）和OCI运行时工具

• 使用容器/图像进行图像管理

• 使用容器/存储器存储和管理图像层

• 通过容器网络接口（CNI）提供网络支持

CRI-O提供了大量文档，包括指南、教程、文章甚至播客，您还可以访问其Github页面（https://github.com/cri-o/cri-o）。

原文链接：

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

译者介绍：

ArthurGuo 职场老司机。21世纪初开始拥抱开源，后转型项目管理。现在某云计算公司担任技术总监。掌握多门计算机语言，但更擅长人类语言。爱玩文字，不喜毒舌。

↓↓ 点击"阅读原文" 【加入云技术社区】

相关阅读：

更多文章请关注

文章好看点这里[在看]👇