通过重新构建Kubernetes来实现更具弹性的容器编排系统

通过重新构建Kubernetes来实现更具弹性的容器编排系统

译自：rearchitecting-kubernetes-for-the-edge

摘要

近年来，kubernetes已经发展为容器编排的首要选择。kubernetes主要面向云环境，但新的边缘场景要求性能、可用性和可扩展编排。kubernetes在etcd(一个强一致的键值存储)中保存了所有集群信息。我们发现规模较大的etcd集群可以提供更高的可用性，但请求延迟也会显著增加，吞吐量显著下降。再加上大约30%的Kubernetes请求是写入的，这直接影响了Kubernete的请求延迟和可用性，降低了其对边缘的适用性。我们重新审视了强一致的需求，并提出了一个最终一致性的方案。该方案可以提供更高的性能、可用性和可扩展性，且能够支持大部分对kubernetes的需求。目的是为了让kubernetes更适用于对性能有严格要求，且需要动态伸缩的边缘场景。

1 简介

近年来，容器和相关的编排技术已经广泛用于工业领域。kubernetes[12]俨然已经成为一个重要的数据中心解决方案。边缘场景下普遍会涉及上千个使用有限CPU和RAM的节点，因此它们对性能、可用性以及可靠的编排能力有一定要求。Kubernetes已经广泛应用于整个行业，其中59%的大型组织已经在生产中使用Kubernetes[15]。kubernetes的灵活性可以实现函数服务、存储编排和公有云集成[7]等。这种采纳度和灵活性使得Kubernetes成为一个有吸引力的边缘部署平台。kubernetes使用etcd[8]作为所有控制面组件的唯一可信源。这使得etcd成为所有请求路径的关键因素。第二章介绍了Kubernetes和etcd的背景。

虽然在边缘部署Kubernetes很有吸引力，但仍然存在一些挑战。Kubernetes和etcd都可能是资源密集型的[9,11]，因此倾向于将Kubernetes部署到边缘[3,4,10]。相比云数据中心，边缘环境通常具有更慢的带宽以及更高的网络连接延迟，尤其是到非本地服务的连接。这些环境可能会分布在更大的范围内，并且由于邻近性，会对用户交互做出更多响应，同时需要容忍多种类型的故障。由于这些严苛的条件，因此性能、可靠性和可扩展编排就成为其关键需求。第三章我们调研了etcd的性能限制，以及对可扩展性和kubernetes的影响。

Kubernetes依赖etcd，但其有限的可扩展性会导致边缘的可用性和效率问题。Kubernetes受到根本设计决策的限制：依赖存储的强一致性。第四章我们会审视用于提升边缘性能、可用性和可扩展编排的设计决策。

如果不依赖强一致性，架构可能会相对容易一些，特别是在实现性能、可用性和可扩展性方面。第五和第六章会讨论实现上的相关工作。

本论文的主要贡献是：(1)解释了etcd如何成为Kubernetes集群的瓶颈，第二章；(2)大规模场景下验证etcd的性能，并讨论对可用性的影响,，第三章；(3)回到强一致性设计上，并提出使用最终一致性，第四章。

2 KUBERNETES和ETCD

Kubernetes 将容器进行分组管理，称为Pods。Pods会被分配到工作节点，并使用本地守护进程(Kubelet)管理其生命周期。当需要在控制面实现如Pods和services副本时，会需要更多的资源。控制面由主节点的Pods构成，实现了核心功能，如调度和API server。

request type	Count	percentage
Range	1542	52.3
Txn Range	476	16.1
Txn Put	866	29.3
Watch create	67	2.3
Total	2951	100

表1:Etcd请求计数。范围请求都是线性化的。忽略可忽略不计的请求。

这些控制面组件都是无状态的，可以通过水平扩展来帮助提升性能和冗余。期望的集群状态以及当前应用状态、节点和其他资源都保存在一个etcd集群中。Kubernetes通常部署在一个具有高带宽、低延迟网络的数据中心环境中。理想情况下，为了提高可靠性[9]，可以部署在多个数据中心中，这需要在每个数据中心中同时运行主节点和etcd。但跨数据中心部署etcd需要在权衡其可用性和一致性，根据CAP理论[24]，在网络分区场景下，etcd牺牲了可用性来保证强一致性。

2.1 etcd

