在K8S/OpenShift上开发应用程序的14种最佳实践



:notebook: 备注:

本篇为译文, 思路和我之前的: 《容器化应用系统上生产的最佳实践》和 《容器最佳实践》有异曲同工之妙。理论上K8S通用, 特此翻译分享。

原文：openshift blog - 14 Best Practices for Developing Applications on OpenShift

原文作者: Ales Nosek

原文地址： <https://www.openshift.com/blog/14-best-practices-for-developing-applications-on-openshift>



在这一年中，我一直在与几个开发团队合作，他们开始在K8S/OpenShift上构建应用程序。 我的目标是为开发人员提供指导和最佳实践，以帮助他们成功地将应用程序部署到生产环境中。 如果您是在K8S/OpenShift之上构建应用程序的开发人员，那么您可能会对此博客感兴趣。



该博客包括两类最佳实践。 第一类列出了提高应用程序可靠性的实践，第二类包括了提高安全性的实践。 请注意，这两个类别之间有些重叠。 您会发现在某种程度上可以提高安全性的可靠性实践，反之亦然。



应用程序可靠性



以下9种最佳实践可提高应用程序可用性，正常运行时间，并总体上改善应用程序用户体验。



1. 将应用程序配置外部化



包含环境特定配置的容器镜像不能在环境（Dev，QA，Prod）中升级。 为了实现可靠的发布过程，应将在较低环境中测试过的相同镜像部署到生产中。(译者注: 一次构建, 到处运行)



将特定于环境的配置保留在容器镜像之外。 例如，使用ConfigMaps和Secrets存储应用程序配置。



1. 在pod定义中定义资源请求和资源限制



由于请求资源的配置不正确，应用程序可能会耗尽内存或导致CPU饥饿。 指定请求的内存和CPU资源可以使群集做出适当的调度决策，以确保应用程序具有请求的资源可用。



1. 始终在POD定义中定义liveness 和readiness探针。



运行状况检查探针使群集可以为您的应用程序提供基本的弹性。 它允许群集重新启动您的应用程序（liveness 探测失败），或者避免在未准备好服务请求的情况下将流量路由到您的应用程序（readiness 探测）。



1. 使用pod disruption budgets保护应用程序



在某些情况下，需要从集群节点中驱逐应用程序pods。例如，在管理员可以执行节点维护之前，或者在集群autoscaler在降级时从集群中删除节点之前，需要进行驱逐。为了确保您的应用程序在需要驱逐pods时仍然可用，您必须定义各自的PodDistruptionBudget对象。



1. 确保应用程序Pod正常终止



终止时，应用程序容器应完成所有进行中的请求并正常终止现有连接。 这允许在终端用户不注意的情况下重新启动pod，例如在部署应用程序的新版本时。



1. 每个容器运行一个进程



避免在单个容器中运行多个进程。 在单独的容器中运行1个进程可以更好地隔离进程，避免信号路由出现问题，并避免出现僵尸进程。



1. 实现应用程序监控和告警



应用程序监控和告警对于保持应用程序在生产中良好运行并满足业务目的至关重要。 使用Prometheus＆Grafana等监控工具来监控您的应用程序.



1. 配置应用程序以将其日志写入stdout / stderr (译者注: 其他K8S发行版按需采纳)



OpenShift将收集这些日志(指stdout/stderr)并将其发送到集中位置（ELK，Splunk）。 在分析生产问题时，应用程序日志是宝贵的资源。 基于应用程序日志内容的告警有助于确保应用程序按预期运行.



1. 考虑实施以下弹性措施：



1. 断路器

2. 超时

3. 重试

4. 速率限制



列出的弹性措施可以使您的应用程序在出现故障时表现更好。 它们可保护您的应用程序免于过载（速率限制，断路器），并在遇到连接问题（超时，重试）时提高性能。 考虑利用Service Mesh实现这些措施，而无需在应用程序中更改代码。



应用程序安全性



本节包括5个最佳实践，它们将提高应用程序的安全性。 我强烈建议您考虑在您的环境中实施所有这些实践。



1. 使用受信任的基础镜像



尽可能使用供应商提供的容器镜像。 供应商镜像已经过测试，强化和支持。 如果使用社区支持的图像，请仅使用您信任的社区提供的图像。 在公共注册表（例如Docker Hub）中有未知来源的图像。 不要使用它们！



1. 使用最新版本的基础镜像



仅最新版本的容器镜像包含所有可用的安全修复程序。 设置CI管道以在构建应用程序镜像时始终提取最新版本的基础镜像。 另外，设置CI管道以在更新的基础镜像可用时重建应用程序。



1. 使用单独的构建镜像和运行时镜像 (译者注: docker的多阶段构建功能)



创建具有最小依赖性的单独的运行时镜像可减少攻击面并产生较小的运行时镜像。 构建镜像包含构建依赖关系，构建依赖关系对于构建应用程序是必需的，而对于运行应用程序则不是必需的



1. 尽可能遵守受限的安全上下文约束(restricted security context constraint) (译者注: 应该是OpenShift特有的安全加固功能)



修改您的容器镜像以允许在受限的SCC(security context constraint简写)下运行。



应用程序容易受到攻击，攻击者可以控制应用程序。 强制使用OpenShift受限制的SCC可提供最高级别的安全性，以防止在应用程序被破坏的情况下损害集群节点。



1. 使用TLS保护应用程序组件之间的通信。



应用程序组件可能会传达应受到保护的敏感数据。 除非您认为基础OpenShift网络是安全的，否则您可能希望利用TLS保护应用程序组件之间的通信。 考虑利用Service Mesh对应用程序TLS进行管理。



总结



在此博客中，我们回顾了14种最佳实践，可以帮助您在K8S/OpenShift上构建更可靠，更安全的应用程序。 开发人员可以使用此列表导出自己的强制性实践列表，所有团队成员都必须遵循该列表.



该博客中列出的实践列表是一个良好的开端。 如果您想了解更多信息，可以在OpenShift文档的创建镜像部分中找到另一套很好的建议。