问题背景

并不是所有的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》