谈谈 的疑问和局限性 Kubernetes

2014 年颁布的 Kubernetes 在当天俨然已成为容器编排畛域的理想规范，置信谈到 Kubernetes的开发者都会一再复述上述现象。如下图所示，当天的大少数团体或许团队都会选用 Kubernetes 治理容器，而也有 75% 的人会在消费环境中经常使用Kubernetes。

图 1 - Kubernetes 容器编排[^1]

在这种全民学习和经常使用 Kubernetes 的大背景下，咱们也应该十分明晰地知道 Kubernetes 有哪些局限性。虽然 Kubernetes能够处置容器编排畛域的大少数疑问，但是依然有一些场景是它很难处置、甚至不可处置的，只要对这些潜在的危险有明晰的看法，才干更好地驾驭这项技术，这篇文章将从集群治理和运行场景两个局部谈谈Kubernetes 社区目前的开展和一些局限性。

集群治理

集群是一组能够在一同协同上班的计算机，咱们可以将集群中的一切计算机看成一个全体，一切资源调度系统都是以集群为维度启动治理的，集群中的所无机器造成了资源池，这个渺小的资源池会为待运转的容器提供资源口头计算义务，这里便捷谈一谈Kubernetes 集群治理面对的几个复杂疑问。

水平裁减性

集群大小是咱们在评价资源治理系统时须要关注的关键目的之一，但是 Kubernetes能够治理的集群规模远远小于业界的其余资源治理系统。集群大小为什么关键呢，咱们先来看另一个雷同关键的目的 —资源应用率，很多工程师或许没有在私有云平台上放开过资源，这些资源都相当低廉，在 AWS 上放开一个与主机差不多性能的虚构机实例(8 CPU、16GB)每个月大略须要 150 美金，约为 1000 人民币[^2]。

图 2 - AWS EC2 多少钱

大少数的集群都会经常使用 48 CPU 或许 64 CPU 的物理机或许虚构机作为集群中的节点，假设咱们的集群中须要蕴含 5,000个节点，那么这些节点每个月大略要 8,000,000 美元，约为 50,000,000 人民币，在这样的集群中优化 1% 的资源应用率就相当于每个月节俭了500,000 的老本。

少数在线义务的资源应用率都很低，更大的集群意味着能够运转更多的上班负载，而多种高峰和低谷期不同的负载部署在一同可以成功超售，这样能够清楚地提高集群的资源应用率，假设单个集群的节点数足够多，咱们在部署不同类型的义务时会有更正当的组合，可以完美错开不同服务的高峰期。

Kubernetes 社区对外宣传的是单个集群最多允许 5,000 节点，Pod 总数不超越 150,000，容器总数不超越 300,000 以及单节点Pod 数量不超越 100 个[^3]，与几万节点的 Apache Mesos 集群、50,000 节点的微软 YARN 集群[^4]相比，Kubernetes的集群规模整整差了一个数量级。虽然阿里云的工程师也经过优化 Kubernetes 的各个组件成功了 5位数的集群规模，但是与其余的资源治理方式相比却有比拟大的差距[^5]。

图 3 - Apache Mesos 与 Hadoop YARN

须要留意的是 Kubernetes 社区虽然对外宣称单集群可以允许 5,000节点，同时社区也有各种各样的集成测试保障每个改动都不会影响它的伸缩性[^6]，但是 Kubernetes真的十分复杂，咱们没有方法保障你经常使用的每特性能在扩容的环节中都不出疑问。而在消费环境中，咱们甚至或许在集群扩容到 1000 ~ 1500节点时遇到瓶颈。

每个稍具规模的大公司都想要成功更大规模的 Kubernetes 集群，但是这不是一个改几行代码就能处置的便捷疑问，它或许须要咱们限度 Kubernetes中一些性能的经常使用，在扩容的环节中，etcd、API主机、调度器以及控制器都有或许出现疑问。社区中曾经有一些开发者留意到了其中的一些疑问，例如在节点上参与缓存降低 API主机的负载[^7]，但是要推进相似的扭转还是很艰巨的，有志之士可以尝试在社区推进相似的名目。

多集群治理

单个集群的容量再大也不可处置企业面对的疑问，哪怕有一天 Kubernetes 集群可以到达 50,000节点的规模，咱们依然须要治理多个集群，多集群治理也是 Kubernetes 社区目前正在探求的方向，社区中的多集群兴味小组(SIGMulti-Cluster)目前就在成功相关的上班[^8]。在作者看来，Kubernetes的多集群会带来资源不平衡、跨集群访问艰巨以及提高运维和治理老本三大疑问，咱们在这里谈一谈目前在开源社区和业界几种可供参考和选用的处置打算。

