Kubernetes監控實踐

1、Kubernetes介紹

Kubernetes（K8s）是一個開源平臺，可以有效簡化應用管理、應用部署和應用擴展環節的手動操做流程，讓用戶更加靈活地部署管理雲端應用。

做爲可擴展的容錯平臺，K8s幾乎可以部署在全部基礎設施中，與Google Cloud、MS Azure及AWS等公有云、私有云、混合雲、服務器集羣、數據中心等完美兼容。Kubernetes最大的亮點在於支持容器自動部署和自動複製。這也是大量雲端微服務基礎設施部署在K8s上的緣由。

2、K8s由來

K8s最初是由Google工程師設計開發的，於2014年上線並開源，目前由來自微軟、紅帽、IBM及Docker等軟件巨頭的社區貢獻者維護升級。

Google不只開源了公司整個基礎設施在容器中的運行方式，還積極開發Linux容器技術，支撐Google全部雲服務。K8s是基於雲平臺15年的生產工做負載運行經驗設計出來的，用於處理成千上萬個容器。Google每週部署20多億個容器。在K8s上線前，Google主要經過內部開發平臺Borg進行容器部署。Borg是大型內部集羣管理系統，運行了無數應用和集羣任務，多年的開發經驗奠基了K8s技術的基礎。

3、K8s工做原理

K8s本質上是分部在不一樣機器上的容器化應用的協調系統，目的是幫助開發人員經過K8s的可預測性、可擴展性和高可用性管理容器化應用和服務的整個生命週期，經過更高水平的抽象，將多個機器統一成一個機器。這對於大型環境的運行來講相當重要。

K8s不只可以優化Docker的鏡像運行能力和容器管理能力，還能兼容rkt和CoreOS等容器引擎。

上方架構圖展現了K8s工做原理。圖中包含一組Master組件，其中包括不少pod。Pod針對特定應用的「邏輯主機」進行建模。每一個Pod均包含一個或多個應用容器、存儲資源、惟一的網絡IP及容器運行細節。Pod是容器的最小原子單元。理論上，Pod中包含一個或多個高度耦合的應用。理想狀況下，每一個Pod中包含一個容器。

每一個進程包含一個API server、一個scheduler和多個controller。

API server負責暴露K8s API、處理REST操做及後續更新。Scheduler負責將未部署的Pod匹配到合適虛擬機或物理機上。若是沒有合適的機器，則Pod將處於未分配狀態，直至出現合適的節點。Master運行集羣級別的其餘功能，經過嵌入式controller完成建立端點、發現節點、複製控制等操做。因爲controller設計靈活且可擴展，Kube管理員可自行建立controller。Kube經過API server監控K8s集羣的共享狀態，並對集羣狀態進行調整，確保當前狀態與理想狀態一致。

K8s提供支持容器化應用統一自動化、控制和升級的各項功能，包括企業級容器部署、內置服務發現、自動擴展、持久化存儲、高可用、集羣互通和資源裝箱等。

依賴這些功能，K8s實現了對單體應用、批處理應用及高度分佈式微服務應用等不一樣應用架構的支持。

4、K8s監控實踐中的挑戰

2014年上線以來，K8s一直在變革容器技術，已經成爲快速批量啓動應用的關鍵工具。與此同時，挑戰也隨之而來，容器編排極其複雜。

K8s雖然已經極大地簡化了容器實現和管理過程當中從調度、配置到狀態自動維護等一系列任務的操做難度，但監控方面依然存在挑戰：

• 相互通訊的應用分佈在不一樣的雲服務平臺上。K8s本質上是一個通用平臺，用戶可在平臺上自由部署應用。企業通常會採用多雲端解決方案，不只可以減小對單一雲服務平臺的依賴，還能縮短故障停機時間，避免數據丟失。但這種部署方式也給實時數據抓取和應用狀態監控帶來了挑戰。

