為了能夠提前發(fā)現(xiàn)kubernetes集群的問(wèn)題以及方便快捷的查詢?nèi)萜鞯母黝悈?shù)，比如，某個(gè)pod的內(nèi)存使用異常高企?等等這樣的異常狀態(tài)（雖然kubernetes有自動(dòng)重啟或者驅(qū)逐等等保護(hù)措施，但萬(wàn)一沒(méi)有配置或者失效了呢），容器的內(nèi)存使用量限制，過(guò)去10秒容器CPU的平均負(fù)載等等容器的運(yùn)行參數(shù)，這些情況我們自然還是將kubernetes集群納入到監(jiān)控系統(tǒng)中好些，畢竟能夠發(fā)現(xiàn)問(wèn)題和解決問(wèn)題更加的優(yōu)雅嘛。

因此，我們需要能夠有一個(gè)比較全面的監(jiān)測(cè)容器運(yùn)行的實(shí)時(shí)的監(jiān)控系統(tǒng)，版本答案當(dāng)然就是Prometheus了。Prometheus監(jiān)控系統(tǒng)可以多維度的，方便的將我們需要的信息收集起來(lái)，然后通過(guò)Grafana做一個(gè)華麗的展示。

那么，對(duì)于容器這個(gè)對(duì)象來(lái)說(shuō)，我們要使用的收集器就是cAdvisor啦，但cAdvisor這個(gè)收集器和node_exporter，mysqld_exporter 這些收集器不太一樣，它是集成在kubelet這個(gè)服務(wù)內(nèi)的，因此，我們不需要額外的安裝cAdvisor收集器，也就是說(shuō)不需要像node_exporter這樣的系統(tǒng)信息收集器一樣單獨(dú)部署了，只要kubernetes的節(jié)點(diǎn)上有運(yùn)行kubelet這個(gè)服務(wù)就可以了。

下面就kubernetes集群的Prometheus專用于容器的實(shí)時(shí)信息收集器cAdvisor如何認(rèn)識(shí)它，如何部署它并集成到Prometheus內(nèi)做一個(gè)詳細(xì)的介紹。
?

?一，
cAdvisor的簡(jiǎn)介
cAdvisor是一個(gè)谷歌開(kāi)發(fā)的容器監(jiān)控工具，它被內(nèi)嵌到k8s中作為k8s的監(jiān)控組件。cAdvisor對(duì)Node機(jī)器上的資源及容器進(jìn)行實(shí)時(shí)監(jiān)控和性能數(shù)據(jù)采集，包括CPU使用情況、內(nèi)存使用情況、網(wǎng)絡(luò)吞吐量及文件系統(tǒng)使用情況，由于cAdvisor是集成在Kubelet中的，因此，當(dāng)kubelet啟動(dòng)時(shí)會(huì)自動(dòng)啟動(dòng)cAdvisor，即一個(gè)cAdvisor僅對(duì)一臺(tái)Node機(jī)器進(jìn)行監(jiān)控。
?

當(dāng)然也可以單獨(dú)安裝?cAdvisor 來(lái)監(jiān)控只有docekr容器的機(jī)器而沒(méi)有k8s集群環(huán)境的監(jiān)控

二，其它的用于收集容器信息的信息收集器
heapster和Metrics server以及kube-state-metrics都可用于提供容器信息，但它們所提供的信息維度是不同的，heapster已經(jīng)被Metrics server所取代 了，如果沒(méi)記錯(cuò)的話，應(yīng)該是從k8s的1.16版本后放棄了heapster。

Metrics server作為新的容器信息收集器，是從 api-server 中獲取容器的 cpu、內(nèi)存使用率這種監(jiān)控指標(biāo)，并把他們發(fā)送給存儲(chǔ)后端，可以算作一個(gè)完整的監(jiān)控系統(tǒng)。cAdvisor是專有的容器信息收集，是一個(gè)專有工具的地位，而kube-state-metrics是偏向于kubernetes集群內(nèi)的資源對(duì)象，例如deployment，StateFulSet，daemonset等等資源，可以算作一個(gè)特定的數(shù)據(jù)源

