并行多核体系结构基础在线阅读免费版|百度网盘下载

编者评论：并行多核架构基础在线阅读

面对智能、大数据时代异构并行化趋势，涵盖多核架构的基本内容和本质，填补国内外教学空白，小编为大家带来并行多核架构的基础今天的核心架构。有兴趣的请下载阅读

简介

虽然多核现在是主流架构，但很少有教科书涵盖并行多核架构。本书填补了这一空白，为研究生或高级本科建筑课程提供了所有材料，

重点是多核处理器的架构。本书也适合从事多核编程或多核芯片设计的专业人士作为参考。

关于作者

Yan Solihin 是北卡罗来纳州立大学电气与计算机工程系的教授。长期从事计算机体系结构研究。主要研究方向为计算机体系结构、计算机系统建模方法、图像处理，

在计算机体系结构和性能建模领域发表了大量高水平论文，相关研究得到了美国国家自然科学基金会、英特尔、IBM、三星、Tekelec、SunMicrosystems 和惠普的资助。 He was elected as an IEEE Fellow in 2017,

并入选高性能计算机体系结构国际会议 (HPCA) 名人堂 (2015)。此外，长期从事计算机体系结构教学，教学经验丰富。创建并领导了针对性能、可靠性和安全性的架构研究小组，并开源了许多用于多核架构的性能建模和性能优化的软件工具。

相关内容部分预览

图书特色

向读者介绍如何编写共享内存并行程序的不同视角。

帮助读者了解共享存储多核和多处理器所需的软件基础和硬件支持。

讨论存储层次结构、设计共享内存并行多处理器时的基本问题、缓存一致性、存储一致性、同步、互连网络，并向读者展示不同概念如何相互作用和适应。

探索图形处理单元 (GPU) 系统中常用的单指令流多线程 (SIMT) 编程模型。

Kubernetes 架构基础知识

Kubernetes 是一个具有大量代码和功能的大型开源项目。读者可能读过 Kubernetes 相关的文章，或者在其他项目中涉足该领域，甚至在工作中使用过 Kubernetes。但是为了理解和有效地使用 Kubernetes，并将其更好地付诸实践，您需要对它有更深入的了解。本章将构建 Kubernetes 的基本框架。首先我们要了解Container Orchestration的含义；然后我们将解释与 Kubernetes 相关的几个重要概念，这些概念将贯穿全书；如何将 Kubernetes 的所有功能提供给用户；然后介绍Kubernetes支持的各种运行时和容器引擎（Docker就是其中之一）；部署管道的作用）进行了讨论。

本章将重点介绍以下几个方面：容器编排、Kubernetes适用条件、Kubernetes设计原则和架构、Kubernetes支持的不同运行环境。读者将熟悉一个开源存储库的整体结构，并为解决剩下的问题打下良好的基础。

1.1 了解容器编排

Kubernetes 的主要功能是容器编排，即确保所有容器按计划运行在物理机或虚拟机上。这些容器被打包以在部署环境和集群配置的约束下执行大量工作负载。此外，Kubernetes 必须密切关注所有正在运行的容器，替换已中止、无响应或其他不健康的容器。后续章节将介绍 Kubernetes 的更多能力，本章将重点介绍容器及其编排。

1.1.1 物理机、虚拟机和容器

硬件通过容器编排运行。运行工作负载需要一些真实的硬件配置，包括具有计算能力（CPU 或核心）、内存和一些本地持久存储（硬盘驱动器或 SSD）的物理物理机。此外，还需要一些共享的持久化存储，所有的物理机都使用网络连接起来，这样它们就可以找到彼此并相互通信。此时，您可以在物理机上运行多个虚拟机，或者干脆保持裸机。 Kubernetes可以部署在物理硬件或者虚拟机集群上，也可以直接在物理硬件或者虚拟机上管理容器。理论上，Kubernetes 集群可以由物理机和虚拟机的组合组成，但这并不常见。

1.1.2 云容器

容器非常适合封装微服务，因为它们不仅为微服务提供隔离，而且非常轻量级，并且在部署多个微服务时不会像使用虚拟机时那样产生太多开销。这使得容器成为云部署的理想选择，因为将整个虚拟机分配给每个微服务非常昂贵。

