跳到主要內容

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

留言

這個網誌中的熱門文章

【攤位大地遊戲(開源巔峰挑戰賽)】Booth Reward Activity! 2024

/English Below/ 來啊,造訪攤位掃 QRCode,集點數換 2024 年限定贈品啊! 一年只有這一檔,錯過要再等一年! 在找工作嗎?想認識不同的社群嗎?想獲得 COSCUP 2024 專屬的限量贈品嗎? 利用空餘時間去各個攤位聊聊天、看一看,就可以參與大地遊戲拿獎品喲! 大地遊戲怎麼玩:​​ (歡迎順路參與 參與者大調查),填寫表單取得 OPass 票券,並下載與登入 OPass App: 取得 OPass 票券 。 前往 TR 309、312、409-1、515、516 逛各攤位。 在攤位前打開 OPass 的「我的票卷」,秀出 Opass QRcode 讓攤位人員掃描取得點數。 到 TR309 的「大會攤位」兌換贈品,數量有限! 造訪每個攤位掃描後,可獲得 5 點,今年有 28 攤 完成一日志工任務後,可獲得 50 點,至多可解 4 次 擔任講者,可享福利 400 點(請以收到的登入連結進入,每名講者限領取乙次) 今年的紀念品除了可以現金購買,也可以用點數兌換呦! ≡≡≡≡ 集點方法 ≡≡≡≡ 上方每ㄧ個方框,都是ㄧ個攤位或者ㄧ個小任務,每當你造訪完成任務後,即可打開「我的票券」中顯示你的 QRcode 給關主獲取點數,您可以在上方看到您的戰果點數。當您心滿意足準備離開大惠會場前,記得到下述地方將您的點數兌換成滿滿的回憶! ≡≡≡ 點數兌換處 ≡≡≡ 【TR309 外:大會攤位】 1 點即是 1 元,您可以在大會攤位上購置各種精美紀念品,包含滑鼠墊、鍵帽、透卡與紀念 T 恤!。 ≡≡≡ 點數兌換規則 ≡≡≡ 您可以於【紀念品攤位】旁的點數兌換區把點數兌換

你所不知道的 foodpanda

  2020 左右,隨著新冠疫情流行,台灣也逐漸流行起一股懶人旋風。懶懶躺在沙發上,動動手指滑滑螢幕,生鮮或美食就能快速又安全地由可愛的粉紅色熊貓外送員送達您門口。多數人知道 foodpanda 是台灣最大生鮮美食外送平台,也不少人知道 foodpanda 在台灣不斷擴張業務範圍,但 foodpanda 也有許多台灣科技圈所不知道的事。 例如,foodpanda 其實並非台灣本土廠商,也非只專注在亞洲區域。foodpanda 隸屬於德國 Delivery Hero 集團,業務橫跨歐洲、亞洲、美洲及北非,旗下更有十多個生鮮美食外送品牌。除此之外,foodpanda 於 2021 年時也在台灣正式成立全球第三個 Tech Hub。做為四大產品 RD 研發中心之一,台灣與德國柏林、新加坡及土耳其伊斯坦堡的人才緊密地合作,專注於打造 end-to-end 的顧客體驗。諸如月費方案 Panda Pro、外帶自取、餐廳內用 (目前仍未在台灣上市) 等功能。期待能持續吸收優秀人才、與其它三個跨國研發中心合作,打造後疫情時代新的成長引擎。 事實上,台灣的 foodpanda 研發團隊並不僅止於打造台灣本土產品。反之,我們所建立的平台及產品,已成功於近 20 個國家、10 個品牌上市。要在快速的步調下,打造持續進步且符合不同國家文化客戶需求的產品,我們依靠的是 專案團隊成員一條龍組合 從 Product Manager、Engineering Manager、iOS/Android/Web/Backend developer、QA、Product Designer、Product Analyst 全都在同一個 product line squad。讓相同產品的團隊成員能緊密合作、第一手快速了解市場、滿足需求。 國際專業團隊緊密合作 foodpanda 的 iOS/Android/Web/Backend 等專業工程師,都各自設有其跨 squad 的 chapter 組織。讓工程師能在專案團隊以外,有跨國跨團隊專業能力交流的機會。在 chapter 中,相同技術域領的專家們,會一起制定共同的實作標準、分享在專案中遇到類似的挑戰,並且找出可能的應對方案。因此,在 foodpanda 我們不只打產品專案團隊的速度戰、還打整個集團的整合能力團體戰,讓德國、新加坡、台灣、伊斯坦堡的工程師們用最有

行前通知信 / It’s that time of year… All the fun at COSCUP x RubyConfTW 2021

(English below / 下半部有英文版) COSCUP x RubyConfTW 2021 即將在 07/31 - 08/01 線上舉辦! 在即將到來的活動有幾件事情需要事先準備的,在此一一說明,讓當日的活動可以順利進行。 活動前 議程表 還沒看這次有哪些議題的,可以先看看已公告的 議程表 ,每一軌的的議程表上方將會在議程開始時出現 YouTube 轉播。讓妳有隨意逛教室、逛議程的感受。 講者須知 如果您是講者,在活動前應該會收到關於 StreamYard 的連結邀請,如果沒有收到,請聯絡您的社群負責人或是議程主持人。 線上會場大廳 由於目前此刻,我們的線上會場還在加緊趕工敲敲打打中,建議連回到 COSCUP 官網首頁,由首頁上的指引進入。 我們這次會使用 Gather.Town 平台登入,在活動開始期間,可以先閱讀 操作手冊 ! 活動入口連結: 活動大廳: 連結 攤位區 01: 連結 攤位區 02: 連結 BoF: 連結 前夜派對(Welcome Party!): Party 1 | Party 2 Opening Hours 7/30 7/31 8/01 入口區 ENTRANCE 24H 24H 24H 攤位區 Booth 1 / Booth 2 CLOSED 10:00 18:00 10:00 18:00 Party | BoF Party 1 / Party 2 17:30 22:00 17:30 22:00 CLOSED 個人贊助 感謝各方好友支持 COSCUP!每贊助一筆 2500 元,可獲得 COSCUP 2021 獨家贈品一份。或是其他金額小額捐款/香油錢(無贈品)。 個人贊助由此去! 活動前一天