三，cAdvisor的初步使用

kubelet是kubernetes集群中真正維護(hù)容器狀態(tài)，負(fù)責(zé)主要的業(yè)務(wù)的一個(gè)關(guān)鍵組件。每個(gè)節(jié)點(diǎn)上都運(yùn)行一個(gè) kubelet 服務(wù)進(jìn)程，默認(rèn)監(jiān)聽(tīng) 10250 端口，接收并執(zhí)行 master 發(fā)來(lái)的指令，管理 Pod 及 Pod 中的容器。kubernetes的節(jié)點(diǎn)IP+10250端口就是kubelet的API。

幾個(gè)重要的端口：

A：

10250（kubelet API）：kubelet server 與 apiserver 通信的端口，定期請(qǐng)求 apiserver 獲取自己所應(yīng)當(dāng)處理的任務(wù)，通過(guò)該端口可以訪問(wèn)獲取 node 資源以及狀態(tài)。kubectl查看pod的日志和cmd命令，都是通過(guò)kubelet端口10250訪問(wèn)。

10248端口是什么呢？是kubelet的健康檢查端口，可以通過(guò) kubelet 的啟動(dòng)參數(shù) –healthz-port 和 –healthz-bind-address 來(lái)指定監(jiān)聽(tīng)的地址和端口。

需要注意的是，Kubernetes 1.11+ 版本以后，kubelet 就移除了 10255 端口， metrics 接口又回到了 10250 端口中。

版本的kubernetes還有一個(gè)4194端口，此端口是cAdvisor的web管理界面的端口，可能是出于安全漏洞的考慮，后續(xù)版本移除了此端口，因此，此端口在我這個(gè)版本內(nèi)并沒(méi)有開(kāi)啟。

?B：API的使用
既然都說(shuō)了節(jié)點(diǎn)IP+10250是kubelet的API了，那么，我們肯定可以從這個(gè)API里獲取到一些信息了，這些信息其實(shí)就是cAdvisor收集到的，如何使用這個(gè)API呢？這個(gè)API可是需要使用證書(shū)的https哦。因此，計(jì)劃建立一個(gè)sa，通過(guò)sa的token來(lái)登陸這個(gè)API

1）利用ServiceAccount訪問(wèn)API

利用ServiceAccount訪問(wèn)API

找一個(gè)具有cluster-admin權(quán)限的ServiceAccount，其實(shí)每個(gè)集群內(nèi)都很容易找到這樣的sa，但為了說(shuō)明問(wèn)題還是新建一個(gè)任意的具有最高權(quán)限的sa吧，實(shí)際的生產(chǎn)中可不要這么搞哦。

新建一個(gè)sa：

kubectl create ns monitor-sa  #創(chuàng)建一個(gè)monitor-sa的名稱空間
kubectl create serviceaccount monitor -n monitor-sa  #創(chuàng)建一個(gè)sa賬號(hào)
kubectl create clusterrolebinding monitor-clusterrolebinding -n monitor-sa --clusterrole=cluster-admin  --serviceaccount=monitor-sa:monitor

查看secret：

[root@node3 ~]# k get secrets -n monitor-sa 
NAME                  TYPE                                  DATA   AGE
default-token-fw7pq   kubernetes.io/service-account-token   3      81s
monitor-token-tf48k   kubernetes.io/service-account-token   3      81s

獲取登錄用的token：

[root@node3 ~]# k describe secrets -n monitor-sa monitor-token-tf48k 

使用10250這個(gè)API：

將token保存到變量TOKEN里面，然后下面的API調(diào)試接口命令里面引用
[root@node3 ~]# TOKEN=“”

curl https://127.0.0.1:10250/metrics/cadvisor -k -H "Authorization: Bearer $TOKEN"

