Kubernetes应用管理的难题是什么

这篇文章主要讲解了“Kubernetes应用管理的难题是什么”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Kubernetes应用管理的难题是什么”吧！

研发对应用管理的诉求

让我们来看一下这样一个 K8s 的 yaml 文件，这个 yaml 文件已经是被简化过的，但是我们可以看到它仍然还是比较长。

面对这样一个广受“复杂”诟病的 YAML 文件，我相信大家都会忍不住想该怎么简化。

自上而下，我们大致把它们分为三块：

• 一块是扩缩容、滚动升级相关的参数，这一块应该是应用运维的同学比较关心的；

• 中间一块是镜像、端口、启动参数相关的，这一块应该是开发的同学比较关心的；

• 最后一块大家可能根本看不懂，通常情况下也不太需要明白，可以把它们理解为 K8s 平台层的同学需要关心的。

看到这样一个 yaml 文件，我们很容易想到，只要把里面的字段封装一下，把该暴露的暴露出来就好了。确实，我们内部就有 PaaS 平台这么做。

内部的某个 PaaS 平台精心挑选了部分字段，并做了一个漂亮的前端界面给用户，只透出给用户 5 个左右的字段，大大降低了用户理解 K8s 的心智负担。然后底层实现用类似模板的方式把用户这五个字段渲染出来一个完整的 yaml 文件。

突出的字段大概如下图所示：

不得不说这种方式是非常有效的，针对简单无状态的应用，精简 API 可以大大降低 K8s 的门槛，快速并且高效的对接用户，PaaS 平台也顺利让大家使用了起来。同时，我也从一些技术分享中了解到许多其他公司也是用这种类似的方式简化的 K8s API。

但是当用户的业务开始大规模对接以后，我们就会自然而然遇到有状态的复杂应用，用户就会开始抱怨 PaaS 平台能力不够了。比如我们的 Zookeeper 多实例选主、主从切换这些逻辑，在这五个字段里就很难展开了。

归根结底就是屏蔽大量字段的方式会限制基础设施本身的能力演进，但是 K8s 的能力是非常强大而灵活的。我们不可能为了简化而放弃掉 K8s 强大的能力。

就比如当前这个例子，我们很容易想到，针对复杂有状态的应用，应该通过 K8s 里面的 CRD 和 Operator 来解决。

确实，我们内部对接复杂应用云原生化的时候，也推荐他们编写 Operator，但是经常出现这样一段对话。

中间件的工程师跟我们说，我这有个 Zookeeper 该用哪种 K8s 的 Workload 接入啊？我们想了想，K8s 设计如此精妙，自然没有解决不了的问题，于是我们推荐他们使用 Operator。他们就懵了，说你们搞云原生的这几年造新词的能力绝对一流，之前都没听说过。

想想也是，业务方理解这些新概念不难，但是真的要自己去上手实现，还是非常困难的。我们自然也觉得业务方更应该专注于他们的业务本身，于是我们不得不帮他们一起写。

可以看到，我们亟需一个统一的模型去解决研发对应用管理的诉求。

感谢各位的阅读，以上就是“Kubernetes应用管理的难题是什么”的内容了，经过本文的学习后，相信大家对Kubernetes应用管理的难题是什么这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！