将应用程序部署到 Kubernetes 生产环境的最佳实践

2022-06-16

428

将应用程序部署到Kubernetes的生产环境中，这意味着您将面向终端用户正式公开该应用。每个人都希望这将是一次成功的发布，并对此表示毫无疑问。您对应用集群的容量管理、安全态势感知、灾难恢复等过程了如指掌……这些，现在，都将成为现实！

本文，我将为即将上线、部署应用程序的每个人推荐“将程序部署到生产环境中”的最佳实践。需要学习做什么，如何做，以及为什么要这样做。所有这些都是为了让您拥有可靠的操作，并能够专注于改进应用程序，而不是当问题来临时才紧急“救火”。

多场景负载测试的巨大价值

在使用应用程序的新版本或初始版本之前，需要能够对其进行负载测试。开发者可以使用诸如 JMeter 或 Locust 之类的合成负载生成器，也可以通过 Selenium 之类的用户交互工具重放一组记录。

为什么要进行负载测试？

很多原因。事实上，方便容量管理是原因之一，但肯定不是唯一的原因！

普通负载测试（容量管理测试）

为什么要做？确保为环境和应用程序分配了足够的容量。

如何做？设置合成工作负载生成器或重放相关工作负载。请平台管理员监控生产环境的容量使用情况。确保包括相关组件的性能和容量。例如，应用程序日志和应用程序指标是必需的，再比如，平台中的所有支持系统。

做什么？出于容量管理原因而执行的简单的负载测试。注意响应时间，生成平均、中位数、第 90 和第 95 个百分位响应时间的统计数据。

期望的结果：发现分配的容量是足够的。

可能的解决方案：（应用程序开发人员）确保应用程序具有合理的资源请求和限制。（平台运营商）确保 Kubernetes 平台组件和底层集群有足够的容量。

更新应用程序（可用性测试）

为什么要做？为确保应用程序可以在不停机的情况下更新，提供适当的可用性保证。

如何做？对应用程序进行一些细微的更改，例如，在某些 API 的输出中添加“Lorem ipsum”，然后重新部署。

做什么？在应用程序运行并承受负载时执行的负载测试。确保在负载测试工具中能够记录任何故障。

期望的结果：测量的停机时间是可以接受的（这个时间需要自己来定义）。

可能的解决方案：确保自己有正确的部署策略。在这里，个人是更喜欢滚动更新而不是重新创建。另外，还需确保根据需要调整部署策略的其他参数。

更新集群（可用性、稳定性测试）

为什么要做？节点故障可能导致应用程序挂掉。如果意外发生在晚上，那么管理员需要半夜爬起床来才能做出响应，此时应用程序的故障时间已经持续很久了。此外，管理员需要一些额外的资源容量来在节点的基本操作系统上执行关键的安全更新。

如何做？就像一个普通的负载测试，但现在要求管理员对所有 Kubernetes 集群节点执行滚动重启。

做什么？在应用程序运行并承受负载时执行负载测试。确保在负载测试时可以在工具中记录下所有故障。理想情况下，应该是可以实现的。

期望的结果：在节点故障或资源耗尽期间测量的停机时间（由于 Pod 迁移）是可以接受的。容量足以容纳一个节点故障或耗尽。

可能的解决方案：

· 确保应用程序具有适当的资源请求和资源限制；
· 确保应用程序至少有两个副本，并能够结合起来；
· 确保应用程序具有 topologySpreadConstraints 以便 Pod 不会在同一个 Node 上结束。

第2、3条措施，能够将使得应用程序组件的两个副本不会同时受到停机时间的影响。

关闭Cloud Region（抗灾能力测试）

为什么要做？如果需要跨多个区域进行部署，则必须测试资源的额外弹性。否则，区域故障可能会导致应用程序停机。

如何做？如上所述，但现在要求管理员删除整个区域。

期望的结果：在区域故障期间测量的停机时间（由于 Pod 迁移）是可以接受的。容量足以容纳一个区域的故障。

可能的解决方案：

· 确保应用程序具有适当的资源请求和限制。

· 确保应用程序至少有两个副本，并且

· 确保应用程序具有 topologySpreadConstraints 以确保 Pod 不会最终位于同一区域。

第2、3条措施，可以使应用程序组件的两个副本不会同时受到区域故障的影响。另外，根据之前的测试，还应该确保它们不会在同一个节点上结束。

灾难恢复：制定计划并执行

为什么要做？这可以确保改应用的研发团队就谁负责什么工作以及谁支持什么工作达成一致。这比最终认为“支持这个东西”是其他团队的问题要好得多。

如何做？要求管理员破坏环境并从异地备份中恢复。检查您的应用程序是否已备份并且其数据是否已按预期恢复。

期望的结果：测量的恢复点和恢复时间是可以接受的。

可能的解决方案：确保将应用程序数据存储在 PersistentVolumes 或（托管在）数据库中。对于 Compliant Kubernetes 用户，您可能会注意到 PersistentVolume 在 Compliant Kubernetes 中默认使用 Velero进行备份。（根据服务条款， Elastisys Managed PostgreSQL 客户默认拥有备份和时间点恢复。）

从零开始重新部署以确保能成功实现自动化

为什么这么做？这可以确保不存在 tribal knowledge，确保 Git 存储库是唯一的事实来源。其中关键的是，如果不是所有的应用都写在代码中并且完全自动化，你就必须找到一两个恰好知道该如何部署的工程师。在正常情况下，这样做的难度实在是大。如果工程师恰好在休假、生病或离职了，情况可能会更糟。

如何做？要求您的管理员“重置”环境，即移除所有容器镜像、移除所有缓存的容器镜像、移除所有 Kubernetes 资源等，重新部署应用程序。

期望的结果：测试出来的部署时间是可以接受的。

可能的解决方案：确保将所有代码和 Kubernetes 清单添加到 Git 存储库，并确保存在相关文档。

概括

本文展示了负载测试在使应用程序为生产做好准备、并面向终端用户上线的诸多用途。这个过程是有效的，其提供了巨大的实用价值。

那么，应该多久做一次负载测试呢？在微服务世界中，我们需要持续地发布应用新版本，但同时，也请为负载测试花点时间，因为根据经验，在这个过程中你将会发现所需要解决的问题。前几次测试中更多，随着时间的推移bug将会更少。

通过执行这些最佳实践措施，您将可以放心地进行部署，做好准备让您的App席卷全球。

行云创新基于Kubernetes及容器部署应用的最佳实践

行云创新CloudOS，一站式云原生开发平台，“以应用为核心”，为企业构建敏捷创新的应用研发环境，实现应用研发可视化和敏捷化，实现底层技术平台标准化，让传统应用研发团队零门槛转型为云原生研发团队，支撑传统应用云原生化，加快企业数字化转型。

从应用需求发起 > 建立项目 > 架构设计 > 代码研发 > 程序测试 > 应用发布 > 应用运维，应用全生命周期管理一个平台、一站搞定。