bin.pan

@WangZzzhe agent的参数： ```YAML template: metadata: annotations: katalyst.kubewharf.io/qos_level: system_cores creationTimestamp: null labels: app: katalyst-agent app.kubernetes.io/instance: katalyst-colocation app.kubernetes.io/name: katalyst-agent spec: containers: - args: - --plugin-registration-dir=/var/lib/katalyst/plugin-socks - --checkpoint-manager-directory=/var/lib/katalyst/plugin-checkpoint - --locking-file=/tmp/katalyst_colocation_katalyst_agent_lock - --node-name=$(MY_NODE_NAME) -...

> @flpanbin > 修改 `--topology-policy-name=none` 为 `--topology-policy-name=best-effort` 再尝试下 > none policy下不会进行资源分配 @WangZzzhe 设置了 `--topology-policy-name=best-effort` 还是不行 ```shell root@ubuntu:~/katalyst# ps -ef | grep katalyst-agent root 2423499 2423425 15 Jun05 ? 01:31:28 katalyst-metric...

@WangZzzhe 请问这个有什么定位思路吗？还需要提供哪些信息来定位问题呢？ 我按照文档安装的 Kubewharf enhanced kubernetes, 文档提供的 helm 命令安装的相关组件： `helm install katalyst-colocation -n katalyst-system --create-namespace kubewharf/katalyst-colocation` ```shell root@ubuntu:~/katalyst/examples# kubectl get nodes NAME STATUS ROLES AGE VERSION 10.6.202.151 Ready control-plane 13d...

> @flpanbin > 根据katalyst-agent的启动参数，应该是运行了ORM模式，kubelet中的qosResourceManager是没有生效的。 >  > 从KCNR的信息看这个pod已经分配成功了，独占了一个NUMA的24C 但是为什么我查看容器的 cpuset 和 还是显示的 0-47呢，按理说应该是分配了24core ```shell root@ubuntu:~/katalyst# cat /sys/fs/cgroup/cpuset/kubepods/podb077c70f-6103-43f9-ba77-64d67ec736ba/cpuset.cpus 0-47 root@ubuntu:~/katalyst# cat /sys/fs/cgroup/cpuset/kubepods/podb077c70f-6103-43f9-ba77-64d67ec736ba/80c10c4e45cbe275bafac9cf8b74ef72e6c0b9565d33389fce86f6e7c3737843/cpuset.cpus 0-47 root@ubuntu:~/katalyst# cat /sys/fs/cgroup/cpuset/kubepods/podb077c70f-6103-43f9-ba77-64d67ec736ba/604fc985574b2ff117630b699dd4e9ac77c95d316b6ece904385694db0090268/cpuset.cpus 0-47 ```

@WangZzzhe syncContainer 没有看到有错误日志，但是看有日志显示分配的结果是 0-47： `cpu for pod: default/dedicated-normal-pod2, container: stress is {CpusetCpus false true 48 0-47 map[] map[] nil {} 0}` ```SHELL I0606 06:28:10.191773 1 manager.go:536] [ORM] reconcile... I0606 06:28:10.193289...

@WangZzzhe ` /var/lib/katalyst/qrm_advisor/cpu_plugin_state` 显示分配了多次，最后一次的分配结果是` `"allocation_result": "0-47",` ```shell { "policyName": "dynamic", "machineState": { "0": { "default_cpuset": "", "allocated_cpuset": "0-23", "pod_entries": { "754dc697-7658-47cc-8faa-0280c2931925": { "stress": { "pod_uid": "754dc697-7658-47cc-8faa-0280c2931925", "pod_namespace": "default", "pod_name": "dedicated-normal-pod2",...

感谢您的反馈，请问这个有稳定的复现路径吗？

> 在使用kubectl-node_shell时，也有这种情况，cloudshell关闭时，pod仍然存活。期望cloudshell为comleted状态时，能把对应的pod清理掉。 为了提高控制台打开的速度，cloudshell 会复用已创建的 worker， 所以 worker 使用完后可能不会立即删除。如果空闲 worker 数不超过 core-worker-limit，则会一直保留。core-worker-limit 参数默认值为 5，麻烦确认下是否是这种场景。 如果不是上述场景麻烦描述下具体的操作步骤。 方便的话，麻烦贴下 cloudtty-controller-manager 的日志。

> 0.5.0版本不会根据core-worker-limit进行复用，建议使用哪个版本？ 使用新版本试试 0.7.8。

感谢您的反馈，这个问题我们排期优化下，也欢迎大家一起参与贡献。