AI+ 云原生，把卫星遥感虐的死去活来

​​​​​​​​​​摘要：遥感影像，作为地球自拍照，能够从更广阔的视角，为人们提供更多维度的辅助信息，来帮助人类感知自然资源、农林水利、交通灾害等多领域信息。

本文分享自华为云社区《AI+云原生，把卫星遥感虐的死去活来》，作者：tsjsdbd。

AI 牛啊，云原生牛啊，所以 1+1>2？

遥感影像，作为地球自拍照，能够从更广阔的视角，为人们提供更多维度的辅助信息，来帮助人类感知自然资源、农林水利、交通灾害等多领域信息。

AI 技术，可以在很多领域超过人类，关键是它是自动的，省时又省力。可显著提升遥感影像解译的工作效率，对各类地物元素进行自动化的检测，例如建筑物，河道，道路，农作物等。能为智慧城市发展 &治理提供决策依据。

云原生技术，近年来可谓是一片火热。易构建，可重复，无依赖等优势，无论从哪个角度看都与 AI 算法天生一对。所以大家也可以看到，各领域的 AI 场景，大都是将 AI 推理算法运行在 Docker 容器里面的。

AI+云原生这么 6，那么强强联手后，地物分类、目标提取、变化检测等高性能 AI 解译不就手到擒来？我们也是这么认为的，所以基于 AI+Kubernetes 云原生，构建了支持遥感影像 AI 处理的空天地平台。

不过理想是好的，过程却跟西天取经一般，九九八十一难，最终修成正果。

业务场景介绍

遇到问题的业务场景叫影像融合（Pansharpen），也就是对地球自拍照进行“多镜头合作美颜”功能。（可以理解成：手机的多个摄像头，同时拍照，合并成一张高清彩色大图）。

所以业务简单总结就是：读取 2 张图片，生成 1 张新的图片。该功能我们放在一个容器里面执行，每张融合后的结果图片大约 5GB。

问题的关键是，一个批次业务量需要处理的是 3000 多张卫星影像，所以每批任务只需要同时运行完成 3000 多个容器就 OK 啦。云原生 YYDS！

业务架构图示

为了帮助理解，这里分解使用云原生架构实现该业务场景的逻辑图如下：

在云上，原始数据，以及结果数据，一定是要存放在对象存储桶里面的。因为这个数据量，只有对象存储的价格是合适的。（对象存储，1 毛钱/GB。文件存储则需要 3 毛钱/GB）

因为容器之间是互相独立无影响的，每个容器只需要处理自己的那幅影像就行。例如 1 号容器处理 1.tif 影像；2 号容器处理 2.tif 影像；以此类推。

所以管理程序，只需要投递对应数量的容器（3000+），并监控每个容器是否成功执行完毕就行（此处为简化说明，实际业务场景是一个 pipeline 处理流程）。那么，需求已经按照云原生理想的状态分解，咱们开始起(tang)飞(keng)吧~

注：以下描述的问题，是经过梳理后呈现的，实际问题出现时是互相穿插错综复杂的。

K8s 死掉了

当作业投递后，不多久系统就显示作业纷纷失败。查看日志报调用 K8s 接口失败，再一看，K8s 的 Master 都已经挂了。。。

K8s-Master 处理过程，总结版：

1.    发现 Master 挂是因为 CPU 爆了

2.    所以扩容 Master 节点（此次重复 N 次）；

3.    性能优化：扩容集群节点数量；

4.    性能优化：容器分批投放；

5.    性能优化：查询容器执行进度，少用 ListPod 接口；

详细版：

看监控 Master 节点的 CPU 已经爆掉了，所以最简单粗暴的想法就是给 Master 扩容呀，嘎嘎的扩。于是从 4U8G * 3 一路扩容一路测试一路失败，扩到了 32U64G * 3。可以发现 CPU 还是爆满。看来简单的扩容是行不通了。

3000 多个容器，投给 K8s 后，大量的容器都处于 Pending 状态（集群整体资源不够，所以容器都在排队呢）。而正在 Pending 的 Pod，K8s 的 Scheduler 会不停的轮训，去判断能否有资源可以给它安排上。所以这也会给 Scheduler 巨大的 CPU 压力。扩容集群节点数量，可以减少排队的 Pod 数量。

另外，既然排队的太多，不如就把容器分批投递给 K8s 吧。于是开始分批次投递任务，想着别一次把 K8s 压垮了。每次投递数量，减少到 1 千，然后到 500，再到 100。

同时，查询 Pod 进度的时候，避免使用 ListPod 接口，改为直接查询具体的 Pod 信息。因为 List 接口，在 K8s 内部的处理会列出所有 Pod 信息，处理压力也很大。

