使用 Sysdig 監控 Kubernetes

今天我們分享一篇由 Sysdig 的 Chris Crane 撰寫的客座文章，內容關於他們將監控功能整合到 Kubernetes 中。

Kubernetes 提供了一個完整的環境來編寫可擴展且基於服務的應用程式。它負責處理容器分組、探索、負載平衡和自我修復等事務，讓您無需擔心。設計優雅、可擴展，且 API 使用起來令人愉悅。

和任何新的基礎架構平台一樣，如果您想在生產環境中運行 Kubernetes，您會希望能夠監控和排除故障。我們 Sysdig 是 Kubernetes 的忠實粉絲，而且，嗯：我們在這裡提供協助。

Sysdig 在完整的 Sysdig 產品線中提供對 Kubernetes 的原生可見性。這包括 sysdig，我們的開源 CLI 系統探索工具，以及 Sysdig Cloud，第一個也是唯一一個從頭開始設計以支援容器和微服務的監控平台。

在高層次上，Sysdig 產品可以感知整個 Kubernetes 叢集層次結構，包括命名空間、服務、複製控制器和標籤。因此，收集到的所有豐富的系統和應用程式數據現在都可以在您的 Kubernetes 基礎架構的上下文中使用。這對您意味著什麼？簡而言之，我們相信 Sysdig 可以成為您的首選工具，讓 Kubernetes 環境的監控和故障排除變得更加容易！

在這篇文章中，我將快速預覽開源 sysdig 和 Sysdig Cloud 中的 Kubernetes 可見性，並展示幾個有趣的用例。讓我們從開源解決方案開始。

使用 csysdig 探索 Kubernetes 叢集

利用 sysdig 的 Kubernetes 支援最簡單的方法是啟動 csysdig，sysdig 的 ncurses UI

> csysdig -k http://127.0.0.1:8080
*注意：使用 -k 命令指定您的 Kubernetes API 伺服器的位址，sysdig 將輪詢所有相關資訊，同時利用標準和 watch API。

現在 csysdig 正在運行，按下 F2 以打開視圖面板，您會注意到出現了許多新視圖。「k8s 命名空間」視圖可用於查看命名空間列表，並觀察每個命名空間在此機器上使用的 CPU、記憶體、網路和磁碟資源量

同樣地，您可以選擇「k8s 服務」以查看按服務劃分的相同資訊

或「k8s 控制器」以查看複製控制器

或「k8s Pod」以查看在此機器上運行的 Pod 列表以及它們使用的資源

基於向下鑽取的導航

csysdig 的一個很酷的功能是向下鑽取的能力：只需選擇一個元素，點擊 Enter，然後 – 砰 – 現在您正在查看其內部。向下鑽取也意識到 Kubernetes 層次結構，這意味著我可以從一個服務開始，獲取其 Pod 列表，查看哪些容器在其中一個 Pod 內部運行，然後進入其中一個容器以探索檔案、網路連線、進程甚至線程。請查看下面的影片。

動作！

關於 csysdig 還有一件事。正如最近宣布的那樣，csysdig 也提供「控制面板」功能，使得可以使用熱鍵根據目前選擇的元素執行命令列。因此，我們確保使用許多有用的熱鍵豐富 Kubernetes 視圖。例如，您可以透過按下「x」刪除命名空間或服務，或者您可以透過按下「d」描述它們。

然而，我最喜歡的熱鍵是「f」，用於追蹤 Pod 正在產生的日誌，以及「b」，它利用 kubectl exec 在 Pod 內部提供一個 shell。被帶入您正在觀察的 Pod 的 bash 提示符非常有用，而且坦白說，有點神奇。 :-)

這就是 sysdig 中 Kubernetes 的快速預覽。但請注意，所有這些功能僅適用於單一機器。如果您想監控分散式 Kubernetes 叢集會發生什麼事？請看 Sysdig Cloud。

使用 Sysdig Cloud 監控 Kubernetes

讓我們從快速回顧 Kubernetes 的架構開始。從物理/基礎架構的角度來看，Kubernetes 叢集由一組受主節點監督的從屬節點機器組成。主節點的任務包括協調跨從屬節點的容器、追蹤狀態以及透過 REST API 和 UI 公開叢集控制。

