如果您曾使用过近期发布的 IBM Maximo Application Suite (MAS)，您可能遇到过 admin-build-config pod 反复进入 已驱逐 状态。

乍一看，一切似乎正常。CPU 利用率低，内存使用量合理，持久存储也有充足的可用容量。然而，该 pod 却持续失败并重启，导致 MAS 环境无法完成构建。

最近，我发现这个问题在较新的 MAS 版本中变得越来越普遍，而且在许多情况下，根本原因根本不是 CPU、内存或持久存储。

而是临时存储。

了解临时存储

与持久卷不同，临时存储仅在 pod 的生命周期内存在。由于它位于工作节点本身，Kubernetes 会密切监控其消耗，并在超出配置限制时驱逐 pod。

对于许多管理员来说，临时存储很容易被忽视，因为它通常不属于常规容量讨论的一部分。我们关注 CPU、内存和 PVC 大小，但构建工作负载会消耗大量的临时磁盘空间。

常见触发因素：多个定制归档文件

我注意到的一种模式是，此问题最常发生在配置了多个（或非常大）定制归档文件进行部署的环境中。

在管理员构建过程中，MAS 会下载并解压每个定制归档文件，然后将其内容添加到构建中。虽然单个归档文件可能影响很小，但多个归档文件会显著增加临时存储消耗……而且速度很快！

让许多管理员措手不及的是，所需空间通常远大于 ZIP 文件本身的合计大小。在解压和处理过程中，临时文件会在 Pod 的临时存储中创建和存储。随着定制包的数量和大小增加，临时存储需求也随之增加。构建过程很快就会超出配置的临时存储限制，导致 Pod 在完成之前被逐出。

症状

当临时存储成为问题时，Kubernetes 会 非常 在事件消息中明确指出。如果 admin-build-config Pod 处于“已逐出”状态，请点击“事件”选项卡并查找类似以下的消息：
‍

‍

解决问题

当管理员构建工作负载超出默认分配时，增加 Admin Build Config 的临时存储请求和限制将解决此问题。
‍

在 manageWorkspace 自定义资源定义 (CRD) 中查看您当前的配置。开箱即用 (OOTB) 的默认值如下所示：
‍

‍

在 IBM 的 documentation中， manageWorkspace CRD 可以 据称 通过修改 OpenShift 控制台 UI 中的 `spec.settings.deployment.ephemeralStorage` 部分进行更新。然而，尝试通过 UI 更新这些值均未成功。配置会反复恢复到默认设置。
‍

我发现唯一可靠的方法是使用 `oc patch` 命令应用更改：
‍

oc patch manageworkspace a311833-mas -n mas-a311833-manage --type='merge' -p '{"spec":{"settings":{"deployment":{"ephemeralStorage":{"limits":{"adminBuild":"200Gi"},"requests":{"adminBuild":"50Gi"}}}}}}' 

‍
应用补丁后，等待协调过程完成。协调完成后，将创建一个新的构建 Pod。打开 `admin-build-config` Pod 的 YAML 文件，验证更新后的临时存储值是否存在。在 YAML 中搜索“ephemeral”一词可以轻松确认更改已成功应用。
‍