OK，輸出茫茫多，稍微截一點(diǎn)吧，剩下的就不貼了，具體的含義后面在說(shuō)吧：

[root@node3 ~]# curl https://127.0.0.1:10250/metrics/cadvisor -k -H "Authorization: Bearer $TOKEN" |less

將上面的命令改造一下，使用kube-apiserver 的服務(wù)來(lái)訪問(wèn)kube-apiserver 的API接口：

curl https://10.96.0.1/api/v1/nodes/node3/proxy/metrics -k -H "Authorization: Bearer $TOKEN"
[root@node3 ~]# curl https://10.96.0.1/api/v1/nodes/node3/proxy/metrics -k -H "Authorization: Bearer $TOKEN" |less

OK，以上是通過(guò)一個(gè)具有admin權(quán)限的serviceAccount賬戶直接連接cadvisor和kube-apiserver的API動(dòng)態(tài)獲得節(jié)點(diǎn)的pod，endpoint等等資源的各個(gè)維度的數(shù)據(jù)。

現(xiàn)在需要將這些集成到Prometheus server里了。

Kubernetes監(jiān)控體系總結(jié)_kube-state-metrics 代替了cadvisor嗎-CSDN博客

Docker 是一個(gè)開(kāi)源的應(yīng)用容器引擎，讓開(kāi)發(fā)者可以打包他們的應(yīng)用以及依賴包到一個(gè)可移植的容器中，然后發(fā)布到任何流行的 Linux/Windows/Mac 機(jī)器上。容器鏡像正成為一個(gè)新的標(biāo)準(zhǔn)化軟件交付方式。為了能夠獲取到 Docker 容器的運(yùn)行狀態(tài)，用戶可以通過(guò) Docker 的 stats 命令獲取到當(dāng)前主機(jī)上運(yùn)行容器的統(tǒng)計(jì)信息，可以查看容器的 CPU 利用率、內(nèi)存使用量、網(wǎng)絡(luò) IO 總量以及磁盤 IO 總量等信息。

顯然如果我們想對(duì)監(jiān)控?cái)?shù)據(jù)做存儲(chǔ)以及可視化的展示，那么 docker 的 stats 是不能滿足的。

為了解決 docker stats 的問(wèn)題（存儲(chǔ)、展示），谷歌開(kāi)源的 cadvisor 誕生了，cadvisor 不僅可以搜集一臺(tái)機(jī)器上所有運(yùn)行的容器信息，還提供基礎(chǔ)查詢界面和 http 接口，方便其他組件如 Prometheus 進(jìn)行數(shù)據(jù)抓取，或者 cAdvisor + influxDB + grafana 搭配使用。cAdvisor 可以對(duì)節(jié)點(diǎn)機(jī)器上的資源及容器進(jìn)行實(shí)時(shí)監(jiān)控和性能數(shù)據(jù)采集，包括 CPU 使用情況、內(nèi)存使用情況、網(wǎng)絡(luò)吞吐量及文件系統(tǒng)使用情況

監(jiān)控原理

cAdvisor 使用 Go 語(yǔ)言開(kāi)發(fā)，利用 Linux 的 cgroups 獲取容器的資源使用信息，在 K8S 中集成在 Kubelet 里作為默認(rèn)啟動(dòng)項(xiàng)，官方標(biāo)配。

Docker 是基于 Namespace、Cgroups 和聯(lián)合文件系統(tǒng)實(shí)現(xiàn)的

Cgroups 不僅可以用于容器資源的限制，還可以提供容器的資源使用率。不管用什么監(jiān)控方案，底層數(shù)據(jù)都來(lái)源于 Cgroups

Cgroups 的工作目錄 ? /sys/fs/cgroup 下包含了 Cgroups 的所有內(nèi)容。Cgroups 包含了很多子系統(tǒng)，可以對(duì) CPU，內(nèi)存，PID，磁盤 IO 等資源進(jìn)行限制和監(jiān)控。

