本文作者孔飛骑晶，來自快貓星云團(tuán)隊(duì)，Kubernetes專家寂嘉，Categraf 采集器核心研發(fā)工程師

云原生包含了開源軟件遏暴、云計(jì)算和應(yīng)用架構(gòu)的元素。云計(jì)算解決開源軟件的運(yùn)行門檻問題衷模，同時(shí)降低了運(yùn)維成本和基礎(chǔ)架構(gòu)成本; 云原生給出了更多的應(yīng)用架構(gòu)規(guī)范, 更聚焦于能力和生態(tài)鹊汛。隨著 Kubernetes 在基礎(chǔ)設(shè)施的大規(guī)模落地蒲赂，監(jiān)控的需求也發(fā)生了變化，建設(shè)一套更符合云原生規(guī)范的監(jiān)控體系勢在必行刁憋。

一 監(jiān)控需求變化

• 指標(biāo)周期變短: 相比物理機(jī)時(shí)代滥嘴，基礎(chǔ)設(shè)施動(dòng)態(tài)化，Pod銷毀重建非常頻繁至耻，監(jiān)控指標(biāo)跟隨 Pod 的生命周期
• 指標(biāo)數(shù)量增加: 隨著微服務(wù)化流行若皱，指標(biāo)的數(shù)量也大幅增長，研發(fā)工程師也更愿意埋點(diǎn)尘颓，獲取服務(wù)狀態(tài)走触；各種采集器層出不窮，指標(biāo)應(yīng)采盡采
• 指標(biāo)維度更加豐富：物理機(jī)時(shí)代監(jiān)控多從資源視角出發(fā)疤苹，更關(guān)注機(jī)器互广、交換機(jī)、中間件的采集卧土；新的監(jiān)控維度更加豐富惫皱，維度標(biāo)簽動(dòng)輒十幾個(gè)幾十個(gè)
• 基礎(chǔ)設(shè)施復(fù)雜度變高，監(jiān)控難度增加：Kubernetes 組件和應(yīng)用架構(gòu)模型都需要投入時(shí)間去了解學(xué)習(xí)尤莺。Kubernetes 本身組件都通過 /metrics 接口暴露了監(jiān)控?cái)?shù)據(jù)旅敷，但是缺少體系化的文檔指導(dǎo)和最佳實(shí)踐總結(jié)
• 自動(dòng)發(fā)現(xiàn)更重要：相比物理機(jī)時(shí)代的靜態(tài)采集，自動(dòng)發(fā)現(xiàn)采集目標(biāo)的能力變得更重要

這個(gè)系列的文章重點(diǎn)講解 Kubernetes 云原生監(jiān)控體系缝裁，講解 Kubernetes 本身各個(gè)組件的監(jiān)控扫皱，以及運(yùn)行在 Kubernetes 上的業(yè)務(wù)應(yīng)用的監(jiān)控。

二 采集目標(biāo)

2.1 從 Kubernetes 架構(gòu)看采集目標(biāo)

• 控制面組件監(jiān)控捷绑，包括 kube-apiserver韩脑、kube-controller-manager、kube-scheduler粹污、etcd 的監(jiān)控
• node 組件監(jiān)控跛璧，包括 kubelet互纯、kube-proxy 等組件的監(jiān)控
• Kubernetes對象監(jiān)控（kube-state-metrics琐谤，后文簡稱KSM）
• 宿主節(jié)點(diǎn)資源監(jiān)控
• 業(yè)務(wù)自身監(jiān)控贯城，業(yè)務(wù)自身的狀態(tài)監(jiān)控，白盒埋點(diǎn)監(jiān)控

2.2 簡單梳理監(jiān)控指標(biāo)

2.2.1 kube-apiserver

kube-apiserver 是 Kubernetes 的總?cè)肟谘夹穑渌?Kubernetes 組件都是通過與kube-apiserver 交互實(shí)現(xiàn)各種功能

