为什么说容器和Kubernetes几乎可以搞定一切

Kubernetes在定义、共享和运行应用程序方面具有很大的优势，而且Kubernetes的学习曲线与在生产中运行任何应用程序的学习曲线相同——这实际上比学习所有传统知识（负载均衡器、路由器、防火墙、交换机、集群软件、集群文件系统等）要容易。这就是DevOps，开发人员和运维部门之间合作，用于指定在生产中以什么方式运行，这意味着双方都有学习曲线。

现在，笔者分享为什么对在Kubernetes上运行应用程序的未来感到非常兴奋。

从一开始，Kubernetes就能够很好地运行基于Web的工作负载（容器化）。像Web服务器、Java和相关的应用服务器（PHP、Python等）这样的工作负载不在话下。DNS、负载均衡和SSH（由kubectl exec取代）等支持服务由平台处理。在笔者职业生涯的大部分时间里，这些都是在生产中运行的工作负载，所以笔者充分认识到除了DevOps和敏捷之外，使用Kubernetes运行生产工作负载的重要性。

Kubernetes会提高效率，让commissioning和decommissioning变得非常容易，而之前这对传统IT来说非常困难。因此，从早期开始，Kubernetes就用一种配置语言（Kube YAML / Json）提供了建模生产工作负载所需的所有基本原语。

但是，如果你需要通过复制运行Multi-master MySQL，会发生什么？使用Galera的冗余数据呢？你如何做快照和备份？那些复杂的工作负载如SAP怎么办？使用简单应用程序（Web服务器等）的Day Zero（部署）对于Kubernetes来说相当容易，但是Day Two的运维和工作负载没有得到解决。

这并不是说Day Two复杂工作负载的运维比传统IT更难解决，但使用Kubernetes并不容易。每个用户都试图想法来解决这些问题，而在过去的5年中，最大的问题是复杂工作负载的Day Two运维。

值得庆幸的是，随着Kubernetes Operator的出现，这种情况正在发生变化。随着Operator的出现，我们现在有了一个框架，可以将Day Two

的运维知识植入平台。我们现在可以定义、自动化和维护各种系统管理任务。

Operator基本上整理好了Day Two运维知识，即相关工作负载（数据库，Web服务器等）的主题专家（SME，如数据库管理员或系统管理员），通常会在某个地方保留笔记。为了利用这些知识，我们需要：

——生成一个事件，通常是控系统发现故障，我们创建故障单

——SME必须调查这个问题，即使它已经出现过一百万次

——SME必须执行知识（执行备份/恢复，配置Galera或交易复制等）

有了Operator，所有这些SME知识都可以嵌入到在实际工作负载之前部署的单独容器镜像中。我们部署Operator容器，然后Operator部署并管理一个或多个工作负载实例。然后，我们使用诸如Operator Lifecycle Manager之类的东西来管理Operator。

因此，用Kubernetes，我们不仅简化了应用程序的部署，还简化了生命周期的管理。Operator还为我们提供了管理非常复杂、有状态的应用程序的工具——这些应用程序具有深层配置要求（集群、复制、修复、备份/恢复）。最棒的是，构建容器的人现在很可能是Day Two运维的专家，他们可以将这些知识嵌入到运维环境中。

Kubernetes的未来是光明的，就像之前的虚拟化一样，工作负载的扩展是不可避免的。学习如何驾驭Kubernetes可能是开发人员或系统管理员在其职业发展中可以做出的最大投资。随着工作负载的扩展，职业机会也在扩展。

原文链接：

https://opensource.com/article/19/6/kubernetes-potential-run-anything

获取更多开源云技术资讯&大咖交流&免费活动，欢迎添加开源云中文社区小助手，备注开源云！

（长按识别二维码添加）