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

Kubernetes v1.22 中的 Alpha 特性：API Server Tracing

作者：David Ashpole (Google) |

在分散式系統中，找出問題所在可能很困難。您在一個元件的日誌中搜索，結果發現問題源自另一個元件。您在那裡搜尋，結果發現需要啟用除錯日誌才能弄清楚到底出了什麼問題……如此迴圈。您的請求路徑越複雜，就越難回答它去了哪裡。我個人花了很多時間在各種 Kubernetes 元件上進行這種“舞蹈”。分散式跟蹤是一種旨在幫助解決這些情況的工具，而 Kubernetes API 伺服器也許是最重要的需要除錯的 Kubernetes 元件。在 Kubernetes 的 Sig Instrumentation，我們的使命是讓您更容易理解叢集中發生的事情，我們很高興地宣佈 Kubernetes API 伺服器中的分散式跟蹤在 1.22 版本中達到了 Alpha 階段。

什麼是跟蹤？

分散式跟蹤將來自多個不同來源的一系列超詳細資訊連結在一起，並將這些遙測資料構建成該請求的單個樹。與透過使用日誌級別限制攝入資料量的日誌記錄不同，跟蹤收集所有詳細資訊並使用取樣來僅收集一小部分請求。這意味著一旦您擁有一個可以證明問題的跟蹤，您就應該擁有解決問題所需的所有資訊——無需搜尋物件 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 中，每百萬個 span 收集的樣本數量可以使用新引入的 --experimental-distributed-tracing-sampling-rate=1000000 標誌進行配置。

示例跟蹤：列出節點

我可以使用任何跟蹤後端，但決定使用 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 伺服器向准入 webhook 發出請求的青色 span，以及來自准入 webhook 服務請求的棕色 span。即使您沒有檢測您的 webhook，您仍然會從 API 伺服器向 webhook 發出請求中獲取 span。

參與其中！

由於這是我們首次嘗試向 Kubernetes 元件新增分散式跟蹤，因此可能還有很多可以改進的地方！如果我的掙扎與您產生共鳴，或者您只是想嘗試 Kubernetes 的最新功能，請試用該功能並提交您遇到的任何問題以及您認為可以改進該功能的方法。

這僅僅是我們可以在 Kubernetes 中利用分散式跟蹤所能做的開始。如果您認為其他元件會受益於分散式跟蹤，或者想幫助將 API 伺服器跟蹤推向 GA，請加入我們 定期會議 的 sig-instrumentation 組，並參與其中！