“云原生”或简称“云”应用程序是专门为在云基础设施中工作而创建的。 它们通常构建为一组打包在容器中的松散耦合的微服务，而容器又由云平台进行管理。 默认情况下，此类应用程序已做好应对故障的准备，这意味着即使在发生严重的基础设施级故障时，它们也能可靠地工作并可扩展。 硬币的另一面是云平台对容器应用程序施加的一组限制（合同），以便能够自动管理它们。
尽管充分意识到迁移到基于云的应用程序的必要性和重要性，但许多组织仍然不知道从哪里开始。 在这篇文章中，我们将探讨一些原则，如果在开发容器化应用程序时遵循这些原则，即使在 IT 基础设施发生严重故障的情况下，您也可以实现云平台的潜力并实现应用程序的可靠运行和扩展等级。 这里概述的原则的最终目标是学习如何构建可以由 Kubernetes 等云平台自动管理的应用程序。
软件设计原则
在编程世界中，原则是指开发软件时必须遵循的相当普遍的规则。 使用任何编程语言时都可以使用它们。 每个原则都有自己的目标，实现这些目标的工具通常是模板和实践。 还有一些创建高质量软件的基本原则，所有其他原则都源于这些原则。 以下是基本原则的一些示例：
- （保持简单，愚蠢）——不要让它复杂化；
- (Don't Repeat Yourself) - 不要重复自己；
- （你不会需要它）——不要创建不是立即需要的东西；
- 关注点分离——分担责任。
正如您所看到的，这些原则没有设定任何具体规则，而是属于基于实践经验的所谓常识性考虑的范畴，这些常识性考虑是许多开发人员所共享的，并且是他们经常参考的。
此外，还有 – 罗伯特·马丁制定的面向对象编程和设计的前五个原则。 SOLID 包含广泛的、开放式的、互补的原则，当这些原则一起应用时，有助于创建更好的软件系统并更好地长期维护它们。
SOLID原则属于OOP领域，用类、接口和继承等概念和概念的语言来表述。 以此类推，云应用的开发原则也可以制定，只是这里的基本元素不会是类，而是容器。 通过遵循这些原则，您可以创建更好地满足 Kubernetes 等云平台的目的和目标的容器化应用程序。
云原生容器：红帽方法
如今，几乎所有应用程序都可以相对轻松地打包到容器中。 但要在 Kubernetes 这样的云平台中有效地自动化和编排应用程序，还需要付出额外的努力。
下面概述的想法的基础是方法论 以及关于构建 Web 应用程序各个方面的许多其他工作，从源代码管理到扩展模型。 所描述的原则仅适用于基于微服务构建并为 Kubernetes 等云平台设计的容器化应用程序的开发。 我们讨论的基本元素是容器镜像，目标容器运行时是容器编排平台。 所提出的原则的目标是创建可以在大多数编排平台上自动执行调度、扩展和监控任务的容器。 这些原则的介绍没有特定的顺序。
单一关注原则（SCP）
该原则在很多方面与单一职责原则相似。 ），它是 SOLID 集的一部分，规定每个对象必须有一个职责，并且该职责必须完全封装在一个类中。 SRP 的要点是，每一项职责都是变更的原因，并且一个类必须有且只有一个变更的原因。
在 SCP 中，我们使用“关注”一词而不是“责任”一词来表示与 OOP 类相比，容器具有更高的抽象级别和更广泛的用途。 如果 SRP 的目标是只有一个改变的理由，那么 SCP 的背后就是扩展重复使用和替换容器的能力的愿望。 通过遵循 SRP 并创建一个解决单个问题并以功能完整的方式完成它的容器，您可以增加在不同应用程序上下文中重用该容器映像的机会。
SCP 原则规定，每个容器应该解决一个问题并做好它。 此外，容器世界中的 SCP 比 OOP 世界中的 SRP 更容易实现，因为容器通常运行一个进程，并且大多数时候该进程解决一项任务。
如果容器微服务必须同时解决多个问题，那么可以将其划分为单任务容器，并使用 sidecar 和 init 容器模板组合在一个 pod（容器平台部署的单位）内。 此外，SCP 可以轻松地将旧容器（例如 Web 服务器或消息代理）替换为解决相同问题但具有扩展功能或更好扩展性的新容器。
高可观测性原则（HOP）
当容器被用作打包和运行应用程序的统一方式时，应用程序本身被视为黑匣子。 但是，如果这些是云容器，则它们必须向运行时提供特殊的 API 来监视容器的运行状况，并在必要时采取适当的操作。 如果没有这一点，就不可能统一更新容器和管理其生命周期的自动化，这反过来又会恶化软件系统的稳定性和可用性。
实际上，容器化应用程序至少应该具有用于各种类型健康检查的 API：活性测试和就绪测试。 如果应用程序声称要做更多事情，它必须提供其他方法来监视其状态。 例如，通过 STDERR 和 STDOUT 记录重要事件，以便使用 Fluentd、Logstash 和其他类似工具进行日志聚合。 以及与跟踪和指标收集库的集成，例如 OpenTracing、Prometheus 等。
一般来说，应用程序仍然可以被视为黑匣子，但必须为其提供平台所需的所有 API，以便以最佳方式对其进行监控和管理。
生命周期一致性原则 (LCP)
LCP 是 HOP 的对立面。 HOP 规定容器必须向平台公开读取 API，而 LCP 要求应用程序能够从平台接受信息。 此外，容器不仅必须接收事件，还必须适应事件，换句话说，对事件做出反应。 因此，该原则的名称可以被视为向平台提供编写 API 的要求。
平台具有不同类型的事件来帮助管理容器的生命周期。 但由应用程序本身决定感知其中哪些以及如何做出反应。
显然，有些事件比其他事件更重要。 例如，如果应用程序不能很好地容忍崩溃，则它必须接受信号：终止（SIGTERM）消息并尽快启动其终止例程以捕获 SIGTERM 之后出现的信号：kill（SIGKILL）。
此外，PostStart 和 PreStop 等事件对于应用程序的生命周期也很重要。 例如，启动应用程序后，可能需要一些预热时间才能响应请求。 或者应用程序在关闭时必须以某种特殊方式释放资源。
图像不变性原则（IIP）
人们普遍认为，容器化应用程序在构建后应该保持不变，即使它们在不同的环境中运行。 这就需要在运行时外部化数据存储（换句话说，为此使用外部工具）并依赖外部的、运行时特定的配置，而不是为每个环境修改或创建唯一的容器。 对应用程序进行任何更改后，必须重新构建容器映像并将其部署到使用的所有环境。 顺便说一句，在管理 IT 系统时，也使用类似的原则，称为服务器和基础设施的不变性原则。
IIP 的目标是防止为不同的运行时环境创建单独的容器映像，并在任何地方使用相同的映像以及适当的特定于环境的配置。 遵循这一原则可以让您从云系统自动化的角度实现应用程序更新的回滚和前滚等重要实践。
过程一次性原则（PDP）
容器最重要的特性之一是其短暂性：容器的实例易于创建且易于销毁，因此可以随时轻松地用另一个实例替换。 进行此类替换的原因可能有很多：可服务性测试失败、应用程序扩展、转移到另一台主机、平台资源耗尽或其他情况。
因此，容器化应用程序必须使用某些外部手段来维护其状态，或者使用具有冗余的内部分布式方案。 此外，应用程序必须快速启动和快速关闭，并为突发的致命硬件故障做好准备。
有助于实现这一原则的一种做法是保持容器较小。 云环境可以自动选择一个主机来启动容器实例，因此容器越小，启动速度就越快——它只会更快地通过网络复制到目标主机。
自包含原则（S-CP）
根据这一原则，在组装阶段，所有必要的部件都包含在容器中。 容器应该建立在系统只有纯 Linux 内核的假设之上，因此所有必要的附加库都应该放置在容器本身中。 它还应该包含相应编程语言的运行时、应用程序平台（如果需要）以及容器应用程序运行时所需的其他依赖项等内容。
对于因环境而异的配置，必须在运行时提供例外情况，例如通过 Kubernetes ConfigMap。
应用程序可能包括多个容器化组件，例如容器化 Web 应用程序内的单独 DBMS 容器。 根据S-CP原则，这些容器不应该合并为一个，而是应该使得DBMS容器包含数据库运行所需的一切，而Web应用程序容器包含Web运行所需的一切应用程序，相同的网络服务器。 因此，在运行时，Web 应用程序容器将依赖于 DBMS 容器并根据需要访问它。
运行时限制原则 (RCP)
S-CP 原则定义了容器应如何构建以及图像二进制文件应包含什么。 但容器不仅仅是一个只有一个特征——文件大小的“黑匣子”。 在执行期间，容器呈现其他维度：使用的内存量、CPU 时间和其他系统资源。
这里 RCP 原则就派上用场了，根据该原则，容器必须减少对系统资源的需求并将其转移到平台。 通过每个容器的资源配置文件（需要多少 CPU、内存、网络和磁盘资源），平台可以最佳地执行调度和自动缩放、管理 IT 容量并维护容器的 SLA 级别。
除了满足容器的资源需求外，应用程序不要超越自身的边界也很重要。 否则，当发生资源短缺时，平台更有可能将其列入需要终止或迁移的应用程序列表中。
当我们谈论云优先时，我们谈论的是我们的工作方式。
上面，我们制定了一些通用原则，为云环境构建高质量的容器应用程序奠定了方法基础。
请注意，除了这些一般原则之外，您还需要使用容器的其他高级方法和技术。 此外，我们还有一些更具体的简短建议，应根据具体情况应用（或不应用）：
- 尝试减小镜像的大小：删除临时文件，不要安装不必要的软件包——容器大小越小，通过网络组装并复制到目标主机的速度就越快。
- 关注任意用户 ID：不要使用 sudo 命令或任何特殊用户 ID 来启动容器。
- 标记重要端口：您可以在运行时设置端口号，但最好使用 EXPOSE 命令指定它们 - 这将使其他人和程序更容易使用您的图像。
- 在卷上存储持久数据：容器销毁后应保留的数据应写入卷中。
- 编写图像元数据：标签、标签和注释使图像更易于使用 - 其他开发人员会感谢您。
- 同步主机和镜像：一些容器化应用程序要求容器在某些属性上与主机同步，例如时间或机器ID。
- 总之，我们分享模板和最佳实践，将帮助您更有效地实施上述原则：
11月11.00日在XNUMX
你会学到什么：
- 不可变的红帽企业 Linux CoreOS
- OpenShift 服务网格
- 算子框架
- Knative框架
来源： habr.com