Kubernetes集羣的監控報警策略最佳實踐

版權聲明：本文爲博主原創文章，未經博主贊成不得轉載。 https://blog.csdn.net/M2l0ZgSsVc7r69eFdTj/article/details/79652064

本文爲Kubernetes監控系列的第二篇文章。系列文件夾例如如下：

1. Kubernetes監控開源工具基本介紹以及怎樣使用Sysdig進行監控

2. Kubernetes集羣的監控報警策略最佳實踐（本篇）

3. Kubernetes中的服務發現與故障排除（敬請期待）

4. Docker與Kubernetes在WayBlazer的使用案例（敬請期待）

本文將介紹關於怎樣在Kubernetes集羣中配置基礎設施層的警報。本文是關於在生產中使用Kubernetes系列的一部分。 第一部分介紹了Kubernetes和監控工具的基礎知識；這部分涵蓋了Kubernetes報警的最佳實踐，第三部分將介紹Kubernetes服務發現與故障排除，最後一部分是監控Kubernetes的實際使用案例。
監控是每個優質基礎設施的基礎，是達到可靠性層次的基礎。

監控有助於下降對突發事件的響應時間，實現對系統問題的檢測、故障排除和調試。

在基礎設施高度動態的雲時代。監控也是容量規劃的基礎。

有效的警報是監控策略的基石。當你轉向容器和Kubernetes編排環境，你的警報策略也需要演進。正是因爲下面幾個核心緣由。當中不少咱們在"怎樣監視Kubernetes"中進行了講述：

• 可見性：容器是一個黑盒。

  傳統工具僅僅能針對公共監控端點進行檢查。假設想深刻監控相關服務，則需要採取不同的方法。

  
  

• 新的基礎架構層：現在服務和主機之間有一個新的層：容器和容器編排服務。

  這些是你需要監控的新內部服務，你的監控系統需要了解這些服務。

  
  

• 動態重調度：容器沒有像以前那樣的服務節點。因此傳統的監控不能有效地工做。沒有獲取服務度量標準的靜態端點，沒有執行服務實例的靜態數量（設想一個金絲雀公佈或本身主動伸縮設置）。在某節點中一個進程被kill是正常的。因爲它有很是大的機會被又一次調度到基礎設施的其它節點。

  
  

• 元數據和標籤：隨着服務跨多個容器，爲所有這些服務加入系統級別的監控以及服務特定的度量標準，再加上Kubernetes帶來的所有新服務。怎樣讓所有這些信息對咱們有所幫助？有時你但願看到分佈在不一樣節點容器中的服務的網絡請求度量，有時你但願看到特定節點中所有容器的一樣度量。而不關心它們屬於哪一個服務。這就需要一個多維度量系統，需要從不一樣的角度來看待這些指標。假設經過Kubernetes中存在的不一樣標籤本身主動標記度量標準，並且監控系統可以瞭解Kubernetes元數據，那麼僅僅需要在每種狀況下依照需要聚合和切割度量標準就可以實現多維度度量。

考慮到這些問題。讓咱們建立一組對Kubernetes環境相當重要的報警策略。

咱們的Kubernetes報警策略教程將涵蓋：

• 應用程序層度量標準的報警

• Kubernetes上執行的服務的報警

• Kubernetes基礎設施的報警

• 在主機/節點層上的報警

最後咱們還將經過檢測系統調用問題來了解怎樣經過報警加速故障排除。

應用程序層度量標準的報警

工做指標（working metrics）可以確認應用程序是否按預期執行。這些度量標準一般來自用戶或消費者對服務的指望操做。或者是由應用程序經過statsd或JMX在內部生成。假設監控系統自己提供網絡數據，就可以使用它來建立基於響應時間的報警策略。

下面演示樣例是一個公共REST API端點監控警報，監控prod命令空間中的名爲javaapp的deployment，在10分鐘內假設延遲超過1秒則報警。

所有這些報警高度依賴於應用程序、工做負載模式等等，但真正的問題是怎樣在所有服務中一致性地獲取數據。

在理想環境中，除了核心監控工具以外。無需再購買綜合監控服務就能夠得到這一套關鍵指標。
這個類別中經常出現的一些指標和報警是：

• 服務對應時間

• 服務可用性

• SLA合規性

• 每秒請求的成功/失敗數

Kubernetes上執行的服務的報警

對於服務級別，和使用Kubernetes以前對於服務集羣需要作的事情應該沒什麼不一樣。試想下。當在MySQL/MariaDB或者MongoDB等數據庫服務中查看副本狀態與延遲時。需要考慮些什麼？
沒錯。假設想知道服務的全局執行和執行狀況，就需要利用監視工具功能依據容器元數據將度量標準進行聚合和分段。
如 第一篇文章所述。Kubernetes將容器標記爲一個deployment或者經過一個service進行暴露，在定義報警時就需要考慮這些因素。好比針對生產環境的報警（可能經過命名空間進行定義）。
下面是Cassandra集羣的演示樣例：

