容器服kubernetes

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

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

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

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

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

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

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

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

本系列的结论

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

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

翻译自:

容器服kubernetes