1. 运行时 (Runtime)

现在我们已经建立了云原生环境的基础，我们将向上移动一个基础设施层，并放大到运行时层。它包含了容器在云原生环境中运行所需的所有内容。这包括用于启动容器的代码，称为容器运行时；为容器提供持久存储的工具；以及那些管理容器环境网络的工具。

但是请注意，不要将这些资源与上面讨论的供应层处理的网络和存储工作混淆。他们专注于让容器平台运行起来。这类工具用于启动和停止容器，帮助它们存储数据，并允许它们彼此通信。

1.1. 云原生存储（Cloud Native Storage）

1.1.1. 是什么？

存储是存储应用程序的持久数据的地方，通常称为持久卷。为了可靠地运行，应用程序需要能够容易地访问存储。通常，当我们说到持久数据时，我们指的是存储数据库、消息或任何其他我们希望确保在应用程序重新启动时不会消失的信息。

1.1.2. 解决什么问题？

云原生架构是流动的、灵活的和弹性的，这使得容器在重新启动过程中保持持久化数据是极其具有挑战性的事情。为了扩大和缩小或自我修复，容器化的应用程序被不断地创建和删除，随着时间的推移改变物理位置。这就是必须独立于节点提供云原生存储的原因。不过，要存储数据，您需要硬件，具体来说是磁盘，而磁盘与任何其他硬件一样，都与基础设施有关 -- 这是我们面临的第一个大挑战。

另外，实际的存储接口可能在数据中心之间发生很大的变化(在以前，每个基础设施都有自己的存储解决方案和自己的接口)，这使得可移植性非常困难。

最后，手动配置和自动伸缩两者是不兼容的，因此，为了从云的弹性中获益，存储必须自动配置。

云原生存储是为这种新的云原生现状量身定制的。

1.1.3. 有什么作用？

这类工具有以下两种帮助，为容器提供云原生存储选项：

• 1. 标准化容器和存储提供者之间的接口，
• 1. 或者通过备份和恢复操作提供数据保护。

前者指的是使用云原生兼容容器存储接口(第二类工具)的存储，可以自动提供，通过消除人工瓶颈实现自动伸缩和自修复。

1.1.4. 技术101

云原生存储在很大程度上是通过容器存储接口(CSI)实现的，CSI 提供了向容器提供文件和块存储的标准 API。这类工具中有许多，包括开源工具和供应商提供的工具，它们利用 CSI 为容器提供按需存储。

此外，还有一些技术旨在解决其他云原生存储的挑战。Minio 是一个流行的项目，它为对象存储提供了一个与 S3 兼容的 API。像 Velero 这样的工具有助于简化备份和恢复 Kubernetes 集群本身以及应用程序使用的持久数据的过程。

1.2. 容器运行时（Container Runtime）

1.2.1. 是什么？

正如在镜像仓库中所讨论的，容器是一组用于执行(或启动)应用程序的计算约束。容器化应用程序认为它们是在自己的专用计算机上运行，而不知道它们正在与其他进程共享资源(这类似于虚拟机)。

容器运行时是执行容器化(或“约束”)应用程序的软件。如果没有运行时，只有容器镜像，即静态文件，这只能用于描述容器化应用是什么样子（即不能实际运行）。运行时将在容器中启动一个应用程序，并为其提供所需的资源。

1.2.2. 解决什么问题？

容器镜像(带有应用程序规范的文件)必须以标准化、安全且隔离的方式启动。标准化是因为无论在哪里运行，都需要标准的操作规则。安全，因为你不想让不应该访问它的人访问它。隔离，是因为你不希望应用程序影响或被其他应用程序影响(例如，如果一个共存的应用程序崩溃)。隔离起到了基本上保护的作用。此外，还需要为应用程序提供资源，如CPU、存储和内存。

1.2.3. 有什么作用？

容器运行时完成如下这些工作。它以标准化的方式在所有环境中启动应用程序，并设置安全边界。后者是这些工具的不同之处。像 CRI-O或gVisor这样的运行时加强了它们的安全边界。运行时还为容器设置资源限制。如果没有它，应用程序可能会根据需要消耗资源，可能会从其他应用程序中夺走资源，所以你总是需要设置限制。