这一套组合拳下来，Master 节点终于不挂了。不过，一头问题按下去了，另一头问题就冒出来了。

容器跑一半，挂了

虽然 Master 不挂了，但是当投递 1~2 批次作业后，容器又纷纷失败。

容器挂掉的处理过程，总结版：

1.    发现容器挂掉是被 eviction 驱逐了；

2.    Eviction 驱逐，发现原因是节点报 DiskPressure（存储容量满了）；

3.    于是扩容节点存储容量；

4.    延长驱逐容器（主动 kill 容器）前的容忍时间；

详细版：

（注：以下问题是定位梳理后，按顺序呈现给大家。但其实出问题的时候，顺序没有这么友好）

容器执行失败，首先想到的是先看看容器里面脚本执行的日志呗：结果报日志找不到~

于是查询 Pod 信息，从 event 事件中发现有些容器是被 Eviction 驱逐干掉了。同时也可以看到，驱逐的原因是 DiskPressure（即节点的存储满了）。

当 DiskPressure 发生后，节点被打上了驱逐标签，随后启动主动驱逐容器的逻辑：

由于节点进入 Eviction 驱逐状态，节点上面的容器，如果在 5 分钟后，还没有运行完，就被 Kubelet 主动杀死了。（因为 K8s 想通过干掉容器来腾出更多资源，从而尽快退出 Eviction 状态）。

这里我们假设每个容器的正常运行时间为 1~2 个小时，那么不应该一发生驱动就马上杀死容器（因为已经执行到一半的容器，杀掉重新执行是有成本浪费的）。我们期望应该尽量等待所有容器都运行结束才动手。所以这个 pod-eviction-timeout 容忍时间，应该设置为 24 小时（大于每个容器的平均执行时间）。

  Disk Pressure 的直接原因就是本地盘容量不够了。所以得进行节点存储扩容，有 2 个选择：1）使用云存储 EVS（给节点挂载云存储）。 2）扩容本地盘（节点自带本地存储的 VM）。

由于云存储（EVS）的带宽实在太低了，350MB/s。一个节点咱们能同时跑 30 多个容器，带宽完全满足不了。最终选择使用 i3 类型的 VM。这种 VM 自带本地存储。并且将 8 块 NVMe 盘，组成 Raid0，带宽还能 x8。

对象存储写入失败

容器执行继续纷纷失败。

容器往对象存储写入失败处理过程，总结版：

1.    不直接写入，而是先写到本地，然后 cp 过去。

2.    将普通对象桶，改为支持文件语义的并行文件桶。

详细版：

查看日志发现，脚本在生成新的影像时，往存储中写入时出错：

我们整集群是 500 核的规模，同时运行的容器数量大概在 250 个（每个 2u2g）。这么多的容器同时往 1 个对象存储桶里面并发追加写入。这个应该是导致该 IO 问题的原因。

对象存储协议 s3fs，本身并不适合大文件的追加写入。因为它对文件的操作都是整体的，即使你往一个文件追加写入 1 字节，也会导致整个文件重新写一遍。

最终这里改为：先往本地生成目标影像文件，然后脚本的最后，再拷贝到对象存储上。相当于增加一个临时存储中转一下。

在临时中转存储选择中，2 种本地存储都试过： 1）块存储带宽太低，350MB/s 影响整体作业速度。2）可以选择带本地存储的 VM，多块本地存储组成 Raid 阵列，带宽速度都杠杠滴。

同时，华为云在对象存储协议上也有一个扩展，使其支持追加写入这种的 POSIX 语义，称为并行文件桶。后续将普通的对象桶，都改为了文件语义桶。以此来支撑大规模的并发追加写入文件的操作。

K8s 计算节点挂了

So，继续跑任务。但是这容器作业，执行又纷纷失败鸟~

计算节点挂掉，定位梳理后，总结版：

1.    计算节点挂掉，是因为好久没上报 K8s 心跳了。

2.    没上报心跳，是因为 kubelet（K8s 节点的 agent）过得不太好（死掉了）。

3.    是因为 Kubelet 的资源被容器抢光了（由于不想容器经常 oom kill，并未设置 limit 限制）

4.    为了保护 kubelet，所有容器全都设置好 limit。

详细版，直接从各类奇葩乱象等问题入手：

• 容器启动失败，报超时错误。

• 然后，什么 PVC 共享存储挂载失败：

• 或者，又有些容器无法正常结束（删不掉）。

• 查询节点 Kubelet 日志，可以看到充满了各种超时错误：

啊，这么多的底层容器超时，一开始感觉的 Docker 的 Daemon 进程挂了，通过重启 Docker 服务来试图修复问题。