主要的云提供商（如 AWS、GCE 和 Azure）现在提供容器托管服务，其中一些基于 Kubernetes（如 Google 的 GKE）；其他如微软 Azure 的容器服务都是基于 Apache Mesos 等的其他解决方案。此外，AWS 将 ECS（EC2 上的容器服务）作为自己的编排解决方案。 Kubernetes 的强大之处在于它可以部署在这些云服务器上。 Kubernetes 有一个云提供商接口，允许任何云提供商无缝地执行和集成 Kubernetes。

1.1.3 服务器运行方式

过去系统很小，每个服务器都有一个名称。开发人员和用户确切地知道每台机器上运行的是什么软件。我工作过的许多公司都进行了几天的讨论来决定服务器命名主题。例如，作曲家和希腊神话人物是受欢迎的选择。开发人员将服务器视为他们心爱的宠物。如果一台服务器出现故障，那将是一场大危机，每个人都需要将全部精力放在这三件事上：更换新服务器；确定故障服务器上仍在运行哪些数据；如何使这些数据可用在新服务器上运行。如果故障服务器存储了一些重要的数据，就只能寄希望于备份数据和数据恢复。

显然，这种方式是不合适的，当有几十台甚至上百台服务器时，必须像牲畜一样对待，需要考虑集体而不是个人。或许此时在造机器的时候，还是需要把它们当宠物一样对待，但对于web服务器来说，就只能把它们当成牲畜了。

Kubernetes 将这种方法发挥到了极致，接管了将容器分配给特定机器的整个任务。无需花费大量时间与单个机器（节点）进行交互。这最适合无状态工作负载。对于有状态的应用，情况稍有不同，但 Kubernetes 提供了一个名为 StatefulSet 的解决方案，我们接下来会讨论。

本节介绍容器编排的概念，讨论主机（物理机或虚拟机）与容器的关系，并讨论在云中运行容器的优势。最后，用牲畜和宠物的类比来讨论运行模式。第 1.2 节将深入了解 Kubernetes 的世界并了解与之相关的概念和术语。

1.2 Kubernetes相关概念

本节将简要介绍与 Kubernetes 相关的许多重要概念，并提供一些示例来说明这些概念的重要性和关系，以熟悉这些术语和概念。接下来，展示如何将这些概念编织在一起以实现出色的结果。读者可以将其中许多概念视为构建块。一些概念被实现为 Kubernetes 组件，例如节点和主节点。这些组件处于不同的抽象级别，将在 1.5 节中详细讨论。

图 1.1 是著名的 Kubernetes 架构。

图 1.1 Kubernetes 架构

1.2.1 集群

集群是 Kubernetes 用来运行构成系统的各种工作负载的主机存储和网络资源的集合。一个完整的系统可以由多个集群组成。稍后将详细讨论集群联合的高级用例。

1.2.2 节点

节点是单个主机，可以是物理机或虚拟机，其职责是运行 Pod。每个 Kubernetes 节点运行多个 Kubernetes 组件，例如 Kuberlet 和 Kube 代理。节点由 Kubernetes 主控制器管理。这些节点类似于 Kubernetes 工蜂，并肩负着重担。他们曾经被称为奴才。如果读者过去读过文献，请不要混淆，下属指的是节点。

1.2.3 主节点

主节点是 Kubernetes 的控制平面，由几个组件组成，包括 API 服务器、调度程序和控制器管理器。主节点负责全局和集群级别的节点调度和事件处理。通常情况下，所有主控制器组件都位于单个主机上，当考虑高可用性场景或大型集群时，首选多个主节点。高可用集群在第 4 章详细讲解。

1.2.4 吊舱

Pod 是 Kubernetes 中的工作单元。每个 Pod 包含一个或多个容器。 Pod 通常在同一台机器上运行并一起调度。 Pod 中的所有容器都具有相同的 IP 地址和端口空间，它们可以通过 localhost 或标准进程进行通信。此外，Pod 中的所有容器都可以访问托管在托管 Pod 的节点上的本地共享存储，该存储存在于每个容器上。 Pod 是 Kubernetes 的一个重要特性。作为在多个进程中运行的主要 Docker 应用程序的超级管理员，可以在单个 Docker 容器中运行多个应用程序，但不鼓励这种做法，原因如下。

透明性：让Pod中的容器对基础设施可见，让基础设施可以为这些容器提供服务，比如进程管理、资源监控等，为用户提供了很多便利。

解耦的软件依赖关系：各个容器可以独立进行版本控制、重建和重新部署。 Kubernetes 甚至有望支持单个容器的实时更新。

