设计云原生应用程序的15条基本原则

2022-04-14 11:56:43来源：进击云原生

设计可扩展的云原生应用程序需要深思熟虑，即便拥有大量云来部署我们的应用程序，目前仍有许多挑战需要克服。以复杂而臭名昭著的分布式计算仍然是真实的。同时网络的不稳定也会导致速度变慢和意外错误。因为云原生应用程序通常是微服务，因此必须专门设计和部署以克服这些挑战。

在本文中，我将介绍如何设计云原生应用程序并将其部署在 Kubernetes 上的15条基本原则。

原则1：单个 Pod 几乎是不可用的

因为 Kubernetes 可以在必要时自行决定终止 Pod，所以你需要一个控制器来创建你的 Pod。除了一次性调试之外，尽量少使用单个 Pod。

副本集也几乎不是你想直接使用的东西。

相反，你应该有一个 Deployment 或 StatefulSet 创建 Pod。无论你是否打算运行多个实例，这都适用。你希望实现自动化的原因是 Kubernetes 不保证 Pod 的持续生命周期，所以需要同时运行多个实例，以防万一其中的容器发生故障。

原则2：明确区分有状态和无状态组件

Kubernetes 定义了许多不同的资源和管理它们的控制器。每个都有自己的语义。我看到了关于 Deployment、StatefulSet 和 DaemonSet 是什么以及它们能做什么或不能做什么的困惑。用对了意味着你清楚地表达了你的意图，Kubernetes 可以帮助你实现目标。

如果使用得当，Kubernetes 会强制你这样做，但存在许多复杂的解决方案。简单的经验法则是让所有有状态的东西都在 StatefulSet 中，而在 Deployments 中是无状态的，因为这样做是 Kubernetes 的方式。使用时还请仔细阅读官方文档。

原则3：将秘密与非秘密配置分开，以明确使用以保证安全

ConfigMap 和 Secret 之间几乎没有技术差异。既包括它们在 Kubernetes 内部的表示方式，也包括它们的使用方式。例如，应用程序配置存储在 ConfigMap 中，然后带有凭据的数据库连接字符串属于Secret。

原则4：启用自动扩容选项

就像所有 Pod 实际上都由 Deployment 管理并以 Service 为前端一样，你还应该始终考虑为你的 Deployment 使用Horizontal Pod Autoscaler (HPA)。

从来没有人愿意在他们的服务在生产环境中耗尽容量。同样，没有人希望最终用户因为 Pod 的容量分配不佳而受苦。从一开始就为此做好准备意味着你将被迫进入缩放可以并且将会发生的心态。这比容量用完要好得多。

根据一般的可扩展性设计原则，你应该已经准备好运行每个应用程序组件的多个实例。这对于可用性和可扩展性至关重要。

请注意，你也可以使用 HPA 自动扩展 StatefulSet。然而，有状态的组件通常应该只在绝对需要时才进行扩展。

例如，扩展数据库可能会导致大量数据复制和额外的事务管理发生，如果数据库已经处于高负载状态，这会产生不可控制的问题。此外，如果你确实自动缩放有状态组件，请考虑禁用自动缩减。特别是，如果有状态组件需要以某种方式与其他实例同步。相反，手动触发此类操作更安全。

原则5：通过与容器生命周期管理挂钩来增强和启用自动化

一个容器可以定义一个 PostStart 和 PreStop 钩子，这两个钩子都可以用来执行重要的工作，以通知应用程序的其他组件一个实例的新启动或其即将终止。PreStop 函数将在终止之前调用，并且有一个(可配置的)时间来完成。使用它来确保即将终止的实例完成其工作，将文件提交到持久卷，或者为了有序和自动关闭而需要发生的任何其他事情。

原则6：正确使用探针来检测故障并自动从故障中恢复

与单进程系统相比，分布式系统将以越来越不直观的方式失败。网络是一大类新的故障原因。我们越能检测到故障，我们就越有机会从故障中自动恢复。

为此，Kubernetes 为我们提供了探测能力。特别是就绪探测非常有用，因为失败会向 Kubernetes 发出信号，表明你的容器(以及 Pod)还没有准备好接受请求。

尽管有明确的文档，但活性探针经常被误解。失败的活性探测表明组件永久卡在需要强制重启才能解决的不良情况。

启动探针被添加到 Kubernetes 以指示何时开始使用其他探针进行探测。因此，这是一种将它们推迟到执行它们开始有意义的方法。

原则7：让有故障组件快速暴露出来

应用程序组件发生严重故障(崩溃)、快速故障(一旦出现问题)和大声故障(在其日志中包含信息丰富的错误消息)。这样做可以防止数据在你的应用程序中陷入奇怪的状态，只会将流量路由到健康的实例，并且还会提供根本原因分析所需的所有信息。本文中的所有自动化和其他原则将帮助你在找到根本原因的同时保持你的应用程序处于良好状态。