etcd是一个强一致的分布式键值存储，它使用Raft一致性协议[33]来维护一致性和写仲裁。作为Kubernetes的控制面组件，与其他控制面服务一样，etcd会被部署在集群的单独机器或主机上。但由于存在与其他节点保证强一致性带来的开销，因此它并不是可以水平扩容的。推荐的etcd节点为3或5个，在保证高可用的时候减少强一致性带来的开销[14]。

表1划分了到一个单节点etcd集群的Kubernetes请求，这些请求用于做一些基本的Kubernetes操作(包括配置)，平均运行10次。操作中会创建含3个Pods的deployment，扩容到10个副本，然后缩容到5个副本，最后删除该deployment。这种验证方式简单描述了Kubernetes中deployment的扩缩容场景。Range 请求是通过多个键进行的GET操作，PUT是对单个键的写入，这些请求也可以包含在事务中(txn)。一个watch create请求告诉etcd通知请求者所提供范围内所有键的变更信息。从这张表中，我们可以看到，Put占了大约30%的总请求量，Put请求在集群生存期内可能会按比例增加。在变更频繁时，组件会依赖watch进行更新，而不是通过range请求轮询。因此，Etcd对写入的有效处理是Kubernetes正常运行的一个重要因素。

2.2 调度

本章看下如何调度一个ReplicaSet的一个新Pod(见图1)。当变更一个Replicaset资源的replicas字段时会触发调度新的Pod。该值的变化可能源于故障节点、自动缩放器或手动缩放。步骤1和2中，ReplicaSet controller通过watch观察到ReplicaSet资源产生了更新，并确定必要的后续动作，本场景下会创建一个新的Pod资源。步骤3和4可以看到Pod资源被写入etcd。由于etcd的强一致性，步骤5要求大部分成员完成写操作(写仲裁)。

图1：调度Pod的请求流。控制平面组件为红色，etcd节点为绿色，节点本地组件为蓝色，群集外部组件为黄色。

步骤6和7中，新的Pod资源会传递到调度器，这也是通过一个注册的watch完成的，但此处watch的是Pod资源。现在Pod资源并不会指定哪个节点去运行。调度器会过滤出适合的节点，并选出合适的节点去运行该Pod。然后在步骤8和9中，调度器会将更新后的Pod资源(带分配的节点)信息写入etcd。在步骤10中，需要再一次将数据传递给大部分成员。更新后的Pod资源会通知到相关节点上的Kubelet(步骤11和12)。至此Kubelet会开始启动容器流程，包括从容器仓库拉取容器镜像(步骤13)。在启动Pod过程中，会将事件写入etcd(步骤14和15，以及相关的写仲裁--步骤16)。

在完成这些步骤之后，就可以在节点上成功配置并运行Pod(由Kubelet管理)。后面会持续产生更多事件，如在指定新的副本数时会触发ReplicaSet资源的更新。但这些事件价值并不大，因为ReplicaSet资源通常受Department资源的控制，这些事件反而增加了额外的通信和延迟，类似地，Kubernetes自定义控制器和资源也会导致通信和调度延迟显著增加，并延迟Pod的初始化，在图1中使用★来表示这些步骤。可以看到，很多步骤需要进行独立的写仲裁，这些步骤增加了Pod调度延迟，并成为影响可靠性和可用性的依赖链上的一部分。虽然etcd集群中的写仲裁是并行的，且整体延迟受限于最慢的节点，但大型集群会加剧这种情况，由于主节点承受着更多的通信负载，因此节点不太可能在相同的时间内执行写操作。

3 etcd性能

在大型环境(如edge)中的etcd需要同时保证性能和高效的扩展性。本章会展示对etcd扩展性的初步验证结果。

测试采用etcd官方的性能验证工具来测试两种不同的操作：put和线性range请求。在etcd中，线性读必须返回集群的共识值。每次测试只会使用单一的请求类型。

为了运行一定数量(3.4.13版本)的etcd节点，我们使用Docker来实例化etcd节点，并通过Docker网络组成具有安全通信的集群。每个容器的资源限制为2CPUs和1GB RAM，使用SSD作为存储。主机为Linux，内核版本4.15.0，CPU为Intel Xeon 4112，含16核CPU以及196GB RAM。每个测试配置会重复执行10次，并给出这些重复的中间值。测试会涉及所有节点(不仅仅是主节点)，每次运行都会使用1000个客户端，每个客户端会创建100条连接，总计100000个操作。目的是在一个没有网络延迟的理想环境下提供一个最佳的场景来验证etcd的性能和可扩展性。网络干扰会进一步增加系统的可变性和不稳定性，导致更多故障场景，如部分分区[1,17]。

