跳到主要內容

改善可觀測的前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

留言

這個網誌中的熱門文章

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

COSCUP 2024 Call for Proposals: Until 9th, May Submit Your Proposals HERE! 今年 COSCUP 一如往常,徵求各式各樣不同的 Open Source 相關稿件。請於 05 月 09 日(AoE) 前投稿,徵稿主題可參考本頁下方各議程軌資訊。 請注意,每場議程長度預設為 30 分鐘 ,惟部分議程軌開放其他議程長度,會在報名表單第二頁選填。 為了增添 COSCUP 的國際能見度,今年所有入選稿件希望都可以提供中英文版雙語資訊。徵稿階段,您可先以自己偏好的語言準備演講或撰寫 CfP 稿件。 提醒您,COSCUP 是一個倡導開放的研討會,所有演講將錄影並以創用 YouTube CC 姓名標示-相同方式分享 4.0 釋出。如果您的演講有任何不能錄影或不願以此條款釋出的狀況,請務必於投稿表單上註明。 We are looking for talks in several open-source related areas, please submit your proposal before May 09th, 2024 (AoE, Anywhere on Earth) . The theme for submissions can be referenced from the information on various tracks at the bottom of this page. 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. To make it more accessible for international audiences, we kindly request CFP information to be provided in both Chinese and

Designers in Tech- Open Source Design Workshop

關於工作坊 今年在COSCUP(Conference for Open Source Coders, Users Promoters)將協同國際團隊 Superbloom(以人為本出發幫助設計更具包容性和開放性的國際非營利組織)舉辦Designers in Tech- Open Source Design Workshop工作坊,此工作坊是專門為希望對社會做出正面貢獻的設計師所設計的,我們將邀起您以設計師的姿態,在科技人為主的世界裡舞擺出專屬於你的開源貢獻。 設計,如果共享後會有怎樣的可能性?開源設計為另一種合作模式,結合「共同協作」,讓人們可以自由地存取、使用、修改和分享設計資源來達到共同設計的目的。這次的工作坊試圖透過一個公開、透明、無國界的網路平台Github,讓設計師有機會參與平日以工程師為主的平台,並在上面做出生平第一次的開源設計貢獻,重新定義開源貢獻與設計的可能。 我們相信藉由設計師的參與可以優化現有以工程師、開發者為重的開源生態。通過設計師將專案納入更多的可及性和包容性。活動主旨在帶領設計師學習Github平台操作,進而可自行為開源專案進行貢獻。我們致力於賦能設計師開源專案貢獻力,摒除藩籬,打破開源僅為程式開發是唯一有價值貢獻的迷思。 我們將以「設計思考」思維出發並結合Superbloom的「使用者研究」個案來帶領工作坊,進一步在GitHub上挑選出3個專案做出貢獻:去中心化的移動網絡瀏覽器( Ceno Browser )、事實查核( Co-Facts )、通訊軟體( Session )。全程手把手引導教學如何以設計師的身份在GitHub上做出貢獻,提供全面的支援。在工作坊結束後,參與者能更加了解開源設計及在開源專案自行進行協作。 誰應該參加這個工作坊? 我們的工作坊對於UI/UX、平面設計師都相當歡迎 誰將帶領這個工作坊? Eriol Fox:Eriol擁有10年以上的設計工作經驗,從營利性企業開始,後來轉向非政府組織和開源軟件組織。他們曾參與涉及可持續食品系統、和平建設和危機應對技術的複雜問題。Eriol目前在Simply Secure工作,從事設計、研究、開源和技術項目。 Eriol是紐卡斯爾大學Open Lab的兼職資助博士研究員,他研究設計師如何參與以人道主義和人權為重點的開源軟件項目。

Berry AI 深化美國客戶合作,利用電腦視覺優化速食營運

聚焦速食產業 AI 應用,Berry AI 已獲得多個大型速食品牌信任 Berry AI 運用電腦視覺技術幫助速食業者蒐集營運資訊,用於優化營運流程與改善消費者體驗。自 2022 年成功進入美國市場後,銷售成績大幅成長,目前已成為美國速食 AI 科技領導業者。 Berry AI 團隊成員來自哈佛大學、杜克大學、紐約大學等知名學府以及阿里巴巴、聯發科、Microsoft、Appier、HTC 等大型跨國科技企業與 AI Labs、Umbo CV、Gogolook 、Cubo AI 等知名新創。Berry 研發團隊鼓勵成員探索與應用新的技術,我們延攬 AI 領域富有盛名且擁有數十年研究經驗的教授做為技術顧問,大幅增強團隊的研發能量。我們擁抱技術的無限可能性,並且相信共享知識的力量,研發團隊亦定期舉辦 Workshop 與技術交流會,分享彼此研究進度與開發心得,共同學習新知識。讓每一位成員都能夠盡情發揮自己的才華,實現自己的技術夢想。 Berry AI 於 2022 年開始與多家美國客戶展開合作,產品獲得肯定,先是與全球第 2 與第 3 大漢堡連鎖業者 Burger King 和 Wendy’s,以及全球第 3 大披薩連鎖業者 Little Caesars 進行試點導入,並於 2023 年擴大合作,將產品導入更多分店。在速食產業內建立起產品口碑後,Berry AI 與更多品牌建立合作關係,在 2024 上半年已經和 5 個新品牌以及大型加盟商進行試點導入,包含 Zaxby's、7 Brew 和 Scooter's Coffee 等,預計在下半年擴大導入各品牌,讓銷售成績有另一個指數性成長。「Berry 運用 AI 技術幫助業者優化成本、提升營收,創造巨大的效益。全美共有超過 20 萬間速食店,未來數年將有數萬間分店導入 AI 產品。」CEO Eric 說道。 Berry AI 的解決方案架構為 Edge AI 與混合雲的架構,產品則聚焦於協助美國速食業改善 Speed of Service,透過提供給客戶 AI-based Drive-Thru Timer System,以及店內的 Customer Journey 追蹤系統,協助客戶即時了解狀況、找到問