点击上方蓝字 👆关注公众号，别让消息溜走

后台回复【加群】，与牛人互动不停

集群资源是一个典型的可量化的指标，我们缺少的只是一个好用的容量规划和评估工具。

在 Kubernetes 容量规划过程中，可能会面临以下一些问题：

1. 1. 动态性： Kubernetes 集群的工作负载通常是动态变化的，包括应用的扩展和缩减、新的容器启动和停止等。因此，准确预测资源需求变得更加复杂，需要考虑这种动态性对容量规划的影响。

2. 2. 多维度资源： Kubernetes 中的容器不仅仅涉及 CPU 和内存等标准资源，还涉及网络带宽、存储等资源。同时考虑多个资源的规划，增加了问题的复杂性。

3. 3. 不同的工作负载： Kubernetes 集群可能运行多种不同类型的工作负载，包括长时间运行的服务、批处理任务等。不同工作负载的资源需求差异较大，需要针对不同类型的应用进行不同的容量规划。

4. 4. 扩展性： Kubernetes 集群可以跨多个节点和多个集群进行扩展。因此，在进行容量规划时，需要考虑不同节点和集群之间的资源分配和负载均衡。

5. 5. 变化的业务需求： 业务需求的变化可能会导致容量规划需要频繁调整。例如，推出新产品或促销活动可能会导致突然的资源需求增加，需要及时调整容量。

6. 6. 不同的环境： Kubernetes 可以在不同的环境中运行，包括开发、测试和生产环境。每个环境可能有不同的资源要求和限制，需要根据环境的特点进行容量规划。

7. 7. 监控和数据收集： 准确的容量规划需要基于实际的监控数据和性能指标。搭建和维护监控系统以及收集和分析数据可能会带来一定的挑战。

8. 8. 复杂的资源关系： Kubernetes 中的资源关系可能相互影响，例如，一个容器的 CPU 使用率可能会影响同一节点上其他容器的性能。因此，需要考虑这些资源关系对容量规划的影响。

然而，容量管理在现代 IT 环境中扮演着至关重要的角色，尤其在容器平台如 Kubernetes 中。它的核心在于优化资源分配，确保系统稳定、高效运行，同时降低成本和减少资源浪费。而在容量管理中，规划和预测是不可或缺的关键步骤，其重要性体现在以下几个方面：

1. 1. 资源合理分配和利用： 规划和预测帮助管理员了解系统资源的使用情况和趋势，从而更好地进行资源分配。通过准确预测资源需求，可以避免资源不足或过剩的问题，确保系统持续高效运行。

2. 2. 性能优化： 规划和预测使管理员能够提前发现系统资源的瓶颈和短缺，进而采取适当措施来优化系统性能。通过在系统达到临界点之前做出调整，可以避免因资源不足而导致的性能下降或故障。

3. 3. 成本控制： 在云计算和容器化环境中，资源的成本是一个重要考量因素。规划和预测可以帮助管理员避免资源过度购买或不足分配，从而降低不必要的成本开销。

4. 4. 紧急扩展避免： 通过预测未来资源需求，管理员可以提前规划扩容策略，避免在资源紧缺时临时扩展带来的问题。这有助于保持系统稳定性，避免用户体验下降。

5. 5. 故障预防： 规划和预测能够帮助管理员识别潜在的风险因素，防范系统崩溃或性能问题。通过及早采取措施，可以提前消除可能导致故障的因素。

6. 6. 业务持续性： 在高流量或特殊活动期间，资源需求可能会急剧增加。通过规划和预测，管理员可以确保系统能够满足业务需求，维持业务的连续性和稳定性。

kluster-capacity 旨在通过模拟线上真实调度器的能力来解决上述问题，目前已经支持三个能力：容量评估，调度模拟，集群压缩。

这个仓库的灵感来自于 https://github.com/kubernetes-sigs/cluster-capacity。

安装

Homebrew

通过 Homebrew 安装:

brew tap k-cloud-labs/tap
brew install k-cloud-labs/tap/kluster-capacity

Krew

通过 Krew 安装:

kubectl krew install kluster-capacity

从源码编译

编译整个程序:

$ cd $GOPATH/src/github.com/k-cloud-labs/
$ git clone https://github.com/k-cloud-labs/kluster-capacity
$ cd kluster-capacity
$ make build

有三个可用的子命令：ce、cc和ss，分别表示剩余容量估算、集群压缩和调度模拟。

容量评估

介绍

随着集群中节点上新的 Pod 被调度，消耗的资源越来越多。监控集群中可用的资源非常重要，因为运维人员可以及时增加当前的资源，以免所有资源都耗尽。或者，采取不同的步骤来增加可用资源。

集群容量包括单个集群节点的容量。容量涵盖了 CPU、内存、磁盘空间和其他资源。

整体剩余可分配容量是一个估计值。目标是分析剩余可分配的资源并估计可用容量，即可以在集群中安排给定资源需求的 Pod 实例数量。

增强

以下是对原集群容量的一些增强功能：

• • 支持直接从集群中使用现有的 Pod 作为 Pod 模板。

• • 支持针对不同的 Pod 模板进行批量模拟。

运行

# 直接使用指定的 pod 模板
$ ./kluster-capacity ce --pods-from-template <path to pod templates> 
# 使用集群中指定的 pod 作为模板
$ ./kluster-capacity ce --pods-from-cluster <namespace/name key of the pod> 