• 要處理各種 API 調(diào)用觉啊，需要重點(diǎn)關(guān)注吞吐、延遲沈贝、錯(cuò)誤率這些指標(biāo)
• 緩存對象數(shù)據(jù)杠人，需要關(guān)注自身的 CPU 和內(nèi)存使用率

2.2.2 kube-controller-manager

kube-controller-manager 負(fù)責(zé)監(jiān)聽對象狀態(tài)，并與期望狀態(tài)對比，如果狀態(tài)不一致就進(jìn)行調(diào)諧（reconcile)

• 主要關(guān)注各個(gè) controller 的任務(wù)數(shù)嗡善、隊(duì)列深度
• 與 kube-apiserver 交互的請求數(shù)辑莫、耗時(shí)、錯(cuò)誤數(shù)

2.2.3 kube-scheduler

kube-scheduler 經(jīng)過一些打分算法罩引，給 Pod 選取合適的 Node

• 調(diào)度框架的各個(gè)擴(kuò)展點(diǎn)各吨、算法的耗時(shí)
• 調(diào)度隊(duì)列的任務(wù)數(shù)、隊(duì)列深度
• 與 kube-apiserver 交互的請求數(shù)袁铐、耗時(shí)揭蜒、錯(cuò)誤數(shù)

2.2.4 etcd

etcd 主要存儲(chǔ)各種 Kubernetes 的對象數(shù)據(jù)，etcd 與 kube-apiserver 直接交互

• 關(guān)注 etcd 處理的請求量剔桨、請求耗時(shí)忌锯、cache 命中情況
• etcd 集群的狀態(tài)，是否在做 snapshot领炫、是否在做數(shù)據(jù) defrag、leader/learner 以及切換次數(shù)
• etcd 的 db size 张咳，wal 寫入狀態(tài)等
• etcd 各種操作的耗時(shí)帝洪、數(shù)量情況
• etcd 的 CPU、內(nèi)存脚猾、fd 使用情況

2.2.5 Node節(jié)點(diǎn)

• Node本身的資源（cpu 內(nèi)存 硬盤 網(wǎng)絡(luò) fd等）
• Node上容器資源（cpu 內(nèi)存 硬盤 網(wǎng)絡(luò) fd等）
• Node上組件的監(jiān)控葱峡，kubelet、kube-proxy龙助、dockerd砰奕、containerd 等

2.2.6 KSM

• workloads（工作負(fù)載）指標(biāo)，比如業(yè)務(wù)部署了多少個(gè) deployment提鸟，部署了多少個(gè)pod军援，各個(gè) pod 的狀態(tài)如何
• 資源 quota 還剩多少

2.2.7 業(yè)務(wù)監(jiān)控

• 業(yè)務(wù)本身提供的 metrics 接口，來暴露業(yè)務(wù)指標(biāo)
• 業(yè)務(wù)進(jìn)程自身的通用監(jiān)控指標(biāo)称勋，比如進(jìn)程的CPU胸哥、內(nèi)存、IO赡鲜、句柄等

三 采集方式

3.1 權(quán)限

監(jiān)控對象明確后空厌，就要確定如何收集指標(biāo)。在收集具體指標(biāo)前银酬，首先要搞定的就是權(quán)限嘲更。Kubernetes 大部分指標(biāo)的采集都是需要 kube-apiserver 授權(quán)的。關(guān)于 Kubernetes 的 authorization揩瞪，主要包含RBAC赋朦、ABAC、Node Authorization、Webhook Authorization北发。

• RBAC：Role-based access control 是基于角色的訪問控制
• ABAC：Atrribute-based access control 是基于屬性的訪問控制
• Node Authorization：節(jié)點(diǎn)鑒權(quán)纹因，專門用于 kubelet 發(fā)出的 API 請求進(jìn)行鑒權(quán)
• Webhook Authorization：webhook 是一種 HTTP 回調(diào)，kube-apiserver 配置webhook 時(shí)琳拨， 會(huì)設(shè)置回調(diào) webhook 的規(guī)則瞭恰，這些規(guī)則中包含了調(diào)用的 api group、version狱庇、operation惊畏、scope等信息。

