跳到主要內容

改善可觀測的前10個Kubernetes指標和服務

Introduction:

Kubernetes是廣泛使用的平台,用於管理規模化的容器化應用程序。隨着Kubernetes中服務數量的增加,有必要了解集群的性能和健康情況。您可以使用正確的指標來識別和解決潛在問題,以避免它們成為重大問題。雖然有許多可用於收集遙測數據的端點,例如cAdvisor、Metric Server、API Server、Node Exporter、Kube State Metric等等,但是考慮哪些指標可能是具有挑戰性的。與其立即關注基礎設施指標,重要的是討論Kubernetes中的常見問題以及為什麼特定指標被認為是前十大指標的一部分。此外,監控依賴服務對於確保最佳的Kubernetes環境和應用程序堆棧性能至關重要。如果我只能提名十個優先項目供觀察,這將是我要監控的前十大Kubernetes指標和服務,以獲得更好的可觀察性能。


Misconfiguration OOOooops!

Number 10 - Deployment Success vs Failure

在 Kubernetes 中,配置錯誤是常見問題,往往會導致系統性能和可靠性受到影響。根據與同行的討論、個人經驗和許多事後故事,即使是最有經驗的工程師在推出更新或服務時,也可能會意外地包含錯誤版本、錯過字段或使用無效輸入。

各種工具和工程實踐可用於減輕此類錯誤配置。其中一種實踐是良好的版本控制實踐和強大的部署流水線。您可以在每個部署階段部署煙霧測試來試用新服務,例如LaunchDarkly。這將幫助您在它們引起任何重大問題之前捕獲任何錯誤配置。

此外,利用基礎設施即代碼(IaC)、嚴格的同行評審和採用配置管理工具是確保最佳配置一致性和在出現問題時輕鬆回滾的好方法。例如,像GitLab管道狀態、CNCF生態系統中的ArgoCD和Flux等平台在滾動服務時跟蹤成功和失敗的部署非常有用。這些可以幫助您識別系統中的任何配置錯誤,並在它們產生重大影響之前快速解決它們。


GitLab 中的管道 pipeline details 細節範例:

使用 ArgoCD 同步的管道 pipeline visualization 可視化範例


We need MOOORRREEE!

Number 9 - CPU resource usage

Number 8 - Memory resource usage

在為 Kubernetes 設計應用程序時,考慮 CPU 和內存資源的分配非常重要。工程師經常花費大量時間來規劃這些分配,以確保最佳性能並避免諸如限流或 OOMkilled 症狀等問題。此外,這個 Kubernetes 實例計算器 可以成為容量規劃的有價值的工具。

Kubernetes 實例計算器learnk8s.io 提供

資源配額是 Kubernetes 工程師之間經常爭論的話題。有些人認為配額是必要的,可以防止資源耗盡並確保可靠性,而另一些人則認為配額會限制平台的可擴展性和靈活性。Google 建議在 Kubernetes 中設置 資源請求和限制 以提高資源利用率並避免潛在問題。然而,需要注意的是每個應用程式的特定需求和工作負載可能會有所不同。正如 Eric Khun 在信息文章 “Isolating No CPU Limits” 中所建議的一樣,適用於一種應用程式的方法可能不適合另一種應用程式。因此,非常重要的是仔細考慮每個應用程式的具體需求,並使用適當的工具和指標來確保最佳性能和可靠性。

要獲取 CPU 和內存使用信息,您可以使用度量服務器的資源度量管道中的指標。這些指標對於在 Kubernetes 中進行有效的水平和垂直縮放以及在潛在性能問題變成重大問題之前識別這些問題非常關鍵和有益。


Help! My Pods Are Stuck!

Number 7 - Pod Status Phase

Number 6 - Pod Status Reasons

使用Kubernetes運行容器化應用程序時,常常會遇到一些問題,例如pod卡住或無法按預期運行。這可能發生的原因有很多,如資源不足、達到資源限制、使用不正確的映像、配置錯誤以及無法解析DNS名稱等。為了確定問題的原因,Kubernetes提供了一個有用的命令“kubectl describe pods X”,其中包括關於pod的詳細信息,包括其狀態、事件和日誌。這些信息可以幫助工程師更有效地診斷和解決問題。