图2a展示了通过一系列延迟开销来达到强一致写的目的，每次写操作都需要保证将数据写入大部分节点。同时读延迟相对较低，避免该延迟影响到数据(到磁盘)的刷新。随着集群规模的增加，主节点需要执行的同步工作也会增加，进而导致可见的性能下降。使用最终一致性存储时，读写延迟曲线比较类似，并随着集群的扩展而降低(可以更有效地分散负载)。

图2b展示了节点数目增加对吞吐量的影响。在这两种测试场景下，大型etcd集群规模都会导致严重的吞吐量下降。由于请求需要多数仲裁，因此会导致节点间产生大量请求，最终成为瓶颈并降低吞吐量。使用最终一致性存储可以提升吞吐量，原因是不需要在节点之间协调请求[41]。

由于在扩展时存在性能限制，etcd需要权衡性能和可用性。这种可用性上的限制限制可能会导致Kubernetes集群无法处理故障，或无法通过扩展服务来满足需求。这些结论和占相当比例的Kubernetes puts请求表明etcd和这类强一致性数据存储在更苛刻的边缘环境下是不够的。

4 最终一致性存储

本章介绍如何使用最终一致性存储来替换etcd，以及相关的实现考量点。

4.1 etcd API

由于API server和etcd之间存在耦合，因此需要实现实现并暴露相同的API(尽管内部运作和保障有所不同)。这种方式可以确保不需要对Kubernetes的组件进行修改。

由于架构上的差异，提议的方式将暴露不同于etcd的API行为。

图3：提议的数据存储分配Pod的请求流。数据存储节点之间的同步现在是延迟的，不会干扰请求的关键路径。

例如，在提议的工作中，确定哪个节点是主节点是不明智的，相反，它可能会将每个节点作为领导者。

4.2 延迟同步

为了实现API的功能来获得低延迟，提议的数据存储需要支持单节点的读写，而无需立即与其他节点建立通信。这可能会因为并行写入其他节点而引入数据冲突。无冲突复制数据类型(CRDTs)[37]可以以延迟同步的方式解决数据冲突。由于关键路径中的数据存储节点之间没有请求，这样就可以在大规模集群下快速响应API server。

CRDTs 有两种主要的类型：基于状态的和基于操作的。为了同步基于状态的两个副本，CRDTs 会传输整个本地状态来与远端状态进行合并。相反，对于基于操作的CRDTs，只会给远端传输下发的操作。相比于基于状态的CRDTs ，基于操作的CRDTs 的带宽要求更小 [18, 23, 40]。

Kubernetes使用protobuf格式文件来声明存储到etcd种的资源格式，然后解析为Json。由于这些资源还不是CRDTs，因此只会在存储中进行转换，该过程可能会需要计算新值和存储值的区别，并导出相应的操作到CRDT。通过这些操作和对数据格式的了解，我们可以使用JSON CRDT[27]来提供对Kubernetes资源的最终一致性。最近的工作中[28]，我们在不可信环境的不同节点的单次往返同步中引入了低延迟。这可以应用于CRDTs，进而为边缘提供高效的同步方式。

4.3 对Kubernetes的影响

从表1中，我们看到事务在etcd的请求中占很大的比例。由于没有了一致性，提议的数据存储中的事务在执行时间内仅会操作目标存储的数据。这意味着可能会操作不同于其他节点的旧数据。但概率有界过时[19]表明最终一致性系统仍然可以显示数据的最新更新。此外，由于Kubernetes组件的控制回路，任何错误都可以被及时矫正。例如，如果两个不同的节点同时增加了一个ReplicaSet资源，此时可能会调度两个新的Pods。这些数据节点同步时，可能会将这些变更合并为总计增加两个副本。Kubernetes控制器会观察到新的值，然后决定是否可以保持或减少副本数。

5 架构实现