易用性：用户无需运行自己的流程管理器，也无需担心信号和退出代码的事务传播等问题。

效率：容器可以更轻量级，因为基础架构将承担更多责任。

Pod 为相互依赖且需要在同一主机上协作以实现其目标的容器组提供了很好的解决方案。请记住，Pod 被认为是临时的、可替代的实体，可以在需要时丢弃和替换，并且 Pod 可以破坏任何 Pod 存储。每个 Pod 都有一个唯一的 ID (UID)，因此仍然可以区分它们。

1.2.5 标签

标签是用于对对象集合（通常是 Pod）进行分组的键值对。这对于其他几个概念很重要，例如副本控制器、副本集和需要对动态对象组进行操作、识别组成员的服务。对象和标签之间存在N×N的关系，每个对象可以有多个标签，每个标签可以应用于不同的对象。标签的设计有一定的限制，对象上的每个标签都必须有唯一的键，标签键必须遵循严格的语法。它的语法由两部分组成：前缀和名称。前缀是可选的，如果存在，用正斜杠 (/) 与名称分隔，并且必须是有效的 DNS 子域，前缀最多 253 个字符。该名称是强制性的，最多可包含 63 个字符。名称必须以字母、数字、字符（a~z、A~Z、0~9）开头和结尾，并且只能包含字母、数字、字符、点、破折号和下划线。值的规则与名称的规则相同。请注意，标签仅用于标识对象，不会将任何元数据附加到对象。这就是注释的目的（参见第 1.2.6 节）。

1.2.6 备注

注解允许将任意元数据与 Kubernetes 对象相关联。 Kubernetes 只存储注释并使其元数据可用。与标签不同，它对字符类型和大小没有严格的要求。复杂的系统通常需要这样的元数据，Kubernetes 认识到这样的需求并开箱即用地提供它，这样用户就不必提取自己单独的元数据存储进行映射。

此处介绍了大部分 Kubernetes 概念，并进行了简要概述。在 1.2.7 节中，我们将从设计动机、内部结构和实现以及源代码等方面继续研究 Kubernetes 的架构。

1.2.7 标签选择器

标签选择器根据标签选择对象，根据相等选择器指定键和值。基于值的相等或不等，它有两个运算符：=（或==）和!=，代码如下。

角色=网络服务器

这将选择具有该标签键和值的所有对象。

标签选择器可以用多个逗号分隔，代码如下。

角色 = 网络服务器，应用程序！= foo

基于集合的选择器可扩展性能并允许基于多个值进行选择。代码如下。

在（网络服务器、后端）中的角色

1.2.8 副本控制器和副本集

副本控制器和副本集管理一组由标签选择器标识的 Pod，确保一定数量的 Pod 始终在运行。它们之间的主要区别在于，副本控制器通过名称匹配测试成员资格，而通过基于集合的选择器测试副本集。副本集被更新并指定为下一代副本控制器。在撰写本文时，它仍处于测试阶段，并非所有工具都支持。但也许当读者读到这本书时，它已经完全成熟了。

Kubernetes 将保持在副本控制器或副本集中运行相同数量的 Pod。当由于主机节点或 Pod 本身的问题而导致数量下降时，Kubernetes 将启动新的用例。需要注意的是，如果人为启动的 Pod 数量超过了指定的数量，则副本控制器会结束多余 Pod 的进程。

副本控制器曾经是许多工作流的中心，例如滚动更新和运行一次性作业。随着 Kubernetes 的发展，它引入了对许多类似工作流的直接支持，例如 Deployment、Job 和 DaemonSet 等专用对象。这些将在接下来的章节中提到。

1.2.9 服务

服务向用户或其他服务公开一些功能。它们通常包含一组由标签区分的 Pod。服务可以提供对外部资源的访问路径，或者直接控制虚拟 IP 的 Pod。本地 Kubernetes 服务器通过方便的端点公开功能。需要注意的是，该服务是在第 3 层（TCP/UDP）上执行的。 Kubernetes 1.2 增加了 entry 对象，它提供了对 HTTP 对象的访问，稍后将更详细地讨论。可以通过以下两种机制之一发布或发现服务：DNS 或环境变量。服务可以通过 Kubernetes 进行负载均衡。但当服务使用外部资源或需要特殊处理时，开发人员可以自行管理和平衡负载。

