为什么容器和Kubernetes几乎有潜力运行一切【Containers】

在我的第一篇文章中，《Kubernetes是一辆自卸车：这就是为什么》中，我谈到了Kubernetes在定义，共享和运行应用程序方面如何出色，类似于自卸卡车在移动污垢方面如何出色。在第二篇《如何导航Kubernetes学习曲线》中，我解释了Kubernetes的学习曲线实际上与运行生产中的任何应用程序的学习曲线相同，实际上比学习所有传统作品（负载均衡器，路由器，防火墙，交换机，集群软件，集群文件系统等）。这是DevOps，这是开发人员和运营部门之间的合作，用于指定事物在生产中的运行方式，这意味着双方都需要学习。在第四篇Kubernetes的基础知识中：学习如何首先驾驶，我重新构造了Kubernetes的学习框架，重点是驾驶自卸卡车而不是建造或装备它。在第四篇文章中，有4种工具可以帮助您驱动Kubernetes，我将分享我爱上的工具，以帮助您在Kubernetes中构建应用程序（驱动自卸车）。

从一开始，Kubernetes就能够很好地运行基于Web的工作负载（包含容器）。 Web服务器，Java和相关的应用程序服务器（PHP，Python等）之类的工作负载都可以正常工作。平台处理诸如DNS，负载平衡和SSH（由kubectl exec取代）之类的支持服务。在我的职业生涯的大部分时间里，这些都是我在生产中运行的工作负载，因此，我立即意识到，除了DevOps、敏捷之外，使用Kubernetes运行生产工作负载的强大功能。即使我们几乎不改变我们的文化习惯，也可以提高效率。调试和退役变得非常容易，而这对于传统IT来说是极为困难的。因此，从早期开始，Kubernetes就为我提供了用一种配置语言（Kube YAML / Json）对生产工作负载进行建模所需的所有基本原语。

但是，如果您需要运行具有复制功能的多主MySQL，会发生什么情况？使用Galera的冗余数据呢？您如何进行快照和备份？那么像SAP这样复杂的工作负载呢？使用Kubernetes，使用简单的应用程序（Web服务器等）进行的第0天（部署）相当简单，但是没有解决第二天的操作和工作负载。这并不是说，具有复杂工作负载的第二天运营要比传统IT难解决，但是使用Kubernetes并没有使它们变得更容易。留给每个用户设计自己的天才想法来解决这些问题，这基本上是当今的现状。在过去的五年中，我遇到的第一类问题是复杂工作负载的第二天操作。

值得庆幸的是，随着Kubernetes Operators的出现，这种情况正在改变。随着运营商的出现，我们现在有了一个框架，可以将第二天的运营知识汇总到平台中。现在，我们可以应用我在Kubernetes基础知识中描述的相同的定义状态和实际状态方法：学习如何首先驱动-我们现在可以定义，自动化和维护各种各样的系统管理任务。

我之所以将操作员称为“机器人系统管理员”，是因为他们本质上将第二天的操作知识整理成一堆，该知识涉及某个工作负载类型（数据库，Web服务器等）的主题专家（SME，例如数据库管理员或系统管理员）通常会在Wiki中的某个地方保留其注释。 Wiki中存在这些注释的问题是，为了将知识应用于解决问题，我们需要：

1. 生成事件，通常是监视系统发现故障并创建故障单
2. 即使是我们一百万次见过的问题，人类中小企业也必须调查问题
3. 中小企业必须执行知识（执行备份/还原，配置Galera或事务复制等）

通过运营商，所有这些SME知识都可以嵌入到单独的容器映像中，该映像在实际工作负荷之前就已部署。我们部署Operator容器，然后Operator部署和管理一个或多个工作负载实例。然后，我们使用“操作员生命周期管理器”（Katacoda教程）之类的方法来管理操作员。

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

本系列的结论

Kubernetes的未来是光明的，就像之前的虚拟化一样，工作负载扩展是不可避免的。学习如何驱动Kubernetes可能是开发人员或系统管理员可以对自己的职业发展做出的最大投资。随着工作量的扩大，职业机会也将增加。因此，这是驾驶一辆出色的自卸卡车，它在移动泥土方面非常优雅...

如果您想在Twitter上关注我，我会在@fatherlinux上分享有关此主题的很多内容