使用ChatOps实现协作K8s故障排除

聊天一直在在线交流的方式中扮演着重要的角色。它与最新的JavaScript框架非常相似，但却在利基社区或应用程序中获得了最大的成功。

其中一个应用程序是帮助人们协作开发软件。与多人在各自独立的机器上工作、依赖屏幕共享或将代码样本复制粘贴到Jira不同，聊天创造了一个机会，可以进行关于软件的持续对话，甚至可以自动化CI/CD管道、部署到生产和响应停机。

2013年，GitHub引入Hubot，创造了ChatOps一词——Hubot是一个开源聊天机器人，允许开发人员在Campfire聊天室部署、监控、提供更多内容。他们的想法是将开发人员完成工作所需的流程引入到他们用来组织和协作的工具中——聊天室。如果他们可以在同一提示下聊天并采取行动，那么他们就不必在许多工具之间进行上下文切换，而且他们可以在透明的团队范围内保持自己的行动。

2014年至2016年间，ChatOps风靡一时。对话驱动的开发感觉就像一股新鲜空气。随着远程工作和云原生的快速增长，管理者迫切地寻求新的模式，如协作管理，以处理分布式员工和基础设施。但那些早期版本的ChatOps也很快消失了，DevOps团队将聊天降格为内部电子邮件的替代品。

2016年是云原生的开始。从那以后发生了很多变化。正如之前所说，聊天总是在小型社区中找到最大的价值，这正是为什么ChatOps for Kubernetes再次引领对话驱动的潮流。

ChatOps for Kubernetes是什么？

简而言之，ChatOps允许你直接与Kubernetes集群聊天，以监控、调试和优化它。

为了说明这是如何工作的，让我们来看看一个场景，其中ChatOps for Kubernetes可以帮助你在开始影响用户体验之前解决面向用户的问题。

现在是周六晚上10点，负责运行你组织web应用程序的Kubernetes集群出现了意外异常。幸运的是，你有一个ChatOps应用程序，它可以监控Kubernetes集群的资源，并倾听它们发出的事件，包括这种异常。ChatOps应用程序将该事件转换为警报，并将其发送到所在组织的聊天应用程序（如Slack、Microsoft Teams、Discord或Mattermost），供所有DevOps工程师和管理员查看。

因为已经很晚了，待命的工程师会在聊天应用上得到一个ping，告诉他们放下手头的工作，开始调查。在正常情况下，没有笔记本电脑和稳定的WiFi连接是一个严重的障碍，但ChatOps允许工程师仅使用iPhone上的Slack应用程序来监控、调查和调试错误事件的来源。

ChatOps将任何聊天应用程序丰富为一个始终在线、上下文感知、透明的终端，可以通过所有kubectl语法直接访问Kubernetes集群，工程师需要这些语法来获取有关出现问题的关键信息以及如何解决问题。

当其他人加入这场争论时，他们可以在调试工作的同时，开始讨论和合作这个问题。聊天应用程序不仅成为已采取行动的历史记录，而且是进一步开发新的最佳实践、改进内部文档和最终分析的强大审计日志。

进入Kubernetes的协作管理

当DevOps中的协作管理工作良好时，它会鼓励透明度和行为，从而提升整个团队。

——以富有成效的方式提供建设性的反馈并接受他人的反馈，尤其是与开发和QA等其他团队的反馈。

——集体头脑风暴，团队中的每个成员，无论其角色或资历如何，都应积极参与决策。

——管理者、主管和员工之间高度诚实，以建立信任并促进合作精神。

——朝着共同的目标而不是个人的目标努力，为许多不同的人充当教练和同事。

云原生环境往往会给本已具有挑战性的工作带来一些麻烦。你可能有一个非常复杂的基于微服务的架构，其中多个集群运行在并行数据中心上，团队中的大多数人很有可能是远程启动的。DevOps文化、分布式技术和不断协调的需求的结合使得实施协作管理成为一项更大的技术挑战，但并非不可能。

ChatOps有助于弥合人员和技术之间的差距，让他们并行工作，使协作管理在几个常见的DevOps场景中发挥作用：