假設咱們在Kubernetes、AWS EC2或OpenStack中執行Cassandra。則衡量指標cassandra.compactions.pending存在每個實例上，但是現在咱們要查看在prod命名空間內的cassandra複製控制器中聚合的指標。這兩個標籤都來自Kubernetes，但咱們也可以更改範圍，包含來自AWS或其它雲提供商的標籤，好比可用區域。

這個類別中經常出現的一些指標和警報是：

• HTTP請求數

• 數據庫鏈接數、副本數

• 線程數、文件描寫敘述符數、鏈接數

• 中間件特定指標：Python uwsgi worker數量。JVM堆大小等

另外，假設正在使用外部託管服務。則很是可能需要從這些提供程序導入度量標準。因爲它們可能還有需要作出反應的事件。

 

Kubernetes基礎設施的報警

在容器編排層面的監控和報警有兩個層面。一方面，咱們需要監控Kubernetes所處理的服務是否符合所定義的要求。還有一方面。咱們需要確保Kubernetes的所有組件都正常執行。
由Kubernetes處理的服務
1.1 是否有足夠的Pod/Container給每個應用程序執行？
Kubernetes可以經過Deployments、Replica Sets和Replication Controllers來處理具備多個Pod的應用程序。它們之間差異比較小。可以使用它們來維護執行一樣應用程序的多個實例。執行實例的數量可以動態地進行伸縮，甚至可以經過本身主動縮放來實現本身主動化。
執行容器數量可能發生變化的緣由有多種：因爲節點失敗或資源不足將容器又一次調度到不一樣主機或者進行新版本號的滾動部署等。假設在延長的時間段內執行的副本數或實例的數量低於咱們所需的副本數，則表示某些組件工做不正常（缺乏足夠的節點或資源、Kubernetes或Docker Engine故障、Docker鏡像損壞等等）。
在Kubernetes部署服務中。跨多個服務進行例如如下報警策略對照是很是有必要的：

timeAvg(kubernetes.replicaSet.replicas.running) < timeAvg(kubernetes.replicaSet.replicas.desired)

正如以前所說，在又一次調度與遷移過程執行中的實例副本數少於預期是可接受的。因此對每個容器需要關注配置項 .spec.minReadySeconds （表示容器從啓動到可用狀態的時間）。你可能也需要檢查 .spec.strategy.rollingUpdate.maxUnavailable 配置項，它定義了在滾動部署期間有多少容器可以處於不可用狀態。
下面是上述報警策略的一個演示樣例，在 wordpress 命名空間中集羣 kubernetes-dev 的一個deployment wordpress-wordpress。

1.2 是否有給定應用程序的不論什麼Pod/Container？
與以前的警報類似。但具備更高的優先級（好比，這個應用程序是半夜獲取頁面的備選對象）。將提醒是否沒有爲給定應用程序執行容器。
下面演示樣例，在一樣的deployment中添加警報，但不一樣的是1分鐘內執行Pod <1時觸發：

1.3 從新啓動循環中是否有不論什麼Pod/Container？
在部署新版本號時。假設沒有足夠的可用資源，或者僅僅是某些需求或依賴關係不存在，容器或Pod終於可能會在循環中持續又一次啓動。這樣的狀況稱爲「CrashLoopBackOff」。發生這樣的狀況時，Pod永遠不會進入就緒狀態，從而被視爲不可用，並且不會處於執行狀態，所以，這樣的場景已被報警覆蓋。雖然如此。筆者仍但願設置一個警報，以便在整個基礎架構中捕捉到這樣的行爲。立刻了解詳細問題。這不是那種中斷睡眠的報警，但會有很多實用的信息。
這是在整個基礎架構中應用的一個演示樣例，在過去的2分鐘內檢測到4次以上的又一次啓動：

監控Kubernetes系統服務
除了確保Kubernetes能正常完畢其工做以外。咱們還但願監測Kubernetes的內部健康情況。這將取決於Kubernetes集羣安裝的不一樣組件。因爲這些可能會依據不一樣部署選擇而改變，但有一些基本組件是一樣的。
2.1 etcd是否正常執行？
etcd是Kubernetes的分佈式服務發現、通訊、命令通道。監控etcd可以像監控不論什麼分佈式鍵值數據庫同樣深刻，但會使事情變得簡單。

咱們可以進一步去監控設置命令失敗或者節點數，但是咱們將會把它留給將來的etcd監控文章來描寫敘述。
2.2 集羣中有足夠的節點嗎？
節點故障在Kubernetes中不是問題。調度程序將在其它可用節點中生成容器。

但是，假設咱們耗盡節點呢？或者已部署的應用程序的資源需求超過了現有節點？或者咱們達到配額限制？
在這樣的狀況下發出警報並不easy，因爲這取決於你想要在待機狀態下有多少個節點，或者你想要在現有節點上推送多少超額配置。可以使用監控度量值kube_node_status_ready和kube_node_spec_unschedulable進行節點狀態警報。
假設要進行容量級別報警，則必須將每個已調度Pod請求的CPU和memory進行累加。而後檢查是否會覆蓋每個節點，使用監控度量值kube_node_status_capacity_cpu_cores和kube_node_status_capacity_memory_bytes。

