都在说云原生,它的技术图谱你真的了解吗?

都在说云原生,它的技术图谱你真的了解吗?_第1张图片

来源 | K8sMeetup社区

作者 | Catherine Paganini

翻译 | Sarah(K8sMeetup)

校对 | 木子(才云)

如果你研究过云原生应用程序和相关技术,大概率你遇到过 CNCF 的云原生全景图。这张全景图技术之多规模之大无疑会让人感到震惊,该如何去理解这张图呢?

如果把它拆开来一次只分析一小块内容,你会发现整个全景图没有那么复杂。事实上,该全景图按照功能有序地组织在一起,一旦你了解了每个类别代表的内容,你就可以轻松游走于全景图中。

本文是这一系列的第一篇文章,我们将把整个全景图拆解开来,并对整个全景图进行综述。在后续文章中,我们将聚焦在每一层(or 每一列),对每个类别解决的问题和原理进行更为详细的解读。

都在说云原生,它的技术图谱你真的了解吗?_第2张图片

云原生全景图的 4 层

首先,我们剥离掉所有单个的技术,仅查看类别(如下图)。图中有不同的“行”,像建筑的不同层,每层都有自己的子类别。最底层提供了构建云原生基础设施的工具。往上,你可以开始添加运行和管理应用程序所需的工具,比如运行时和调度层。在最上层,有定义和开发应用程序的工具,比如数据库、镜像构建和 CI/CD 工具(我们将在后文讨论)。

都在说云原生,它的技术图谱你真的了解吗?_第3张图片

好了,现在你应该记住了云原生全景图始于基础设施,往上的每一层都更接近实际的应用程序。这就是每层代表的意思(后面我们会讨论上图右边的两“列”)。下面我们就从最底层开始,逐层进行解析。

供应层 (Provisioning)

供应指的是为云原生应用准备标准基础环境所涉及的工具。它包含了基础设施的创建、管理、配置流程的自动化,以及容器镜像的扫描、签名和存储等。供应层通过提供设置和实施策略,在应用程序和平台中构建身份验证和授权,以及处理密钥分发等等的工具,也拓展到了安全领域。

供应层包括:

  • 自动化和部署工具:帮助工程师在无需人工干预情况下即可构建计算环境;

  • 容器注册表:存储应用程序的可执行文件;

  • 不同安全领域的安全和合规框架

  • 密钥管理解决方案:通过加密确保只有授权的用户才能访问特定的应用程序。

这些工具使工程师可以编写基础设施参数,使系统可以按需搭建新环境,确保了一致性和安全性。

运行时层(Runtime)

接下来是运行时层。这个词可能会让你感到迷惑。像很多 IT 术语一样,运行时没有严格的定义,且可以根据语境有不同的用法。狭义上讲,运行时是特定机器上准备运行应用程序的沙盒——也就是保障应用程序正常运行所需的最低配置。广义上讲,运行时是运行一个应用程序所需的所有工具。

在 CNCF 云原生全景图中,运行时保障了容器化应用程序组件的运行和通信, 包括:

  • 云原生存储:为容器化应用提供虚拟磁盘或持久化存储;

  • 容器运行时:为容器提供隔离、资源和安全;

  • 云网络:分布式系统的节点(机器或进程)通过其连接和通信。

编排和管理层(Orchestration and Management)

一旦按照安全和合规性标准(供应层)自动化基础设施供应,并安装了应用程序运行所需的工具(运行时层),工程师就需要弄清楚如何编排和管理应用程序。编排和管理层将所有容器化服务(应用程序组件)作为一个群组管理。这些容器化服务需要相互识别和通信,并需要进行协调。这一层可为云原生应用提供自动化和弹性能力,使云原生应用天然具有可扩展性。

这一层包含:

  • 编排和调度:部署和管理容器集群,确保它们具有弹性伸缩能力,相互之间低耦合,并且可扩展。事实上,编排工具(绝大多数情况下就是 Kubernetes)通过管理容器和操作环境构成了集群;

  • 协调和服务发现:使得服务(应用程序组件)之间可以相互定位和通信;

  • 远程进程调用(RPC):使跨节点服务间通信的技术;

  • 服务代理:服务间通信的中介。服务代理的唯一目的就是对服务之间的通信进行更多控制,而不会对通信本身添加任何内容。服务代理对下面将提到的服务网格(service mesh)至关重要。

  • API 网关:一个抽象层,外部应用可通过 API 网关进行通信;

  • Service Mesh:某种程度上类似于 API 网关,它是应用程序进行通信的专用基础架构层,提供基于策略的内部服务间通信。此外,它还可能包含流量加密、服务发现、应用程序监控等内容。

