临时工作负载是云原生技术的基石，提供增强的弹性和可扩展性。本文深入研究了这些瞬态系统的架构，强调了在云原生框架中实现无状态应用程序的重要性和复杂性。
我们将剖析现实场景，提炼出无状态应用程序的开发、部署和维护的有效策略，特别是在Kubernetes和类似的编排平台中。
1、什么是临时工作负载？
临时工作负载是Kubernetes等容器编排平台的基本组成部分，尤其是现在一些运维团队正在运行多达10个集群并应对不断上升的复杂性。
要了解临时工作负载的工作原理，我们首先需要了解Pod，它是可以创建和管理的最小可部署单元。
Pod的设计理念是易于一次性和更换。因此，无法向其中添加容器。Pod通常会在需要时通过部署（更改或修改状态）进行删除和替换。
在某些情况下，开发人员可能需要检查Pod的当前状态，也许是为了解决难以复制的错误。这就是临时容器的用武之地，它们运行来检查Pod的状态并运行各种命令。
一旦临时容器完成其管理功能，它就不会重新启动。这些容器还使用Pod的现有资源分配来运行，同时共享公共容器命名空间，从而使它们非常轻量级。
2、临时容器与其他容器有何不同？
临时容器与其他容器之间的主要区别在于它们不保证资源或执行，并且永远不会自动重新启动。但是，与普通容器一样，临时容器一旦添加到Pod中就无法修改或删除。
尽管它们与其他容器具有相同的ContainerSpec，但大多数字段是不允许的，并且不能被临时容器使用。此外，临时容器可能没有任何端口，这意味着无法使用Ports、LivenessProbe和ReadinessProbe等字段。在您熟悉所有允许的字段之前，请参阅KubernetesAPI参考文档。
此外，每个临时容器都是使用编排平台API内的特定Ephemeral Containers处理程序创建的。这不是将它们直接添加到pod.spec中，因此无法使用Kubernetes中的kubectledit命令添加这些容器。
3、临时容器：主要用途
临时容器的主要用例是在常规调试工具已用尽时进行交互式故障排除。这可能是因为容器已崩溃或容器映像不提供任何调试实用程序。Distroless镜像就是一个典型的例子。
可以将临时容器注入到导致问题的Pod中，从而允许开发人员检查文件、收集日志、运行命令甚至安装诊断工具。当在静态环境中复制或诊断问题已被证明很困难时，这种诊断协议特别有用。
其他短暂用例包括：
立即收集日志并执行分析以识别Pod内的问题
恢复和修复数据而不影响正在运行的Pod
监控和分析资源以优化Pod性能
4、云原生环境中的无状态应用程序
了解临时容器的多功能实用性使我们自然而然地进入无状态应用程序的领域，特别是在云原生环境中。
这些应用程序不受维护状态的限制，利用短暂工作负载的瞬态性质来发挥其优势。这种无缝集成对于提高Kubernetes集群的效率、利用数据存储的缺乏和添加新实例的选项是必要的。
在Kubernetes等编排平台中，应用程序可以是无状态的或有状态的。
无状态应用程序不会持久保存状态并利用短暂的工作负载；这实际上意味着应用程序使用临时资源来运行，然后在删除或关闭Pod时将其删除。
无状态应用程序需要最少的资源来执行其功能，并在完成任务后消失。
同时，有状态应用程序中的工作负载需要持久存储，通常是外部存储，例如网络连接或远程存储。
在这种情况下，云原生意味着在使用云计算架构的环境中构建、部署和管理应用程序。这种环境需要具有高度可扩展性、弹性和灵活性的轻量级应用程序，以便可以快速修改和更新以满足用户的需求。这就是为什么无状态应用程序更合适。
金融行业就是一个很好的例子，例如执行当日ACH转账，这些转账通常由临时工作负载和无状态应用程序处理，这确保了高可用性、可扩展性和快速交易处理，这对于银行间交易在没有网络的情况下进行至关重要。拴住。
5、无状态应用程序的优点
无状态应用程序的主要优点是它可以在临时内存上运行，并且不会在会话之间存储任何信息，从而消耗可用资源。
这类似于不存储用户信息的HTML应用程序。相反，此信息存储在称为cookie的数字文件中，这些文件保存在用户的网络或客户端上。当用户重新访问网站时，浏览器将加载相关cookie以检索有关先前会话的详细信息。
其他优点包括：
无状态应用程序是有益的，因为它们无法控制系统上的驻留内存，因此与有状态应用程序相比，它们成本更低，并且更易于设计和维护。
由于无状态应用程序单独处理每个请求，因此它们也更具可扩展性，从而可以添加新实例而不会导致任何状态一致性或负载平衡问题。
由于不存储跨状态请求，因此单个故障不会影响其余请求，从而提高了系统容错能力。
6、无状态应用程序的缺点
由于无状态应用程序需要在每个会话管理请求中发送所有数据，这会降低它们的效率并导致性能和延迟降低。有状态应用程序包含执行其功能所需的一切，并且可以随时调用，使它们更加方便并且能够拥有更广泛的用例。
幸运的是，这个缺点在依赖速度并且需要无缝扩展和修改的云原生环境中并不是特别相关。有状态应用更适合资源丰富的边缘计算环境。
其他缺点包括：
有状态应用程序执行的活动可能会使无状态应用程序变得复杂，需要跨多个请求管理状态的机制。跨请求管理状态的EG数据库。
无状态架构不适合设计涉及实时协作、聊天功能或游戏功能的应用程序。
7、无状态应用程序的示例
Web服务器是无状态应用程序的一个明显示例，因为它们响应没有任何状态信息的请求，将域名转换为IP地址的DNS服务器也是如此。Cloudflare或AmazonCloudFront等内容分发网络(CDN)也可以缓存和分发没有状态信息的内容。
与此同时，日常软件中无状态应用程序的使用有所增加，例如基于Web的PDF编辑器、待办事项应用程序以及任何可以从不依赖会话中受益的应用程序。这增加了系统的整体刚性，特别是在处理需要安全许可的数据时。
尽管如此，仍然有使用Kubernetes部署有状态应用程序的支持者，再次强调了两个阵营之间日益加深的分歧。
8、开发、部署和管理无状态应用程序：最佳实践
以下是开发、部署和管理无状态应用程序时应遵循的五种最佳实践，以确保安全性、可扩展性等。
使用托管服务来维护无状态应用程序，包括自动扩展、备份和安全监控。
如果您不使用托管服务，则建议使用自动扩展工具来调整容量以满足需求。
实施容错架构以确保高水平的系统可用性和弹性。该架构在需要时运行备份组件以维持性能水平。
使用加密来保护无状态应用程序，同时遵循最佳实践来创建安全的开发环境和CI/CD管道。
安装监控和日志记录软件以快速识别应用程序中的任何错误并突出显示性能下降的任何情况。
人工智能和机器学习还通过自动化开发过程中的测试阶段，帮助使无状态应用程序更加安全和高效。这可以确保不会遗漏错误，并且开发人员可以更好地分配时间来专注于提高应用程序性能。
人工智能有望提高开发和维护无状态云原生应用程序的效率，并优化成本并增强安全性。到2022年，全球人工智能投资已达到920亿美元，其中很大一部分是因为优化应用程序开发的必要性。
无状态应用程序非常适合云原生环境，因为它们使用临时存储来运行，并且由于使用临时工作负载而不会存储信息。因此，无状态应用程序不像有状态应用程序那样占用大量资源，并且更具可扩展性和弹性。
不仅如此，无状态架构也不太复杂，使得开发一系列云原生应用程序更具成本效益且更容易。从Web服务器到CDN，无状态应用程序是任何不需要任何状态信息即可运行的应用程序的完美解决方案。
