一、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智慧運維