应用定义和开发层 (Application Definition and Developement)

现在,我们来到了最顶层。应用定义和开发层,顾名思义,聚集了让工程师构建和运行应用程序的工具。上述所有内容都是关于构建可靠、安全的环境,以及提供全部所需的应用程序依赖。

这一层包括:

  • 数据库:使应用程序能以有序的方式收集数据;

  • 流和消息传递:使应用程序能发送和接收消息(事件和流)。它不是网络层,而是让消息成为队列并处理消息的工具;

  • 应用程序定义和镜像构建:用于配置、维护和运行容器镜像(应用程序的可执行文件)的服务;

  • 持续集成和持续交付(CI/CD):使开发者可自动测试代码是否与代码库(应用程序的其余部分)兼容。如果团队足够成熟,甚至可以自动部署代码到生产环境。

贯穿所有层的工具

接下来我们将进入到云原生全景图右侧贯穿所有层的两列。可观察性和分析(Observability&analysis)是监控各层的工具,平台则将各层中不同的技术捆绑为一个解决方案。

都在说云原生,它的技术图谱你真的了解吗?_第4张图片

可观察性和分析(Observability and Analysis)

为了限制服务中断并降低解决问题的平均时间(MRRT),你需要监控和分析应用层序的方方面面,以便在出现异常时可立即发现并纠正。复杂环境中容易出现故障,这些工具可快速识别并解决故障,从而降低故障带来的影响。由于这一类别贯穿并监控各层,因此它在侧面,而不是嵌入到某一层中。

这这一类别你将发现:

  • 日志工具:收集事件日志(有关进程的信息);

  • 监控方案:收集指标(以数字表示的系统参数,例如 RAM 可用性);

  • 追踪工具:追踪比监控更进了一步,它们监控用户请求的传播,与服务网格相关。

  • 混沌工程(Chaos Engineering):在生产环境中测试软件的工具,可识别缺陷并进行修复,减少其对服务交付的影响。

平台类(Platform)

可以看到,图中每一个模块解决一个特定的问题。但我们知道,仅有存储并不能提供应用程序所需的全部功能。你还需要编排工具,容器运行时,服务发现,网络,API 网关等等。平台覆盖多层,将不同的工具组合在一起,以解决更大的问题。

配置和微调不同的模块使其安全可靠,并确保它利用的技术都能及时更新、所有漏洞都打了补丁,这并不是一件容易的事情。使用平台时,用户不用额外担心这些细节问题。

你可能会注意到,所有的类别都围绕着 Kubernetes 展开。这是因为 Kubernetes 虽然只是云原生景观图这张拼图中的一块,但它却是云原生技术栈的核心。顺便说一下,CNCF 刚创建时,Kubernetes 就是其中的第一个种子项目,后来才有了其他项目。

平台可分为四类:

  • Kubernetes 发行版:采用未经修改的开放源代码(尽管有人对其进行了修改),并根据市场需要增加了其他功能;

  • 托管的 Kubernetes:类似于 Kubernetes 发行版,但是由提供商托管;

  • Kubernetes 安装程序:自动执行 Kubernetes 的安装和配置过程;

  • PaaS/容器服务:类似于托管的 Kubernetes,但是包含了一套更广泛的应用部署工具(通常是来自云原生景观图)。

    总结

在每个类别中,针对相同或相似的问题,都有不同的工具可选择。有一些是适用于新现实的预云原生技术,还有一些则是全新的。区别在于它们的实现和设计方法。没有完美的技术符合你的所有需求。大多数情况下,技术受设计和架构选择的限制——始终需要权衡取舍。

在选择技术栈时,工程师必须仔细考虑每种能力和需要权衡取舍的地方,以确定最合适的选项。虽然这样会让情况变得更复杂,但在选择应用程序所需的最适合的数据存储、基础设施管理、消息系统等方案时,这样做是最可行的办法。现在,构建一个系统比云原生之前的时代容易多了。如果构建恰当,云原生技术将提供更强大的灵活性。在现如今快速变化的技术生态中,这可能是最重要的能力之一。

更多阅读推荐

  • SRE 是如何保障稳定性的

  • 新春聊一下:技术架构与架构师角色的诸多思考

  • 如何写出让 CPU 跑得更快的代

  • 备战春招:阿里一面,给了几条SQL,问需要执行几次树搜索操作?

你可能感兴趣的:(大数据,java,人工智能,kubernetes,分布式)