使用容器吗?来熟悉一下云原生计算基金会上的这些项目。
随着使用容器开发应用程序的实践越来越流行，云本地应用程序也在不断增加。根据定义：
“云原生技术用于开发应用程序，这些应用程序使用封装在容器中的服务构建，部署为微服务，并通过敏捷的 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 世纪初开始拥抱开源，后转型项目管理。现在某云计算公司担任技术总监。掌握多门计算机语言，但更擅长人类语言。爱玩文字，不喜毒舌。
