使用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。

原文連結：https://thenewstack.io/enabling-collaborative-k8s-troubleshooting-with-chatops/