用户您好!请先登录!

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

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

很有可能自己的下半个人生技术生涯就从Service Mesh开始了。趁早不趁晚,熟悉一下云原生计算基金会上的这些项目。

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

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

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

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

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

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

云原生计算基金会项目图

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

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

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

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

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个有趣的处于“毕业”阶段和“孵化”阶段的开源项目。

2019年最受欢迎的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,并且这个项目有一个非常活跃的开发人员和用户社区。它现在是一个独立的开源项目,独立于公司进行维护。

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

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
充分证明了一件事,用英文,早永生。
X-Eyes Admin
X-Eyes Admin

要发表评论,您必须先登录