无论是在你的组件中，还是在集群本身中。失败是不可避免的，应用程序中的组件必须能够自动处理失败或重启。

原则8：保证可观测性

监控、日志记录和链路跟踪是可观察性的三大支柱。只需将自定义指标提供给你的监控系统，编写结构化日志(例如 JSON 格式)，而不是故意删除 HTTP 标头(例如带有相关 ID 的标头)，而是将它们作为记录内容的一部分，将为你的应用程序提供可观察的所有内容。

如果你需要更详细的跟踪信息，请将你的应用程序与 Open Telemetry API 集成。但是前面的步骤使你的应用程序易于观察，无论是人工操作员还是自动化。基于对你的应用程序有意义的指标进行自动缩放几乎总是比基于 CPU 使用率等原始指标更好。

SRE 的 “四个黄金信号” 是延迟、流量、错误和饱和度。从经验上看，使用特定于应用程序的指标跟踪这些监控信号比使用通用基础资源获得的原始指标要有用得多。

原则9：适当限制 Pod 资源请求

通过适当地设置Pod资源请求和限制，Horizontal Pod Autoscaler 和 Cluster Autoscaler 都可以做得更好。如果他们知道需要多少容量和可用容量，则确定你的 Pod 和整个集群需要多少容量的工作会容易的多。

不要将你的请求和限制设置得太低!一开始这可能很诱人，因为它允许集群运行更多的 Pod。但除非请求和限制设置相同(为 Pod 提供 “有保证的” QoS 类)，否则你的 Pod 在正常(常规流量)操作期间可能会获得更多资源。看起来一切都很好地工作。但在高峰期，它们的QPS将被限制在你指定的数量。而扩大规模实际上意味着每个部署的 Pod 占用更多的资源，但是整体性能可能会更差。

原则10：预留容量并优先考虑 Pod 优先级

在容量管理方面，命名空间资源配额、节点上预留的计算资源以及适当设置 Pod 优先级有助于确保集群容量和稳定性不受影响。

避免集群负载过高，以至于网络插件的 Pod 被驱逐。

原则11：根据需要强制合并或分散 Pod

Pod传播约束以及亲和性和反亲和性规则可以做到将 Pod 放在一起(以提高网络流量效率)或将它们分散(以实现冗余)跨多云区域保证可用性的好方法。

原则12：在可能导致停机的计划操作期间确保 Pod 可用性

Pod Disruption Budget 指定一次允许多少个 Pod 集合(例如在 Deployment 中)被自愿中断(即由于你的命令，而不是故障)。尽管管理员标记了部分不可用集群节点，这有助于确保高可用性。例如，在集群升级期间会发生这种情况，并且通常每月发生一次，因为 Kubernetes 更新速度很快。

请注意，如果你错误地设置 Pod 中断预算，你可能会限制管理员进行集群升级的能力。这会干扰自动操作系统修补并危及环境的安全状况。

PDB 会限制因自愿中断而同时停机的复制应用程序的 Pod 数量。

原则13：选择蓝/绿或金丝雀部署而不是停机部署

在这个时代，为了升级维护而关闭整个应用程序是不可接受的。这现在被称为“stop-the-world 部署”，其中应用程序暂时无法访问。通过更复杂的部署策略，可以实现更平滑和更渐进的变化。最终用户根本不需要知道应用程序已更改。

蓝/绿和金丝雀部署曾经是一门黑色艺术，但 Kubernetes 让所有人都可以更廉价的使用它。更快的推出组件的新版本。不过可能需要您在自己的脚本中或多或少地手动实现它们，但是更多好的方式是选择一些 CD 发布工具，以执行高级部署策略，例如 ArgoCD(蓝/绿或金丝雀)。

在技术层面上，大多数部署策略归结为同时部署同一组件的两个版本，并以不同的方式将请求拆分给它们。你可以通过 Service 本身执行此操作，例如，用适当的标签标记新版本的 5% 的 Pod，以使 Service 将流量路由到它们。或者即将推出的 Kubernetes Gateway 将开箱即用。

原则14：避免授予 Pod 不需要的权限

Kubernetes 本身并不安全，默认情况下也不安全。但是您可以对其进行配置以强制执行安全最佳实践，例如限制容器在节点上可以执行的操作。

以非 root 用户身份运行您的容器。在 Docker 中构建容器镜像使得容器默认以 root 身份运行这一事实可能已经为黑客带来了近十年的乐土。仅在容器构建过程中使用 root 来安装依赖项，然后创建一个非 root 用户并让其运行您的应用程序。

如果你的应用程序确实需要提升权限，那么仍然使用非 root 用户，删除所有 Linux 功能，并仅添加最少的功能集。

原则15：限制Pod在集群中可以做的事情

禁止将默认服务帐户暴露给您的应用程序。除非您特别需要与 Kubernetes API 交互，否则不应将默认服务帐户令牌安装到其中。然而，默认情况下，Kubernetes 是允许的。