Heapster
Heapster 是容器集群監(jiān)控和性能分析工具，天然的支持 Kubernetes 和 CoreOS。

Heapster 首先從 K8S Master 獲取集群中所有 Node 的信息，然后通過(guò)這些 Node 上的 kubelet 獲取有用數(shù)據(jù)，而 kubelet 本身的數(shù)據(jù)則是從 cAdvisor 得到。所有獲取到的數(shù)據(jù)都被推到 Heapster 配置的后端存儲(chǔ)中，并還支持?jǐn)?shù)據(jù)的可視化。現(xiàn)在后端存儲(chǔ) + 可視化的方法，如 InfluxDB + grafana。

Heapster 可以收集 Node 節(jié)點(diǎn)上的 cAdvisor 數(shù)據(jù)，還可以按照 kubernetes 的資源類型來(lái)集合資源，比如 Pod、Namespace 域，可以分別獲取它們的 CPU、內(nèi)存、網(wǎng)絡(luò)和磁盤的 metric。默認(rèn)的 metric 數(shù)據(jù)聚合時(shí)間間隔是 1 分鐘。

注意 ：Kubernetes 1.11 不建議使用 Heapster，就 SIG Instrumentation 而言，這是為了轉(zhuǎn)向新的 Kubernetes 監(jiān)控模型的持續(xù)努力的一部分。仍使用 Heapster 進(jìn)行自動(dòng)擴(kuò)展的集群應(yīng)遷移到 metrics-server 和自定義指標(biāo) API。

kubernetes 集群資源監(jiān)控之前可以通過(guò) heapster 來(lái)獲取數(shù)據(jù)，在 1.11 開(kāi)始開(kāi)始逐漸廢棄 heapster 了，采用 metrics-server 來(lái)代替，metrics-server 是集群的核心監(jiān)控?cái)?shù)據(jù)的聚合器，它從 kubelet 公開(kāi)的 Summary API 中采集指標(biāo)信息，metrics-server 是擴(kuò)展的 APIServer，依賴于 kube-aggregator，因?yàn)槲覀冃枰?APIServer 中開(kāi)啟相關(guān)參數(shù)。

Metrics Server 并不是 kube-apiserver 的一部分，而是通過(guò) Aggregator 這種插件機(jī)制，在獨(dú)立部署的情況下同 kube-apiserver 一起統(tǒng)一對(duì)外服務(wù)的。

Aggregator

通過(guò)聚合層擴(kuò)展 Kubernetes API使用聚合層（Aggregation Layer），用戶可以通過(guò)額外的 API 擴(kuò)展 Kubernetes， 而不局限于 Kubernetes 核心 API 提供的功能。這里的附加 API 可以是現(xiàn)成的解決方案比如 metrics server, 或者你自己開(kāi)發(fā)的 API。聚合層不同于 定制資源（Custom Resources）。后者的目的是讓 kube-apiserver 能夠認(rèn)識(shí)新的對(duì)象類別（Kind）。

聚合層聚合層在 kube-apiserver 進(jìn)程內(nèi)運(yùn)行。在擴(kuò)展資源注冊(cè)之前，聚合層不做任何事情。要注冊(cè) API，用戶必須添加一個(gè) APIService 對(duì)象，用它來(lái)“申領(lǐng)” Kubernetes API 中的 URL 路徑。自此以后，聚合層將會(huì)把發(fā)給該 API 路徑的所有內(nèi)容（例如 /apis/myextension.mycompany.io/v1/…） 轉(zhuǎn)發(fā)到已注冊(cè)的 APIService。

APIService 的最常見(jiàn)實(shí)現(xiàn)方式是在集群中某 Pod 內(nèi)運(yùn)行 擴(kuò)展 API 服務(wù)器。如果你在使用擴(kuò)展 API 服務(wù)器來(lái)管理集群中的資源，該擴(kuò)展 API 服務(wù)器（也被寫成“extension-apiserver”） 一般需要和一個(gè)或多個(gè)控制器一起使用。apiserver-builder 庫(kù)同時(shí)提供構(gòu)造擴(kuò)展 API 服務(wù)器和控制器框架代碼。