另一方面，從邏輯/應用程式的角度來看，Kubernetes 叢集以圖中所示的層次結構方式排列

• 所有容器都在 Pod 內部運行。一個 Pod 可以託管單個容器，或多個協作容器；在後一種情況下，Pod 中的容器保證位於同一機器上，並且可以共享資源。
• Pod 通常位於服務之後，服務負責平衡流量，並將一組 Pod 作為單個可探索的 IP 位址/埠公開。
• 服務由複製控制器（「RC」）水平擴展，複製控制器根據需要為每個服務建立/銷毀 Pod。
• 命名空間是可以包含一個或多個服務的虛擬叢集。

因此，為了清楚起見，多個服務甚至多個命名空間可以分散在相同的物理基礎架構上。

在與數百位 Kubernetes 使用者交談後，似乎典型的叢集管理員通常對從物理角度看待事物感興趣，而服務/應用程式開發人員則更傾向於從邏輯角度看待事物。

考慮到這兩種用例，Sysdig Cloud 對 Kubernetes 的支援運作方式如下：

• 透過自動連接到 Kubernetes 叢集 API 伺服器並查詢 API（包括常規 API 和 watch API），Sysdig Cloud 能夠推斷出您的微服務應用程式的物理和邏輯結構。
• 此外，我們透明地提取重要的元數據，例如標籤。
• 此資訊與我們正在申請專利的 ContainerVision 技術相結合，該技術使得無需對容器或應用程式進行任何檢測即可檢查容器內運行的應用程式。基於此，Sysdig Cloud 可以從以基礎架構為中心和以應用程式為中心的角度提供豐富的可見性和上下文。兩全其美！讓我們看看這實際上是什麼樣子。

Sysdig Cloud 的核心功能之一是群組，它允許您定義應用程式和基礎架構的元數據層次結構。透過應用適當的群組，您可以根據容器的物理層次結構（例如，物理叢集 > 從屬節點機器 > Pod > 容器）或根據其邏輯微服務層次結構（例如，命名空間 > 複製控制器 > Pod > 容器 – 如您在本範例中所見）來探索您的容器。

如果您對底層物理資源的利用率感興趣 – 例如，識別吵雜的鄰居 – 那麼物理層次結構非常棒。但是，如果您希望探索應用程式和微服務的效能，那麼邏輯層次結構通常是最佳起點。

例如：在這裡您可以看到我們 WordPress 服務的整體效能：

請記住，實作此服務的 Pod 分散在多個機器上，但我們仍然可以將此服務的總請求計數、響應時間和 URL 統計資訊匯總在一起。而且別忘了：這不需要對 wordpress、apache 或底層容器進行任何配置或檢測！

從這個視圖中，我現在可以輕鬆地為這些服務級別的指標建立警報，並且我可以隨時深入挖掘任何單個容器進行深度檢查 – 一直到進程級別 – 包括回到過去！

可視化您的 Kubernetes 服務

我們還在 Sysdig Cloud 著名的拓撲視圖中加入了 Kubernetes 感知，包括物理和邏輯層級。

下面的兩張圖片顯示了完全相同的基礎架構和服務。但第一張圖片描繪了物理層次結構，包括一個主節點和三個從屬節點；而第二張圖片將容器分組到命名空間、服務和 Pod 中，同時抽象化容器的物理位置。

希望第二個（以服務為導向的）視圖有多麼自然和直觀是顯而易見的。應用程式的結構和各種依賴關係立即清晰明瞭。儘管這些微服務在我們的機器叢集中混合在一起，但各種微服務之間的交互變得顯而易見！

結論

我非常有信心我們在這裡提供的功能代表 Kubernetes 環境可見性方面的一大飛躍，並且不會讓您失望。我也希望它可以成為一個有用的工具，使您能夠更安心地在生產環境中使用 Kubernetes。謝謝，祝您挖掘愉快！

您可以在 github 和 sysdig.org 上找到開源 sysdig，並且可以在 sysdig.com 上註冊 Sysdig Cloud 的免費試用版。

若要觀看現場演示並與專案背後的一些人員會面，請在本週四加入我們在舊金山舉辦的 Kubernetes 和 Sysdig Meetup。

• ←上一篇
下一篇→