Kubernetes（K8s）非常火，但被人诟病最多的还是其复杂性，并且不管是在云中还是本地，都没有很好的集群故障排除的方法。因此，尽管 K8s 的采用率持续增长，但许多开发人员和运维团队对这项较新的技术感到吃力，为此必须学习新的术语、工作流程、工具等。

一、K8s 难在哪里

K8s 的分立部件需要广泛的专业知识，即使只是在设置过程中。考虑到旋转 K8 集群需要了解和配置从 pods 到服务的多个组件，更不用说 etcd、API 服务器、kubelet 和 kube-proxy 等资源了。

然后是规划、扩展和网络建设。一个失误可能很快转化为无数的可扩展性、可靠性甚至安全性问题。

此外，生态系统本身也在不断快速增长和演变。对于初学者来说，工具和附加组件可能很多，而且很难跟上。并不是每个开发者都专门接受过 K8s 技能的培训。

我们不能忘记，这项技术有许多移动部件和复杂的相互作用，当发生故障时，进行故障排除可能既困难又耗时。诊断故障原因需要深入的技术知识和专业知识，而这些知识和专业技能往往存在于少数经验丰富的工程师的头脑中。

让我们深入研究，探索有助于克服明显技能差距问题的新的创新方法。

二、没错，ChatGPT 能当此大任

Kubernetes 很难有效地学习和使用，因为没有一刀切的方法。K8s 是高度可定制的，可以根据应用程序或基础设施的具体需求以多种不同的方式进行配置。通常很难将您从文档（而且有很多）和培训中学到的东西应用到现有的环境中，因为团队缺乏对其架构的上下文理解和可见性。

当前的体系结构是什么样子的？哪些 pod 绑定到特定的命名空间？节点的运行状况如何？询问我们环境的基本问题需要在 AWS 控制台、kubectl 命令行、Terraform 配置文件和监控工具之间进行上下文切换。

如果我们可以问 ChatGPT 这些问题呢？

让我们看一个使用由 ChatGPT 提供支持的 PromptOps 来理解集群中所有部署的示例。PromptOps 提供了一个免费的 Kubernetes 咨询工具，用户可以通过 BASH 脚本、文档参考和其他有用资源的形式提出问题并获得即时帮助。

通过提供来自不同来源的 PromptOps 基础设施的碎片数据，如 Confluence、Notion、Terraform 配置文件等，我们希望 PromptOps 能够快速聚合所有信息，并帮助可视化架构。我们没有手动运行 kubectl 命令来检查部署，而是在聊天中提示 PromptOps 来描述集群中存在的部署。

以下是 PromptOps 的回应：PromptOps > I suggest running this script to answer your question.

PromptOps 提供了一个要运行的脚本，并引用了一个包含集群信息的 Notion 页面。在执行脚本时，PromptOps 提供集群内部署的输出。

PromptOps 还提供了集群中所有部署的可视化图，使学习更加容易。

PromptOps 的响应简化了 Kubernetes 基础设施管理，使 DevOps 团队中的每个人都能跟上当前架构的步伐并跟上变化。

通过自动化故障调查节省时间

让我们看看生产问题的疑难解答，看看 PromptOps 如何帮助确定 Kubernetes 中故障的根本原因。

Kubernetes 度量和日志提供了从集群到容器的所有级别的关键见解。它们提供有关资源利用率、pod 和节点状态、集群自动缩放指标、网络错误、容器运行时间等信息。

但所有这些指标的问题在于，它们并没有立即发挥作用。日志流或度量图表无法提供必要的上下文或方向。有一些工具可以提供帮助，但它们往往会使事情变得更加复杂，需要在整个技术堆栈中提取上下文，以查看真正发生了什么，或者在出现问题时谁做了什么。在 CtrlStack，我们一直在结合 PromptOps 来分析因果图、Kubernetes 事件、指标和日志，以减少手动故障排除的挑战。目标是通过使用 PromptOps 生成解释原因的根本原因分析摘要，帮助 DevOps 团队快速理解 Kubernetes 问题。在本例中，CtrlStack 中的根本原因分析仪表板的因果图被输入到 PromptOps 中，以进行故障排除和解决，如下所述。

下面是一个根本原因分析面板的随意图形示例。

有了这个，我们提示 PromptOps 解释这个图。以下是 PromptOps 的回应：

PromptOps>以下是对图形的解释：

该图显示了 Kubernetes pod 中错误的根本原因。该错误是由 pod 映像中的更改引起的，这些更改类似于 Kubernetes pod_error 度量中的更改。该错误也类似于在 kubernetes_ptime 和 kubernetes_pod_mem_usage 度量中发现的拐点，以及 node1 中的拓扑变化。

该图显示了 kubernetes_po_error 更改的根本原因。有三个见解。首先是图像发生了变化。第二个是在度量 kubernetes_ptime 和 kubernetes_pod_mem_usage 中发现了拐点。第三个是节点 1 的拓扑结构发生了变化。

PromptOps 返回了正常运行时间和内存使用指标之间的信息相关性，以及相关的拓扑变化。这些见解包括检查 Kubernetes 的更改事件、度量、资源使用情况和拓扑结构更改。基于这种自动事件调查，开发人员和操作员应该有足够的上下文来快速确定解决问题的下一步措施。

三、将 ChatGPT 与 Change AI 相结合，缩小技能差距

根据提供的例子，很明显，ChatGPT 可以提供宝贵的帮助来缩小 Kubernetes 的技能差距。ChatGPT 为 DevOps 团队提供了快速的见解和清晰的解释，以解决生产问题。这使初级运营商和初涉 Kubernetes 的开发人员能够独立学习技术并解决常见问题。

虽然 ChatGPT 的响应可以快速了解问题，但它需要特定于 Kubernetes 部署的不同问题的上下文信息。这就是 Change AI 的用武之地。Change AI 平台提供了因果图，将资源容量、基础设施变化、配置变化、指标历史图表和事件时间表联系起来，以优化根本原因分析的路径。

基于 ChatGPT 的 Kubernetes 学习方法有可能显著提高 DevOps 的生产力，同时消除认知过载。通过将 ChatGPT 与 Change AI 相结合，团队可以将他们的 Kubernetes 技能提高一倍，并获得更好的可观察性。

原文链接：https://thenewstack.io/overcoming-the-kubernetes-skills-gap-with-chatgpt-assistance/

相关内容拓展：（技术前沿）

看到 ChatGPT 带来的生产力，我想到了低代码平台。近 10 年间，甚至连传统企业都开始大面积数字化时，我们发现开发内部工具的过程中，大量的页面、场景、组件等在不断重复，这种重复造轮子的工作，浪费工程师的大量时间。

针对这类问题，低代码把某些重复出现的场景、流程，具象化成一个个组件、api、数据库接口，避免了重复造轮子。极大的提高了程序员的生产效率。

介绍一款程序员都应该知道的软件 JNPF 快速开发平台，同样支持 K8s，采用业内领先的 SpringBoot 微服务架构、支持 SpringCloud 模式，完善了平台的扩增基础，满足了系统快速开发、灵活拓展、无缝集成和高性能应用等综合能力； 采用前后端分离模式，前端和后端的开发人员可分工合作负责不同板块，省事又便捷。

还没有了解低代码这项技术可以赶紧体验学习！体验官网：https://www.jnpfsoft.com/?infoq