首先要引见的是 kubefed，该名目是 Kubernetes 社区给出的处置打算，它同时提供了跨集群的资源和网络治理的性能，社区的多集群兴味小组(SIGMulti-Cluster)担任了该名目的开发上班：

图 4 - Kubernetes 联邦

kubefed经过一个中心化的联邦控制面板治理多集群中的元数据，高层的控制面板会为治理器群中的资源创立对应的联邦对象，例如：FederatedDeployment：

-path:-path:value:-path:op:#Ensureanannotation-path:op:#Addsanargument`-q`#thiswillobviouslyshifttheexistingarguments,if-path:op:value:

高层的控制面板会依据联邦对象 FederatedDeployment 的规格文件生成对应的 Deployment 并推送到高层的集群，高层集群可以反常依据Deployment 中的定义创立特定数量的正本。

图 5 - 从联邦对象到普通对象

FederatedDeployment 只是一种最便捷的散发战略，在消费环境中咱们宿愿经过联邦的集群成功容灾等复杂性能，这时可以应用ReplicaSchedulingPreference 在不同集群中成功愈加默认的散发战略：

上述调度的战略可以成功上班负载在不同集群之间的权重，在集群资源无余甚至出现疑问时将实例迁徙到其余集群，这样既能够提高服务部署的灵敏性和可用性，基础架构工程师也可以更好地平衡多个集群的负载。

咱们可以以为 kubefed的关键作用是将多个松懈的集群组成强耦合的联邦集群，并提供愈加初级的网络和部署性能，这样咱们可以更容易地处置集群之间资源不平衡和连通性的一些疑问，但是该名目的关注点不蕴含集群生命周期的治理，

集群接口

Cluster API 也是 Kubernetes 社区中与多集群治理相关的名目，该名目由集群生命周期小组(SIGCluster-Lifecycle)担任开发，其关键目的是经过申明式的 API 简化多集群的预备、更新和运维上班，你在该名目的 设计提案中能够找到它的职责范围[^9]。

图 6 - Cluster API 概念

在该名目中最关键的资源就是 Machine，它示意一个 Kubernetes集群中的节点。当该资源被创立时，特定提供商的控制器会依据机器的定义初始化并将新的节点注册到集群中，在该资源被更新或许删除时，也会口头操作到达用户的形态。

这种战略与阿里的多集群治理的方式有一些相似，它们都经常使用申明式的 API 定义机器和集群的形态，而后经常使用 Kubernetes 原生的 Operator模型在更高一层的集群中治理高层集群，这能够极大降低集群的运维老本并提高集群的运转效率[^10]，不过相似的名目都没有思考跨集群的资源治理和网络治理。

运行场景

咱们在这一节将谈谈 Kubernetes中一些幽默的运行场景，其中包括运行散发方式的现状、批处置调度义务以及硬多租户在集群中的允许，这些是社区中比拟关注的疑问，也是 Kubernetes目前的盲点。

运行散发

Kubernetes 主名目提供了几种部署运行的最基本方式，区分是 Deployment、StatefulSet 和DaemonSet，这些资源区分适用于有形态服务、有形态服务和节点上的守护进程，这些资源能够提供最基本的战略，但是它们不可处置愈加复杂的运行。

图 7 - Kubernetes 运行治理

随着 CRD 的引入，目前社区的运行治理小组(SIG Apps)基本不会向 Kubernetes主仓库引入较大的改动，大少数的改动都是在现有资源上启动的修补，很多经常出现的场景，例如只运转一次性的 DaemonSet[^11]以及金丝雀和蓝绿部署等性能，如今的资源也存在很多疑问，例如 StatefulSet 在初始化容器中卡住不可回滚和更新[^12]。

咱们可以了解社区不想在 Kubernetes 中保养更多的基本资源，经过几个基本的资源可以笼罩 90% 的场景，剩下的各种复杂场景可以让其余社区经过CRD 的方式成功。不过作者以为假设社区能够在抢先成功更多高品质的组件，这关于整个生态都是很有价值并且很关键的上班，须要留意的是假设各位读者想要在Kubernetes 名目中成为奉献者，SIG Apps 或许不是一个很好的选用。

批处置调度

机器学习、批处置义务和流式义务等上班负载的运转从 Kubernetes 降生第一天起到当天都不是它的强项，大少数的公司都会经常使用 Kubernetes运转在线服务处置用户恳求，用 Yarn 治理的集群运转批处置的负载。