• 在動態基礎設施上不斷遷移應用。因爲應用處於頻繁遷移狀態，所以很難作到全部平臺和協議之間的徹底可見，這就會隱藏系統的瓶頸問題。不少公司的基礎設施上都運行着多個應用，所以這種問題是不可避免的。若是沒有穩健的監控系統，用戶便沒法發現應用的潛在問題。

• 監控對象數量繁多且極爲複雜：K8s由不少組件構成，很是複雜，所以要監控K8s，就必須監控下列全部對象：

  • 集羣容量和資源利用狀況：（a）Node：確保K8s全部節點的狀態，監控CPU、內存和硬盤的使用狀況；（b）Pod：確保全部已實現Pod狀態正常；（c）Container：根據配置的消耗上限監控CPU和內存的消耗狀況。 應用：根據請求率、吞吐量、錯誤率監控集羣中應用的性能和可用性。
  • 終端用戶體驗：監控移動應用和瀏覽器性能，優化加載時間和可用性，提升客戶滿意度。
  • 配套基礎設施：前文提到，K8s的運行平臺也很是重要。

• 操做細節：K8s的全部核心組件（即kubelet、Kube controller manager和Kube scheduler）都有不少標記。這些標記決定了集羣的操做和運行方式，其初始默認值通常較小，適用於規模較小的集羣。隨着集羣規模的擴大，用戶須要及時對集羣進行調整，並監控K8s的標籤和註釋等細節。

但監控工具從K8s抓取大量數據時會影響集羣性能甚至致使集羣故障，所以須要肯定監控基線。須要診斷故障時，可適當調高基線值。

調高基線值的同時要部署更多master和node，提升可用性。涉及大規模部署時，可單獨部署專門存儲K8s數據的集羣，這樣可以保證在建立監控事件、檢索監控數據時，主要實例的性能不受影響。

5、從源頭上監控K8s

和不少容器編排平臺同樣，K8s具有基本的服務器監控工具。用戶可對這些工具進行適當調整，以便更好地監控K8s的運行狀況。主要工具以下：

• K8s儀表盤：插件工具，展現每一個K8s集羣上的資源利用狀況，也是實現資源和環境管理與交互的主要工具。
• 容器探針：容器健康狀態診斷工具。
• Kubelet：每一個Node上都運行着Kubelet，監控容器的運行狀況。Kubelet也是Master與各個Node通訊的渠道。Kubelet可以直接暴露cAdvisor中與容器使用相關的個性化指標數據。
• cAdvisor：開源的單節點agent，負責監控容器資源使用狀況與性能，採集機器上全部容器的內存、網絡使用狀況、文件系統和CPU等數據。
• cAdvisor簡單易用，但也存在不足：一是僅能監控基礎資源利用狀況，沒法分析應用的實際性能；二是不具有長期存儲和趨勢分析能力。
• Kube-state-metrics：輪詢Kubernetes API，並將Kubernetes的結構化信息轉換爲metrics。
• Metrics server：Metrics server定時從Kubelet的Summary API採集指標數據，並以metric-api的形式暴露出去。

總體監控流程以下：

• cAdvisor默認安裝在全部集羣節點上，採集容器和節點的指標數據。
• Kubelet經過kubelet API將指標數據暴露出去。
• Metrics判斷全部可用節點，請求kubelet API上送容器和節點使用狀況數據，而後經過Kubernetes聚合API將指標數據暴露出去。

上述基礎性工具雖然不能提供詳細的應用監控數據，但可以幫助用戶瞭解底層主機和K8s節點的狀況。

通常來講，K8s集羣管理員主要關注全局監控，而應用開發人員則主要關注應用層面的監控狀況。但二者的共同訴求都是在控制投入成本的前提下儘量全面地監控系統、採集數據。下週文章中，咱們將介紹兩個可行的監控方案：Prometheus和Sensu。兩個方案都能全面提供系統級的監控數據，幫助開發人員跟蹤K8s關鍵組件的性能、定位故障、接收預警。

本篇爲譯文

原文做者：STEFAN THORPE

譯自Monitoring Kubernetes

譯文首發於UAVStack智能運維