在主機/節點層上的報警

主機層的警報與監視虛擬機或物理機差異不大。主要是關於主機是啓動仍是關閉或不可訪問狀態。以及資源可用性（CPU、內存、磁盤等）。
主要差異是現在警報的嚴重程度。

在此以前。系統服務宕機可能意味着你的應用程序中止執行並且要緊急處理事故（禁止有效的高可用性）。而對於Kubernetes來講當服務發生異常，服務可以在主機之間移動。主機警報不該該不受重視。
讓咱們看看咱們應該考慮的幾個方面：

1. 主機宕機
假設主機停機或沒法訪問，咱們但願收到通知。

咱們將在整個基礎架構中應用此單一警報。咱們打算給它一個5分鐘的等待時間。因爲咱們不想看到網絡鏈接問題上的嘈雜警報。

你可能但願將其下降到1或2分鐘，詳細取決於你但願接收通知的速度。

2. 磁盤利用率
這是略微複雜一些的警報。咱們在整個基礎架構的所有文件系統中應用此警報。咱們將範圍設置爲 everywhere，並針對每個 fs.mountDir 設置單獨的評估/警報。
下面是超過80％使用率的通用警報。但你可能需要不一樣的策略。如具備更高閾值（95％）或不一樣閾值的更高優先級警報（詳細取決於文件系統）。

假設要爲不一樣的服務或主機建立不一樣的閾值。僅僅需更改要應用特定閾值的範圍。
3. 一些其它資源
此類別中的常見資源是有關負載、CPU使用率、內存和交換空間使用狀況的警報。假設在必定的時間內這些數據中的不論什麼一個顯著提高，可能就需要警報提醒您。

咱們需要在閾值、等待時間以及怎樣斷定噪聲警報之間進行折中。

假設您想爲這些資源設置指標。請參考下面指標：

• 負載：load.average.1m, load.average.5m 和 load.average.15m

• CPU：cpu.used.percent

• memory：memory.used.percent 或 memory.bytes.used

• swap：memory.swap.used.percent 或 memory.swap.bytes.used

一些人一樣使用這個類別監控他們部分基礎架構所在雲服務提供商的資源。

Sysdig額外監控：監控系統調用

從警報觸發並收到通知的那一刻起，真正的工做就開始爲DevOps值班成員開展工做。有時執行手冊就像檢查工做負載中的輕微異常同樣簡單。

這多是雲提供商的一個事件，但但願Kubernetes正在處理這個問題，並且僅僅需要花費一些時間來應對負載。
但是假設一些更棘手的問題出現在咱們面前。咱們可以看到咱們擁有的所有武器：提供者狀態頁面、日誌（但願來自中心位置）、不論什麼形式的APM或分佈式追蹤（假設開發者安裝了代碼或者外部綜合監測）。而後，咱們祈禱這一事件在這些地方留下了一些線索。以便咱們可以追溯到問題出現的多種來源緣由。
咱們怎麼可以在警報被解除時本身主動dump所有系統調用？系統調用是所發生事情的真實來源，並將包含咱們可以得到的所有信息。經過系統調用有可能發現觸發警報的根本問題所在。Sysdig Monitor贊成在警報觸發時本身主動開始捕獲所有系統調用。

好比，可以配置CrashLoopBackOff場景：

僅僅有當你安裝代碼後。Sysdig Monitor代理才幹從系統調用攔截中計算出來對應的指標。

考慮HTTP響應時間或SQL響應時間。Sysdig Monitor代理程序在套接字上捕獲read()和write()系統調用。解碼應用程序協議並計算轉發到咱們時間序列數據庫中的指標。這樣作的優勢是可以在不觸及開發者代碼的狀況下得到儀表盤數據和警報：

結論

咱們已經看到怎樣使用容器編排平臺來添加系統中移動部分的數量。擁有容器本地監控是創建可靠基礎架構的關鍵要素。監控不能僅僅關注基礎架構。而是需要從底層的主機到應用程序指標所在的頂端來了解整個技術棧。

可以利用Kubernetes和雲服務提供商的元數據信息來彙總和細分監控指標和警報將成爲多層次有效監控的必要條件。咱們已經看到怎樣使用標籤來更新咱們已有的警報或建立Kubernetes上所需的新警報。
接下來，讓咱們看看在Kubernetes編排環境中的典型服務發現故障排除的挑戰。


原文連接：https://sysdig.com/blog/alerting-kubernetes/

深刻淺出Kubernetes及企業AI平臺落地實踐培訓

本次培訓內容包含：容器原理、Docker架構、工做原理、網絡方案、存儲方案、Harbor、Kubernetes架構、組件、核心機制、插件、核心模塊、監控、日誌、二次開發、TensorFlow架構、工做原理、注意事項以及實踐經驗等，點擊識別下方二維碼加微信好友瞭解 詳細培訓內容。
4月20日正式上課，點擊閱讀原文連接就能夠報名。