crayon

I encountered the same problem

> @ZQHcode 节点管理 ，是哪个github 项目 你好，节点管理：https://github.com/TencentBlueKing/bk-nodeman

1. 解决元组越界 2. 更新 CMDB 加重试逻辑，参考：https://github.com/TencentBlueKing/bk-nodeman/blob/b862c685693139a4edf9b8b406b52e22c16bfa8a/apps/backend/components/collections/agent_new/install_other_agent.py#L47

 

# GSE 证书获取方案 ## 基本思路 证书放置在某个具体路径下，必要时通过环境变量声明该路径 ## 容器化 挂载或 `ConfigMap` 形式将证书目录挂到容器 此处可参考 GSE 的做法：     可能存在的问题： * 每套环境证书可能不一样，如果是 `ConfigMap` 如何保证一套代码部署多个环境？ ## 二进制 联系部署测在节点管理部署机器上共享证书目录

 `InstallProxy` `ReinstallProxy` 也需要补充这个原子

开发方案 * 问题定位：删除的业务没有在项目同步逻辑（gcloud/core/project.py sync_projects_from_cmdb）进行相应的停用/删除操作 * 如何处理：对比当前拉取的业务列表与项目（from_cmdb=true）的差异，将多出来的项目进行停用

## 联调信息 ### taskflow/api/status/xx/?instance_id=xxx 增加 `auto_retry_infos`  ### taskflow/api/node/detail/ 增加 `auto_retry_info`  手动重试次数 = 节点重试总数(`retry`) - 自动重试次数(`auto_retry_info.auto_retry_times`)

## 结论 性能瓶颈不是 API 服务副本数量，而是单个 Pod 并发空间太小，原先 1c2g 的情况下，gunicon worker / threads = 4 / 4 的配置 QPS 只能达到 40 ～ 50，单次并发请求在 20 左右便开始出现 502 ，目前扩容到 4c4g，gunicon 配置调整为 worker /...

「定时」执行中的新状态是「等待处理」 - 等待处理不允许用户暂停，会不会导致「暂停不及时」 如果定时过程中可以暂停，那用户就可以在「消息展示」前，大概率暂停住任务  实现方案： * 基于 `/taskflow/api/status` `/apigw/sops/get_task_status/` 进行改造  * 兼容方案：感觉网关的获取状态不好动，可能其他系统有依赖，需要梳理