三探云原生全景图，这次聊聊运行时层

在《俯瞰云原生，这便是供应层》我们介绍了云原生全景图的最底层：供应层，本文将带大家了解运行时层，这一层包含了容器在云原生环境中运行所需的一切。

作者 | Catherine Paganini，Jason Morgan

来源 | K8sMeetup社区

头图 | 下载于视觉中国

在《俯瞰云原生，这便是供应层》中，我们探索了构建云原生平台和应用的基础，本文我们将一起了解运行时层（runtime），这一层包含了容器在云原生环境中运行所需的一切。即：启动容器的代码，也叫运行时引擎；使容器获得持久化存储的工具；以及管理容器环境网络的工具。

但是注意，不要将这一层的资源与基础设施和供应层的网络和存储弄混淆，后者的工作是让容器平台运行起来。容器直接使用运行时层的工具来启动或停止，存储数据，以及相互通信。

云原生存储

是什么

存储是存放一个应用程序持久数据的地方，也叫做持久卷（persistent volume)。轻松访问持久卷对于应用程序可靠运行至关重要。通常，当我们说持久数据的时候，我们是指数据库、消息之类的，或其他任何在应用重新启动时不会丢失的信息。

解决什么问题

云原生架构具有高度的灵活性和弹性，这使得重启应用时存储持久数据变得很有挑战性。容器化应用程序在扩容、缩容或自动恢复时，会不断地创建或删除实例，并随着时间改变物理位置。因此，必须以与节点无关的方式提供云原生存储。但是，要存储数据，就需要硬件（具体来说是磁盘）。磁盘和其他硬件一样，受到基础设施的限制。这是第一个大的挑战。

第二个挑战是存储接口。该接口在数据中心之间可能会发生很大的变化（在以前，不同的基础设施都有自己的存储解决方案，并带有自己的接口），这使得可移植性变得非常困难。

最后，由于云的弹性，存储必须以自动化方式进行配置，因为手动配置和自动扩展不兼容。面临以上这些问题，云原生存储就是为新的云原生环境量身定制的。

如何解决

该类别的工具可以：

为容器提供云原生存储选项；
标准化容器与存储提供者之间的接口；
通过备份和还原操作提供数据保护。

云原生存储意味着使用兼容云原生环境的容器存储接口（也就是下一个类别中的工具），并且可以自动配置，通过消除人力瓶颈从而实现了自动扩展和自我恢复。

对应工具

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

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

容器运行时

是什么

前面我们提到过，容器是一组用于执行应用程序的技术约束。容器化的应用程序相信自己正在专用计算机上运行，而忽略了它们其实是与其他进程（类似于虚拟机）共享资源。

容器运行时是执行容器化（或“隔离”）应用的软件。如果没有运行时，将只有容器镜像——指定容器化应用程序外观的文件。运行时将在容器中启动应用程序，并为其提供所需的资源。

解决的问题

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

标准化：无论它们在何处运行，都需要标准操作规则；
安全：访问权限应该要注意设置；
隔离：该应用程序不应影响其他应用程序或受到其他应用程序的影响（例如，位于同一位置的应用程序崩溃）。隔离基本上起到保护作用。

此外，必须为应用程序提供 CPU、存储、内存等资源。

如何解决

容器运行时可以完成所有这些工作。它以标准化方式在所有环境中启动应用程序，并设置安全边界。安全边界是运行时和其他工具不同的地方，CRI-O 或 gVisor 等运行时强化了它们的安全性边界。运行时还为容器设置资源限制。没有资源限制，应用程序可能会根据需要消耗资源，这样就有可能占用其他应用程序的资源。因此设置资源限制是很必要的。

对应的工具

不是所有此类别中的工具都一样。Containerd（Docker 产品的一部分）和 CRI-O 是标准的容器运行时实现。有一些工具可以将容器的使用扩展到其他技术，例如 Kata，它允许将容器作为 VM 运行。其他工具旨在解决与容器相关的特定问题，例如 gVisor，它在容器和 OS 之间提供了额外的安全层。

云原生网络

是什么

容器通过云原生网络实现相互之间及和基础设施层之间的通信。分布式应用程序具有多个组件，这些组件将网络用于不同目的。此类别中的工具将虚拟网络覆盖在现有网络之上，专门用于应用程序进行通信，称为覆盖网络（overlay network)。

解决什么问题

通常我们将在容器中运行的代码称为应用程序，但实际上，大多数容器中仅包含大型应用程序的一小部分特定功能。诸如 Netflix 或 Gmail 之类的现代应用程序实际上由许多较小的组件组成，每个组件都在自己的容器中运行。为了使所有这些独立的部分正常运行组成一个完整的应用，容器之间需要相互通信。此类别的工具就提供该专用通信网络。

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

如何解决

此类别中的项目和产品使用 CNCF 中的项目——容器网络接口（Container Network Interface, CNI）为容器化应用提供网络功能。某些工具（例如 Flannel）仅为容器提供基本连接。其他工具（如 NSX-T）提供了完整的软件定义网络层，可为每个 Kubernetes 名称空间创建一个隔离的虚拟网络。

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

对应工具

CNI 标准化了网络层为 Pod 提供功能的方式，这在很大程度上实现了该领域的多样性和创新性。为 Kubernetes 环境选择网络非常关键，有许多工具可选。Weave Net，Antrea，Calico 和 Flannel 均提供有效的开源网络层，它们的功能各不相同，应根据特定需求进行选择。

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