有关 IP 地址、虚拟 IP 地址和端口空间的详细信息将在后面的章节中深入讨论。

1.2.10 存储卷

Pod 上的存储是临时的，会随 Pod 一起消失。如果数据只在节点上的容器之间交换就足够了，但有时数据需要在 Pod 上存储更长的时间，或者在 Pod 之间传递，存储卷的概念支持了这种需求。需要注意的是，虽然Docker中也有存储卷的概念，但是还是比较有限的（虽然越来越强大了）。 Kubernetes 使用自己的存储卷，并且支持额外的容器类型（例如 rkt），因此它从根本上独立于 Docker 的存储卷。

存储卷有多种类型，目前 Kubernetes 都直接支持。如果可以添加一个间接层，则可能会开发一个抽象存储卷插件。 emptyDir 存储卷类型为每个容器安装一个卷，默认情况下备份在主机上的任何可用容器上。如果需要，可以请求存储介质。当 Pod 因任何原因终止时，此存储将被删除。针对特定的云环境、各种网络文件系统，甚至 Git 存储库，有许多存储卷类型。一个有趣的存储卷类型是 PersistentDiskClaim，它概述了一些细节并使用了开发人员云提供商环境中的默认持久存储。

1.2.11 有状态服务集

如果您关心 Pod 上的数据，可以使用持久存储。但是，如果您需要 Kubernetes 来管理分布式数据存储库（例如 Kubernetes 或 MySQL Galera），则无法使用常规 Pod 和服务来模拟它，因为这些集群存储将数据分布在不同的节点上。回到有状态服务集，上一篇文章讨论了宠物和牲畜之间的关系，以及如何管理和执行牲畜。有状态服务集介于两者之间。有状态服务集确保在任何给定时间运行给定数量的唯一可识别宠物（类似于复制控制器）。宠物有以下特点。

DNS 中可用的稳定主机名。

序数索引。

与序号和主机名相关联的稳定存储。

一组有状态的服务可以帮助对等点发现、添加或删除宠物。

1.2.12 关键对象

密钥对象是包含敏感信息的小对象，例如凭据和令牌。它们以明文形式存储在 etcd 中，可通过 Kubernetes API 服务器访问，并在需要访问时作为文件加载到 Pod 中（使用在常规容量上加载的私钥对象容量）。同一个 key 对象可以安装到多个 Pod 中。 Kubernetes 本身对其组件进行加密，开发人员可以创建自己的密钥对象。另一种方法是将密钥对象用作环境变量。需要注意的是，为了获得更好的安全性，在预制密钥对象的情况下，Pod中的密钥对象一般都存放在tmpfs内存中。

1.2.13 名称

Kubernetes 中的每个对象都由一个 UID 和一个名称标识，用于在 API 调用中引用该对象。名称不应超过 253 个字符，并使用小写字母数字字符、下划线 (_) 和点 (.)。如果您删除一个对象，您可以创建另一个与被删除对象同名的对象，但 UID 在集群的整个生命周期内必须是唯一的。 UID 由 Kubernetes 生成，因此无需担心重复。

1.2.14 命名空间

命名空间是一个虚拟集群。由命名空间分隔的多个虚拟集群可以形成一个物理集群。每个虚拟集群都与其他虚拟集群完全隔离，它们只能通过一个通用接口交换信息。请注意，命名空间中不存在节点对象和持久存储卷。 Kubernetes 可以调度来自不同命名空间的 Pod 在同一个节点上运行。同样，来自不同命名空间的 Pod 可以使用相同的持久存储。

使用命名空间时，必须考虑网络策略和资源配额，以确保正确访问和分配物理集群资源。

1.3 深入理解Kubernetes架构

Kubernetes 有一个雄心勃勃的目标，即跨环境和云提供商管理和简化分布式系统的编排、部署和管理。它提供了许多功能和服务，这些功能和服务应该可以适应各种环境，并且会继续发展并保持对大多数用户来说足够简单。这是一项艰巨的任务。 Kubernetes 通过清晰的布局、高水平的设计和成熟的架构实现了这一点，该架构同时促进了系统的可扩展性和灵活性。 Kubernetes 的许多部分仍然是硬编码或上下文敏感的，但它们逐渐分解为插件，从而保持内核的通用性和通用性。在本节中，我们将逐层剖析 Kubernetes。首先，我们将介绍各种分布式系统设计模式以及 Kubernetes 是如何支持它们的。然后我们会介绍 Kubernetes 的外层，也就是它的 API 集。接下来，我们将介绍构成 Kubernetes 的实际组件。 ;最后对源码树做个简单的介绍，以便更好地了解Kubernetes的结构。