1.2.4. 技术101

这类工具并非都是平等的。Containerd (著名 Docker 产品的一部分)和 CRI-O 是标准的容器运行时实现。还有一些工具将容器的使用扩展到其他技术，例如 Kata，它允许您将容器作为 vm 运行。其他的则旨在解决特定的与容器相关的问题，如在容器和操作系统之间提供额外安全层的 gVisor。

1.3. 云原生网络（Cloud Native Network）

1.3.1. 是什么？

容器之间通过基于基础设施层的云原生网络进行通信。分布式应用程序有多个组件，这些组件通过使用网络来达到不同的目的。这类工具在现有网络之上创建一个虚拟网络，专门用于应用程序通信，称为 overlay 网络。

1.3.2. 解决什么问题？

虽然通常将在容器中运行的代码称为应用程序，但现实情况是，大多数容器只包含大型应用程序的一小部分特定功能。像 Netflix 或 Gmail 这样的现代应用程序是由许多这样的小组件组成的，每个组件都在自己的容器中运行。为了允许所有这些独立的部分作为一个内聚应用程序发挥作用，容器需要私下地彼此通信。这类工具提供了专用通信网络。

容器之间流动的数据和消息可能具有敏感或私有的数据。因为原生地网络使用软件来控制、检查和修改数据流，所以管理、保护和隔离容器之间的连接要容易得多。在某些情况下，您可能希望扩展您的容器网络和网络策略，如防火墙和访问规则，以允许应用程序连接到运行在容器网络外的虚拟机或服务。云原生网络的可编程特性和通常的声明性使这成为可能。

1.3.3. 有什么作用？

这类项目和产品使用容器网络接口(CNI)，一个 CNCF 项目，为容器应用程序提供网络功能。有些工具，如Flannel，非常简单，提供到容器的基本连接。其他的，比如NSX-T提供了一个完整的软件定义的网络层，为每个Kubernetes命名空间创建一个隔离的虚拟网络。

至少，容器网络需要为 pods 分配 IP 地址(在 Kubernetes 中运行的容器应用程序就是在这里运行的)，以允许其他进程访问它。

1.3.4. 技术101

这个空间的多样性和创新很大程度上是由CNI(类似于上面提到的存储和容器存储接口)实现的。CNI标准化了网络层向pod提供功能的方式。为您的Kubernetes环境选择正确的容器网络是至关重要的，您有许多工具可以选择。Weave Net、Antrea、Calico和Flannel都提供了有效的开源网络层。它们的功能差异很大，您的选择应该最终由您的特定需求驱动。

许多供应商使用软件定义网络(Software Defined Networking, SDN)工具支持和扩展Kubernetes网络，提供对网络流量的额外洞察，实施网络策略，甚至将容器网络和策略扩展到更广泛的数据中心。

1.4. 总结：运行时

这就是我们对运行时层的概述，它提供了在云原生环境中运行所需的所有工具:

• 云原生存储可以让应用程序轻松快速地访问可靠运行所需的数据
• 容器运行时，它创建并启动执行应用程序代码的容器
• 云原生网络为容器应用程序提供了通信连接。

1.5. 经验推荐

结合 CNCF 项目的成熟度和实际用户使用场景，在技术选型时可以考虑做如下考虑：

云原生存储为容器化的应用程序提供了虚拟化磁盘或持久性。可以考虑使用 ROOK 做相关的云原生存储服务。一般的项目也可能直接使用 NFS 或者本地存储类型，除此之外可能会在 ceph 和 glusterfs 之间进行选型。

容器运行时为容器提供了运行环境，约束，资源和安全性方面的考虑，并使用编码后的应用程序执行了文件。Docker 是最广为人知的容器运行环境，但生产环境下也有一些其他的容器环境在运行。Containerd 是满足 OCI 规范的核心容器运行时，从设计上就是为了嵌入大型系统的。CRI-O 也是不错的选择。

而关于云原生网络，CNI 作为一种通用的网络解决的框架，选择确实很多，主流可选择 Flannel、Calico 、Cilium 与 Weave net。专业复杂场景也可以选择 Open vSwitch 方案实现，如 OpenShift-SDN 等。