一、Kubernetes介紹
Kubernetes（K8s）是一個開源平台，能夠有效簡化應用管理、應用部署和應用擴展環節的手動操作流程，讓用戶更加靈活地部署管理雲端應用。
作為可擴展的容錯平台，K8s幾乎能夠部署在所有基礎設施中，與Google Cloud、MS Azure及AWS等公有雲、私有雲、混合雲、服務器集群、數據中心等完美兼容。Kubernetes最大的亮點在於支持容器自動部署和自動復制。這也是大量雲端微服務基礎設施部署在K8s上的原因。
二、K8s由來
K8s最初是由Google工程師設計開發的，於2014年上線並開源，目前由來自微軟、紅帽、IBM及Docker等軟件巨頭的社區貢獻者維護升級。
Google不僅開源了公司整個基礎設施在容器中的運行方式，還積極開發Linux容器技術，支撐Google所有雲服務。K8s是基於雲平台15年的生產工作負載運行經驗設計出來的，用於處理成千上萬個容器。Google每周部署20多億個容器。在K8s上線前，Google主要通過內部開發平台Borg進行容器部署。Borg是大型內部集群管理系統，運行了無數應用和集群任務，多年的開發經驗奠定了K8s技術的基礎。
三、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實現了對單體應用、批處理應用及高度分布式微服務應用等不同應用架構的支持。
四、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數據的集群，這樣能夠保證在創建監控事件、檢索監控數據時，主要實例的性能不受影響。
五、從源頭上監控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智能運維