2014 年发布的 KubeRnetes 在今天俨然已成为容器编排领域的事实标准，相信谈到 KubeRnetes 的开发者都会一再复述上述现象。如下图所示，今天的大多数个人或者团队都会选择 KubeRnetes 管理容器，而也有 75% 的人会在生产环境中使用 KubeRnetes。
图 1 – KubeRnetes 容器编排
在这种全民学习和使用 KubeRnetes 的大背景下，我们也应该非常清晰地知道 KubeRnetes 有哪些局限性。虽然 KubeRnetes 能够解决容器编排领域的大多数问题，但是仍然有一些场景是它很难处理、甚至无法处理的，只有对这些潜在的风险有清晰的认识，才能更好地驾驭这项技术，这篇文章将从集群管理和应用场景两个部分谈谈 KubeRnetes 社区目前的发展和一些局限性。
集群管理
集群是一组能够在一起协同工作的计算机，我们可以将集群中的所有计算机看成一个整体，所有资源调度系统都是以集群为维度进行管理的，集群中的所有机器构成了资源池，这个巨大的资源池会为待运行的容器提供资源执行计算任务，这里简单谈一谈 KubeRnetes 集群管理面对的几个复杂问题。
水平扩展性
集群大小是我们在评估资源管理系统时需要关注的重要指标之一，然而 KubeRnetes 能够管理的集群规模远远小于业界的其他资源管理系统。集群大小为什么重要呢，我们先来看另一个同样重要的指标 &Mdash; 资源利用率，很多工程师可能没有在公有云平台上申请过资源，这些资源都相当昂贵，在 AWS 上申请一个与主机差不多配置的虚拟机实例(8 CPU、16 GB)每个月大概需要 150 美金，约为 1000 人民币。
图 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 个，与几万节点的 Apache Mesos 集群、50,000 节点的微软 YARN 集群相比，KubeRnetes 的集群规模整整差了一个数量级。虽然阿里云的工程师也通过优化 KubeRnetes 的各个组件实现了 5 位数的集群规模，但是与其他的资源管理方式相比却有比较大的差距。
图 3 – Apache Mesos 与 Hadoop YARN
需要注意的是 KubeRnetes 社区虽然对外宣称单集群可以支持 5,000 节点，同时社区也有各种各样的集成测试保证每个改动都不会影响它的伸缩性，但是 KubeRnetes 真的非常复杂，我们没有办法保证你使用的每个功能在扩容的过程中都不出问题。而在生产环境中，我们甚至可能在集群扩容到 1000 ~ 1500 节点时遇到瓶颈。
每个稍具规模的大公司都想要实现更大规模的 KubeRnetes 集群，但是这不是一个改几行代码就能解决的简单问题，它可能需要我们限制 KubeRnetes 中一些功能的使用，在扩容的过程中，etcd、API 服务器、调度器以及控制器都有可能出现问题。社区中已经有一些开发者注意到了其中的一些问题，例如在节点上增加缓存降低 API 服务器的负载，但是要推动类似的改变还是很困难的，有志之士可以尝试在社区推动类似的项目。
多集群管理
单个集群的容量再大也无法解决企业面对的问题，哪怕有一天 KubeRnetes 集群可以达到 50,000 节点的规模，我们仍然需要管理多个集群，多集群管理也是 KubeRnetes 社区目前正在探索的方向，社区中的多集群兴趣小组(SIG Multi-ClUSteR)目前就在完成相关的工作。在作者看来，KubeRnetes 的多集群会带来资源不平衡、跨集群访问困难以及提高运维和管理成本三大问题，我们在这里谈一谈目前在开源社区和业界几种可供参考和选择的解决方案。
kubefed
首先要介绍的是 kubefed，该项目是 KubeRnetes 社区给出的解决方案，它同时提供了跨集群的资源和网络管理的功能，社区的多集群兴趣小组(SIG Multi-ClUSteR)负责了该项目的开发工作：
图 4 – KubeRnetes 联邦
kubefed 通过一个中心化的联邦控制面板管理多集群中的元数据，上层的控制面板会为管理器群中的资源创建对应的联邦对象，例如：FedeRatedDeployMent：
kind: FedeRatedDeployMent spec: OVeRRides: # apply OVeRRides to clUSteR1 – clUSteRNaMe: clUSteR1 clUSteROVeRRides: # Set the Replicas field to 5 – path: “/spec/Replicas” value: 5 # Set the image of the fiRst contAIneR – path: “/spec/template/spec/contAIneRs/0/image” value: “Nginx:1.17.0-alpine” # EnsuRe the annOTAtion “foo: baR” exists – path: “/Metadata/annOTAtions” op: “add” value: foo: baR # EnsuRe an annOTAtion wITh key “foo” does not exist – path: “/Metadata/annOTAtions/foo” op: “ReMOVe” # Adds an aRguMent `-q` at index 0 of the aRgs list # tHis will obvioUSly sHift the existing aRguMents, if any – path: “/spec/teMplate/spec/contAIneRs/0/aRgs/0” op: “add” value: “-q”
上层的控制面板会根据联邦对象 FedeRatedDeployMent 的规格文件生成对应的 DeployMent 并推送到下层的集群，下层集群可以正常根据 DeployMent 中的定义创建特定数量的副本。
图 5 – 从联邦对象到普通对象
FedeRatedDeployMent 只是一种最简单的分发策略，在生产环境中我们希望通过联邦的集群实现容灾等复杂功能，这时可以利用 ReplicaSchedulingPRefeRence 在不同集群中实现更加智能的分发策略：
APIversion: scheduling.kubefed.io/v1alpha1 kind: ReplicaSchedulingPRefeRence Metadata: naMe: test-deployMent naMespACE: test-ns spec: taRgetKind: FedeRatedDeployMent tOTAlReplicas: 9 clUSteRs: A: MinReplicas: 4 MaxReplicas: 6 weight: 1 B: MinReplicas: 4 MaxReplicas: 8 weight: 2
上述调度的策略可以实现工作负载在不同集群之间的权重，在集群资源不足甚至出现问题时将实例迁移到其他集群，这样既能够提高服务部署的灵活性和可用性，基础架构工程师也可以更好地平衡多个集群的负载。
我们可以认为 kubefed 的主要作用是将多个松散的集群组成强耦合的联邦集群，并提供更加高级的网络和部署功能，这样我们可以更容易地解决集群之间资源不平衡和连通性的一些问题，然而该项目的关注点不包含集群生命周期的管理，
集群接口
ClUSteR API 也是 KubeRnetes 社区中与多集群管理相关的项目，该项目由集群生命周期小组(SIG ClUSteR-lifecycle)负责开发，其主要目标是通过声明式的 API 简化多集群的准备、更新和运维工作，你在该项目的 设计提案 中能够找到它的职责范围。
图 6 – ClUSteR API 概念
在该项目中最重要的资源就是 MacHine，它表示一个 KubeRnetes 集群中的节点。当该资源被创建时，特定提供商的控制器会根据机器的定义初始化并将新的节点注册到集群中，在该资源被更新或者删除时，也会执行操作达到用户的状态。
这种策略与阿里的多集群管理的方式有一些相似，它们都使用声明式的 API 定义机器和集群的状态，然后使用 KubeRnetes 原生的 OpeRaTor 模型在更高一层的集群中管理下层集群，这能够极大降低集群的运维成本并提高集群的运行效率，不过类似的项目都没有考虑跨集群的资源管理和网络管理。
应用场景
我们在这一节将谈谈 KubeRnetes 中一些有趣的应用场景，其中包括应用分发方式的现状、批处理调度任务以及硬多租户在集群中的支持，这些是社区中比较关注的问题，也是 KubeRnetes 目前的盲点。
应用分发
KubeRnetes 主项目提供了几种部署应用的最基本方式，分别是 DeployMent、StatefulSet 和 DaeMonSet，这些资源分别适用于无状态服务、有状态服务和节点上的守护进程，这些资源能够提供最基本的策略，但是它们无法处理更加复杂的应用。
图 7 – KubeRnetes 应用管理
随着 CRD 的引入，目前社区的应用管理小组(SIG apps)基本不会向 KubeRnetes 主仓库引入较大的改动，大多数的改动都是在现有资源上进行的修补，很多常见的场景，例如只运行一次的 DaeMonSet 以及金丝雀和蓝绿部署等功能，现在的资源也存在很多问题，例如 StatefulSet 在初始化容器中卡住无法回滚和更新。
我们可以理解社区不想在 KubeRnetes 中维护更多的基本资源，通过几个基本的资源可以覆盖 90% 的场景，剩下的各种复杂场景可以让其他社区通过 CRD 的方式实现。不过作者认为如果社区能够在上游实现更多高质量的组件，这对于整个生态都是很有价值并且很重要的工作，需要注意的是假如各位读者想要在 KubeRnetes 项目中成为贡献者，SIG apps 可能不是一个很好的选择。
批处理调度
机器学习、批处理任务和流式任务等工作负载的运行从 KubeRnetes 诞生第一天起到今天都不是它的强项，大多数的公司都会使用 KubeRnetes 运行在线服务处理用户请求，用 YaRn 管理的集群运行批处理的负载。
hadoop-yaRn
ͼ 8 – Hadoop YaRn
在线任务和离线任务往往是两种截然不同的作业，大多数的在线任务都是无状态的服务，它们可以在不同机器上进行迁移，彼此很难有极强的依赖关系;但是很多离线任务的拓扑结构都很复杂，有些任务需要多个作业一同执行，而有些任务需要按照依赖关系先后执行，这种复杂的调度场景在 KubeRnetes 中比较难以处理。
在 KubeRnetes 调度器引入调度框架之前，所有的 Pod 在调度器看来是没有任何关联的，不过有了调度框架，我们可以在调度系统中实现更加复杂的调度策略，例如保证一组 Pod 同时调度的 PodGRoup，这对于 SpaRk 和 TensoRFlow 任务非常有用。
#