到本节结束时，读者将对 Kubernetes 的架构、执行以及它的一些设计决策有深入的了解。

分布式系统设计模式

托尔斯泰的《安娜·卡列尼娜》中描述幸福家庭（分布式工作系统）的一句话都是相似的。这意味着所有设计良好的分布式系统都必须遵循最佳实践和原则，才能正常运行。 Kubernetes 不仅是一个管理系统，它还应用这些最佳实践为开发人员和管理员提供高水平的服务。下面描述了几种设计模式。

1、边车模式

sidecar 模式在 Pod 中除了主应用程序容器之外还共同定位另一个容器。应用程序容器不知道 sidecar 容器，只是执行自己的任务。 Central Logging Agent 就是一个很好的例子。主容器只会记录到标准输出，但边车容器会将所有日志发送到中央日志服务，在那里将汇总来自整个系统的日志。使用 sidecar 容器比在主应用程序容器中添加中央日志具有巨大的优势，应用程序不再受中央日志的负担，如果您想升级或更改中央日志记录策略或切换到新的提供程序，只需更新并且部署了一个sidecar容器，应用容器并没有改变任何东西，所以不会被意外破坏。

2、外交官模式

外交模式是指将远程服务视为本地服务并使其成为策略的一部分。外交模式的一个很好的例子是，如果你有一个 Redis 集群，其中一个主机用于写入，其余副本用于读取，本地外交容器可以充当代理并将 Redis 暴露给本地主机应用程序容器。主应用程序容器只是简单地连接到 localhost:6379（Redis 默认端口）上的 Redis，但它实际上只是连接到在同一个 pod 中运行的外交容器，它过滤请求并将写入请求发送到真正的 Redis 主机，并发送读取随机向其中一个只读副本请求，类似于边车模式，在此期间主应用程序不知道正在运行的进程。这在测试真正的本地 Redis 集群时很有帮助。另外，如果Redis集群配置发生变化，只需要修改dipilet容器，主应用也不了解这个操作流程。

3、适配器模式

适配器模式是关于主应用程序容器的标准化输出。逐步推出的服务可能会面临以下问题：该服务生成的报表格式可能与之前版本不一致，而其他使用该输出的服务和应用程序尚未升级。适配器容器可以与新的应用程序容器共同部署在同一个 Pod 上，并将其输出与旧版本匹配，直到所有用户都升级。适配器容器与主应用程序容器共享文件系统来监控本地文件系统，每当有新应用程序写入文件时，适配器容器会立即进行适配。

4、多节点模式

Kubernetes 直接通过 Pod 直接支持单节点模式。不直接支持多节点模式，如leader选举、工作队列、分散集合等，但是可以通过标准接口组合Pods来实现Kubernetes支持。

1.4 Kubernetes API

如果你想了解一个系统的功能和它提供的服务，你需要关注它的API。 API 为系统的用户提供了全局图片。 Kubernetes 从多个角度为开发者提供了多套 REST API。一些 API 需要工具使用，而另一些 API 可以由开发人员直接使用。 API 的一个重要方面是它们也在不断发展，Kubernetes 开发人员通过尝试扩展（向现有对象添加新对象和新字段）、避免重命名或删除现有对象和字段来保持它们的可管理性。此外，所有 API 端点都是版本化的，通常也包含 Alpha 或 Beta 表示法。代码显示如下。

/api/v1

/api/v2alpha1

可以通过基于客户端库的 kubectl CLI 或直接调用 REST API 来访问 API。以下部分详细描述了身份验证和授权机制。至此，读者可以对API有一个初步的了解。

1.4.1 Kubernetes API

这是 Kubernetes 的主要 API，而且非常庞大。上面提到的所有概念和许多辅助概念都有对应的API对象和操作。使用正确的权限，可以列出、获取、创建和更新对象。以下是获取所有 pod 列表的常用操作的详细文档。

GET /api/v1/pods

它支持各种可选参数。

pretty：如果为 true，则以漂亮的形式打印输出。

labelSelector：用于限制结果的选择器表达式。

