Kubernetes監(jiān)控實(shí)踐

一、Kubernetes介紹

Kubernetes（K8s）是一個(gè)開源平臺(tái)，能夠有效簡(jiǎn)化應(yīng)用管理、應(yīng)用部署和應(yīng)用擴(kuò)展環(huán)節(jié)的手動(dòng)操作流程，讓用戶更加靈活地部署管理云端應(yīng)用。

作為可擴(kuò)展的容錯(cuò)平臺(tái)，K8s幾乎能夠部署在所有基礎(chǔ)設(shè)施中，與Google Cloud、MS Azure及AWS等公有云、私有云、混合云、服務(wù)器集群、數(shù)據(jù)中心等完美兼容。Kubernetes最大的亮點(diǎn)在于支持容器自動(dòng)部署和自動(dòng)復(fù)制。這也是大量云端微服務(wù)基礎(chǔ)設(shè)施部署在K8s上的原因。

二、K8s由來

K8s最初是由Google工程師設(shè)計(jì)開發(fā)的，于2014年上線并開源，目前由來自微軟、紅帽、IBM及Docker等軟件巨頭的社區(qū)貢獻(xiàn)者維護(hù)升級(jí)。

Google不僅開源了公司整個(gè)基礎(chǔ)設(shè)施在容器中的運(yùn)行方式，還積極開發(fā)Linux容器技術(shù)，支撐Google所有云服務(wù)。K8s是基于云平臺(tái)15年的生產(chǎn)工作負(fù)載運(yùn)行經(jīng)驗(yàn)設(shè)計(jì)出來的，用于處理成千上萬個(gè)容器。Google每周部署20多億個(gè)容器。在K8s上線前，Google主要通過內(nèi)部開發(fā)平臺(tái)Borg進(jìn)行容器部署。Borg是大型內(nèi)部集群管理系統(tǒng)，運(yùn)行了無數(shù)應(yīng)用和集群任務(wù)，多年的開發(fā)經(jīng)驗(yàn)奠定了K8s技術(shù)的基礎(chǔ)。

三、K8s工作原理

K8s本質(zhì)上是分部在不同機(jī)器上的容器化應(yīng)用的協(xié)調(diào)系統(tǒng)，目的是幫助開發(fā)人員通過K8s的可預(yù)測(cè)性、可擴(kuò)展性和高可用性管理容器化應(yīng)用和服務(wù)的整個(gè)生命周期，通過更高水平的抽象，將多個(gè)機(jī)器統(tǒng)一成一個(gè)機(jī)器。這對(duì)于大型環(huán)境的運(yùn)行來說至關(guān)重要。

K8s不僅能夠優(yōu)化Docker的鏡像運(yùn)行能力和容器管理能力，還能兼容rkt和CoreOS等容器引擎。

上方架構(gòu)圖展示了K8s工作原理。圖中包含一組Master組件，其中包括很多pod。Pod針對(duì)特定應(yīng)用的“邏輯主機(jī)”進(jìn)行建模。每個(gè)Pod均包含一個(gè)或多個(gè)應(yīng)用容器、存儲(chǔ)資源、唯一的網(wǎng)絡(luò)IP及容器運(yùn)行細(xì)節(jié)。Pod是容器的最小原子單元。理論上，Pod中包含一個(gè)或多個(gè)高度耦合的應(yīng)用。理想情況下，每個(gè)Pod中包含一個(gè)容器。

每個(gè)進(jìn)程包含一個(gè)API server、一個(gè)scheduler和多個(gè)controller。

API server負(fù)責(zé)暴露K8s API、處理REST操作及后續(xù)更新。Scheduler負(fù)責(zé)將未部署的Pod匹配到合適虛擬機(jī)或物理機(jī)上。如果沒有合適的機(jī)器，則Pod將處于未分配狀態(tài)，直至出現(xiàn)合適的節(jié)點(diǎn)。Master運(yùn)行集群級(jí)別的其他功能，通過嵌入式controller完成創(chuàng)建端點(diǎn)、發(fā)現(xiàn)節(jié)點(diǎn)、復(fù)制控制等操作。由于controller設(shè)計(jì)靈活且可擴(kuò)展，Kube管理員可自行創(chuàng)建controller。Kube通過API server監(jiān)控K8s集群的共享狀態(tài)，并對(duì)集群狀態(tài)進(jìn)行調(diào)整，確保當(dāng)前狀態(tài)與理想狀態(tài)一致。