這里，Aggregator APIServer 的工作原理，可以用如下所示的一幅示意圖來(lái)表示清楚 ：

因?yàn)?k8s 的 api-server 將所有的數(shù)據(jù)持久化到了 etcd 中，顯然 k8s 本身不能處理這種頻率的采集，而且這種監(jiān)控?cái)?shù)據(jù)變化快且都是臨時(shí)數(shù)據(jù)，因此需要有一個(gè)組件單獨(dú)處理他們，于是 metric-server 的概念誕生了。

Metrics server 出現(xiàn)后，新的 Kubernetes 監(jiān)控架構(gòu)將變成下圖的樣子

1. 核心流程（黑色部分）：這是 Kubernetes 正常工作所需要的核心度量，從 Kubelet、cAdvisor 等獲取度量數(shù)據(jù)，再由 metrics-server 提供給 Dashboard、HPA 控制器等使用。
2. 監(jiān)控流程（藍(lán)色部分）：基于核心度量構(gòu)建的監(jiān)控流程，比如 Prometheus 可以從 metrics-server 獲取核心度量，從其他數(shù)據(jù)源（如 Node Exporter 等）獲取非核心度量，再基于它們構(gòu)建監(jiān)控告警系統(tǒng)。

注意：

• metrics-sevrer 的數(shù)據(jù)存在內(nèi)存中。

• metrics-server 主要針對(duì) node、pod 等的 cpu、網(wǎng)絡(luò)、內(nèi)存等系統(tǒng)指標(biāo)的監(jiān)控

kube-state-metrics
已經(jīng)有了 cadvisor、heapster、metric-server，幾乎容器運(yùn)行的所有指標(biāo)都能拿到，但是下面這種情況卻無(wú)能為力：

• 我調(diào)度了多少個(gè) replicas？現(xiàn)在可用的有幾個(gè)？
• 多少個(gè) Pod 是 running/stopped/terminated 狀態(tài)？
• Pod 重啟了多少次？
• 我有多少 job 在運(yùn)行中
  ?

而這些則是 kube-state-metrics 提供的內(nèi)容，它基于 client-go 開(kāi)發(fā)，輪詢 Kubernetes API，并將 Kubernetes 的結(jié)構(gòu)化信息轉(zhuǎn)換為 metrics。

kube-state-metrics 與 metrics-server 對(duì)比

我們服務(wù)在運(yùn)行過(guò)程中，我們想了解服務(wù)運(yùn)行狀態(tài)，pod 有沒(méi)有重啟，伸縮有沒(méi)有成功，pod 的狀態(tài)是怎么樣的等，這時(shí)就需要 kube-state-metrics，它主要關(guān)注 deployment,、node 、 pod 等內(nèi)部對(duì)象的狀態(tài)。而 metrics-server 主要用于監(jiān)測(cè) node，pod 等的 CPU，內(nèi)存，網(wǎng)絡(luò)等系統(tǒng)指標(biāo)。

