Kubernetes生产节点缩容方案
受疫情影响，公司收益也大受影响，从我入职以来一直在进行成本缩减，不要问，问就是我没被裁。现在已经轮到 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），驱逐容器会报错 error: cannot delete Pods with local storage (use –delete-local-data to override): xxx容器名，如果数据不重要可以进行强制删除，如果重要，需要重新评估该节点是否要缩容
kubectl drain <节点名称> --ignore-daemonsets --delete-local-data确认节点驱逐情况
等待节点 pod 全部驱逐，且重新调度，启动成功
确认当前缩容节点没有除 DeamonSet 外的资源在运行
再进行节点脱离集群
云服务直接控制台删除节点
或者其他的 k8s web 管理平台(kuboard/kubesphere/rancher/…)
自建集群使用命令行
kubectl delete node <节点名称>确认驱逐后pod情况
删除一台节点后，观察驱逐 pod 被调度后的节点资源使用情况，综合评估是否适合继续进行节点缩容
如果不适合继续缩容，需要把刚才禁止调度的节点恢复
kubectl uncordon <节点名称1> ...如果适合继续缩容，则从驱逐节点容器继续操作节点。
以上是生产 k8s 缩容节点的步骤和决策。
博客内容遵循 署名-非商业性使用-相同方式共享 4.0 国际 (CC BY-NC-SA 4.0) 协议
