受疫情影响,公司收益也大受影响,从我入职以来一直在进行成本缩减,不要问,问就是我没被裁。现在已经轮到 k8s 节点倒霉了,要准备对几台节点进行裁员,由我来进行方案定制

Kubernetes生产节点缩容方案

worker节点数 14

单节点 16c64g

评估各节点 pod 数量和资源使用情况,根据综合比使用各项资源最少的进行缩减规划工作,尽量减少 pod 驱逐后最小化对业务的实际影响,观察驱逐后 pod 运行情况,和重新调度后节点资源使用情况。

然后我按照评估情况,拿出了 3 台节点进行缩容备选

节点 pod数量(限制32) cpu使用 cpu请求 cpu限制 内存使用 内存请求 内存限制
这里是ip 13 0.4(2.7%) 74.60% 92.30% 44.60% 35% 38%
这里是ip 14 0.5(3.5%) 70.30% 83.50% 51.50% 41% 43.10%
这里是ip 14 0.6(3.7%) 57% 70.90% 55.20% 47.20% 45.70%

经过和同事领导一致商议,决定先对前两台进行缩容,因为之后有一部分服务要上容器,留个冗余。

驱逐方案步骤

禁止节点调度

将要缩容的几个节点全部执行,以免驱逐后又调度到其他缩容节点

drain 也能变为禁止调度的状态,相比较 cordon 来说比较暴力,cordon 最为稳妥

kubectl cordon <节点名称1> <节点名称2> ...

确认节点状态

是否存在 SchedulingDisabled 关键字

kubectl get node | grep <节点名称>

驱逐节点容器

建议逐个节点进行驱逐,方便观察容器重新调度情况

因为节点默认有几个 DeamonSet 的组件在运行,如:kube-proxy、flannel(网络插件)、filebeat、node_exporter等,驱逐 pod 需要添加参数 –ignore-daemonsets

kubectl drain <节点名称> --ignore-daemonsets

当节点容器依赖本地 local 存储时(如emptyDir),驱逐容器会报错,如果数据不重要可以进行强制删除,如果重要,需要重新评估该节点是否要缩容,我以后遇到会补进来的

确认节点驱逐情况

等待节点 pod 全部驱逐,且重新调度,启动成功

确认当前缩容节点没有除 DeamonSet 外的资源在运行

再进行节点脱离集群

云服务直接控制台删除节点

或者其他的 k8s web 管理平台(kuboard/kubesphere/rancher/…)

自建集群使用命令行

kubectl delete node <节点名称>

确认驱逐后pod情况

删除一台节点后,观察驱逐 pod 被调度后的节点资源使用情况,综合评估是否适合继续进行节点缩容

如果不适合继续缩容,需要把刚才禁止调度的节点恢复

kubectl uncordon <节点名称1> ...

如果适合继续缩容,则从驱逐节点容器继续操作节点。

以上是生产 k8s 缩容节点的步骤和决策。

评论




正在载入...
PoweredHexo
HostedAliyun
DNSAliyun
ThemeVolantis
UV
PV
BY-NC-SA 4.0