這篇文章已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。

Kubernetes v1.22 Alpha 版新功能：API 伺服器追蹤

作者：David Ashpole (Google) |

在分散式系統中，可能很難找出問題所在。您 grep 遍歷一個組件的日誌，只是為了發現問題的根源在另一個組件中。您在那裡搜索，只是為了發現您需要啟用除錯日誌才能找出真正出了什麼問題... 並且這種情況不斷發生。您的請求路徑越複雜，就越難回答關於它去向的問題。我個人花費了許多小時與各種 Kubernetes 組件進行這種舞蹈。分散式追蹤是一種旨在幫助應對這些情況的工具，而 Kubernetes API 伺服器可能是最需要除錯的 Kubernetes 組件。在 Kubernetes 的 Sig Instrumentation 中，我們的使命是讓您更容易了解叢集中發生的事情，我們很高興宣布 Kubernetes API 伺服器中的分散式追蹤在 1.22 中達到了 alpha 階段。

什麼是追蹤？

分散式追蹤將來自多個不同來源的一堆超詳細資訊連結在一起，並將該遙測數據結構化為該請求的單一樹狀結構。與透過使用日誌級別來限制攝取數據量的日誌記錄不同，追蹤收集所有詳細資訊，並使用抽樣僅收集一小部分請求。這意味著一旦您有一個演示問題的追蹤，您應該擁有解決問題根源所需的所有資訊 - 無需 grep 物件 UID！不過，我最喜歡的方面是追蹤視覺化的實用性。即使您不了解 API 伺服器的內部運作方式，或者不知道 etcd「交易」是什麼，我敢打賭您（是的，您！）也能大致告訴我事件的順序，以及哪些組件參與了請求。如果某個步驟花費很長時間，則很容易判斷問題出在哪裡。

為何選擇 OpenTelemetry？

重要的是，無論誰管理您的基礎架構，或您選擇與哪些供應商整合，Kubernetes 都能為所有人良好運作。對於 Kubernetes 與遙測解決方案的整合而言，尤其如此。OpenTelemetry 作為 CNCF 專案，也秉持這些核心價值，並且正在創建 Kubernetes 中我們需要的東西：一組用於追蹤客戶端程式庫 API 和標準追蹤格式的開放標準。透過使用 OpenTelemetry，我們可以確保使用者有自由選擇其後端的權利，並確保供應商擁有公平的競爭環境。時機再好不過了：OpenTelemetry golang API 和 SDK 非常接近其 1.0 版本發布，並將很快為這些開放標準提供向後相容性。

為何要檢測 API 伺服器？

Kubernetes API 伺服器是追蹤的絕佳候選者，原因如下：

  • 它遵循標準的「RPC」模型（透過向下游組件發出請求來服務請求），這使其易於檢測。
  • 使用者對延遲很敏感：如果請求完成時間超過 10 秒，許多客戶端將會逾時。
  • 它具有複雜的服務拓撲：單一請求可能需要諮詢十幾個 webhook，或涉及對 etcd 的多個請求。

嘗試使用 webhook 進行 APIServer 追蹤

啟用 API 伺服器追蹤

  1. 啟用 APIServerTracing 功能閘道。

  2. 透過將 kube-apiserver 上的 --tracing-config-file 標誌指向我們的設定檔來設定我們的追蹤設定，該設定檔包含：

apiVersion: apiserver.config.k8s.io/v1alpha1
kind: TracingConfiguration
# 1% sampling rate
samplingRatePerMillion: 10000

啟用 Etcd 追蹤

更新：以下內容在部落格發布後新增 新增 --experimental-enable-distributed-tracing、--experimental-distributed-tracing-address=0.0.0.0:4317、--experimental-distributed-tracing-service-name=etcd 標誌到 etcd 以啟用追蹤。請注意，這會追蹤每個請求，因此如果您啟用它，可能會產生大量追蹤。所需的 etcd 版本為 3.5 至 3.5.4。

從 3.5.5 版到 3.5.10 版，追蹤的預設取樣率設定為 0%，表示預設情況下不收集任何追蹤。遺憾的是，沒有提供用於設定更高取樣率的選項。（請參閱詳細資訊）

在 3.5.11 版中，可以使用新引入的 --experimental-distributed-tracing-sampling-rate=1000000 標誌配置每百萬個 span 要收集的樣本數。

範例追蹤：列出節點

我可以使用任何追蹤後端，但我決定使用 Jaeger，因為它是最受歡迎的開源追蹤專案之一。我在我的叢集中部署了 Jaeger All-in-one 容器，在我的控制平面節點上部署了 OpenTelemetry 收集器（範例），並捕獲了像這樣子的追蹤

Jaeger screenshot showing API server and etcd trace

青色線條來自 API 伺服器，包括它服務於 /api/v1/nodes 的請求，以及向 ETCD 發出 grpc Range RPC。黃色線條來自 ETCD 處理 Range RPC。

範例追蹤：使用 Mutating Webhook 建立 Pod

我使用 OpenTelemetry 檢測了 範例 webhook（我必須 修補 controller-runtime，但它製作了一個精美的演示），並將追蹤路由到 Jaeger。我收集了像這樣子的追蹤

Jaeger screenshot showing API server, admission webhook, and etcd trace

與之前的追蹤相比，有兩個新的 span：來自 API 伺服器的青色 span，它向 admission webhook 發出請求，以及來自 admission webhook 服務請求的棕色 span。即使您沒有檢測您的 webhook，您仍然會從 API 伺服器獲得向 webhook 發出請求的 span。

參與其中！

由於這是我們首次嘗試將分散式追蹤添加到 Kubernetes 組件，因此可能有很多我們可以改進的地方！如果我的掙扎引起了您的共鳴，或者您只是想嘗試 Kubernetes 提供的最新功能，請試用該功能並針對您遇到的任何問題以及您認為可以改進該功能的方式開啟 issue。

這僅僅是我們可以在 Kubernetes 中使用分散式追蹤的開始。如果您認為還有其他組件可以從分散式追蹤中受益，或者想幫助將 API 伺服器追蹤帶到 GA，請加入 sig-instrumentation 參加我們的 例行會議 並參與其中！