使用 Sysdig 監控 Kubernetes

今天我們分享一篇來自 Sysdig 的 Chris Crane 的客座文章，內容關於他們與 Kubernetes 的監控整合。

Kubernetes 提供了一個完整的環境來編寫可擴充套件的、基於服務的應用程式。它負責容器分組、發現、負載均衡和修復等事務，因此您無需擔心這些問題。其設計優雅、可擴充套件，API 使用起來也令人愉悅。

與任何新的基礎設施平臺一樣，如果您想在生產環境中執行 Kubernetes，您會希望能夠對其進行監控和故障排除。Sysdig 的我們是 Kubernetes 的忠實擁躉，嗯：我們來助您一臂之力。

Sysdig 在其全線產品中提供對 Kubernetes 的原生可見性。這包括我們的開源 CLI 系統探索工具 sysdig，以及第一個也是唯一一個從頭開始設計以支援容器和微服務的監控平臺 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 將利用標準 API 和 watch API 輪詢所有相關資訊。

現在 csysdig 正在執行，按下 F2 調出視圖面板，您會注意到存在許多新檢視。**k8s 名稱空間**檢視可用於檢視名稱空間列表，並觀察每個名稱空間在此機器上使用的 CPU、記憶體、網路和磁碟資源量。

同樣，您可以選擇**k8s 服務**以按服務檢視相同的資訊

或**k8s 控制器**以檢視複製控制器

或**k8s Pods**以檢視在此機器上執行的 Pod 列表及其使用的資源

基於鑽取的導航

csysdig 中的一個很酷的功能是鑽取能力：只需選擇一個元素，點選回車鍵——轟——現在您正在檢視其內部。鑽取還了解 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 叢集以這張圖片所示的層次結構排列

• 所有容器都在**Pods**中執行。一個 Pod 可以託管一個單獨的容器，也可以託管多個協作容器；在後一種情況下，Pod 中的容器保證位於同一臺機器上，並且可以共享資源。
• Pod 通常位於**服務**之後，服務負責均衡流量，並以單個可發現的 IP 地址/埠公開一組 Pod。
• 服務透過**複製控制器**（“RC”）橫向擴充套件，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 見面會。

• ←上一篇
• 下一篇→