一、Kubernetes介紹

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

成都創(chuàng)新互聯(lián)專注于企業(yè)成都營銷網(wǎng)站建設(shè)、網(wǎng)站重做改版、鄭州網(wǎng)站定制設(shè)計、自適應(yīng)品牌網(wǎng)站建設(shè)、H5網(wǎng)站設(shè)計、商城系統(tǒng)網(wǎng)站開發(fā)、集團(tuán)公司官網(wǎng)建設(shè)、外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計等建站業(yè)務(wù)，價格優(yōu)惠性價比高，為鄭州等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

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

二、K8s由來

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

Google不僅開源了公司整個基礎(chǔ)設(shè)施在容器中的運(yùn)行方式，還積極開發(fā)Linux容器技術(shù)，支撐Google所有云服務(wù)。K8s是基于云平臺15年的生產(chǎn)工作負(fù)載運(yùn)行經(jīng)驗(yàn)設(shè)計出來的，用于處理成千上萬個容器。Google每周部署20多億個容器。在K8s上線前，Google主要通過內(nèi)部開發(fā)平臺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ù)測性、可擴(kuò)展性和高可用性管理容器化應(yīng)用和服務(wù)的整個生命周期，通過更高水平的抽象，將多個機(jī)器統(tǒng)一成一個機(jī)器。這對于大型環(huán)境的運(yùn)行來說至關(guān)重要。

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

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

每個進(jìn)程包含一個API server、一個scheduler和多個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)行集群級別的其他功能，通過嵌入式controller完成創(chuàng)建端點(diǎn)、發(fā)現(xiàn)節(jié)點(diǎn)、復(fù)制控制等操作。由于controller設(shè)計靈活且可擴(kuò)展，Kube管理員可自行創(chuàng)建controller。Kube通過API server監(jiān)控K8s集群的共享狀態(tài)，并對集群狀態(tài)進(jìn)行調(diào)整，確保當(dāng)前狀態(tài)與理想狀態(tài)一致。

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

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

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

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

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

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

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

  • 集群容量和資源利用情況：（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ù)請求率、吞吐量、錯誤率監(jiān)控集群中應(yīng)用的性能和可用性。
  • 終端用戶體驗(yàn)：監(jiān)控移動應(yīng)用和瀏覽器性能，優(yōu)化加載時間和可用性，提高客戶滿意度。
  • 配套基礎(chǔ)設(shè)施：前文提到，K8s的運(yùn)行平臺也非常重要。

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

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

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

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

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

• K8s儀表盤：插件工具，展示每個K8s集群上的資源利用情況，也是實(shí)現(xiàn)資源和環(huán)境管理與交互的主要工具。
• 容器探針：容器健康狀態(tài)診斷工具。
• Kubelet：每個Node上都運(yùn)行著Kubelet，監(jiān)控容器的運(yùn)行情況。Kubelet也是Master與各個Node通信的渠道。Kubelet能夠直接暴露cAdvisor中與容器使用相關(guān)的個性化指標(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)控基礎(chǔ)資源利用情況，無法分析應(yīng)用的實(shí)際性能；二是不具備長期存儲和趨勢分析能力。
• Kube-state-metrics：輪詢Kubernetes API，并將Kubernetes的結(jié)構(gòu)化信息轉(zhuǎn)換為metrics。
• Metrics server：Metrics server定時從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)，請求kubelet API上送容器和節(jié)點(diǎn)使用情況數(shù)據(jù)，然后通過Kubernetes聚合API將指標(biāo)數(shù)據(jù)暴露出去。

上述基礎(chǔ)性工具雖然不能提供詳細(xì)的應(yīng)用監(jiān)控數(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ù)。下周文章中，我們將介紹兩個可行的監(jiān)控方案：Prometheus和Sensu。兩個方案都能全面提供系統(tǒng)級的監(jiān)控數(shù)據(jù)，幫助開發(fā)人員跟蹤K8s關(guān)鍵組件的性能、定位故障、接收預(yù)警。

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

譯自Monitoring Kubernetes

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

分享文章：Kubernetes監(jiān)控實(shí)踐-創(chuàng)新互聯(lián)
轉(zhuǎn)載來源：http://chinadenli.net/article26/doeocg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站營銷、企業(yè)網(wǎng)站制作、移動網(wǎng)站建設(shè)、微信小程序、虛擬主機(jī)、網(wǎng)站排名

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)