为什么容器和 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 上的第 0 天（部署）非常容易，但是第 2 天的运维和工作负载并没有得到解决。这并不是说使用复杂工作负载的第 2 天运维比传统的 IT 解决方案更难，而是 Kubernetes 并没有使其更容易。每个用户都需要自己想出天才的想法来解决这些问题，这基本上是今天的现状。在过去的 5 年中，我收到的第一类问题是关于复杂工作负载的第 2 天运维。

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

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

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

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

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