更多运行参数及功能，请执行如下命令：

$ ./kluster-capacity ce --help

演示

假设集群运行有 4 个节点和 1 个主节点，每个节点有 2 个 CPU 和 4GB 内存。而每个 Pod 所需的资源为 150m CPU 和 100Mi 内存。

$ ./kluster-capacity ce --pods-from-template <path to pod templates> --verbose
Pod requirements:
    - cpu: 150m
    - memory: 100Mi

The cluster can schedule 52 instance(s) of the pod.
Termination reason: FailedScheduling: pod (small-pod-52) failed to fit in any node
fit failure on node (kube-node-1): Insufficient cpu
fit failure on node (kube-node-4): Insufficient cpu
fit failure on node (kube-node-2): Insufficient cpu
fit failure on node (kube-node-3): Insufficient cpu


Pod distribution among nodes:
    - kube-node-1: 13 instance(s)
    - kube-node-4: 13 instance(s)
    - kube-node-2: 13 instance(s)
    - kube-node-3: 13 instance(s)

随着集群中运行的 pod 数量增加，再次运行分析时，可调度的 pod 数量也会减少。

$ ./kluster-capacity ce --pods-from-template <path to pod templates> --verbose
Pod requirements:
    - cpu: 150m
    - memory: 100Mi

The cluster can schedule 46 instance(s) of the pod.
Termination reason: FailedScheduling: pod (small-pod-46) failed to fit in any node
fit failure on node (kube-node-1): Insufficient cpu
fit failure on node (kube-node-4): Insufficient cpu
fit failure on node (kube-node-2): Insufficient cpu
fit failure on node (kube-node-3): Insufficient cpu


Pod distribution among nodes:
    - kube-node-1: 11 instance(s)
    - kube-node-4: 12 instance(s)
    - kube-node-2: 11 instance(s)
    - kube-node-3: 12 instance(s)

输出格式

ce 命令有一个 --output (-o) 标志，可以将其输出格式化为 json 或 yaml。

$ ./kluster-capacity ce --pods-from-template <path to pod templates> -o json|yaml

调度模拟

介绍

调度器模拟以当前集群中的所有 node、pod 等相关资源为输入，模拟从没有 pod 到创建并调度所有 pod 的过程。这可以用来计算集群压缩率比，以评估调度效果或衡量调度算法的质量。

与集群压缩相比，其结果更加激进和理想化。

运行

 ./kluster-capacity ss 

更多运行参数及功能，请执行如下命令：

$ ./kluster-capacity ss --help

它支持两种终止条件：AllSucceed 和 AllScheduled。前者是指所有pod调度成功后程序结束，后者是指所有 pod 至少被调度一次后程序退出。默认值为 AllSucceed。可以使用 --exit-condition 标志设置退出条件。

演示

假设集群运行有 4 个节点和 1 个主节点，每个节点有 2 个 CPU 和 4GB 内存。有 40 个资源需求是 100m CPU 和 200Mi 内存的 Pod 需要被调度。

如果调度器使用 LeastAllocated 策略，调度结果可能如下所示：

$ ./kluster-capacity ss --verbose
Termination reason: AllSucceed: 40 pod(s) have been scheduled successfully.

Pod distribution among nodes:
        - kube-node-1: 10 instance(s)
        - kube-node-2: 10 instance(s)
        - kube-node-3: 10 instance(s)
        - kube-node-4: 10 instance(s)

如果调整调度器使用 MostAllocated 策略，调度结果可能如下所示：

$ ./kluster-capacity ss --verbose
Termination reason: AllSucceed: 40 pod(s) have been scheduled successfully.

Pod distribution among nodes:
        - kube-node-1: 20 instance(s)
        - kube-node-2: 20 instance(s)

可以分析上面的调度结果来评估调度策略的有效性和集群容量压缩比。例如，上面的结果表示集群压缩比为2，这意味着在理想情况下有50%的资源浪费。

集群压缩

介绍

集群压缩以集群的当前状态，包括所有 node、pod 和其他相关资源作为输入，模拟通过移除节点来压缩集群的过程。它可用于计算集群的压缩比，这是衡量资源利用效率的指标。

与模拟调度相比，集群压缩的结果通常更显示，可操作性更强。

运行

 ./kluster-capacity cc --verbose

更多运行参数及功能，请执行如下命令：

$ ./kluster-capacity cc --help

演示

假设集群运行有 4 个节点和 1 个主节点，每个节点有 2 个 CPU 和 4GB 内存。运行有 40 个资源需求是 100m CPU 和 200Mi 内存的 Pod。

./kluster-capacity cc --verbose
2 node(s) in the cluster can be scaled down.

Termination reason: FailedSelectNode: could not find a node that satisfies the condition, 1 master node(s); 2 node(s) can't be scale down because of insufficient resource in other nodes;

nodes selected to be scaled down:
        - kube-node-1
        - kube-node-3

上面的结果表明，给定 40 个 pod 的资源需求，在保证所有 pod 都能被调度的情况下，集群可以去掉 2 个节点，压缩比为 2，也就是有 50% 的资源浪费。

后续演进

当前已经支持上述三种能力，后续会继续完善其他容量、资源管理相关能力，如

• • 基于 snapshot 的模拟

• • 资源碎片分析