從積極的角度來看,Kubernetes正在改善其錯誤信息,以指導工程師在出現問題時快速識別和解決問題。通過提供更有用和可操作的錯誤信息,工程師可以快速識別和解決問題,從而減少平均解決時間(MTTR)。進一步改進MTTR的一種方法是通過自定義終止消息來提高MTTR,這使您能夠提供有關為什麼Pod被終止的更具體和相關的信息。這可以幫助您快速識別和解決問題,提高Kubernetes環境的整體可靠性和性能

早期檢測問題的一種方法是通過監視 kube_pod_status_phasekube_pod_status_reason 指標,這些指標可以在 Kube State Metrics - Pod Metrics 中找到。這些指標可以提供有關您的 pod 的狀態和健康情況的有價值見解,幫助您快速識別和解決可能出現的任何問題。

使用 ‘Kubectl describe pods’ 的範例如 ‘kubectl’ 快捷表中所述
cheatsheet.

例如,如果一個 Pod 在 “Pending” 階段停留很長時間,這可能表示集群中沒有足夠的資源來調度該 Pod。同樣,如果一個 Pod 處於 “CrashLoopBackOff” 階段,這可能表明 Pod 中的容器一再失敗,需要進一步調查。


Network Headaches & Service Availability

Number 5 - DNS Health

Number 4 - Application Error Rate

Number 3 - Ingress Error Rate

在 Kubernetes 中,網路故障可能會導致系統中斷,進而帶來嚴重後果和服務中斷。由於分佈式架構和各種組件的複雜性,解決這些問題可能具有挑戰性。因此,重要的是要全面了解基礎架構和網路配置,以有效地識別和解決網路故障。此外,實施冗余和故障轉移機制可以幫助減輕網路故障的影響,並提高系統的整體可靠性和可用性。

從Kubernetes版本1.12開始,CoreDNS是推薦的DNS伺服器,取代了kube-dns。在Kubernetes中,為服務和Pod創建DNS紀錄,使您可以使用一致的DNS名稱訪問服務,而不是IP地址。Kubernetes發布有關服務和Pod的數據,這些數據被用於編程DNS。常見的問題,如解析錯誤和網絡連接問題,會導致重大的中斷或停機。因此,重要的是要跟踪DNS健康狀況,以便有效地識別和解決任何網絡故障。

Health 由 CoreDNS 提供

一旦確保DNS按預期工作,下一步就是測試服務的功能。執行服務可用性檢查對確保應用程序正確運行至關重要。作為應用程序所有者,您可以選擇在集群中測試應用程序的最佳方法。儘管有許多指標可幫助您監視應用程序的性能,但Google網站可靠性工程-四個黃金信號描述了一些最有價值的指標,例如延遲、錯誤、流量和飽和度。然而,在這些指標中,應用程序錯誤率凸顯出作為前10個指標之一的最關鍵指標之一。

通過跟踪應用程序錯誤率,您可以快速識別可能出現的任何問題,以便在它們成為重大問題之前采取糾正措施。這個指標非常關鍵,因為它表明你的應用程序整體的健康狀況和網絡層是否正常工作。如果錯誤率很高,這可能意味著需要立即解決重大問題。另一方面,如果錯誤率很低,這表明您的應用程序表現良好,用戶有良好的體驗。

除了 DNS 和服務檢查外,工程師還會給 Kubernetes 中的 Ingress 層以重點關注。Ingress 是至關重要的,因為它允許管理對 Kubernetes 集群中服務的外部訪問。通過定義路由流量的規則,Ingress 允許在單個 IP 地址上將多個服務暴露給互聯網。這對於需要外部訪問的應用程序特別有用,例如 Web 應用程序,並且可以簡化集群內的網路流量管理。