K8s提供支持容器化應(yīng)用統(tǒng)一自動(dòng)化、控制和升級(jí)的各項(xiàng)功能，包括企業(yè)級(jí)容器部署、內(nèi)置服務(wù)發(fā)現(xiàn)、自動(dòng)擴(kuò)展、持久化存儲(chǔ)、高可用、集群互通和資源裝箱等。

依賴這些功能，K8s實(shí)現(xiàn)了對(duì)單體應(yīng)用、批處理應(yīng)用及高度分布式微服務(wù)應(yīng)用等不同應(yīng)用架構(gòu)的支持。

四、K8s監(jiān)控實(shí)踐中的挑戰(zhàn)

2014年上線以來，K8s一直在變革容器技術(shù)，已經(jīng)成為快速批量啟動(dòng)應(yīng)用的關(guān)鍵工具。與此同時(shí)，挑戰(zhàn)也隨之而來，容器編排極其復(fù)雜。

K8s雖然已經(jīng)極大地簡(jiǎn)化了容器實(shí)現(xiàn)和管理過程中從調(diào)度、配置到狀態(tài)自動(dòng)維護(hù)等一系列任務(wù)的操作難度，但監(jiān)控方面依然存在挑戰(zhàn)：

• 相互通信的應(yīng)用分布在不同的云服務(wù)平臺(tái)上。K8s本質(zhì)上是一個(gè)通用平臺(tái)，用戶可在平臺(tái)上自由部署應(yīng)用。企業(yè)一般會(huì)采用多云端解決方案，不僅能夠減少對(duì)單一云服務(wù)平臺(tái)的依賴，還能縮短故障停機(jī)時(shí)間，避免數(shù)據(jù)丟失。但這種部署方式也給實(shí)時(shí)數(shù)據(jù)抓取和應(yīng)用狀態(tài)監(jiān)控帶來了挑戰(zhàn)。
• 在動(dòng)態(tài)基礎(chǔ)設(shè)施上不斷遷移應(yīng)用。由于應(yīng)用處于頻繁遷移狀態(tài)，因此很難做到所有平臺(tái)和協(xié)議之間的完全可見，這就會(huì)隱藏系統(tǒng)的瓶頸問題。很多公司的基礎(chǔ)設(shè)施上都運(yùn)行著多個(gè)應(yīng)用，因此這種問題是不可避免的。如果沒有穩(wěn)健的監(jiān)控系統(tǒng)，用戶便無法發(fā)現(xiàn)應(yīng)用的潛在問題。

• 監(jiān)控對(duì)象數(shù)量繁多且極為復(fù)雜：K8s由很多組件構(gòu)成，非常復(fù)雜，因此要監(jiān)控K8s，就必須監(jiān)控下列所有對(duì)象：

  • 集群容量和資源利用情況：（a）Node：確保K8s所有節(jié)點(diǎn)的狀態(tài)，監(jiān)控CPU、內(nèi)存和硬盤的使用情況；（b）Pod：確保所有已實(shí)現(xiàn)Pod狀態(tài)正常；（c）Container：根據(jù)配置的消耗上限監(jiān)控CPU和內(nèi)存的消耗情況。 應(yīng)用：根據(jù)請(qǐng)求率、吞吐量、錯(cuò)誤率監(jiān)控集群中應(yīng)用的性能和可用性。
  • 終端用戶體驗(yàn)：監(jiān)控移動(dòng)應(yīng)用和瀏覽器性能，優(yōu)化加載時(shí)間和可用性，提高客戶滿意度。
  • 配套基礎(chǔ)設(shè)施：前文提到，K8s的運(yùn)行平臺(tái)也非常重要。

• 操作細(xì)節(jié)：K8s的所有核心組件（即kubelet、Kube controller manager和Kube scheduler）都有很多標(biāo)記。這些標(biāo)記決定了集群的操作和運(yùn)行方式，其初始默認(rèn)值一般較小，適用于規(guī)模較小的集群。隨著集群規(guī)模的擴(kuò)大，用戶需要及時(shí)對(duì)集群進(jìn)行調(diào)整，并監(jiān)控K8s的標(biāo)簽和注釋等細(xì)節(jié)。