• metric-server（或 heapster）是從 api-server 中獲取 cpu、內(nèi)存使用率這種監(jiān)控指標(biāo)，并把他們發(fā)送給存儲(chǔ)后端，如 influxdb 或云廠商，他當(dāng)前的核心作用是：為 HPA 等組件提供決策指標(biāo)支持。
• kube-state-metrics 關(guān)注于獲取 k8s 各種資源的最新?tīng)顟B(tài)，如 deployment 或者 daemonset，之所以沒(méi)有把 kube-state-metrics 納入到 metric-server 的能力中，是因?yàn)樗麄兊年P(guān)注點(diǎn)本質(zhì)上是不一樣的。metric-server 僅僅是獲取、格式化現(xiàn)有數(shù)據(jù)，寫入特定的存儲(chǔ)，實(shí)質(zhì)上是一個(gè)監(jiān)控系統(tǒng)。而 kube-state-metrics 是將 k8s 的運(yùn)行狀況在內(nèi)存中做了個(gè)快照，并且獲取新的指標(biāo)，但他沒(méi)有能力導(dǎo)出這些指標(biāo)
• 換個(gè)角度講，kube-state-metrics 本身是 metric-server 的一種數(shù)據(jù)來(lái)源，雖然現(xiàn)在沒(méi)有這么做。
• 另外，像 Prometheus 這種監(jiān)控系統(tǒng)，并不會(huì)去用 metric-server 中的數(shù)據(jù)，他都是自己做指標(biāo)收集、集成的（Prometheus 包含了 metric-server 的能力），但 Prometheus 可以監(jiān)控 metric-server 本身組件的監(jiān)控狀態(tài)并適時(shí)報(bào)警，這里的監(jiān)控就可以通過(guò) kube-state-metrics 來(lái)實(shí)現(xiàn)，如 metric-serverpod 的運(yùn)行狀態(tài)。
  ?

?

custom-metrics-apiserver
kubernetes 的監(jiān)控指標(biāo)分為兩種

• Core metrics（核心指標(biāo)）：從 Kubelet、cAdvisor 等獲取度量數(shù)據(jù)，再由 metrics-server 提供給 Dashboard、HPA 控制器等使用。
• Custom Metrics（自定義指標(biāo)）：由 Prometheus Adapter 提供 API custom.metrics.k8s.io，由此可支持任意 Prometheus 采集到的指標(biāo)。
  ?

以下是官方 metrics 的項(xiàng)目介紹：

Resource Metrics API（核心 api）

• Heapster

• Metrics Server

Custom Metrics API：

• Prometheus Adapter

• Microsoft Azure Adapter

• Google Stackdriver

• Datadog Cluster Agent

核心指標(biāo)只包含 node 和 pod 的 cpu、內(nèi)存等，一般來(lái)說(shuō)，核心指標(biāo)作 HPA 已經(jīng)足夠，但如果想根據(jù)自定義指標(biāo)：如請(qǐng)求 qps/5xx 錯(cuò)誤數(shù)來(lái)實(shí)現(xiàn) HPA，就需要使用自定義指標(biāo)了，目前 Kubernetes 中自定義指標(biāo)一般由 Prometheus 來(lái)提供，再利用 k8s-prometheus-adpater 聚合到 apiserver，實(shí)現(xiàn)和核心指標(biāo)（metric-server) 同樣的效果。

HPA 請(qǐng)求 metrics 時(shí)，kube-aggregator(apiservice 的 controller) 會(huì)將請(qǐng)求轉(zhuǎn)發(fā)到 adapter，adapter 作為 kubernentes 集群的 pod，實(shí)現(xiàn)了 Kubernetes resource metrics API 和 custom metrics API，它會(huì)根據(jù)配置的 rules 從 Prometheus 抓取并處理 metrics，在處理（如重命名 metrics 等）完后將 metric 通過(guò) custom metrics API 返回給 HPA。最后 HPA 通過(guò)獲取的 metrics 的 value 對(duì) Deployment/ReplicaSet 進(jìn)行擴(kuò)縮容。

adapter 作為 extension-apiserver（即自己實(shí)現(xiàn)的 pod)，充當(dāng)了代理 kube-apiserver 請(qǐng)求 Prometheus 的功能。

adapter 作為 extension-apiserver（即自己實(shí)現(xiàn)的 pod)，充當(dāng)了代理 kube-apiserver 請(qǐng)求 Prometheus 的功能

其實(shí) k8s-prometheus-adapter 既包含自定義指標(biāo)，又包含核心指標(biāo)，即如果安裝了 prometheus，且指標(biāo)都采集完整，k8s-prometheus-adapter 可以替代 metrics server。

Prometheus 部署方案
prometheus operator

• https://github.com/prometheus-operator/prometheus-operator