watch：如果为 true，则监视更改并返回事件流。

resourceVersion：使用 watch 仅返回此版本之后发生的事件。

timeoutSeconds：列表或监视器的超时时间。

1.4.2 自动缩放 API

自动扩缩 API 非常专注，允许控制对等级别的 pod 自动扩缩器。这个自动缩放器根据 CPU 利用率甚至特定于应用程序的指标来管理一组 Pod。它可以使用 /apis/autoscaling/v1 端点来列出、查询、创建、更新和销毁自动缩放器对象。

批处理 API

批处理 API 用于管理作业。作业是执行和终止某些活动的 Pod。与副本控制器管理的常规 Pod 不同，它们应该在作业完成时终止。批处理 API 使用 Pod 模板来指定作业，然后在大多数情况下允许通过 /apis/batch/v1 端点列出、查询、创建和删除作业。

1.5 Kubernetes 组件

Kubernetes 集群有几个控制集群的主组件，以及在每个集群节点上运行的节点组件。本节将介绍这些组件并解释它们如何协同工作。

1.5.1 主要组件

主组件通常在单个节点上运行，但在高可用性集群或大型集群中，它们可以分布在多个节点上。

1、 API 服务器

Kube API Server（Kube-API Server）提供Kubernetes REST API。由于它的无状态特性，它可以很容易地水平扩展。它的所有数据都存储在 etcd 集群中。 API 服务器是 Kubernetes 控制平面的体现。

2、等等

etcd 是一个非常可靠的分布式数据存储。 Kubernetes 使用它来存储整个集群状态。在小型临时集群中，单个 etcd 可以与所有其他主组件在同一节点上运行。但考虑到冗余和高可用性，较大的集群通常包含 3 个甚至 5 个 etcd 集群。

3、控制器管理器

控制器管理器是打包成单个二进制文件的各种管理器的集合。它包含副本控制器、pod 控制器、服务控制器和端点控制器等。所有这些控制器都通过 API 监控集群状态，它们的工作是控制集群处于目标状态。

4、调度器

Kube 调度器负责将 Pod 调度到节点中。 This is a very complex task as it requires consideration of multiple interacting factors such as the following.

Resource requirements.

Service Request.

Hard/software policy constraints.

Affinity and Anti-Affinity Specifications.

Data locality.

Deadline.

5、 DNS

As of Kubernetes 1.3, the DNS service is part of the standard Kubernetes cluster. It is scheduled as a normal Pod. Every service except the Headless service receives DNS names, and Pods can also receive DNS names, which is useful for automating exploration.

1.5.2 Node Components

Nodes in a cluster require several components to interact with the cluster master, receive workloads to execute, and update the cluster based on their state.

1、 Agent

The Kube proxy performs low-level network maintenance on each node, it is used to present local Kubernetes services, it can perform TCP and UDP forwarding, and it can find the cluster IP through environment variables or DNS.

2、 Kubelet

Kubelet is the on-node representation of Kubernetes. It is responsible for monitoring communication with the main component and managing running Pods, including the following aspects.

Download Pod secrets from the API server.

Mount volumes.

The container (Docker or Rkt) that runs the Pod.

Reports the status of nodes and each Pod.

Run the container liveness probe.

In this section, we delve into Kubernetes' internals through its API and the components used to control and manage the cluster, exploring its architecture and the design patterns it supports from a macro perspective. Section 1.6 describes the runtimes supported by Kubernetes.

1.6 Kubernetes runtime

Kubernetes originally only supported Docker as a container runtime engine, and now things have changed, Rkt has become another supported runtime engine, and there are some interesting attempts to work with Hyper.sh containers through Hypernet. One of the more important design strategies is that Kubernetes itself should be completely decoupled from a specific runtime. Kubernetes' interaction with the runtime is achieved through a relatively generic interface that the runtime engine must implement. Most of the information exchange will be achieved through pods, container concepts, and operations that can be performed on containers, and each runtime engine is responsible for ensuring that the Kubernetes runtime interface is compatible.

In this section, the runtime interface will be introduced in depth, down to a single runtime engine. After reading this section, the reader will be able to choose the runtime engine suitable for the actual use case, and know the specific practical scenarios of switching or combining multiple runtimes in the same system.

1.6.1 Runtime Interface

The runtime interface for containers is detailed in the Kubernetes project on GitHub. Kubernetes is open source, you can check the relevant URL.