但監(jiān)控工具從K8s抓取大量數(shù)據(jù)時(shí)會(huì)影響集群性能甚至導(dǎo)致集群故障，因此需要確定監(jiān)控基線。需要診斷故障時(shí)，可適當(dāng)調(diào)高基線值。

調(diào)高基線值的同時(shí)要部署更多master和node，提高可用性。涉及大規(guī)模部署時(shí)，可單獨(dú)部署專門存儲(chǔ)K8s數(shù)據(jù)的集群，這樣能夠保證在創(chuàng)建監(jiān)控事件、檢索監(jiān)控?cái)?shù)據(jù)時(shí)，主要實(shí)例的性能不受影響。

五、從源頭上監(jiān)控K8s

和很多容器編排平臺(tái)一樣，K8s具備基本的服務(wù)器監(jiān)控工具。用戶可對(duì)這些工具進(jìn)行適當(dāng)調(diào)整，以便更好地監(jiān)控K8s的運(yùn)行情況。主要工具如下：

• K8s儀表盤：插件工具，展示每個(gè)K8s集群上的資源利用情況，也是實(shí)現(xiàn)資源和環(huán)境管理與交互的主要工具。
• 容器探針：容器健康狀態(tài)診斷工具。
• Kubelet：每個(gè)Node上都運(yùn)行著Kubelet，監(jiān)控容器的運(yùn)行情況。Kubelet也是Master與各個(gè)Node通信的渠道。Kubelet能夠直接暴露cAdvisor中與容器使用相關(guān)的個(gè)性化指標(biāo)數(shù)據(jù)。
• cAdvisor：開源的單節(jié)點(diǎn)agent，負(fù)責(zé)監(jiān)控容器資源使用情況與性能，采集機(jī)器上所有容器的內(nèi)存、網(wǎng)絡(luò)使用情況、文件系統(tǒng)和CPU等數(shù)據(jù)。
• cAdvisor簡(jiǎn)單易用，但也存在不足：一是僅能監(jiān)控基礎(chǔ)資源利用情況，無法分析應(yīng)用的實(shí)際性能；二是不具備長(zhǎng)期存儲(chǔ)和趨勢(shì)分析能力。
• Kube-state-metrics：輪詢Kubernetes API，并將Kubernetes的結(jié)構(gòu)化信息轉(zhuǎn)換為metrics。
• Metrics server：Metrics server定時(shí)從Kubelet的Summary API采集指標(biāo)數(shù)據(jù)，并以metric-api的形式暴露出去。

整體監(jiān)控流程如下：

• cAdvisor默認(rèn)安裝在所有集群節(jié)點(diǎn)上，采集容器和節(jié)點(diǎn)的指標(biāo)數(shù)據(jù)。
• Kubelet通過kubelet API將指標(biāo)數(shù)據(jù)暴露出去。
• Metrics判斷所有可用節(jié)點(diǎn)，請(qǐng)求kubelet API上送容器和節(jié)點(diǎn)使用情況數(shù)據(jù)，然后通過Kubernetes聚合API將指標(biāo)數(shù)據(jù)暴露出去。

上述基礎(chǔ)性工具雖然不能提供詳細(xì)的應(yīng)用監(jiān)控?cái)?shù)據(jù)，但能夠幫助用戶了解底層主機(jī)和K8s節(jié)點(diǎn)的情況。

一般來說，K8s集群管理員主要關(guān)注全局監(jiān)控，而應(yīng)用開發(fā)人員則主要關(guān)注應(yīng)用層面的監(jiān)控情況。但兩者的共同訴求都是在控制投入成本的前提下盡可能全面地監(jiān)控系統(tǒng)、采集數(shù)據(jù)。下周文章中，我們將介紹兩個(gè)可行的監(jiān)控方案：Prometheus和Sensu。兩個(gè)方案都能全面提供系統(tǒng)級(jí)的監(jiān)控?cái)?shù)據(jù)，幫助開發(fā)人員跟蹤K8s關(guān)鍵組件的性能、定位故障、接收預(yù)警。

本篇為譯文，原文作者：STEFAN THORPE

譯自Monitoring Kubernetes

譯文首發(fā)于UAVStack智能運(yùn)維