技术能力

k8s/prometheus/cicd/golang 运维平台开发
k8s多集群管理，gpu集群调优
k8s运维开发：webhook、operator、设备插件、开发调度器、在离混部
8模块大运维平台：工单、cmdb、服务树、任务执行中心、巡检平台、

项目经验

### 3. 丰富的运维平台/工具设计能力和良好的go语言编码能力
- 举例：独立设计并研发k8s集群巡检平台【node-env-check】，接管多个k8s集群
- 背景：总结多次k8s集群故障后发现 多数都是来自机器、内核、组件等配置不合理，不一致导致
- 梳理巡检项和巡检基线：
- 网卡驱动和队列等10项
- 机器和内核：cpu频率和tcp半连接队列数等20项
- kubelet配置：绑核和资源预留等5项
- 接入方便，展示给力的巡检组件

- 举例：研发event采集分析组件：基于event的查询分析操作：
- 将全量的event通过采集组件采集到日志平台供后面查询
- 将event转化为metrics监控，并且设置特定场景告警
- event分析大盘：异常event按照原因/控制器/ns/目标对象等分析报表：可以一目了然的从全局观察集群健康情况和变化

- 举例：独立设计并研发通用k8s多集群守卫工具guard覆盖batch平台pending-job自动发现和处理
- batch平台pending-job自动发现和处理
- 分析目前影响batch稳定性的最大问题 ：
- 发现大部分都是节点级别的异常(csi/cri/network)等导致，而且通常一个node的异常会产生放大效应, 即影响10+的job
- 同时手动处理效率较低
- 产品设计： 期望能自动发现异常节点并及时禁止 并自动补救pending-job的副本pod ，包含以下
- 01 异常mount-pod清理
- 02 uss挂载异常的节点需要及时cordon node
- 03 pending job 自动删除异常slave-pod，可以使job-running，并及时cordon node
- 数据说话:完成100+批次的异常node和60+pod自动处理，并且成功在多出 critical告警中拦截异常
- 在工具上线完成后：未再发生大规模的平台异常导致大规模作业pending
- 平均处理效率对比：工具 5 分钟级 对比 手动 3 小时
- 通用k8s多集群
- gpu坏卡自动发现处理功能
- 目前gpu卡缺乏直观坏卡监控指标：编写组件gpu-bad-card-monitor 暴露指标
- 自动禁止坏卡节点并报修，避免影响扩大
- 覆盖kubelet不能自动处理的异常case
- 支持用户自定义异常场景接入
- 支持节点界别的自动发现，处理，记录，通知和自愈等模块
- 举例：完成训练平台资源利用率基础信息采集(租户、项目、任务)工具研发
- 包含租户、项目、作业级别的 信息采集
- 服务资源画像
- 举例：batch组件发布工具：tekton平台上线：
- 封装 10 种常用的流水线给batch，完成200+的发布任务
- 完成24/30个离线k8s集群的接入
- 使得batch的配置文件全部放入git仓库中，可以追查，避免手动修改后配置项混乱不统一的问题

团队情况