——单个随叫随到的工程师：我们在上一节中概述了这个场景，但使用针对Kubernetes的ChatOps，单个随叫随的DevOps工程师在如何、何时和何地响应方面具有更大的灵活性。他们不必被迫回到工作机器，在那里设置环境和密钥/机密以正确查询Kubernetes集群，而是可以在所在组织的聊天应用程序所在的任何地方开始调试。当轮到另一名工程师接手时，ChatOps的集中化和透明化简化了过渡。

——交易监控和调试任务：当第二个工程师上线时，他们加入已经开始调试的频道或房间。由于ChatOps在单个孤立系统上强制执行透明性和从公共终端工作，第二个工程师可以查看已经完成的调试工作的整个审计日志。如果他们要替换第一个工程师，不需要浪费时间重新运行命令，因为他们可以在聊天日志中看到每个kubectl的执行和结果。他们可以调试来自多个集群的部署、服务或其他资源，以鼓励诚实、开放，并从以前的事件和解决周期中不断改进。

——现场配对：或者，如果两名工程师作为一对进行调试和故障排除，ChatOps可以帮助他们像在同一个任务控制室一样处理工作，即使他们恰好相隔数百或数千英里，在不同的远程或家庭办公室。他们不需要依赖尴尬和低效的屏幕共享（在那里只能观察、做笔记和提出建议，甚至更糟糕的是，将他们的kubectl命令复制粘贴到聊天应用程序中）。通过ChatOps支持协作管理精神，工程师可以并行发挥他们的魔力。他们可以随心所欲地进行实验、调试和查询，所有这些都具有良好合作所需的透明度和持续对话。这是一个单独的环境，用于彼此和集群进行交谈。

但并非所有ChatOps平台都是相同的，特别是当Kubernetes参与其中时。

用于监控和调试Kubernetes集群的Botkube

Botkube是Kubernetes的新一代ChatOps。使用开源Botkube，你可以监控多个集群，实时调试部署，并检查集群的状态，以获得团队可以持续改进的建议。

Botkube支持DevOps团队最流行的消息平台，如Slack、Microsoft teams、Discord和Mattermost。甚至支持将消息发送到ElasticSearch以用于存档，或使用传出的webhook来构建自定义消息传递响应管道。

Botkube在2022年10月发布了v0.14.0，提供了更多用户友好的方式来动态更改Botkube通知设置。默认情况下，Botkube会监视并显示在YAML文件中或Helm安装/升级期间配置的频道中的所有Kubernetes事件，但现在你可以在选择的聊天应用程序中通过简单的@Botkube edit SourceBindings消息随时更改这些设置。Botkube还发布了一款新的Slack应用程序，该应用程序更强大，安全选项更丰富。

此外，对于喜欢全面使用开源的组织来说，这是一个重大的胜利，而不仅仅是在其基础设施中：Botkube现在支持Mattermostv7.x！

Botkube v0.13.0仅在一个月前发布，它完全支持最需要的功能：多通道支持。通过在Kubernetes集群中安装一个Botkube，你可以将事件分组并发送到不同的频道和消息平台。例如，可以向Slack发送高严重性事件，如“资源删除”、“未能提取镜像”或“准备就绪探测失败错误”，以获得团队的即时响应，并将其存档在ElasticSearch中，以获取事件响应操作的透明、可审核日志。

社区已经爱上了Botkube，原因还有很多：

——没有新的语法或工作流需要学习：Botkube使用熟悉的kubectl语法，只是使用了一个新的界面。

——Botkube默认情况下作为只读服务账户在集群内部运行，确保你拥有根据组织要求设置的访问控制和管理权限。

——支持监控自定义资源以接收证书过期或备份失败的警报（Velero和Kanister）。

Botkube是完全开源的，在GitHub上有150万星，拥有近100名贡献者和快速增长的社区。

ChatOps for Kubernetes的未来

要开始使用Botkube，需要安装两个组件：选择的聊天应用程序中的Botkube集成、Kubernetes集群中该应用程序的Botkube后端。

由于每个应用程序的设置过程都有所不同（它们需要不同的变量和秘密，更不用说创建和验证聊天机器人的独特设置过程了），你应该查看为所在组织的应用程序定制的文档：Slack、Mattermost、Discord、Teams、ElasticSearch、Webhook。