记第一次上K8S踩的坑
前言前段时间架构升级,从dubbo转到了springcloud,顺便也上了k8s,开始了踩坑之旅正文架构升级进入了调优阶段,但是压测一直过不了,机器压力一直上不去。随之我们展开了一系列排查与调优工作,涉及网络、框架参数、慢sql、内核参数等,基本都撸了一遍,最终结果只是稍有好转,但压力仍然上不去,百思不得其姐。最终在k8s的yaml配置文件中,发现了问题。配置中我们给每个容器都分配了内存,分配了核
·
前言
前段时间架构升级,从dubbo转到了springcloud,顺便也上了k8s,开始了踩坑之旅
正文
架构升级进入了调优阶段,但是压测一直过不了,机器压力一直上不去。随之我们展开了一系列排查与调优工作,涉及网络、框架参数、慢sql、内核参数等,基本都撸了一遍,最终结果只是稍有好转,但压力仍然上不去,百思不得其姐。
最终在k8s的yaml配置文件中,发现了问题。配置中我们给每个容器都分配了内存,分配了核数,恰恰问题都是出现在分配核数上!
这样子分配CPU资源,并没法很好地利用,会造成资源浪费,难怪机器压力一直上不去。
所以我们调整了CPU分配策略,不指定 CPU 的限制数量
- 容器在可以使用的 CPU 资源上没有上限。容器可以使用运行节点上的所有可用的 CPU 资源。
- 容器在具有默认 CPU 限制的命名空间中运行,并且系统会自动为容器分配默认限制。集群管理员可以使用 限制范围 指定 CPU 限制的默认值
更多推荐
已为社区贡献1条内容
所有评论(0)