这是一个创建于 399 天前的主题，其中的信息可能已经有所发展或是发生改变。
第 1 条附言 2024-09-06 16:43:21 +08:00
负载不均衡的问题已经解决了：我按照#8 提供的地址去看了一下 scheduler 的调度日志，发现三台 ubuntu 机器的 NodeResourcesFit 评分非常低，搜索了一些资料也没说是什么问题，我就索性把 ubuntu 节点给重置了然后重启 docker 和 kubelet ，重新加入集群。发现 NodeResourcesFit 评分正常了，容器也能被调度到 ubuntu 节点上。
关于我为什么没有写 limit 和 request 是因为服务器资源挺充足的，想让 pod 能够大限度的获取服务器资源。所以就没有对 limit 和 request ，这样也不会影响到 scheduler 对节点服务器的评分。
关于我为什么没有写 limit 和 request 是因为服务器资源挺充足的，想让 pod 能够大限度的获取服务器资源。所以就没有对 limit 和 request ，这样也不会影响到 scheduler 对节点服务器的评分。
 | 1 BenchWidth OP 补充：5 台 centos7 上有原始服务在运行，k8s 服务器信息获取正常，本来想的是在服务器上集群运行好之后再去手动关闭掉机器上的原始服务。 |
 | 2 seers 2024-09-05 19:52:24 +08:00 via Android 检查下 limit 和 require 吧，资源不够是不会调度过去的 |
 | 3 zhoudaiyu PRO 用 podantiaffnity 试试 |
 | 4 hallDrawnel 2024-09-05 20:18:00 +08:00 去掉敏感信息贴下完整的 deployment yaml 描述 |
| 5 BenchWidth OP @hallDrawnel apiVersion: apps/v1 kind: Deployment metadata: name: namespace: spec: replicas: 1 selector: matchLabels: app: template: metadata: labels: app: spec: containers: - name: image: ports: - containerPort: 8090 --- apiVersion: v1 kind: Service metadata: name: namespace: spec: selector: app: ports: - protocol: TCP port: 8090 targetPort: 8090 |
| 6 BenchWidth OP 2024-09-05 20:38:10 +08:00 @seers 资源是肯定够的，内存、CPU 、磁盘都是充足的 |
 | 7 Frankcox 2024-09-05 20:48:10 +08:00 通过 NodeSelector 或者硬亲和强制指到节点上，看看是否 Pending |
 | 8 mightybruce 2024-09-05 20:57:40 +08:00 k8s 调度本身是基于 linux 内核的完全公平调度器 CFS, 要想做到绝对均衡的调度是不可能的，想实现一些特定的调度可以用 K8s 调度框架来实现插件， 简单的做法就是给机器打上各种标签，然后用 nodeselector 就好了。 |
 | 9 yanbo92 2024-09-05 20:58:07 +08:00 有同样经历，我的调法是把 kube-scheduler 日志等级到 10 或者 11 ，看每个插件打分的结果来微调插件权重。可以参考这篇文章： https://midbai.com/post/scheduler-always-place-pod-on-the-same-node/ |
 | 10 rbaloatiw 2024-09-06 00:38:20 +08:00 @mightybruce #8 > k8s 调度本身是基于 linux 内核的完全公平调度器 CFS 这个说的应该不是 kube-scheduler 吧? 我也会使用 #9 的做法, 通过日志来查看每个插件的打分结果 |
 | 11 assassing 2024-09-06 00:43:51 +08:00 同样有这个困扰，默认调度策略似乎倾向于用满一台服务器再分配到下一台。我用的版本还是 1.22 ，不知道后面更新版本情况怎样？ |
| 12 yanbo92 2024-09-06 00:54:07 +08:00 via iPhone 部分节点有原始服务在跑这个信息比较关键，其实默认那些调度插件只计算由 k8s 自己起的容器申请的资源，节点上有其他非 k8s 集群进程在吃资源，并不会被调度器考虑到。 |
 | 13 ryan4yin 2024-09-06 09:36:27 +08:00 #5 你 limits 跟 requests 都没配，这怎么让 k8s 调度，k8s 管理资源的核心逻辑是 HPA VPA 动态扩缩容，不是把旧的 Pod 删掉，在大机器上给你跑个新的。 建议找个 k8s 教程先学一学吧。 |
 | 14 guanzhangzhang 2024-09-06 09:41:58 +08:00 request 是资源请求占坑，limit 是 cgroup 限制 例如一个 1G 内存的 node 你可以部署多个没有 request 的 pod ，不配置 limits 则实际例如内存 oom 紧张时候 oom-killer 会根据 oom_score 得分去杀进程 同样 1G 内存的 node ，你 request 配置 400M 内存，你 replicas=3 只有两个能调度到该节点，实际内存使用 1M ，都是这样，request 是资源占坑。 limit 除去 cgroup 限制，还涉及到 pod Qos ，会生成 oom_score_adj |
 | 15 cinlen 2024-09-06 10:09:43 +08:00 k8s 默认的调度器不是 load-aware 的，也就是说它感知不到你物理上的资源消耗。 它凭节点上的 pod requests 资源总和做决策，你的 pod 不写 resource.requests ，那在 k8s 调度器看来你的 pod 就不占资源。 你可以确认看看是不是： 1. 这 5 个 centos 节点的 pod requests 资源之和较少 2. 是不是你的架构是 3 master 5 worker ？然后有什么策略会让 workloads 优先考虑调度到 worker 。 |
| 16 hallDrawnel 2024-09-06 12:11:25 +08:00 你的 limit 和 request 都没有啊，k8s 不知道怎么调度。再详细学习下这块。 |
| 17 assassing 2024-09-10 18:26:40 +08:00 @yanbo92 #9 我的开发环境 K8s 版本 v1.22.3 ，一共三个工作节点，两个节点内存几乎满载，评分 NodeResourcesBalancedAllocation 都是 100 分，另外一个节点评分是 87 。然后两个满载节点 NodeResourcesFit 评分为 0 ，另外一个节点评分是 12 。这个最终合计评分 99 的节点内存使用率和调度率都只有 50%。所有 pod 都有设置一样的内存请求和内存限制。我想不通，于是想要把 NodeResourcesFit 优先级调高，结果只要启动参数加入 --config ，参数 --kubeconfig 就会失效，让人无能狂怒。请问你是怎么做的？ |
| 18 yanbo92 2024-09-14 11:26:17 +08:00 @assassing #17 我的集群版本是 1.23.0, 这段配置大概是这样 ``` spec: containers: - command: - kube-scheduler - --authentication-kubecOnfig=/etc/kubernetes/scheduler.conf - --authorization-kubecOnfig=/etc/kubernetes/scheduler.conf - --bind-address=127.0.0.1 - --kubecOnfig=/etc/kubernetes/scheduler.conf - --leader-elect=true - --cOnfig=/etc/kubernetes/kube-scheduler-config.yaml - --v=11 ``` |
Select Language