为什么容器和 Kubernetes 有潜力运行几乎所有东西

图片来源：

Opensource.com

在我的第一篇文章《Kubernetes 是一辆自卸卡车：原因在此》中，我谈到了 Kubernetes 如何优雅地定义、共享和运行应用程序，类似于自卸卡车如何优雅地搬运泥土。在第二篇文章《如何应对 Kubernetes 学习曲线》中，我解释说 Kubernetes 的学习曲线实际上与在生产环境中运行任何应用程序的学习曲线相同，而且实际上比学习所有传统组件（负载均衡器、路由器、防火墙、交换机、集群软件、集群文件系统等）更容易。这就是 DevOps，开发者和运维之间的协作，旨在明确事物在生产环境中的运行方式，这意味着双方都有学习曲线。在第四篇文章《Kubernetes 基础知识：先学习如何驾驶》中，我重新构建了学习 Kubernetes 的框架，重点关注驾驶自卸卡车而不是建造或装备它。在第四篇文章《帮助你驾驶 Kubernetes 的 4 个工具》中，我分享了我爱上的工具，这些工具可以帮助在 Kubernetes 中构建应用程序（驾驶自卸卡车）。

在最后一篇文章中，我分享了我对未来在 Kubernetes 上运行应用程序感到兴奋的原因。

从一开始，Kubernetes 就能够很好地运行基于 Web 的工作负载（容器化）。诸如 Web 服务器、Java 以及相关的应用服务器（PHP、Python 等）之类的工作负载都能正常工作。诸如 DNS、负载均衡和 SSH（已由 kubectl exec 替换）之类的支持服务由平台处理。在我的职业生涯的大部分时间里，这些都是我在生产环境中运行的工作负载，因此我立即认识到使用 Kubernetes 运行生产工作负载的强大之处，抛开 DevOps，抛开敏捷。即使我们几乎没有改变我们的文化实践，也有增量的效率提升。配置和解除配置变得极其容易，这在传统的 IT 中是极其困难的。因此，从早期开始，Kubernetes 就为我提供了模拟生产工作负载所需的所有基本原语，使用单一的配置语言（Kube YAML/Json）。

但是，如果您需要运行具有复制功能的多主 MySQL 怎么办？使用 Galera 进行冗余数据呢？如何进行快照和备份？像 SAP 这样的复杂工作负载又该如何处理？对于简单应用程序（Web 服务器等），使用 Kubernetes 进行第一天（部署）的操作已经相当容易，但是第二天和后续的运维操作以及工作负载尚未解决。这并不是说使用复杂工作负载的第二天运维操作比传统的 IT 更难解决，而是 Kubernetes 并没有使它们变得更容易。每个用户都被迫设计自己的天才想法来解决这些问题，这基本上就是今天的现状。在过去的 5 年中，我收到的最多的问题类型是关于复杂工作负载的第二天运维操作。

幸运的是，随着 Kubernetes Operators 的出现，这种情况正在改变。借助 Operators 的出现，我们现在有了一个框架，可以将第二天运维操作知识编入平台。我们现在可以应用我在Kubernetes 基础知识：先学习如何驾驶中描述的相同的“定义状态，实际状态”方法论——我们现在可以定义、自动化和维护各种系统管理任务。

我经常将 Operators 称为“机器人系统管理员”，因为它们本质上是将主题 matter 专家（SME，如数据库管理员或系统管理员）针对该工作负载类型（数据库、Web 服务器等）的许多第二天运维操作知识编成代码，这些知识通常保存在 wiki 中的某个地方的笔记中。这些笔记存在于 wiki 中的问题是，为了将知识应用于解决问题，我们需要

生成一个事件，通常是监控系统发现故障，然后我们创建一个工单
人工 SME 必须调查问题，即使这是我们见过无数次的问题
人工 SME 必须执行知识（执行备份/还原、配置 Galera 或事务复制等）

借助 Operators，所有这些 SME 知识都可以嵌入到一个单独的容器镜像中，该镜像在实际工作负载之前部署。我们部署 Operator 容器，然后 Operator 部署和管理一个或多个工作负载实例。然后，我们使用 Operator Lifecycle Manager（Katacoda 教程）之类的东西来管理 Operators。

因此，随着我们推进 Kubernetes 的发展，我们不仅简化了应用程序的部署，还简化了生命周期内的管理。Operators 还为我们提供了管理非常复杂、有状态的应用程序的工具，这些应用程序具有深入的配置要求（集群、复制、修复、备份/还原）。而且，最棒的是，构建容器的人员可能是第二天运维操作的主题 matter 专家，因此他们现在可以将该知识嵌入到运维环境中。