Kubernetes 是一个复杂框架，用于完成复杂的工作。 管理几个容器可能很复杂，而管理成百上千个容器基本上是不可能的。 Kubernetes 使高可用性和高度可扩展的云应用程序成为现实，并且通常可以很好地完成其工作。 但是，人们往往不会注意到日复一日、月复一月的成功。 平稳运行的几个月和几年并不是凌晨 2 点接到电话的原因。 在 IT 领域，重要的是失败。 不幸的是，失败不会按计划发生。
Jessica Cherry 的新电子书 Kubernetes 混沌工程 介绍了系统工程师如何帮助测试他们设计的系统健壮性的几个概念。 令人惊讶的是，其中很大一部分与失败有关。 以下是我从 Cherry 的书中获得的五个主要经验教训。
有意的失败是成功的一部分
你做得一切都正确也没关系。 您已经购买了定制的硬件来完成这项工作，您已经安装了稳定的发行版，购买了支持，阅读了精美的说明书，记录了您的流程，自动化了恢复，进行了备份等等。 经过所有准备工作，只有一件事可以确定：最终会出错。
以这种方式思考并不是病态的，因为这仅仅是技术和机械系统中发生的事情。 事情会失败。
您无法阻止事情发生故障，但可以在方便的时候让它们发生故障。 不幸的是，在您的系统上强制发生故障并不会“用完”您一年中分配的所有故障。 事情仍然会意外地失败，但是通过按照您自己的计划导致失败，您可以确保拥有解决问题所需的资源和知识。
随机失败是弹性的一部分
您不是唯一需要知道如何处理失败的人。 您的基础设施也需要能够承受失败。 虽然您可以使用计划的失败来测试其中的一些内容，但随机性有助于确保弹性。 毕竟，有些故障会在您不在场的情况下发生，以确保其他一切仍然可以正常工作。 理想情况下，您希望安心，即使发生故障您也不会知道（但您最终会知道，因为您正在监视您的集群。您正在监视您的集群，对吗？）。
弹性需要在许多地方实现
我永远不会忘记第一个大规模（对我来说，当时 200 个用户已经很大规模了）共享文件服务器。 它有一个 LVM 存储池，有足够的空间来存放额外的硬盘驱动器、电池备份、强大的 SAMBA 后端、基于 AMANDA 的备份例程、后备网络以及本地和远程的轻松管理访问。 该服务器不需要持续可用，所以我有很多时间在一周内对其进行测试，但它确实需要在工作日的特定时间可用。 它被广泛使用，我为它感到自豪了几个月。
然后，有一个星期，我的文件服务器的硬盘空间用完了。 没问题——我构建它的目的是为了具有可扩展的存储，所以只需走到服务器旁，插入一个新的驱动器，然后继续我的一天即可。 除了一点小故障：我购买的硬件上的硬盘驱动器不是热插拔的。 （谁知道会有没有热插拔驱动器托架的机架服务器？）整个系统必须关闭才能让我向其中添加存储，而且当然，它发生在星期五下午，当时所有人的工作都在渲染中。
经验教训：弹性不是一个固定的时间点。 您不会设计一个系统在特定时刻是完美的； 您设计它的目的是使其可以在任何时候发生故障。
除非您在意外的时间和意外的地点造成故障，否则很难检测到设计中的薄弱环节。
混沌强化秩序
我过去认为严格的测试是一种奢侈品。 我认为这是大型团队可以负担得起的事情，因为他们肯定有专门的 QA 人员坐在实验室里，修补和拆卸生产环境中内容的副本。
但是，当我荣幸地在越来越大的团队中工作时，我发现更多的人只是意味着进行测试的潜力更大。 它永远不能保证测试实际上正在进行。
任何人都可以采用混沌工程这种实践。 与您的部门交谈，组建一个团队，制定一个计划。 设置监控，使您的集群运行透明，邀请提出问题和挑战。 制定一个正式的混沌工程计划，因为混沌会拉紧秩序，并最终使其更强大。
Kubernetes 可能会非常有趣
人们有时会问我如何使用我的 Raspberry Pi Kubernetes 集群。 诚然，我个人并没有在我的小型开放混合云上运行任何重要服务。 但是事实证明，使用微型超级计算机（好吧，至少对我来说是超级的）有很多乐趣。 查看漂亮的 Grafana 仪表板和使用 Pod 玩 Doom 都很有趣，但是配置、在从网络中突然删除节点后测试集群性能的挑战、尝试查看 SD 卡可以经受多少次不当删除（到目前为止很多次，可能要归功于 ext4）、配置两个容器彼此交互、掌握命名空间和 Pod 的逻辑结构等等也都很有趣。
归根结底，Kubernetes 给了我自己的云，我坦率地享受拥有这种力量的感觉。
混沌工程允许您稍微放纵一下。 它鼓励您有条不紊地鲁莽行事。 最后，您将获得一个更具弹性的系统。
下载电子书
当然，您不能只是尝试漫无目的地破坏自己的计算机并称其为混沌工程。 没有纪律、文档和缓解措施，这只是混乱。 为了确保您以负责任和智能的方式破坏事物，请下载 Kubernetes 混沌工程。 然后释放混沌猴子吧！
1 条评论