畅聊Kubernetes 的问题和局限性

2014 年发布的 Kubernetes 在今天俨然已成为容器编排领域的事实标准，相信谈到 Kubernetes 的开发者都会一再复述上述现象。如下图所示，今天的大多数个人或者团队都会选择 Kubernetes 管理容器，而也有 75% 的人会在生产环境中使用 Kubernetes。

 

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

在这种全民学习和使用 Kubernetes 的大背景下，我们也应该非常清晰地知道 Kubernetes 有哪些局限性。虽然 Kubernetes 能够解决容器编排领域的大多数问题，但是仍然有一些场景是它很难处理、甚至无法处理的，只有对这些潜在的风险有清晰的认识，才能更好地驾驭这项技术，这篇文章将从集群管理和应用场景两个部分谈谈 Kubernetes 社区目前的发展和一些局限性。

集群管理

集群是一组能够在一起协同工作的计算机，我们可以将集群中的所有计算机看成一个整体，所有资源调度系统都是以集群为维度进行管理的，集群中的所有机器构成了资源池，这个巨大的资源池会为待运行的容器提供资源执行计算任务，这里简单谈一谈 Kubernetes 集群管理面对的几个复杂问题。

水平扩展性

集群大小是我们在评估资源管理系统时需要关注的重要指标之一，然而 Kubernetes 能够管理的集群规模远远小于业界的其他资源管理系统。集群大小为什么重要呢，我们先来看另一个同样重要的指标 — 资源利用率，很多工程师可能没有在公有云平台上申请过资源，这些资源都相当昂贵，在 AWS 上申请一个与主机差不多配置的虚拟机实例(8 CPU、16 GB)每个月大概需要 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 社区目前正在探索的方向，社区中的多集群兴趣小组(SIG Multi-Cluster)目前就在完成相关的工作[^8]。在作者看来，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 简化多集群的准备、更新和运维工作，你在该项目的 设计提案 中能够找到它的职责范围[^9]。

 

图 6 - Cluster API 概念

在该项目中最重要的资源就是 Machine，它表示一个 Kubernetes 集群中的节点。当该资源被创建时，特定提供商的控制器会根据机器的定义初始化并将新的节点注册到集群中，在该资源被更新或者删除时，也会执行操作达到用户的状态。

（编辑：宿州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!