## 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](https://docs.gitlab.com/ee/ci/pipelines/#view-pipelines) 細節範例：


使用 ArgoCD 同步的管道 [pipeline visualization](https://argo-cd.readthedocs.io/en/stable/getting_started/#7-sync-deploy-the-application) 可視化範例

---

## We ****need MOOORRREEE!****

**Number 9 - CPU resource usage**

**Number 8 - Memory resource usage**

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


[Kubernetes 實例計算器](https://learnk8s.io/kubernetes-instance-calculator) 由 learnk8s.io 提供

資源配額是 Kubernetes 工程師之間經常爭論的話題。有些人認為配額是必要的，可以防止資源耗盡並確保可靠性，而另一些人則認為配額會限制平台的可擴展性和靈活性。Google 建議在 Kubernetes 中設置 [資源請求和限制](https://cloud.google.com/blog/products/containers-kubernetes/kubernetes-best-practices-resource-requests-and-limits) 以提高資源利用率並避免潛在問題。然而，需要注意的是每個應用程式的特定需求和工作負載可能會有所不同。正如 Eric Khun 在信息文章 "[Isolating No CPU Limits](https://erickhun.com/posts/kubernetes-faster-services-no-cpu-limits/)" 中所建議的一樣，適用於一種應用程式的方法可能不適合另一種應用程式。因此，非常重要的是仔細考慮每個應用程式的具體需求，並使用適當的工具和指標來確保最佳性能和可靠性。

要獲取 CPU 和內存使用信息，您可以使用度量服務器的[資源度量管道](https://kubernetes.io/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/)中的指標。這些指標對於在 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的一種方法是通過自定義[終止消息](https://kubernetes.io/docs/tasks/debug/debug-application/determine-reason-pod-failure/)來提高MTTR，這使您能夠提供有關為什麼Pod被終止的更具體和相關的信息。這可以幫助您快速識別和解決問題，提高Kubernetes環境的整體可靠性和性能

早期檢測問題的一種方法是通過監視 **kube_pod_status_phase** 和 **kube_pod_status_reason** 指標，這些指標可以在 Kube State Metrics - [Pod Metrics](https://github.com/kubernetes/kube-state-metrics/blob/main/docs/pod-metrics.md) 中找到。這些指標可以提供有關您的 pod 的狀態和健康情況的有價值見解，幫助您快速識別和解決可能出現的任何問題。


使用 'Kubectl describe pods' 的範例如 'kubectl' 快捷表中所述
[cheatsheet](https://kubernetes.io/docs/reference/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](https://coredns.io/plugins/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](https://kubernetes.io/docs/reference/using-api/health-checks/)端點。
您可以通過運行以下命令獲取有關 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上[註冊免費帳戶](https://newrelic.com/signup)即可開始！您的帳戶包括每月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://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://sre.google/sre-book/monitoring-distributed-systems/)

[https://kubernetes.io/docs/concepts/overview/components](https://kubernetes.io/docs/concepts/overview/components/)

[https://kubernetes.io/docs/concepts/storage/persistent-volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)

[https://kubernetes.io/docs/concepts/workloads/controllers/replicaset](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/)

[https://kubernetes.io/docs/concepts/cluster-administration/system-metrics](https://kubernetes.io/docs/concepts/cluster-administration/system-metrics/)