2019年非常受欢迎的9个超级云原生开源项目

作者：ArthurGuo 2019-09-11 09:38:18

新闻

云计算

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

成都创新互联主营内丘网站建设的网络公司,主营网站建设方案,成都app开发,内丘h5小程序设计搭建,内丘网站营销推广欢迎内丘等地区企业咨询

 [[276535]]

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

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

“云原生技术用于开发应用程序，这些应用程序使用封装在容器中的服务构建，部署为微服务，并通过敏捷的 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 个有趣的处于“毕业”阶段和“孵化”阶段的开源项目。

　　一、毕业的项目

　　“毕业”阶段项目被许多组织认为是成熟的，必须遵守 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 世纪初开始拥抱开源，后转型项目管理。现在某云计算公司担任技术总监。掌握多门计算机语言，但更擅长人类语言。爱玩文字，不喜毒舌。

网站栏目：2019年非常受欢迎的9个超级云原生开源项目
文章路径：http://www.shufengxianlan.com/qtweb/news18/237318.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联