开发人员给出了如何使用一些sh优化OpenShift容器性能的教程......
加入D Zone社区并获得完整的会员体验。
我是我们的一个客户（一家英国公用事业公司）云迁移项目的一部分，我们在AWS云上的不同环境中安装了OpenShift集群，以部署代码并运行DevOps管道。
我们有五个不同的OpenShift集群，即开发、测试、预生产、生产和自动化。每个集群将有不同数量的节点，其中主节点和基础节点在所有环境中是恒定的（每个环境有三个节点），并且根据每个集群上的工作负载有不同数量的工作节点。因此，考虑到我们在不同集群中使用的节点数量（AWS ec2实例），AWS成本非常高。
我们开发了一个解决方案，可以在非工作时间内优雅地关闭集群，而不会影响任何开发活动。这种优雅的关闭包括运行在工作节点上的所有应用程序Pod和运行在基础节点上的所有OpenShift系统相关Pod。
但是，有一个挑战！
当我们使用OpenShift排水命令来排水节点时，由于会话超时或由于一些pod删除时间过长，一些pod没有完全删除。尽管我们在排水时排除了OpenShift系统相关的Daemonset pod，但在没有会话超时的宽限期内删除所有应用程序pod是一个挑战。为了克服这个问题，我们必须在外壳脚本中实现循环逻辑。
实现涉及一系列shell脚本，这些脚本按照以下顺序一个接一个地调用。
关机：
-
未调度节点
-
应用程序吊舱缩小
-
排水节点
-
停止ec2实例。
创业：
-
启动ec2实例
-
调度-回节点
-
应用规模UP
-
理智检查
这种实现帮助我们的客户节省了大量的AWS基础架构成本。我们将在下面的后续部分中查看实现情况。
在上面的序列中，应用程序Pod的缩放（应用程序缩放）是可选的，因为它完全是项目特定的。
上表描述了初始实现（7月份）和我们对shell代码进行调整后的实现（8月份）之间的差异。
免责声明：
我们的实现适用于Red Hat OpenShift v3.11，同样的实现也适用于OpenShift（OKD）的原始版本。如果有人想在客户的项目中实现这一点，总是建议寻求供应商关于如何/whether允许重新启动节点的建议。一旦底层节点设置好，一些供应商将不支持它们的重启。此外，不建议关闭主节点，因为它们托管许多与系统相关的Pod和API组件。
下面是我们在整个实现中使用的逻辑片段。