后面继续定位发现，K8s 集群显示，好多计算节点 Unavailable 了（节点都死掉啦）。

继续分析节点不可用（Unavailable），可以发现是 Kubelet 好久没有给 Master 上报心跳了，所以 Master 认为节点挂了。说明不仅仅是 Docker 的 Daemon 受影响，节点的 Kubelet 也有受影响。

那什么情况会导致 Kubelet，Docker 这些主机进程都不正常呢？这个就要提到 Kubernetes 在调度容器时，所设计的 Request 和 Limit 这 2 个概念了。

Request 是 K8s 用来调度容器到空闲计算节点上的。而 Limit 则会传递给 Docker 用于限制容器资源上限（触发上限容易被 oom killer 杀掉）。前期我们为了防止作业被杀死，仅为容器设置了 Request，没有设置 Limit。也就是每个容器实际可以超出请求的资源量，去抢占额外的主机资源。大量容器并发时，主机资源会受影响。

考虑到虽然不杀死作业，对用户挺友好，但是平台自己受不了也不是个事。于是给所有的容器都加上了 Limit 限制，防止容器超限使用资源，强制用户进程运行在容器 Limit 资源之内，超过就 Kill 它。以此来确保主机进程（如 Docker，Kubelet 等），一定是有足够的运行资源的。

K8s 计算节点，又挂了

于是，继续跑任务。不少作业执行又双叒失败鸟~

节点又挂了，总结版：

1.    分析日志，这次挂是因为 PLEG（Pod Lifecycle EventGenerator）失败。

2.    PLEG 异常是因为节点上面存留的历史容器太多（>500 个），查询用时太久超时了。

3.    及时清理已经运行结束的容器（即使跑完的容器，还是会占用节点存储资源）。

4.    容器接口各种超时（cpu+memory 是有 limit 保护，但是 io 还是会被抢占）。

5.    提升系统磁盘的 io 性能，防止 Docker 容器接口（如 list 等）超时。

详细版：

现象还是节点 Unavailable 了，查看 Kubelet 日志搜索心跳情况，发现有 PLEG is nothealthy 的错误：

于是搜索 PLEG 相关的 Kubelet 日志，发现该错误还挺多：

这个错误，是因为 kubelet 去 list 当前节点所有容器（包括已经运行结束的容器）时，超时了。看了代码：

https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/pleg/generic.go#L203

kubelet 判断超时的时间，3 分钟的长度是写死的。所以当 pod 数量越多，这个超时概率越大。很多场景案例表明，节点上的累计容器数量到达 500 以上，容易出现 PLEG 问题。（此处也说明 K8s 可以更加 Flexible 一点，超时时长应该动态调整）。

缓解措施就是及时的清理已经运行完毕的容器。但是运行结束的容器一旦清理，容器记录以及容器日志也会被清理，所以需要有相应的功能来弥补这些问题（比如日志采集系统等）。

List 所有容器接口，除了容器数量多，IO 慢的话，也会导致超时。

这时，从后台可以看到，在投递作业期间，大量并发容器同时运行时，云硬盘的写入带宽被大量占用：

对存储池的冲击也很大：

这也导致了 IO 性能变很差，也会一定程度影响 list 容器接口超时，从而导致 PLEG 错误。 

该问题的解决措施：尽量使用的带本地高速盘的 VM，并且将多块数据盘组成 Raid 阵列，提高读写带宽。

这样，该 VM 作为 K8s 的节点，节点上的容器都直接读写本地盘，io 性能较好。（跟大数据集群的节点用法一样了，强依赖本地 shuffle~）。

 在这多条措施实施后，后续多批次的作业都可以平稳的运行完。

总结：“AI+云原生”这条路

云原生是趋势，已经成为大家的共识，各领域也都开始以云原生为底座的业务尝试。AI 是未来，这也是当前不可阻挡的力量。但是当 AI 踏上这条云原生的道路却不那么一帆风顺。至少可以看到，华为云的云原生底座（当然，也包括存储、网络等周边基础设施）还可以有更多的进步空间。

但是，大家也不用担心太多，因为当前华为云的空天地平台，在经历了多年的 AI+云原生的积累，目前可以很稳定的处理 PB 级每日的遥感影像数据，支撑各类空基、天基、地基等场景，并且在该领域保持绝对领先的战斗值。虽然大家看到此间过程有点曲折，但是所有的困难都是涅槃的火种，克服过的困难都是今后可以对客户做的承诺。在这里可以很明确的告诉各位：AI+云原生=真香。

写这篇文章的目的，不是在阐述困难，而是为了总结分享。与同领域的人分享并促进遥感领域的快速发展，共同推动 AI+云原生的落地。

点击关注，第一时间了解华为云新鲜技术~