hadoop-yarn

图 8 - Hadoop Yarn

在线义务和离线义务往往是两种一模一样的作业，大少数的在线义务都是有形态的服务，它们可以在不同机器上启动迁徙，彼此很难有极强的依赖相关;但是很多离线义务的拓扑结构都很复杂，有些义务须要多个作业一同口头，而有些义务须要依照依赖相关先后口头，这种复杂的调度场景在Kubernetes 中比拟难以处置。

在 Kubernetes 调度器引入调度框架之前，一切的 Pod在调度器看来是没有任何关联的，不过有了调度框架，咱们可以在调度系统中成功愈加复杂的调度战略，例如保障一组 Pod 同时调度的 PodGroup[^13]，这关于Spark 和 TensorFlow 义务十分有用。

Volcano 也是在 Kubernetes 上构建的批处置义务治理系统[^14]，它能够处置机器学习、深度学习以及其余大数据运行，可以允许包括TensorFlow、Spark、PyTorch 和 MPI 在内的多个框架。

图 9 - Volcano

虽然 Kubernetes 能够运转一些批处置义务，但是距离在这个畛域上取代 Yarn等老牌资源治理系统上还有十分大的差距，置信在较长的一段期间内，大少数公司都会同时保养 Kubernetes 和 Yarn两种技术栈，区分治理和运转不同类型的上班负载。

硬多租户

多租户是指同一个软件实例可以为不同的用户组提供服务，Kubernetes 的多租户是指多个用户或许用户组经常使用同一个 Kubernetes 集群，当天的Kubernetes 还很难做到硬多租户允许，也就是同一个集群的多个租户不会相互影响，也感知不到彼此的存在。

硬多租户在 Kubernetes中是一个很关键、也很艰巨的课题，合租公寓就是一个典型的多租户场景，多个租客共享屋宇内的基础设备，硬多租户要求多个访客之间不会相互影响，你可以构想这有如许艰巨，Kubernetes社区甚至有一个上班小组专门讨论和钻研相关的疑问[^15]，但是虽然感兴味的工程师很多，但是成绩却十分有限。

图 10 - 多租户

虽然 Kubernetes经常使用命名空间来划分虚构机群，但是这也很难成功真正的多租户。多租户的允许究竟有哪些作用呢，这里便捷列几个多租户带来的好处：

Kubernetes 带来的额外部署老本关于小集群来说十分高昂，稳固的 Kubernetes 集群普通都须要至少三个运转 etcd的主节点，假设大少数的集群都是小集群，这些额外的机器会带来很高的额外开支;

Kubernetes 中运转的容器或许须要共享物理机和虚构机，一些开发者或许在公司外部遇到过自己的服务被其余业务影响，由于主机上容器或许隔离了 CPU和内存资源，但是没有隔离 I/O、网络 和 CPU 缓存等资源，这些资源的隔离是相对艰巨的;

假设 Kubernetes能够成功硬多租户，这不只对云服务商和小集群的经常使用者来说都是个福音，它还能够隔离不同容器之间的影响并防止潜在安保疑问的出现，不过这在现阶段还是比拟难成功的。

总结

每个技术都有自己的生命周期，越底层的技术生命周期会越长，而越高层的技术生命周期也就越短，虽然 Kubernetes是当今容器界的扛把子，但是未来的事件没有人可以说的准。咱们要时辰清楚手中工具的优势和缺陷，花一些期间学习 Kubernetes中设计的精髓，不过假设在未来的某一天 Kubernetes 也成为了过去，咱们也应该感到喜悦，由于会有更好的工具取代它。

[^1]: Kubernetes and Container Security and Adoption Trends

[^2]: AWS Pricing Calculator

[^3]: Considerations for large clusters

[^4]: How Microsoft drives exabyte analytics on the world’s largest YARNcluster

[^5]: 备战双 11!蚂蚁金服万级规模 K8s集群治理系统如何设计?

[^6]: sig-scalability-kubemark dashboard

[^7]: Node-local API cache #84248

[^8]: Multicluster Special Interest Group

[^9]: Cluster API Scope and Objectives

[^10]: Demystifying Kubernetes as a service – How Alibaba cloud manages10,000s of Kubernetes clusters

[^11]: Run job on each node once to help with setup #64623

[^12]: StatefulSet does not upgrade to a newer version of manifests #78007

[^13]: Coscheduling based on PodGroup CRD

[^14]: Volcano · A Kubernetes Native Batch System

[^15]: Kubernetes Working Group for Multi-Tenancy