使用容器吗？来熟悉一下云原生计算基金会上的这些项目。
随着使用容器开发应用程序的实践越来越流行，云本地应用程序也在不断增加。根据定义：
“云原生技术用于开发应用程序，这些应用程序使用封装在容器中的服务构建，部署为微服务，并通过敏捷的 DevOps 流程和持续交付工作流在弹性基础设施上进行管理。”
该描述包括四个元素，这些元素与云原生应用程序是一体的：
- 容器
- 微服务
- DevOps
- 持续集成和持续交付（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 世纪初开始拥抱开源，后转型项目管理。现在某云计算公司担任技术总监。掌握多门计算机语言，但更擅长人类语言。爱玩文字，不喜毒舌。