由于提议的数据存储提升了可扩展性且去除了一致性的要求，因此，它可以使用自动扩缩容。这样可以更加优化资源使用。如果数据存储部署在Kubernetes集群内部，那么可以使用原生的水平扩缩容器作为低复杂度的解决方案。目前的etcd并没有使用这种特性，原因是存在与强一致性系统耦合的缩放限制。

而提议的数据存储可以通过可扩展性来提高可用性，还可以使分区数据中心保持可操作性。快速响应故障或需求变更是一种重要的运维优势，因为系统故障通常会导致复杂问题[1]。

在边缘环境中，提议的数据存储可以随Kubernetes集群的规则扩大而扩大。可以通过对无状态的控制面进行水平扩容来降低延迟，特别适用于调度。而etcd由于无法扩展到这个程度，因而对请求延迟的限制也相对较低。

通过这种可扩展性，可以很灵活地将(带数据存储的)控制面部署到每个工作节点，从而使Kubernetes去中心化。当前的Kubernetes调度器会被一个本地优先的分布式调度器[34, 38, 39, 42]取代。重构意味着在调度过程中，任何请求无需离开始发节点，大大减少了调度延迟。通过这种方式可以实现高效的反应式自动扩缩容，并可以实现原生的函数即服务。

6 相关工作

新的边缘场景包括5G网络[20]，网络计算[30]和弹性CDN[31]。所有这些场景都要求在边缘保证低延迟和可靠性的前提下编排大量机器。Kubernetes在边缘编排中已经非常流行[21,22]。Kubernetes的高性能和高可用性，使其非常适合从这些场景。

联邦Kubernetes[5]会在集群之间分配工作，由负责在成员集群之间分配任务的主机集群组成。这种中心化的方式存在与大型但集群类似的问题，这导致了新的针对使用CRDT的分布式联邦模型的研究[32]。它将集群本地状态与联邦状态分开，只关注联邦状态。 相反，我们的工作解决了集群局部状态的问题。

DOCMA [26]是一个新的基于微服务的容器编排器。它实现了一种去中心化的架构，可以在上千个节点中进行服务部署。但它缺少Kubernetes可以提供的很多特性。DOCMA 表明区中心话的编排具有更高的扩展性，并提供了冗余。

针对边缘环境提出的Kubernetes架构各不相同，但都受到etcd中集中状态的限制。一些提议中会将主节点和etcd部署在一个数据中心中，只将工作节点部署在云端[3]。但到云端的网络可能延迟较高且不稳定，这意味着需要做进一步设计来保证边缘的健壮性[2,6]。其他提议会将所有组件部署在边缘，包括数据中心[4]，但这种方式可能会收到资源的限制。

软件定义网络中有很多围绕控制面状态一致性的研究[25,29,36]。自适应一致性[36]和基于数据分区的一致性需求[29]可能会有助于增强我们的数据存储。或者，如果强一致性系统可以避免多数仲裁，就可以产生出更具可扩展性的系统[16，35]。但这些都需要在延迟和一致性之间进行权衡。相反，我们专注于最小化延迟，使之可以在具有挑战性的边缘环境中提供性能和可用性。

7 总结

本文强调了Kubernetes对etcd的依赖关系，以及导致可用性降低和调度延迟的因素。我们观察到etcd会成为集群扩展的瓶颈，由于其在大规模下的性能限制，会影响调度延迟和整个系统的可用性。我们的结论支持我们的观察到的现象，即依赖数据存储中的强一致性限制了Kubernetes的性能、可用性和可扩展性。.为了解决这些问题，我们建议建立一个分散化的、最终一致的、专门针对Kubernetes的存储。这种设计还为边缘环境带来了重构Kubernetes的机会，从而提高了性能、可用性和可扩展性。 这些改进可以降低延迟，支持在边缘进行更大规模的部署，可以为编排平台的未来提供相关信息，以分散的方式来实现可用性和性能。

引用

[1] 2020. A Byzantine failure in the real world. Retrieved January 13, 2021 from https://blog.cloudflare.com/a-byzantine-failure-in-the-real-world/

[2] 2020. An open platform that extends upstream Kubernetes to Edge. Retrieved January 13, 2021 from https://openyurt.io/en-us/index.html

[3] 2020. K3s: The certified Kubernetes distribution built for IoT & Edge computing. Retrieved January 13, 2021 from https://k3s.io/

[4] 2020. KubeEdge An open platform to enable Edge computing. Retrieved January 13, 2021 from https://kubeedge.io/en/

