阿里雲容器Kubernetes監控(一) - 資源監控

摘要：容器經過集裝箱式的編譯、打包、部署，大大提升了應用的迭代速度。對於架構師而言，容器帶來的是分鐘級的部署、秒級的伸縮與恢復、一個量級的迭代速度提高、50%左右的基礎成本節省。

 

簡介

 

容器經過集裝箱式的編譯、打包、部署，大大提升了應用的迭代速度。對於架構師而言，容器帶來的是分鐘級的部署、秒級的伸縮與恢復、一個量級的迭代速度提高、50%左右的基礎成本節省。可是對於落地實施容器的開發者而言。80%的工做處理的是容器前和容器後的問題，容器前指的是如何本地開發、集成、測試並部署到容器環境；而容器後指的是如何對部署到容器環境後的監控、運維、告警與調優。今天咱們主要來探討的是如何在容器的環境中進行資源維度的監控。

 

先談容器與監控

 

關於容器的監控方案有很是多的種類，你們耳熟能詳的一些組件包括：prometheus、Telegraf、InfluxDB、Cadvisor、Heapster等等。可是從原理上來說無外乎分爲推模式採集與拉模式採集。推模式採集是指經過部署相應的agent，將監控的指標推送到server再進行數據聚合和報警的方式，例如Telegraf就是這種模式的表明。拉模式採集是指經過中心化的server使用API或者腳本等方式從容器直接拉取資源利用率的方式，而prometheus則是這種方式的集大成者。和傳統應用監控相比，容器監控面臨更大的挑戰：首先因爲容器更多的是在資源池中調度，傳統的靜態配置化的監控agent就變得很是麻煩，若是隻在宿主機部署監控agent則會形成缺少必要信息來識別監控對象；其次容器的生命週期與傳統應用相比而言會更加短暫，而由容器抽象的上層概念例如swarm mode中的service或者kubernetes中的ReplicaSet、Deployment等等則沒有太好的辦法從採集的數據中進行反向的抽象，形成單純的容器監控數據沒法有效的進行監控數據的聚合和告警，一旦應用的發佈可能會致使原有的監控與報警規則沒法生效；最後容器的監控須要更多的維度，資源維度、邏輯資源的維度、應用的維度等等。

 

如何在容器服務上進行資源監控

 

其實容器之因此難以監控的主要緣由在於沒法將邏輯的概念和物理概念沒法在監控數據、生命週期上面實現統一。阿里雲容器服務Kubernetes與雲監控進行了深度集成，用應用分組來抽象邏輯概念，今天咱們來看下如何進行Kuberbetes的資源監控和告警。

 

首先Kubernetes節點從職能上分爲Worker和Master兩種不一樣的節點。Master節點上面一般會部署管控類型的應用，總體的資源要求以強魯棒性爲主；而Worker節點更多的承擔實際的Pod調度，總體的資源以調度能力爲主。當你建立一個Kubernetes集羣時，容器服務會爲你自動建立兩個資源分組，一個是Master組，一個是Worker組。Master組中包含了Master節點以及與其相關的負載均衡器。Worker組包含了全部的工做節點。

 

 

能夠經過點擊列表視圖顯示當前資源分組中的資源，例如本例中Master分組包含了三個Master節點以及2個SLB。另外任何在資源組下的資源的報警規則都會被自動繼承，所以在拓撲總覽頁面便可看到全部資源的健康狀態。

 

 

在監控視圖中能夠詳細的在組級別以及實例級別查看詳細的監控數據

 

 

對於Mater節點而言，其上運行的各類組件的健康狀態是更加劇要的，所以在Master分組中設置了全部節點的核心組件的健康檢查，健康檢查狀態出現問題時便可經過釘釘、郵件、短信的方式在第一件獲取到Kubernetes的集羣狀態。

 

 

對於版本在1.8.4及以上的老集羣而言，能夠經過升級監控服務的方式快速創建資源報警分組。對於資源組中的資源能夠經過新建報警規則的方式設置自定義的報警，而報警規則會自動應用到資源組中，且在集羣自動伸縮等場景也會自動添加。

 

 

最後

 

本片文章咱們講解了如何如何經過資源分組進行監控與告警，針對kubernetes的pod、service的監控也即將在4月份進行發佈，盡請期待。

 

原文連接

閱讀更多幹貨好文，請關注掃描如下二維碼：