叮,你收到一份来自CNCF的云原生景观简介

当你在研究云原生应用程序和技术,则可能会看到过云原生计算基金会(CNCF)提供的云原生景观图。毫不奇怪,它的规模相当庞大。如此众多的类别和众多的技术。我们应该如何看待它?

与其他任何复杂事物一样,如果你并对其进行拆分并分析,你会发现它并不那么复杂。实际上,云原生景观图是按功能整齐地组织的,一旦你了解了每个类别所代表的内容,就可以轻松进行“导航”。

在本系列的第一篇文章中,我们将分解这个庞大的云原生景观并提供整体,每个层,每一列和每个类别的概述。在后续文章中,我们将着重介绍每个层和每一列,并介绍每个类别是什么,它解决了什么问题以及如何运用等。

云原生景观的四层

在第一层中,是配置云原生基础架构的工具。第二层和第三层,是添加运行和管理应用程序所需的工具,例如运行时和编排层。在第四层,是用于定义和开发应用程序的工具,例如数据库,镜像构建和CI/CD工具。

现在,云原生景观始于基础架构,每一层都更接近实际应用程序。你可能也注意到还有跨所有层运行的两个“列“,文章后面我们将讨论。

1.供应层(Provisioning)

Provisioning指的是创建和强化云本机应用程序基础所涉及的工具。它涵盖了从自动化基础结构的创建,管理和配置镜像扫描,镜像签名和存储镜像的所有内容。除此之外,它还具备在应用程序和平台中构建身份验证授权以及处理密钥分发的工具,资源调配和安全领域的工具。

在供应层中,你会看到:

  • 自动化和配置工具(Automation &configuration ):可帮助工程师无需人工干预即可构建基础环境。
  • 容器仓库(Container Registry): 存储应用程序的镜像。
  • 安全( Security &compliance ):涉及不同的安全领域。
  • 密钥管理(Key management):有助于加密,以确保只有授权的用户才能访问该应用程序。

这些工具使工程师可以了解所有基础架构的细节,以便根据需要进行调整,来确保它们的一致性和安全性。

2.运行时层(Runtime)

运行时是云原生中最可能引起混淆的术语之一。与IT中的许多术语一样,没有严格的定义,可以根据上下文使用的不同来定义。从狭义上讲,运行时是运行应用程序的特定沙箱环境(应用程序运行所需的最低限度)。从广义上讲,运行时是应用程序运行所需要的任何工具。

在CNCF云原生环境中,运行时重点放在对容器化应用特别重要的组件上。它们包括:

  • 云原生存储(Cloud native storage):为容器化的应用程序提供了虚拟化磁盘或持久性。
  • 容器运行时(Container runtime):为容器提供了约束,资源和安全性等。
  • 云网络(Cloud native networking)分布式系统的节点通过其进行连接和通信的网络。

3.编排和管理层(Orchestration & Management )

一旦按照安全性标准自动搭建了基础结构(供应层),并设置了应用程序需要运行的工具(运行时层),工程师就需要知道如何编排和管理其应用程序。

编排和管理层,把所有容器化应用程序作为一个组进行管理。还要确定是否需要和其他服务相互通信并进行协调。同时,云原生应用程序具有良好的可扩展性。

在这一层中,包括:

  • 编排和调度( Orchestration & scheduling ):部署和管理容器集群,以确保它们具有弹性,松耦合和可伸缩性。具有代表性的容器编排工具就是Kubernetes
  • 服务发现( Coordination and service discovery ):服务可以相互通信的工具。
  • 远程过程调用(RPC):跨节点上的服务进行通信的技术。
  • 服务代理( Service proxy ):代理的唯一目的是对服务通信施加更多控制,它不会对通信本身添加任何内容。这些代理对于下面提到的服务网格至关重要。
  • API网关:一个抽象层,外部应用程序可以通过它进行通信。
  • 服务网格( Service mesh ):在某种程度上类似于API网关,它是应用程序通过其进行通信的专用基础结构层,但是它提供了策略驱动的服务的通信。此外,它可能包括从加密、服务发现、到应用程序可观察性的所有内容。

4.应用程序定义和开发层(Application Definition & Development)

顾名思义,应用程序定义和开发层,是侧重于使工程师能够构建应用程序并使其运行的工具。

在此类别下,你会看到:

  • 数据库( Databases):使应用程序能够以有组织的方式收集数据。
  • 流和消息传递( Streaming & messaging):使应用程序能够发送和接收消息(事件和流)。它不是网络层,而是用于对消息进行排队和处理的工具。
  • 应用程序定义和镜像构建( Application definition &image build ):是帮助配置,维护和运行容器镜像的服务。
  • 持续集成和持续交付(CI/CD):使开发人员能够自动测试代码,自动打包,甚至还可以自动部署到生产环境中。

跨所有层运行的工具

接下来,我们将介绍在所有层上运行的两列–可观察性和分析。

可观察性与分析(Observability &Analysis)

为了降低MRRT(解决软件问题的时间),你需要监视和分析应用程序的各个方面,以便立即发现并纠正任何异常情况。在复杂的环境中故障随时会发生,而这些工具将通过帮助尽快识别和解决故障来帮助减轻故障的负面影响。由于此类别遍历并监视所有层,因此它在侧面,而不是嵌入在特定层中。

在这里你会发现:

  • 日志记录( Logging):收集事件日志(有关进程的信息)的工具。
  • 监视( Monitoring ):收集指标(系统参数,例如RAM可用性等),监视运行状况。
  • 跟踪( Tracing ):比监视更进一步,这与服务网格相关。
  • 混沌工程( Chaos engineering):是对生产中的软件进行测试的工具,可以在交付之前识别缺陷并加以修复。

平台类(Platforms)

如我们所见,每个模块都解决了一个特定的问题。例如,仅存储并不能提供管理应用程序所需的全部功能。你将需要一个编排工具,覆盖多层,将不同的工具捆绑在一起,以解决更大的问题。

你可能会注意到,所有类别都围绕Kubernetes展开。这是因为Kubernetes是最受欢迎的云原生编排工具。

平台可分为四类:

  • Kubernetes发行版:未经修改的开源代码(尽管有人对其进行了修改),并跟踪市场需求添加相应功能。
  • Kubernetes托管:类似于发行版,在提供商的基础架构上进行管理。
  • Kubernetes安装程序:使用它们可以自动执行Kubernetes的安装和配置过程。
  • PaaS /容器服务:与Kubernetes托管相似,但包含了广泛的应用程序部署工具集(通常是云原生环境的一部分)。

结论

在每种类别中,都有旨在解决相同或相似问题的不同工具。区别在于它们的实现和设计方法。

在选择时,工程师必须仔细考虑每种功能并进行权衡,以确定适合其用例的最佳选择。尽管这带来了额外的复杂性,但选择最适合应用程序需求的数据存储,基础架构管理,消息系统等,都是至关重要的。

译文链接: https://thenewstack.io/an-introduction-to-the-cloud-native-landscape/

K8S中文社区微信公众号

评论 抢沙发

登录后评论

立即登录