在 Kubernetes 中,有多個選項可用於管理對服務的外部訪問,包括 NGINX、Traefik 和 Kong,每個選項都具有獨特的功能和優勢。重要的是考慮這些選項並監控 Ingress 錯誤率,以確保 Kubernetes 的最佳性能和可靠性。


Protecting the Control Plane

Number 2 - etcd health

Number 1 - API Server readyz

控制平面是 Kubernetes 中的關鍵要素,它做出了影響整個集群的重大決策。由多個組件組成,如 API 伺服器、調度器、etcd 和控制器管理器,它在集群的平穩運行中發揮著關鍵作用。雖然列出控制平面中的所有組件很誘人,但最重要的兩個組件是 etcd 和 API 伺服器。

Kubernetes 組件

Etcd是Kubernetes控制平面的關鍵組件。它維護集群的當前狀態並確保達到期望狀態。Etcd是一個分佈式數據存儲,它將數據組織成分層鍵值存儲。每個鍵表示一個目錄,每個值表示一個文件。Etcd將數據存儲在多個節點上,即使節點故障也能確保可用性。雖然它被設計為高可用、容錯和可擴展的,但建議使用以下命令密切監視etcd的健康狀況: etcdctl --endpoints**=**$ENDPOINTS endpoint health

最後,API伺服器經過各種改進以增強其穩定性。但是,API伺服器目前的大部分問題都是由於內部網絡問題引起的。需要注意的是,API伺服器有三個可用的端點- healthz、livez和readyz。重要的是要避免使用healthz端點,因為自Kubernetes v1.16以來已被棄用。相反,建議使用 readyz端點。
您可以通過運行以下命令獲取有關 API伺服器readyz 端點的更多詳細信息:kubectl get --raw='/readyz?verbose'


Honorable Mention

和任何前十名清單一樣,可能會有一些項目被忽略或對所提出的清單有不同意見。然而,其他 Kubernetes 指標和服務也值得注意和關注。

Controller Manager

控制器管理器在 Kubernetes 控制平面中扮演著重要角色,通過管理各種控制器來調節集群的狀態。其職責包括確保通過不斷監控和協調資源的實際狀態和期望狀態之間的差異來維護所需狀態。一組控制器負責 Kubernetes 環境的不同方面,如管理 Pod、服務、複製控制器和端點的部署,不斷監視集群的狀態,並在檢測到任何更改時採取行動將其恢復到所需狀態。

Persistent Volumes

持久卷(Persistent Volumes)是Kubernetes中的一個關鍵組件,允許為集群中的pod創建存儲卷。這些卷可以是動態或靜態創建的,並且被設計用於存儲需要在pod的生命週期之外持久化的數據。需要注意的是,在使用持久卷時,需要注意集群中持久卷(PersistentVolume)資源和這些資源的持久卷聲明(PersistentVolumeClaim)請求。

Pods out of Desired Replicas

在管理Kubernetes集群時,維護部署所需的副本數至關重要。當實際副本數與所需副本數不匹配時,會導致Pods不符合所需副本數。這種情況可能是由於手動部署更改、基礎設施問題或其他意外事件造成的。監控部署狀態至關重要,以確保始終維護所需的副本數,避免降低可用性和潛在的擴展問題。

Container Metrics

容器指標對於監控和觀察Kubernetes環境的性能和健康狀況至關重要。需要監控的頂級容器指標包括CPU、內存和網絡使用率。此外,監控磁盤使用率、磁盤I/O和文件系統使用率可以幫助在問題變成重大問題之前識別潛在問題。

Pod Container Status Ready

Kubernetes是一個容器編排平台,提供了一系列健康檢查機制,通常稱為探針。這些探針旨在確保Pod中的容器是否健康並準備好提供流量服務。其中一個探針是活動探針,它由kubelet用於確定是否重新啟動容器。另一方面,就緒探針由服務和部署使用,用於評估Pod是否應該接收流量。這些探針在維護Kubernetes集群的整體健康和性能方面發揮著至關重要的作用。


