uc 容器cpu使用率过高

纵向扩容（垂直伸缩） 和 横向扩容（水平伸缩）

1. 定位高 CPU 占用的容器

2. 扩容方案一：调整容器资源限制（纵向扩容）

3. 扩容方案二：增加 Pod 副本数量（横向扩容）

• 手动扩容：使用命令 kubectl scale deployment <deployment名称> --replicas=<目标数量> 增加实例。
• 自动扩缩容（HPA）：建议为 U-Center 的核心业务容器开启水平伸缩（HPA）功能。配置 CPU 或内存使用率阈值（例如当 CPU 使用率超过 80% 时自动扩容），这样在业务高峰期系统能自动增加 Pod 副本，低谷期自动缩容，无需人工干预。

4. 扩容方案三：扩展底层集群节点

• 向 U-Center 集群中添加更多的 Worker 节点。
• 将现有的节点升级到更高配置的硬件（如更多的 CPU 核心或更大的内存）。

5. 紧急缓解与排查建议

• 临时规避：如果高 CPU 严重影响了系统可用性，可以尝试重启负载过高的非核心 Pod，或者回滚最近可能导致性能问题的升级/配置变更。
• 排查异常：检查是否存在内存泄漏、死循环或异常的日志疯狂打印等应用层面的问题。
• 架构建议：U-Center 2.0 采用微服务容器化架构，支持单机和集群模式。如果您当前使用的是单机部署，且资源经常遇到瓶颈，建议平滑升级为 3 节点（3 Master + N Worker）的集群部署模式，以获得更好的高可用性和资源调度能力。

统一数字底盘 UC（Matrix/K8s）容器 CPU 过高 排查 + 两种扩容完整方案
UC 底层基于 K8s 容器调度，CPU 高分临时调大单容器 CPU 配额（垂直扩容，优先）、新增服务器节点水平扩容；先定位高 CPU 容器，再做扩容，附带 CPU 高负载根因排查。
一、第一步：定位哪个容器 CPU 占满（先排查再扩容）
1.Web 界面查看负载
登录 UC 后台 → 系统 → 部署管理 → 集群监控
查看 Pod 列表 CPU 使用率，记录高负载容器名称（常见：smartcompute、collectplat、udtp-base、bmp-manager、数据库 mysql）。
2. 后台命令行精准定位（SSH 登录 UC 管理节点）
bash
运行
# 按CPU从高到低排序所有容器pod
kubectl top pod -A --sort-by=cpu
# 进入高CPU容器看内部进程（示例pod名smartcompute-xxx）
kubectl exec -it smartcompute-7f965d896c-2xq9d -n matrix -- top
# 查看集群总资源剩余，判断能否直接垂直扩容
kubectl describe nodes
CPU 高常见根因（扩容前优先优化，避免反复扩容）
采集平台 CollectPlat 大量设备上报日志、性能指标，轮询任务打满 CPU；
SmartCompute 计算组件虚拟机 / 容器调度、资源统计循环计算；
UDTP 底座 SBOM 包解析、版本校验后台任务；
数据库慢查询、日志归档任务占用 CPU；
容器默认 CPU 配额过低（默认 0.5/1 核，大规模纳管不足）。
二、方案 1：单容器垂直扩容（修改 Pod CPU 配额，零新增硬件，推荐）
方式 A：Web 图形界面操作（无需命令，生产首选）
路径：系统 → 部署管理 → 应用管理
找到高 CPU 组件（如 BMP_UCP_SmartCompute、CollectPlat），点击组件名称进入详情；
顶部切换「配置」标签，找到资源配额：
CPU 请求 (requests)：组件最小保障 CPU（建议原有值翻倍）
CPU 限制 (limits)：组件最大可用 CPU（原有值翻倍，不要超过节点剩余核数）
示例：原 0.5 核请求 / 1 核限制 → 修改为 1 核请求 / 2 核限制；
保存配置，系统自动滚动重启 Pod，新 CPU 配额即时生效；
监控 5~10 分钟 CPU 使用率，若仍 80%+ 继续上调。


容器资源配额编辑界面
方式 B：后台 K8s 命令行修改（无 Web 权限时）
bash
运行
# 1.编辑对应应用deployment（替换为你的pod前缀，如smartcompute）
kubectl edit deployment smartcompute -n matrix
# 找到resources段落修改cpu数值（单位m，1000m=1核）
resources:
requests:
cpu: "1000m" # 原500m改为1000m
memory: "1Gi"
limits:
cpu: "2000m" # 原1000m改为2000m
memory: "2Gi"
# 保存退出，自动重建pod生效
# 验证新配额
kubectl describe pod smartcompute-xxx -n matrix | grep -A8 Resources
三、方案 2：集群水平扩容（新增物理服务器节点，整机分担负载）
适合场景：所有容器均 CPU 高、单节点资源耗尽，垂直扩容无剩余 CPU 可用。
完整操作步骤
准备同配置新服务器，系统版本与现有 UC 节点一致；
Web 路径：系统 → 部署管理 → 集群 → 添加节点；
输入新节点 IP、root 密码，选择角色（Worker 工作节点，仅承载业务容器，不做主控）；
等待自动初始化、安装 Matrix、加入 K8s 集群（约 15~30 分钟）；
集群新增节点完成后，原有高 CPU 容器会自动调度分摊到新节点，整机 CPU 负载下降；
如需指定组件只跑新节点，可给节点打标签、配置 Pod 亲和调度。
四、配套 CPU 优化（扩容后进一步降低占用）
采集平台 CollectPlat 调优
延长设备性能采集周期（5 分钟→10 分钟）；
关闭无用设备指标采集、关闭未纳管设备轮询；
日志归档优化
调低系统日志、设备 syslog 归档频率，关闭实时全量解析；
数据库优化
清理过期审计 / 性能日志，优化慢查询，增加 mysql 容器 CPU 配额；
后台任务限流
UDTP、报表 Report 组件调小后台并发任务数，避免多线程抢占 CPU。
五、扩容避坑要点
垂直扩容上限：单 Pod limits CPU 不能超过单节点总物理核数，同时所有容器总 CPU 不能超过节点 Allocatable 可分配资源；
滚动重启影响：修改容器配额会分批重建 Pod，业务短时间无中断，但高峰期建议凌晨操作；
基线版本限制：E7302H01 及以上版本支持 Web 可视化改资源配额，老旧 E7302 基线只能用 kubectl 命令修改；
先优化再扩容：日志采集、后台任务逻辑问题导致的 CPU 跑满，单纯扩容只能临时缓解，过几天会再次占满，优先优化任务配置。
六、验证扩容是否生效命令
bash
运行
# 查看容器当前分配CPU与实时使用率
kubectl top pod -n matrix
# 查看节点剩余可分配CPU资源
kubectl describe nodes | grep Allocatable -A5
# 查看Pod新资源限制是否加载成功
kubectl get pod <pod名称> -n matrix -o yaml | grep -A10 resources