Node Authorization 和 Webhook Authorization是兩種專門的鑒權(quán)模型密任。ABAC 是用戶和權(quán)限綁定颜启；RBAC 是用戶和角色綁定，角色和權(quán)限綁定浪讳。RBAC 比 ABAC 多了一個(gè)角色缰盏，更加靈活，后續(xù)我們主要是 RBAC 鑒權(quán)模式進(jìn)行采集指標(biāo)淹遵。

3.2 自動(dòng)發(fā)現(xiàn)

搞定鑒權(quán)模式后口猜，我們面臨的下一個(gè)問題是自動(dòng)發(fā)現(xiàn)。對于控制面組件透揣，類似prometheus 的 static config 可以滿足需求济炎， 對于使用 pod 部署的組件，我們都可以利用 k8s 自身的特性來動(dòng)態(tài)發(fā)現(xiàn)目標(biāo)辐真，進(jìn)而采集數(shù)據(jù)须尚。比如，創(chuàng)建 service侍咱，然后利用 service 動(dòng)態(tài)發(fā)現(xiàn)對應(yīng) endpoint 的變化耐床，這樣 pod 的 ip 發(fā)生變化也不影響采集。如果 公司已經(jīng)有其他成熟的服務(wù)發(fā)現(xiàn)機(jī)制楔脯，也可以直接利用咙咽，比如consul。

3.3 如何部署采集器

搞定了鑒權(quán)和自動(dòng)發(fā)現(xiàn)淤年，接下來要考慮采集器以何種方式采集了钧敞。

• 控制面組件，首先推薦使用 deployment方式 + 自動(dòng)發(fā)現(xiàn); 如果控制面組件是二進(jìn)制方式部署, 可以用 deployment+ consul（或者靜態(tài)抓取方式）麸粮；
• node節(jié)點(diǎn)溉苛，首先推薦使用 daemonset 方式采集 node 指標(biāo)和容器基礎(chǔ)指標(biāo)；
• KSM弄诲，首先推薦使用單副本的 deployment 方式 + 自動(dòng)發(fā)現(xiàn)愚战；
• 業(yè)務(wù)監(jiān)控娇唯，首先推薦使用 sidecar 模式來采集；其次使用集中式的 deployment方式采集寂玲；

部署yaml文件塔插，我們已經(jīng)放在k8s目錄下:

• deployment.yaml 以deployment方式部署
• sidecar.yaml 以sidecar方式部署
• deamonset.yaml 以daemonset方式部署
• scrape_with_cafile.yaml 在pod內(nèi)抓取指標(biāo)
• scrape_with_cafile.yaml 用cafile方式抓取指標(biāo)
• scrape_with_kubeconfig.yaml 用kube-config 文件方式抓取指標(biāo)
• scrape_with_token.yaml 用token方式抓取指標(biāo)

四 監(jiān)控大盤與報(bào)警規(guī)則

按照梳理的指標(biāo)，已經(jīng)將k8s 部分組件的大盤梳理完了拓哟，具體可以參考https://github.com/flashcatcloud/categraf/tree/main/k8s目錄下對應(yīng)的文件想许。

• apiserver-dash.json
• cm-dash.json
• sheducler-dash.json
• etcd-dash.json
• coredns-dash.json

本文先將 Kubernetes 環(huán)境下的監(jiān)控整體工作做了一個(gè)簡單介紹，大家先有一個(gè)感性認(rèn)識断序。后續(xù)我們會(huì)針對具體的步驟做詳細(xì)的介紹流纹，歡迎大家轉(zhuǎn)發(fā)、點(diǎn)贊违诗、關(guān)注和收藏漱凝。

最后，如果還沒有關(guān)注夜鶯和categraf開源項(xiàng)目的朋友诸迟，可以star收藏起來了茸炒，后續(xù)的Kubernetes監(jiān)控講解系列文章，會(huì)重度依賴這兩個(gè)開源項(xiàng)目：

• https://github.com/ccfos/nightingale
• https://github.com/flashcatcloud/categraf

本文由mdnice多平臺發(fā)布