Conclusion

總之,Kubernetes是一個強大的平台,可用於規模化管理容器化應用程序。然而,隨著應用程序變得更加複雜,有必要了解集群的性能和健康狀況。本文討論的前10個Kubernetes指標和服務提供了一種全面有效的監控和識別潛在問題的方法,使其在成為重大問題之前得以解決。

需要記住的是,Kubernetes基礎設施只是構建和部署應用程序的拼圖中的一部分。應用程序服務,如API、數據庫和消息系統,是現代應用程序的支柱。它們使應用程序能夠為最終用戶提供價值。因此,與開發人員密切合作,確保應用程序服務可擴展、可靠、安全,並與Kubernetes基礎設施保持一致,是至關重要的。

從財富100強或初創企業,頂級品牌和軟件工程師都信任New Relic,幫助他們監視,調試和改進整個技術堆棧。只需在New Relic上註冊免費帳戶即可開始!您的帳戶包括每月100 GB的免費數據摄取,一個免費的全平台用戶和無限制的免費基本用戶。


References

https://k8s.af/

https://learnk8s.io/kubernetes-instance-calculator

https://kubernetes.io/docs/tasks/debug/debug-application/determine-reason-pod-failure

https://github.com/kubernetes/kube-state-metrics/blob/main/docs/pod-metrics.md

https://sre.google/sre-book/monitoring-distributed-systems

https://kubernetes.io/docs/concepts/overview/components

https://kubernetes.io/docs/concepts/storage/persistent-volumes

https://kubernetes.io/docs/concepts/workloads/controllers/replicaset

https://kubernetes.io/docs/concepts/cluster-administration/system-metrics

留言

這個網誌中的熱門文章

Kronos 如何做到世界級的成績

  由資深華爾街投資人領軍於 2018 年成立,Kronos Research 結合人工智慧、機器學習、高速網路等先進技術,透過進階的資料分析開發出獨家的量化交易預測模型,並使用全自動的交易策略自營,同時作為加密貨幣造市商,提供全球加密貨幣商品的即時報價。至今四年的時間,便擠身全球前五大的加密貨幣量交易團隊,創下 2021 年每日平均交易額 50 億美金,單日最高交易額 230 億美金的記錄。 人才和技術是 Kronos 最重要的兩大要素,團隊採開放式合作、解決問題導向、美式工作風格,Kronos 期許任何職位的夥伴,都能信任彼此、安心發問、共同快速解決問題。主管的管理策略,不同於傳統上對下的管理,而是以幫助者的角色,解決不同的需求,放大每個職位的生產力。我們希望這個產業在台灣能夠茁壯,讓台灣的技術人才知道有這個國際舞台可以發揮。 一窺量化交易技術及團隊 高頻交易跟一般大家熟知的交易最大的差距在於自動化。我們熟知的交易模式多半透過人工,由交易員綜合市場資訊後向交易所下單;高頻交易則是由程式自動判斷市場資訊並且下單。高頻交易多半關注短時間的市場波動,在收到市場報價後,在極短時間透過預先訓練的統計模型做出買賣決策。在高額報酬的背後,結合了不同專業:包括資料科學、統計與機器學習、底層系統優化、以及分散式系統。 高頻交易的流程,從 Market Data Parser 作為源頭持續搜集來自交易所的歷史資料,交由 Alpha Modeling 訓練出可預測未來短時間市場變動的模型。接著交易團隊撰寫策略程式,並依據策略需要套用選擇合適的 Alpha 模型,由極低延遲的交易程式向交易所下單。以下是各模塊的介紹: Market Data Parser(Data Team):高頻交易是一個資料驅動的行業,全面且高正確率的資料對於後續訓練很重要。Kronos Research 在全球十多個機房內有數百台服務器,每天 24 小時不間斷錄製來自交易所的報價單。面對每天 10TB+ 的巨量資料,data team 大量使用雲端分散技術以及自動化技術確保資料流的穩定。 Alpha Modeling(Alpha Team):在投資市場中,Alpha 代表著高於大盤的超額收益,Alpha Model 則代表預測將來市場的數學模型。Alpha Team 透過統計以及機器學習,以敏銳的邏輯跟觀...

