问题背景
并不是所有的 Kubernetes 集群都有很大数量的机器，一个 Pod 也有可能占用几十 G 内存，心愿读者能在浏览前就理解这样的事实。
在我管控的集群中，有个集群机器数量比拟少（大略 7~8 个计算节点），配置也个别（本文依照 64 核，128G 这样的配置来阐明，将来有可能有更好或者更差的机器），集群的拥有者会心愿他的机器资源可能被无效的利用，最好在 80% 左右，作为管理员的我就须要思考下这个问题。
默认部署策略的应用
该集群中有几个利用的内存使用率很高，每个 Pod 启动后内存会逐步回升，咱们能承受的范畴大略在 20G 左右。对于这种大利用，资源申请不能过高或者过低，因而程序中的资源配置如下，
requests 与 limits 雷同。
requests:
cpu: "10000m"
memory: "21474836480"
limits:
cpu: "10000m"
memory: "21474836480"以 128G 的节点为例，每个节点咱们冀望部署 4 / 5 个 Pod，有以下起因：
- 如果部署 6 个，内存超过 90% 的使用率，监控会报警；
- 如果所有节点都部署 5 个，那么每次滚动更新时就会有可能报警。
比拟现实的计划是某些节点 4 个 Pod，某些节点 5 个 Pod，滚动更新时，从 4 个 Pod 的节点开始，逐渐替换 Pod。
然而这就带来了一个问题，Kuberntes 的默认节点抉择策略是比拟自在的，如果一台机器有资源，那么它有肯定可能被抉择部署。
5 个 Pod 总共 100G mem 的申请资源，就存在这么一种可能性，某个节点的 Pod 有 6 个，某个节点的 Pod 有 3 个，默认的调配策略是有这种可能性的。
咱们在应用默认策略时遇到了好屡次这样的部署后果，只能用 kubectl delete pod 手动来进行修整，用共事的话来讲就是蛋碎了。
一个比较简单的控制策略
Kubernetes 中针对节点的可分配资源是能够定义的，咱们限度节点保留 10% 的资源，用 Ansible 生成的 kubelet 参数能够这么加：–system-reserved=memory={(ansible_memtotal_mb * 0.1)int}Mi 那么，会保障不产生报警，然而各个机器之间的负载还是有可能不平衡，只能局部解决问题。
精密管制 Pod 散布
因为咱们不止部署了一个利用，而且有些利用须要非凡的看待，必定不能齐全寄希望于主动的调配策略。机器自身较少，而且想要实现较高的利用率时，反对用户手工调整 Pod 数量是有必要的。
无关精密管制节点中的 Pod 数量，咱们调研了几种计划：
Pod 拓扑散布束缚
（https://kubernetes.io/docs/co…）
该计划实现较为简单，它引入了域的概念，将节点分组，每个组为一个域，针对各个域中部署的 Pod 数量进行限度，比方两个域之间的 Pod 数量不能相差 1，如果用这个计划解决负载不平衡的问题，那么会引入新的问题：如果咱们减少了新的机器，而新机器的性能配置都较好，那么 Pod 数量不能相差 1，那么新机器的性能不能被充分利用。
说真的，我想不到这个计划利用的场景，如果大家有适合的使用场景及思路能够在评论外面通知我，我也学习下。
节点减少拓展资源
（https://kubernetes.io/docs/ta…）
我集体认为这个计划是一种折衷方案，配置不太简单也能达到想要的成果，具体的实现是减少新的资源限度。
书写控制策略时配合 CPU 以及 mem 来应用：
用户能够手动批改节点的资源限度，也能够针对某几个利用来设置。
当咱们有了不同配置的新机器后，能够针对新机器批改该选项到适合的值。
我认为这个计划（主动抉择 + 手工配置）曾经根本解决了咱们的问题，不过有个小毛病就是：每次增加新的机器都须要设置资源，否则设置会导致 Pod 无奈调配到新节点中。
总结
咱们在解决手动部署问题时也探讨了一下 Kubernetes 更加适宜的场景：领有大量的服务器；服务器中运行渺小服务的状况；并且该集群最好能管制资源利用率在 80% 以下，这样遇到了突发的流量能够做到有空余工夫去扩容。
这篇文章中，我提到了三个解决计划，大家能够针对本人的状况本人去抉择：
- 在建设集群时就思考下，给每个节点预留资源 Pod 的拓扑散布束缚我临时没想到适合的场景 对于某些机器较少的集群，用户想要实现细力度的管制，我还是举荐应用扩大资源来限度。
原文链接：https://corvo.myseu.cn/2021/0… 中一种细力度控制程序部署的计划
起源：云原生技术爱好者社区
作者：冯裕浩
【IDCF 共创读书会】第 2 期汇报在【冬哥有话说】收费直播，关注公众号回复“共创”获取地址
- 11 月 18 日（周四）晚 8 点，共读《第五项修炼》
- 11 月 25 日（周四）晚 8 点，共读《继续交付 2.0》