kube-prometheus

• https://github.com/prometheus-operator/kube-prometheus

在集群外部署

• https://www.qikqiak.com/post/monitor-external-k8s-on-prometheus/

kube-prometheus 既包含了 Operator，又包含了 Prometheus 相關(guān)組件的部署及常用的 Prometheus 自定義監(jiān)控，具體包含下面的組件

• The Prometheus Operator：創(chuàng)建 CRD 自定義的資源對(duì)象
• Highly available Prometheus：創(chuàng)建高可用的 Prometheus
• Highly available Alertmanager：創(chuàng)建高可用的告警組件
• Prometheus node-exporter：創(chuàng)建主機(jī)的監(jiān)控組件
• Prometheus Adapter for Kubernetes Metrics APIs：創(chuàng)建自定義監(jiān)控的指標(biāo)工具（例如可以通過(guò) nginx 的 request 來(lái)進(jìn)行應(yīng)用的自動(dòng)伸縮）
• kube-state-metrics：監(jiān)控 k8s 相關(guān)資源對(duì)象的狀態(tài)指標(biāo)
• Grafana：進(jìn)行圖像展示

我們的做法
我們的做法，其實(shí)跟 kube-prometheus 的思路差不多，只不過(guò)我們沒(méi)有用 Operator ，是自己將以下這些組件的 yaml 文件用 helm 組織了起來(lái)而已：

• kube-state-metrics
• prometheus
• alertmanager
• grafana
• k8s-prometheus-adapter
• node-exporter

當(dāng)然 kube-prometheus 也有 helm charts 由 prometheus 社區(qū)提供：https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack

這么干的原因是：這樣的靈活度是最高的，雖然在第一次初始化創(chuàng)建這些腳本的時(shí)候麻煩了些。不過(guò)還有一個(gè)原因是我們當(dāng)時(shí)部署整個(gè)基于 prometheus 的監(jiān)控體系時(shí)，kube-prometheus 這個(gè)項(xiàng)目還在早期，沒(méi)有引起我們的關(guān)注。如果在 2021 年年初或 2020 年年底的時(shí)候創(chuàng)建的話，可能就會(huì)直接上了。

參考

• https://blog.opskumu.com/cadvisor.html
• https://prometheus.io/
• https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale/
• https://www.cnblogs.com/chenqionghe/p/10494868.html
• https://www.qikqiak.com/post/k8s-operator-101/
• https://kubernetes.io/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/
• https://segmentfault.com/a/1190000017875641
• https://segmentfault.com/a/1190000038888544
• https://yasongxu.gitbook.io/
• https://mp.weixin.qq.com/s/p4FAFKHi8we4mrD7OIk7IQ
• https://kubernetes.feisky.xyz/apps/index/operator
• https://yunlzheng.gitbook.io/prometheus-book/part-iii-prometheus-shi-zhan/operator/what-is-prometheus-operator
  ?

1.k8s原生api地址?

k8s的REST API：

http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/nodes
http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/nodes/<node-name>
http://127.0.0.1:8001/apis/metrics.k8s.io/v1beta1/namespace/<namespace-name>/pods/<pod-name>

2.rancher看k8s接口地址

2.1）看集群的api

2.2）通過(guò)集群api查看id?

2.3）通過(guò)rancher看k8s的api地址?

rancher的REST API:

總接口：https://rancher.jettech.cn/k8s/clusters/c-wpz72/

node:https://rancher.jettech.cn/k8s/clusters/c-wpz72/apis/metrics.k8s.io/v1beta1/nodes

pod:https://rancher.jettech.cn/k8s/clusters/c-wpz72/apis/metrics.k8s.io/v1beta1/pods

?細(xì)說(shuō)k8s監(jiān)控架構(gòu) - 知乎文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-817998.html

到了這里，關(guān)于rancher和k8s接口地址，Kubernetes監(jiān)控體系，cAdvisor和kube-state-metrics 與 metrics-server的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！