2025 議程人氣大揭密!

COSCUP 2025 議程人氣大揭密! 7/9 議程測試上線,今年的 COSCUP 大家最關注的究竟是哪些議程?為了滿足(我們自己也很好奇)大家的好奇心,我們分析了一下 Google Analytics (GA) 報表的排行榜:「最多關注(瀏覽數)」、「最高人氣(活躍使用者數)」及「最具深度(每位活躍使用者的平均參與時間)」來啦! 不管你是第一次參加 COSCUP 的新朋友,還是每年都熱情參與的忠實社群夥伴,都歡迎來瞧瞧這份議程人氣大揭密! 三大指標,看懂關注焦點 我們這次的分析分為「台灣」、「國際」以及「加總」三個區塊,每一個都分別整理出前幾名的議程,讓你快速掌握不同參與者的興趣點。 最多關注(瀏覽數): 最直觀地告訴我們,哪些議程最吸引大家的目光。 最高人氣(活躍使用者數): 讓我們了解,哪些議程讓最多人真正點進去、一探究竟。 最具深度(每位活躍使用者的平均參與時間): 幫助我們發現,哪些議題讓大家停留最久,深入了解內容。 從數據看趨勢,今年的議題熱點 從這份資料中,我們可以觀察到今年 COSCUP 大家感興趣的話題,不僅有傳統開源軟體與程式語言,更有不少議程圍繞在 AI、資料治理、安全合規,以及社群經營等熱門趨勢。 以瀏覽量最高的議程來看,許多朋友依然熱烈追蹤知名講者與經典技術主題。而從參與時間的深度指標來看,一些議題雖然未必獲得大量瀏覽,卻能讓點進去花更多時間細細品味。 同時,我們特別針對國際觀眾的喜好進行分析,也看出國際社群更偏好具有跨國經驗分享、全球趨勢分析與技術實踐經驗的內容,讓我們更加理解國際與在地社群的共同性與差異性。 一起掌握開源潮流!  國際大家看什麼? 最多關注 排名 作者 議程標題 Track 日期時間 議程教室 1 王良丞/LCWang 4色小尺寸電子紙的DRM驅動程式開發之旅 System Software 08-10 09:30 TR213 2 John Ho 何重義、Jessie.D Chang 聊心茶室媽媽桑、Joanna Chen陳芸緻、Bernice Ch...

COSCUP 2023 徵稿辦法 / COSCUP 2023 Call for Proposals

今年 COSCUP 一如往常,徵求各式各樣不同的 Open Source 相關稿件。請於 5 月 22 日 (UTC-12) 前投稿,或可參考本頁下方各議程軌資訊。 請注意, 每場議程長度預設為 30 分鐘 , 惟指定議程軌開放其他議程長度進行選擇 ,會在報名表單第二頁進行填寫,報名表單第一頁的提交型態中,請選擇預設值。 為了追求與全球社群更良好地溝通, 今年所有選中的議程都必須提供英文版的資訊 。一旦您的議程入選,我們會請您提供議程資訊的英文版翻譯。您仍可以自己偏好的語言演講或撰寫 CfP 稿件。 提醒您,COSCUP 是一個倡導開放的研討會,所有演講將錄影並以創用 YouTube CC 姓名標示-相同方式分享 4.0 釋出。如果您的演講有任何不能錄影或不願以此條款釋出的狀況,請務必於投稿表單上註明。 We are looking for talks in several open-source related areas, please submit your proposal before May 22th, 2023 UTC-12. After the review process from the coordinators, we will publish the full programme in early June. Please note that the length of each agenda is preset to 30 minutes, only the specific tracks are open to other agenda lengths for selection, which will be filled in on the second page of the registration form. In the submission type on the first page of the submission form, please select the default value (30 mins) . For better communication with the global community, we require En...