Kubernetes应用程序脆弱得像雪花：寻找可扩展的保护框架

随着开发人员和应用程序团队选择容器和Kubernetes作为构建、部署、运行和扩展应用程序的首选技术，越来越多的数据应用程序每天都会登陆Kubernetes。越来越多的独立软件供应商（ISV）将其应用程序打包成容器分发到Kubernetes上运行，在所有垂直行业中大量使用这些应用程序。许多这样的应用程序都是业务关键型的，其中断可能会导致严重的收入、生产率和声誉损失。

当企业意识到保护其Kubernetes应用程序的业务需求时，他们转而使用市场上可用的开源或商业解决方案。保护Kubernetes应用程序通常需要在发生灾难、网络攻击、恶意或意外用户错误后恢复应用程序：

——在同一集群内

——同一地区的不同集群

——区域/地理上的独立集群

应用这些解决方案来保护和移动Kubernetes应用程序通常不会一蹴而就。Kubernetes（使用自定义资源定义）的灵活性和可扩展性使其在开发人员中非常流行，这使得保护Kubernetes应用程序变得更加困难，因为没有标准的方法来确定灾难后需要备份什么才能成功恢复。

现实世界中的Kubernetes应用程序是雪花

由于没有一个定义应用程序组成部分的标准Kubernetes规范，因此确定要备份和克隆哪些资源的问题尤其具有挑战性。因此，专注于Kubernetes应用程序保护（提供备份/恢复和灾难恢复（DR））的解决方案会假设开发人员将如何构建其应用程序，并尽最大努力找出实际应用程序的组成部分，以及如何最好地保护它。

这种方法可以实现Kubernetes应用程序发现过程的自动化。在高度动态的Kubernetes环境中，自动化应用程序发现过程是可取的。然而，自动发现通常只适用于应用程序简单且仅限于命名空间的一部分情况。如果应用程序跨越多个命名空间，具有集群范围的资源，和/或使用外部完全管理的数据库、数据存储或消息服务，那么提供的过于简单的应用程序发现和随后的应用程序保护功能不足以保护大多数Kubernetes工作负载。

Kubernetes应用程序的构成

大多数真实世界的Kubernetes应用程序都不符合开发人员开发和部署Kubernetes应用程序所遵循的标准配方。开发人员如何定义Kubernetes应用程序可以是以下内容的组合（不是详尽的列表）：

App=1..1个命名空间中有N个资源

App=1..N个命名空间

App=1..N个命名空间+1..N个集群范围的资源

App=1..N个资源位于1..N个命名空间+1..N个集群范围的资源

App=1..N个资源位于1..N个命名空间+1..N个集群范围的资源+外部资源（例如，公共云中的完全管理的数据库）

如上所述，使用命名空间作为应用程序分隔符并不能涵盖开发人员定义其Kubernetes应用程序的所有不同方式。自动推断构成Kubernetes应用程序的所有组件也可能导致识别Kubernetes应用程序资源的失误。

使用用户输入的自定义应用程序定义

为了有效地备份和恢复应用程序，用户必须能够指定Kubernetes应用程序的组成部分，该应用程序提供关键的“服务”，必须确保其业务连续性。理想情况下，应该让用户有机会使用Kubernetes原生机制定义其应用程序，或者允许用户定义符合上面列举的应用程序定义模式的自定义应用程序。

在某些情况下，同样重要的是确定应该从应用程序定义中排除的资源，因为这些资源在目标/目标集群或命名空间中可能不相关，从而阻止成功恢复。一个有效的Kubernetes应用程序保护解决方案必须为用户提供指定这些详细信息的能力，或者智能地促进发现此类复杂的应用程序。一旦用所有必要的资源定义了一个应用程序，保护应用程序就不再是猜测了，从而得到更可预测的结果。

钩子，还是钩子

多年来，企业备份软件一直使用钩子或前置脚本/后置脚本，使用户可以插入自定义 *** 作来执行应用程序一致性备份，例如在拍摄快照以将内存中的表刷新到磁盘之前停止数据库。使用“执行钩子”插入自定义 *** 作的能力在Kubernetes应用程序中有了全新的含义。可预测地控制Kubernetes应用程序的端到端备份和恢复，以在恢复后实现成功的应用程序实例化，通常需要在备份前后以及恢复前后对组成Kubernetes应用程序的多个资源执行自定义 *** 作。

备份恢复工作流期间Kubernetes中的执行钩子可用于实现许多目标，如在备份/恢复之前或之后动态应用网络安全策略，在克隆之前更改入口控制器的注册路径，刷新IP地址，以及其他特定于应用程序的自定义 *** 作。Kubernetes应用程序保护解决方案必须允许具有执行钩子的备份/灾难恢复工作流的可扩展性，使用执行钩子可以插入特定于应用程序的自定义 *** 作。

不备份和恢复的内容

确定哪些应用程序资源需要保护至关重要，但哪些不需要备份和/或恢复也同样重要。这是因为某些资源（如秘密、IP地址和节点端口）在目标集群中可能与灾难恢复无关。对组成Kubernetes应用程序的所有资源进行大容量备份，然后进行后续恢复，可能会导致错误的恢复，因为目标集群中的资源子集完全无效。从概念上讲，通常有两种方法来解决这种情况。

——使用过滤器排除备份或恢复在目标集群中没有意义的特定资源，使Kubernetes或operator（部署和管理Kubernetes应用程序的流行设计模式）能够重新创建这些资源。

——在资源到达目标集群之前进行转换。

Kubernetes应用程序保护解决方案必须允许用户执行上述所有 *** 作，以确保恢复后的应用程序行为正确。

总结

随着企业意识到需要保护其Kubernetes应用程序，在大规模采用这些解决方案之前，评估其可定制性和可扩展性非常重要。提供一套最佳实践也很重要，它可以指导开发人员在设计Kubernetes应用程序时遵循一套方法，包括推荐一套他们利用的标准集群内和外部服务，以便在关键业务Kubernetes应用程序在企业中无处不在时更容易保护它们。

原文链接：

https://thenewstack.io/kubernetes-apps-are-snowflakes-find-an-extensible-protection-framework/

建议检查 显卡 处理器 和 主板等主要部件的温度,有无高温问题,及时处理高温问题以免永久算坏硬件.

如无高温,检查主要部件的驱动尤其是显卡的,

如果都正常,建议重装 *** 作系统

---