[5] 2020. KubeFed: Kubernetes Cluster Federation. Retrieved January 13, 2021 from https://github.com/kubernetes-sigs/kubefed

[6] 2020. SuperEdge: An edge-native container management system for edge computing. Retrieved January 13, 2021 from https://github.com/superedge/superedge

[7] 2021. Cloud Controller Manager. Retrieved February 09, 2021 from https:// kubernetes.io/docs/concepts/architecture/cloud-controller/

[8] 2021. Etcd: A distributed, reliable key-value store for the most critical data of a distributed system. Retrieved February 09, 2021 from https://etcd.io/

[9] 2021. Etcd: Hardware recommendations. Retrieved February 09, 2021 from https://etcd.io/docs/v3.4.0/op-guide/hardware

[10] 2021. K0s: The Simple, Solid & Certified Kubernetes Distribution. Retrieved January 13, 2021 from https://k0sproject.io/

[11] 2021. Kubernetes kubeadm resource requirements. Retrieved February 16, 2021 from https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ create-cluster-kubeadm/

[12] 2021. Kubernetes: Production-Grade Container Orchestration. Retrieved February 09, 2021 from https://kubernetes.io/

[13] 2021. Rook: Open-Source, Cloud-Native Storage for Kubernetes. Retrieved February 09, 2021 from https://rook.io/

[14] 2021. Scaling up etcd clusters. Retrieved February 09, 2021 from https://kubernetes.io/docs/tasks/administer-cluster/configure-upgradeetcd/#scaling-up-etcd-clusters

[15] 2021. Why Large Organizations Trust Kubernetes. Retrieved March 31, 2021 from https://tanzu.vmware.com/content/blog/why-large-organizations-trustkubernetes

[16] Ailidani Ailijiang, Aleksey Charapko, Murat Demirbas, and Tevfik Kosar. 2020. WPaxos: Wide Area Network Flexible Consensus. IEEE Transactions on Parallel and Distributed Systems 31, 1 (2020), 211–223. https://doi.org/10.1109/TPDS.2019. 2929793

[17] Mohammed Alfatafta, Basil Alkhatib, Ahmed Alquraan, and Samer Al-Kiswany. 2020. Toward a Generic Fault Tolerance Technique for Partial Network Partitioning. In Operating Systems Design and Implementation (OSDI) 2020.

[18] Paulo Sèrgio Almeida, Ali Shoker, and Carlos Baquero. 2015. Efficient state-based CRDTs by delta-mutation. https://doi.org/10.1007/978-3-319-26850-7_5

[19] Peter Bailis, Shivaram Venkataraman, Michael J. Franklin, Joseph M. Hellerstein, and Ion Stoica. 2012. Probabilistically Bounded Staleness for Practical Partial Quorums. Proceedings of the VLDB Endowment 5, 8 (April 2012), 776–787. https: //doi.org/10.14778/2212351.2212359

[20] Leonardo Bonati, Michele Polese, Salvatore D’Oro, Stefano Basagni, and Tommaso Melodia. 2020. Open, Programmable, and Virtualized 5G Networks: State-ofthe-Art and the Road Ahead. Computer Networks 182 (2020), 107516. https: //doi.org/10.1016/j.comnet.2020.107516

[21] Hung-Li Chen and Fuchun J. Lin. 2019. Scalable IoT/M2M Platforms Based on Kubernetes-Enabled NFV MANO Architecture. In International Conference on Internet of Things (iThings) 2019. https://doi.org/10.1109/iThings/GreenCom/ CPSCom/SmartData.2019.00188

[22] Corentin Dupont, Raffaele Giaffreda, and Luca Capra. 2017. Edge computing in IoT context: Horizontal and vertical Linux container migration. In Global Internet of Things Summit (GIoTS) 2017. https://doi.org/10.1109/GIOTS.2017.8016218

[23] Vitor Enes, Paulo S. Almeida, Carlos Baquero, and João Leitão. 2019. Efficient Synchronization of State-Based CRDTs. In IEEE International Conference on Data Engineering (ICDE) 2019. https://doi.org/10.1109/ICDE.2019.00022

[24] Armando Fox and Eric A. Brewer. 1999. Harvest, yield, and scalable tolerant systems. In Hot Topics in Operating Systems (HotOS) 1999. https://doi.org/10. 1109/HOTOS.1999.798396

