1. 从单机到多机为什么这一步非走不可单机部署 CubeStudio 的时候所有组件跑在一台机器上用 docker-compose 或者 all-in-one 的安装脚本就能拉起来。刚开始做算法验证、跑几个 demo 任务确实够用。但一旦团队规模上来问题就集中爆发了多个算法工程师同时提交训练任务GPU 显存抢得头破血流某个任务把 CPU 打满整个平台的 API 响应慢得像蜗牛更别提单点故障——那台机器一挂所有人的实验全停。我经历过一次最典型的情况一个 CV 团队在做图像分割的模型迭代同时有四五个人在调参单机上的两张卡根本不够分。有人跑着跑着发现任务被 OOM 杀掉了一查是另一个同事的大 batch 任务把显存吃光了。这种资源争抢在单机模式下无解因为调度粒度太粗没有资源隔离和配额机制。所以从单机扩到多机核心要解决三件事计算资源池化、调度与隔离、组件高可用。CubeStudio 的多机方案本质上就是把控制面和数据面拆开——控制面API Server、调度器、数据库、对象存储可以部署在管理节点上数据面计算节点、训练任务、推理服务分散到多个工作节点。这样每个节点各司其职资源统一调度单点故障的影响面也小得多。适合谁来参考这篇内容如果你已经用单机版跑通了基本流程现在团队要扩到 5 人以上或者手头有 3 台以上的 GPU 服务器想整合成一个平台那下面的实操细节就是为你准备的。如果你还在单机阶段也可以先了解整体架构为后续扩展做规划。1.1 多机部署的架构选型逻辑CubeStudio 的多机部署有几种常见形态选哪种取决于你现有的基础设施和团队运维能力。第一种是基于 K8s 的多机集群。这是最推荐的方式也是 CubeStudio 原生支持最好的路径。管理节点跑 K8s 控制面组件加 CubeStudio 的控制面服务工作节点加入集群后作为计算资源池。所有训练任务、推理服务都以 Pod 的形式调度到工作节点上。这种方式的优势是资源隔离彻底、扩缩容方便、生态工具丰富。缺点是入门门槛稍高需要懂基本的 K8s 概念和操作。第二种是基于 Docker Swarm 或自定义调度器的多机方案。这种适合对 K8s 不太熟悉、但又想快速扩多机的团队。CubeStudio 早期版本有支持过类似模式通过 SSH 分发任务到各个节点用自定义的资源管理器做调度。优点是上手快缺点是资源隔离弱、故障恢复能力差、节点多了之后管理混乱。第三种是混合模式——管理节点用 K8s部分边缘计算节点用轻量级代理接入。这种适合有边缘推理需求的场景比如工厂车间里放几台推理服务器中心机房做训练。CubeStudio 的多集群纳管能力就是为这种场景设计的。我个人的建议很明确只要条件允许直接上 K8s 方案。前期学习成本确实有但后期运维的便利性和扩展性完全值回票价。下面所有的实操也都基于 K8s 方案展开。1.2 部署前的资源规划与检查清单在动手之前先把资源盘清楚。我见过太多人上来就装装到一半发现磁盘不够、端口冲突、版本不兼容又回头重来。硬件资源规划表以 3 节点为例节点角色CPU内存系统盘数据盘GPU网络管理节点8核32GB200GB SSD500GB可选万兆优先工作节点116核64GB200GB SSD1TB2-4张万兆优先工作节点216核64GB200GB SSD1TB2-4张万兆优先管理节点上要跑 K8s 控制面、CubeStudio API、MySQL、Redis、MinIO 等内存和磁盘 IO 是关键。工作节点主要跑训练任务GPU 和本地数据盘最重要。如果预算有限管理节点可以和工作节点复用但生产环境不建议这么做。软件版本检查清单操作系统Ubuntu 20.04/22.04 LTS 或 CentOS 7.9内核版本 4.15 以上Docker20.10.x 及以上需要配置 NVIDIA Container RuntimeNVIDIA 驱动470 或 515与 CUDA 版本匹配K8s1.22 到 1.26 之间比较稳妥太新或太旧都可能遇到兼容问题Helm3.8CubeStudio确认你用的版本支持多机部署看官方 release notes注意所有节点的时钟必须同步用 NTP 服务对齐。K8s 对时间敏感时间偏差超过阈值会导致证书校验失败、调度异常等一堆莫名其妙的问题。网络检查节点之间要能互相 ping 通以下端口必须开放——K8s 控制面用 6443、2379-2380、10250-10252CubeStudio 用 8080、30000-32767NodePort 范围MinIO 用 9000、9001MySQL 用 3306Redis 用 6379。如果走的是云服务器安全组规则也要对应放行。2. 多机 K8s 集群搭建与 CubeStudio 接入这一部分是整个扩展过程的地基。K8s 集群搭不稳后面 CubeStudio 的多机调度就是空中楼阁。2.1 K8s 集群初始化实操我用 kubeadm 来搭这是最标准的方式社区文档全出问题好排查。第一步所有节点安装容器运行时和 kubelet# 安装 Docker curl -fsSL https://get.docker.com | bash # 配置 NVIDIA Container Runtime distribution$(. /etc/os-release;echo $ID$VERSION_ID) curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | apt-key add - curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | tee /etc/apt/sources.list.d/nvidia-docker.list apt-get update apt-get install -y nvidia-docker2 # 配置 Docker daemon cat /etc/docker/daemon.json EOF { exec-opts: [native.cgroupdriversystemd], log-driver: json-file, log-opts: {max-size: 100m}, storage-driver: overlay2, default-runtime: nvidia, runtimes: { nvidia: { path: /usr/bin/nvidia-container-runtime, runtimeArgs: [] } } } EOF systemctl restart docker这里把default-runtime设成 nvidia 很关键这样所有容器默认就能访问 GPU省去每个 Pod 单独配 runtimeClass 的麻烦。native.cgroupdriversystemd要和 kubelet 保持一致否则 kubelet 启动会报错。# 安装 kubelet kubeadm kubectl apt-get update apt-get install -y apt-transport-https ca-certificates curl curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.26/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg echo deb [signed-by/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.26/deb/ / | tee /etc/apt/sources.list.d/kubernetes.list apt-get update apt-get install -y kubelet1.26.0-1.1 kubeadm1.26.0-1.1 kubectl1.26.0-1.1 apt-mark hold kubelet kubeadm kubectl版本锁定很重要别让系统自动升级。我踩过一次坑kubelet 自动升了个小版本结果和 kubeadm 版本不匹配节点直接 NotReady。第二步管理节点初始化集群# 关闭 swap swapoff -a sed -i /swap/s/^/#/ /etc/fstab # 加载内核模块 cat /etc/modules-load.d/k8s.conf EOF overlay br_netfilter EOF modprobe overlay modprobe br_netfilter # 配置内核参数 cat /etc/sysctl.d/k8s.conf EOF net.bridge.bridge-nf-call-iptables 1 net.bridge.bridge-nf-call-ip6tables 1 net.ipv4.ip_forward 1 EOF sysctl --system # 初始化集群 kubeadm init \ --apiserver-advertise-address管理节点IP \ --pod-network-cidr10.244.0.0/16 \ --service-cidr10.96.0.0/12 \ --kubernetes-versionv1.26.0--pod-network-cidr和--service-cidr别和你的物理网络冲突。如果公司内网用的是 10.0.0.0/8那 pod 网段就换个别的比如 172.16.0.0/16。初始化完成后按提示配置 kubectlmkdir -p $HOME/.kube cp -i /etc/kubernetes/admin.conf $HOME/.kube/config chown $(id -u):$(id -g) $HOME/.kube/config第三步安装网络插件我习惯用 Calico稳定、功能全kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.0/manifests/calico.yaml等所有 calico pod 变成 Running 状态再继续下一步。第四步工作节点加入集群在管理节点上执行kubeadm token create --print-join-command拿到加入命令然后在每个工作节点上执行。加入完成后在管理节点kubectl get nodes应该能看到所有节点。第五步给工作节点打标签kubectl label node 工作节点名 node-role.kubernetes.io/worker kubectl label node 工作节点名 gputrue打标签是为了后续调度用的。CubeStudio 的任务调度器可以根据标签把任务分配到指定节点。2.2 CubeStudio 控制面部署与配置调整K8s 集群就绪后开始部署 CubeStudio。如果你之前是单机版现在要做的是把控制面服务迁移到 K8s 上或者用 Helm 重新部署一套。CubeStudio 官方提供了 Helm Chart在charts/cube-studio目录下。先看一下values.yaml里需要改的关键配置# 全局配置 global: namespace: cube-studio storageClass: local-path # 根据你的 K8s 环境选 # MySQL 配置 mysql: enabled: true persistence: size: 50Gi resources: requests: memory: 4Gi cpu: 2 # Redis 配置 redis: enabled: true persistence: size: 10Gi # MinIO 对象存储 minio: enabled: true persistence: size: 500Gi resources: requests: memory: 8Gi cpu: 4 # API Server api: replicas: 2 # 多副本保证高可用 resources: requests: memory: 2Gi cpu: 1 # 调度器配置 scheduler: enabled: true # 多机调度关键配置 nodeSelector: node-role.kubernetes.io/worker: 几个关键点解释一下存储类选择单机版通常用 local-path 就行但多机环境下如果工作节点有多个local-path 会导致 Pod 漂移后数据丢失。生产环境建议用 NFS、Ceph 或者云厂商的块存储。我测试环境用 NFS 就够配置简单多个节点都能挂载同一个存储。MySQL 和 Redis 高可用如果团队规模不大单副本也能接受但要配置好定期备份。如果对可用性要求高可以用外部 MySQL 集群把mysql.enabled设为 false然后在配置里填外部连接串。API Server 多副本至少 2 个副本配合 K8s Service 做负载均衡。这样单个 Pod 挂掉不影响平台使用。调度器配置CubeStudio 的调度器负责把训练任务分配到合适的节点。多机环境下调度器需要知道每个节点的资源情况这通过 K8s 的 node informer 实现。确保调度器的 ServiceAccount 有足够的 RBAC 权限。部署命令helm install cube-studio ./charts/cube-studio -n cube-studio --create-namespace部署完成后检查所有 Pod 状态kubectl get pods -n cube-studio -o wide正常情况应该看到 mysql、redis、minio、api、scheduler、dashboard 等 Pod 都在 Running 状态。如果有 Pod 一直 Pending用kubectl describe pod看事件通常是资源不足或者 PVC 没绑定成功。2.3 工作节点接入与 GPU 资源注册控制面跑起来后要让工作节点的 GPU 资源被 K8s 识别这样调度器才能把 GPU 任务调度过去。安装 NVIDIA Device Pluginkubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.14.0/nvidia-device-plugin.yml这个 DaemonSet 会在每个有 GPU 的节点上跑一个 Pod把 GPU 资源注册到 K8s。安装后等一会儿执行kubectl describe node 工作节点名 | grep nvidia.com/gpu应该能看到类似nvidia.com/gpu: 2的输出说明 GPU 已被识别。验证 GPU 调度写一个简单的测试 PodapiVersion: v1 kind: Pod metadata: name: gpu-test spec: containers: - name: cuda image: nvidia/cuda:11.8.0-base-ubuntu22.04 command: [nvidia-smi] resources: limits: nvidia.com/gpu: 1 restartPolicy: Never nodeSelector: gpu: truekubectl apply之后看日志如果输出 GPU 信息就说明整条链路通了。实操心得Device Plugin 安装后有时候要等 1-2 分钟才能注册成功。如果kubectl describe node一直看不到 GPU 资源先检查节点上是否有nvidia-device-plugin的 Pod 在跑再看它的日志有没有报错。常见问题是驱动版本和 plugin 版本不匹配。3. 多 K8s 集群纳管一套平台管多个集群单集群跑顺了之后下一个需求自然出现公司可能有多个 K8s 集群——一个在机房 A一个在机房 B或者一个在云上一个在本地。CubeStudio 的多集群纳管能力就是解决这个问题的。3.1 多集群纳管的实现原理CubeStudio 的多集群纳管本质上是一种联邦式管理。主集群上跑 CubeStudio 的控制面其他集群作为成员集群注册进来。控制面通过 K8s 的 ServiceAccount Token 或者 kubeconfig 访问成员集群的 API Server把任务下发过去。这里有个关键设计任务调度决策在主集群做但任务执行在成员集群。主集群的调度器知道所有成员集群的资源情况通过定期同步当用户提交任务时调度器根据资源需求、亲和性规则、项目组配额等条件决定把任务发到哪个集群。这种架构的好处是用户只需要访问一个入口不用关心任务实际跑在哪里资源统一视图管理员能看到所有集群的资源使用情况项目组配额可以跨集群设置比如 A 项目组总共能用 10 张 GPU不管在哪个集群缺点是主集群和成员集群之间的网络必须稳定否则任务下发会失败成员集群的 K8s 版本不能和主集群差太多否则 API 兼容性有问题跨集群的数据传输需要考虑比如训练数据在主集群的 MinIO 上成员集群能不能访问3.2 成员集群注册实操第一步在成员集群创建 ServiceAccountapiVersion: v1 kind: ServiceAccount metadata: name: cube-studio-member namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: cube-studio-member-binding roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: cube-studio-member namespace: kube-system注意生产环境不要直接绑 cluster-admin应该按最小权限原则创建一个专用 Role只给必要的权限。这里为了演示方便用了 cluster-admin。第二步获取 Token 和 CA 证书# 获取 Token kubectl -n kube-system create token cube-studio-member # 获取 CA 证书 kubectl -n kube-system get secret service-account-secret -o jsonpath{.data.ca\.crt} | base64 -d ca.crt第三步在主集群注册成员集群CubeStudio 的 Dashboard 上有“集群管理”页面点“添加集群”填入集群名称自定义比如cluster-bjAPI Server 地址成员集群的 API Server 地址通常是https://master-ip:6443Token上一步获取的 TokenCA 证书上一步获取的 ca.crt 内容提交后CubeStudio 会尝试连接成员集群拉取节点信息和资源情况。如果连接成功集群列表里会显示成员集群的状态为“健康”。第四步配置跨集群网络和数据访问这一步最容易被忽略但恰恰是最关键的。成员集群上的 Pod 要能访问主集群的 MinIO 和 MySQL否则任务跑起来也拿不到数据和模型。几种常见方案方案一成员集群和主集群在同一个内网直接用内网 IP 访问。最简单但要求网络打通。方案二用 NodePort 暴露主集群的 MinIO 和 MySQL成员集群通过主集群的节点 IP 加 NodePort 访问。适合跨机房但网络可达的场景。方案三用 Ingress 暴露服务通过域名访问。适合有统一入口网关的环境。方案四在每个成员集群部署 MinIO 网关或者缓存数据就近访问。适合对训练数据读取速度要求高的场景。我实测下来方案二最省事配置简单性能也能接受。在 CubeStudio 的配置里把 MinIO 地址从minio.cube-studio.svc.cluster.local改成主集群节点IP:NodePort成员集群的 Pod 就能访问了。3.3 跨集群调度的策略配置成员集群注册进来后需要配置调度策略决定什么任务往哪个集群发。CubeStudio 支持几种调度策略按标签调度给成员集群打标签比如regionbeijing、gpu-typea100然后在任务提交时指定标签选择器。适合对硬件有特定要求的任务。按资源余量调度调度器实时监控各集群的资源使用率优先把任务发到资源空闲的集群。适合追求整体利用率最大化的场景。按项目组绑定某个项目组固定使用某个集群。适合有数据合规要求、数据不能出某个机房的场景。按优先级调度高优先级任务可以抢占低优先级任务的资源跨集群也生效。配置示例在 CubeStudio 的调度器配置里scheduler: policies: - name: default type: resource-aware clusters: - name: cluster-bj weight: 1.0 - name: cluster-sh weight: 0.8 - name: project-a-policy type: project-bound project: project-a cluster: cluster-bj实操心得跨集群调度最容易出问题的地方是镜像拉取。成员集群的节点上如果没有提前拉取训练镜像任务启动会卡在 ImagePullBackOff。解决办法是在成员集群也配置一个镜像仓库的 mirror或者用 CubeStudio 的镜像预热功能提前把常用镜像分发到各集群。4. 按项目组分配算力多资源组隔离与配额管理多机多集群搭好之后最后一块拼图是资源组。一个公司里通常有多个项目组每个组能用的算力应该有个上限不然就会互相抢资源。4.1 资源组模型设计CubeStudio 的资源组模型可以理解为逻辑上的资源分区。一个资源组可以对应一个或多个 K8s 命名空间也可以跨集群。资源组里可以设置GPU 配额这个组最多能用多少张 GPUCPU 配额最多能用多少核内存配额最多能用多少 GB存储配额最多能用多少 GB 的 PVC优先级高优先级组可以抢占低优先级组的资源资源组和 K8s 的 ResourceQuota 是什么关系CubeStudio 的资源组是更高层的抽象它在 K8s ResourceQuota 的基础上增加了跨集群、按项目组、动态调整的能力。底层还是通过 K8s 的 ResourceQuota 和 LimitRange 来实现硬限制。4.2 创建资源组并绑定项目在 CubeStudio Dashboard 上进入“资源管理”-“资源组”点“新建资源组”。基本信息名称比如nlp-team描述NLP 算法组专用关联项目选择project-nlp资源配额资源类型配额说明GPU8最多同时使用 8 张卡CPU64最多 64 核内存256Gi最多 256GB存储2TiPVC 总容量上限调度策略允许使用的集群cluster-bj、cluster-sh优先级medium是否允许抢占false创建完成后在项目设置里把项目关联到这个资源组。这样项目下的所有任务提交时都会受这个资源组的配额限制。4.3 配额生效验证与动态调整创建完资源组后一定要验证配额是否真的生效。验证方法一提交超额任务在nlp-team项目下提交一个需要 10 张 GPU 的任务观察是否被拒绝或者排队。正常情况下如果配额是 8这个任务应该提交失败提示“资源不足”。验证方法二查看资源使用情况在 Dashboard 的资源组详情页能看到当前的使用量GPU: 6/8 (75%) CPU: 32/64 (50%) 内存: 128Gi/256Gi (50%) 存储: 800Gi/2Ti (40%)动态调整如果某个项目组临时需要更多资源管理员可以在 Dashboard 上直接调整配额不需要重启任何服务。调整后立即生效。注意调低配额时如果当前使用量已经超过新配额不会立即杀掉正在运行的任务但新的任务提交会被拒绝。需要等现有任务跑完使用量降到新配额以下才能继续提交。4.4 多资源组下的调度优先级实战假设公司有三个项目组nlp-team、cv-team、infra-team。资源组配额如下资源组GPU 配额优先级是否可抢占infra-team4high是cv-team8medium否nlp-team6low否当 infra-team 提交一个需要 4 张 GPU 的任务但集群里只剩 2 张空闲 GPU 时因为 infra-team 是 high 优先级且允许抢占调度器会从 nlp-team 正在运行的任务中抢占 2 张 GPU。被抢占的任务会被暂停等资源释放后重新排队。这个机制保证了核心业务的资源需求但也要慎用抢占因为频繁抢占会导致低优先级组的任务一直跑不完。我的建议是只给最核心的业务组开抢占权限并且设置抢占冷却时间比如 30 分钟内最多抢占一次。5. 常见问题与排查技巧实录多机多集群多资源组的部署涉及组件多、链路长出问题是常态。下面是我踩过的坑和对应的排查思路。5.1 节点 NotReady 排查现象kubectl get nodes显示某个工作节点状态是 NotReady。排查步骤登录该节点检查 kubelet 状态systemctl status kubelet看 kubelet 日志journalctl -u kubelet -n 100 --no-pager常见原因Docker 服务挂了systemctl restart docker磁盘满了df -h清理/var/lib/docker和/var/lib/kubelet内存不足free -hkubelet 需要至少 1GB 可用内存证书过期kubeadm certs check-expiration过期了就 renew网络插件异常检查 calico 或 flannel 的 Pod 日志速查表错误信息原因解决failed to get node ip网络配置问题检查节点 IP 和路由PLEG is not healthy容器运行时卡死重启 docker 和 kubeletdisk pressure磁盘使用率超阈值清理镜像和日志memory pressure内存不足清理无用 Pod 或扩容5.2 GPU 资源无法调度现象任务一直 Pending事件显示0/3 nodes are available: 3 Insufficient nvidia.com/gpu。排查确认节点上 GPU 资源是否注册kubectl describe node 节点名 | grep nvidia.com/gpu如果没有输出检查 nvidia-device-plugin Pod 是否 Running如果 plugin Pod 报错常见原因是驱动版本不匹配或/var/lib/kubelet/device-plugins目录权限问题如果节点上有 GPU 但显示数量为 0可能是 GPU 被其他进程占用nvidia-smi看一下实操心得nvidia-device-plugin 有时候会“假死”Pod 是 Running 但不再上报资源。这时候删掉 Pod 让它重建就行kubectl delete pod -n kube-system -l namenvidia-device-plugin-ds。5.3 跨集群任务下发失败现象在主集群提交任务到成员集群任务一直卡在“等待调度”或者“创建中”。排查检查主集群到成员集群的网络连通性telnet 成员集群API-Server-IP 6443检查 Token 是否过期CubeStudio 用的 ServiceAccount Token 默认有效期是 1 年过期后需要重新创建检查成员集群的 RBAC 权限用 Token 手动调一下成员集群的 API看是否有权限检查成员集群的资源是否真的够有时候调度器认为够但实际节点上资源被其他非 CubeStudio 的任务占用了速查表现象可能原因解决连接超时网络不通检查防火墙和安全组401 UnauthorizedToken 无效重新创建 Token403 Forbidden权限不足检查 ClusterRoleBinding资源不足配额或实际资源不够调整配额或扩容5.4 资源组配额不生效现象给项目组设了 GPU 配额 4但用户提交了 8 张卡的任务居然跑起来了。排查确认项目是否真的绑定了资源组在项目设置里看“资源组”字段确认资源组的配额是否保存成功刷新页面看配额值检查是否有管理员权限的用户绕过了配额CubeStudio 里管理员默认不受配额限制检查底层 K8s 的 ResourceQuota 是否创建成功kubectl get resourcequota -n 项目命名空间注意资源组配额是“软限制”还是“硬限制”取决于配置。软限制只做提醒硬限制会直接拒绝。生产环境建议用硬限制避免有人无意中超额。5.5 存储性能瓶颈现象多机环境下训练任务读取数据特别慢GPU 利用率上不去。排查检查存储方案NFS 在小文件多的情况下性能很差考虑换 Ceph 或者本地 SSD检查网络带宽万兆网络是基本要求千兆网络跑大规模训练会成为瓶颈检查 MinIO 的配置单节点 MinIO 没有冗余多节点 MinIO 需要配置纠删码考虑数据本地化把常用数据集提前分发到各工作节点的本地盘训练时直接读本地我实测过一个场景同样的训练任务数据在 NFS 上跑要 4 小时把数据拷到本地 SSD 后只要 2.5 小时。差距非常明显。所以如果预算允许给每个工作节点配大容量 SSD 做数据缓存收益很高。5.6 平台高可用配置检查清单最后列一个高可用检查清单部署完成后逐项核对[ ] K8s 控制面至少 3 个 master 节点生产环境[ ] CubeStudio API Server 至少 2 个副本[ ] MySQL 配置主从复制或使用外部高可用数据库[ ] Redis 配置哨兵或集群模式[ ] MinIO 至少 4 个节点配置纠删码[ ] 所有关键组件配置 PodDisruptionBudget[ ] 配置定期备份MySQL 每天全量备份MinIO 每周全量备份[ ] 监控告警节点资源、Pod 状态、API 响应时间都要有监控[ ] 日志收集所有组件日志集中收集方便排查问题这套多机多集群多资源组的方案我从最初的两台机器折腾到现在管理十几个节点、三个集群中间踩的坑远不止上面列的这些。但每次解决问题后回头看都会发现其实问题本身不复杂复杂的是组件之间的交互和依赖关系。把架构理清楚知道每个组件负责什么、数据怎么流转排查问题就有方向了。最后分享一个小技巧部署完成后写一个自动化巡检脚本每天定时检查所有节点状态、Pod 状态、资源使用率、证书有效期有问题提前告警。这个脚本我用了两年帮我避免了好几次半夜被叫起来处理故障的情况。脚本本身不复杂就是调 K8s API 和 CubeStudio API 拉数据然后做阈值判断但收益非常大。