云原生景观：运行时层解决了什么问题？如何解决的？

之前的文章《叮，你收到一份来自CNCF的云原生景观简介》，我们对CNCF云原生生态系统做了概述。

同时，在《云原生景观：供应层(Provisioning)解决了什么问题？如何解决的？》中，我们探讨了Cloud Native Computing Foundation的Cloud Native景观的供应层，该层主要致力于构建Cloud Native平台和应用程序的基础。

这篇文章，我们着重介绍运行时层，涵盖了容器在云原生环境中运行所需的所有内，包括容器运行时引，容器存储工具，容器网络。

注意：

运行时层的资源不应与与基础结构和供应层的网络和存储混淆。

容器会直接使用运行时层的工具来启动/停止，存储数据以及通信。

查看云原生景观图时，你会注意到一些区别：

• 大盒子中的项目是CNCF托管的开源项目。有些仍处于孵化阶段（浅蓝色/紫色框），而另一些则是已毕业的项目（深蓝色框）。
• 白色小盒子中的项目是开源项目。
• 灰色的盒子是专有产品。

请注意，即使在撰写本文时，我们也看到有新项目成为CNCF的一部分，因此始终参考实际情况-事情发展很快！

云原生存储

是什么

存储，即存放应用程序持久数据的位置，通常称为持久卷。轻松访问持久卷，对于应用程序可靠运行至关重要。通常，当我们说持久数据时，是指想要确保我们在应用重新启动时不会消失的任何数据。

解决了什么问题

云原生架构具有不固定性，灵活性和弹性，这使得应用重启后的持久数据面临挑战。容器化的应用程序在扩缩容或自我修复时，将会连续创建和删除实例，并随时间更改物理位置。因此，必须以与节点无关的方式提供云原生存储。

但是，要存储数据，就要需要硬件（具体来说是磁盘）。磁盘与其他任何硬件一样，都受基础结构约束。这是第一个挑战。

第二个挑战是，存储接口。以前，每个基础架构都有自己的存储解决方案和自己的接口，这使可移植性变得非常困难。

第三个挑战是，由于云的弹性，必须以自动化方式配置存储。

云原生存储，是针对此云原生量身定制。

它如何解决

云原生存储工具，可帮助

a）为容器提供云原生存储选项

b）标准化容器与存储提供者之间的接口

c）通过备份和还原操作提供数据保护

因此，使用云原生存储能够兼容多数三方存储，并且可以自动配置，从而消除了人为瓶颈，实现了自动扩展和自我修复。

相应的解决工具

容器存储接口（CSI）在很大程度上使云原生存储成为可能，该接口允许使用标准API向容器提供文件和块存储。在这个领域中，有许多工具，包括开源的和供应商提供的，都可以利用CSI为容器提供按需存储。

除了这一极其重要的功能之外，我们还有许多其他工具和技术，旨在解决云原生中的存储问题。Minio是一个受欢迎的项目，除其他外，它提供了兼容S3的API用于对象存储。Velero之类的工具可帮助简化Kubernetes集群本身以及应用程序使用的持久数据的备份和还原过程。

容器运行时

是什么

如在《云原生景观：供应层(Provisioning)解决了什么问题？如何解决的？》中所讨论的，容器是一组用于执行应用程序的约束（compute constraints）。容器化的应用程序相信它们正在自己的专用计算机上运行，而忽略了它们与其他进程（类似于虚拟机）共享资源。

容器运行时，是执行集装箱化（或“约束”）的应用程序。如果没有运行时，则只有容器镜像，该文件指定了容器化应用的外观。运行时将在容器中启动应用程序，并为其提供所需的资源。

解决了什么问题

容器镜像（带有应用程序规范的文件）必须以标准化，安全和隔离的方式启动。

标准化，因为无论它们在何处运行，都需要标准的操作规则。

安全，因为你不希望任何不应该访问它的人，对它操作。

隔离，因为你不希望应用程序影响其他应用，或受其他应用程序的影响（例如，在同一节点的其他应用程序崩溃）。隔离基本上起保护作用。此外，必须为应用程序提供从CPU到存储再到内存的资源隔离。

它如何解决

容器运行时可以完成所有这些工作。

它以标准化方式在所有环境中启动应用程序，并设置安全边界。像CRI-O或gVisor这样的运行时，强化了它们的安全性边界。运行时还设置了容器的资源限制。没有它，该应用程序可能会根据需要消耗资源，从而有可能占用其他应用程序的资源，因此你始终需要设置限制。

相应的解决工具

并非此类别中的所有工具都是一样的。 Containerd （Docker产品的一部分）和CRI-O是标准的容器运行时实现。

然后，有一些工具可以将容器的使用扩展到其他技术，例如Kata，它允许你将容器作为VM运行。其他目标旨在解决与容器相关的特定问题，例如gVisor，它在容器和OS之间提供了额外的安全层。

云原生网络

是什么

容器通过云原生网络相互通信，并与基础结构层通信。分布式应用程序具有多个组件，这些组件将网络用于不同目的。

云原生网络类别中的工具将虚拟网络覆盖在现有网络之上，专门用于应用程序进行通信，称为覆盖网络( overlay network )。

解决了什么问题

通常，将在容器中运行的代码称为应用程序，但事实是，大多数容器仅包含较大应用程序的一小部分特定功能。诸如Netflix或Gmail之类的现代应用程序实际上由许多这些较小的组件组成，每个组件都在其自己的容器中运行。为了使所有这些独立的部分充当一个有凝聚力的应用程序，容器需要彼此私下通信。此类工具提供该专用通信网络。

此外，在这些容器之间交换的消息可能是私有的，敏感的或非常重要的。这导致了其他要求，例如为各种组件提供隔离以及检查流量以识别网络问题的能力。在某些用例中，你可能需要扩展这些网络和网络策略（例如防火墙和访问规则），以便你的应用程序可以连接到在我们的容器网络外部运行的虚拟机或服务。

它如何解决

容器网络接口（CNI）为容器化应用程序提供联网功能。某些工具（例如Flannel）相当简单，可提供与容器的基本连接。其他诸如NSX-T等提供了完整的软件定义网络层，可为每个Kubernetes命名空间创建一个隔离的虚拟网络。

容器网络至少需要为Pod（在Kubernetes中运行容器化的应用程序）分配IP地址，以允许其他进程访问它。

相应的解决工具

与存储类似，CNI（容器网络接口）在很大程度上实现了该领域的多样性和创新，该项目标准化了网络层如何为Pod提供功能。

为你的Kubernetes环境选择正确的容器网络至关重要，并且你有许多工具可供选择。Weave Net，Antrea，Calico和Flannel均提供有效的开源网络层。它们的功能千差万别，你的选择应最终由你的特定需求决定。

此外， 许多供应商已准备好使用软件定义网络（ Software Defined Networking ，SDN）工具来支持和扩展你的Kubernetes网络，这些工具使你可以深入了解网络流量，执行网络策略，甚至将容器网络和策略扩展到更广泛的数据中心。

本文，我们对运行时进行了概述，该运行时层提供了在云原生环境中运行所需的所有工具容器。从让应用程序轻松快速访问所需的数据存储，到执行应用程序代码的容器运行时，再到与容器化应用程序进行通信的网络。

在我们的下一篇文章中，我们将重点讨论业务流程和管理层，这是如何将所有这些容器化应用程序作为一个组进行管理的。

译文链接：https://thenewstack.io/the-cloud-native-landscape-the-runtime-layer-explained/