[25] Soheil Hassas Yeganeh and Yashar Ganjali. 2012. Kandoo: A Framework for Efficient and Scalable Offloading of Control Applications. In Hot Topics in Software Defined Networks (HotSDN) 2012. https://doi.org/10.1145/2342441.2342446

[26] Lara L. Jiménez and Olov Schelén. 2019. DOCMA: A Decentralized Orchestrator for Containerized Microservice Applications. In 2019 IEEE Cloud Summit. https: //doi.org/10.1109/CloudSummit47114.2019.00014

[27] Martin Kleppmann and Alastair R. Beresford. 2017. A Conflict-Free Replicated JSON Datatype. IEEE Transactions on Parallel and Distributed Systems 28, 10 (2017), 2733–2746. https://doi.org/10.1109/TPDS.2017.2697382

[28] Martin Kleppmann and Heidi Howard. 2020. Byzantine Eventual Consistency and the Fundamental Limits of Peer-to-Peer Databases. arXiv:2012.00472 [cs.DC]

[29] Teemu Koponen, Martin Casado, Natasha Gude, Jeremy Stribling, Leon Poutievski, Min Zhu, Rajiv Ramanathan, Yuichiro Iwata, Hiroaki Inoue, Takayuki Hama,and Scott Shenker. 2010. Onix: A Distributed Control Platform for Large-Scale Production Networks. In Operating Systems Design and Implementation (OSDI) 2010.

[30] Michał Król, Spyridon Mastorakis, David Oran, and Dirk Kutscher. 2019. Compute First Networking: Distributed Computing Meets ICN. In Information-Centric Networking (ICN) 2019. https://doi.org/10.1145/3357150.3357395

[31] Simon Kuenzer, Anton Ivanov, Filipe Manco, Jose Mendes, Yuri Volchkov, Florian Schmidt, Kenichi Yasukata, Michio Honda, and Felipe Huici. 2017. Unikernels Everywhere: The Case for Elastic CDNs. In Virtual Execution Environments (VEE) 2017. https://doi.org/10.1145/3050748.3050757

[32] Lars Larsson, Harald Gustafsson, Cristian Klein, and Erik Elmroth. 2020. Decentralized Kubernetes Federation Control Plane. In Utility and Cloud Computing (UCC) 2020. https://doi.org/10.1109/UCC48980.2020.00056

[33] Diego Ongaro and John Ousterhout. 2014. In Search of an Understandable Consensus Algorithm. In USENIX Annual Technical Conference (USENIX ATC) 2014.

[34] Xiaoqi Ren, Ganesh Ananthanarayanan, Adam Wierman, and Minlan Yu. 2015. Hopper: Decentralized Speculation-Aware Cluster Scheduling at Scale. In Special Interest Group on Data Communication (SIGCOMM) 2015. https://doi.org/10.1145/ 2785956.2787481

[35] Denis Rystsov. 2018. CASPaxos: Replicated State Machines without logs. arXiv:1802.07000 [cs.DC][36]

[36] Ermin Sakic, Fragkiskos Sardis, Jochen W. Guck, and Wolfgang Kellerer. 2017. Towards adaptive state consistency in distributed SDN control plane. In IEEE International Conference on Communications (ICC) 2017. https://doi.org/10.1109/ ICC.2017.7997164

[37] Marc Shapiro, Nuno Preguiça, Carlos Baquero, and Marek Zawirski. 2011. Conflict-Free Replicated Data Types. In Stabilization, Safety, and Security of Distributed Systems.

[38] John A Stankovic. 1984. Simulations of three adaptive, decentralized controlled, job scheduling algorithms. Computer Networks (1976) 8, 3 (1984), 199–217. https: //doi.org/10.1016/0376-5075(84)90048-5

[39] John A. Stankovic. 1985. Stability and Distributed Scheduling Algorithms. IEEE Transactions on Software Engineering SE-11, 10 (1985), 1141–1152. https://doi. org/10.1109/TSE.1985.231862

[40] Albert van der Linde, João Leitão, and Nuno Preguiça. 2016. Δ-CRDTs: Making

标签：容器,etcd,Kubernetes,编排,2021,https,节点,延迟
来源： https://www.cnblogs.com/charlieroro/p/16581106.html