DevOps課程-Prometheus 2
各種不同的Prometheus在K8S叢集的建置方式:
- 建立所有Prometheus的YAML設定檔(Prometheus,Alertmanager,Grafana…etc),並依照正確的建置順序建立,但是非常不方便,又太多工
- 找到並使用Prometheus Operator,在Operator其上管理所有Prometheus元件
- 最方便 →使用Helm Chart來佈署Prometheus Operator,是由Prometheus社群維護,由Helm來進行初始化建置,再由Operator進行管理維護,本篇課程後面就是這用個方式!
建立Kubernetes叢集,這邊使用EKS:
#講師直接用最簡單指令建置,相關指令筆記可以看前面的EKS筆記,首先簡單看一下預設值:
eksctl create cluster --help
#嘗試如講師一樣直接建立:
eksctl create cluster
我特別注意到預設的建置看起來是指定1.22版的K8S:
所以也特別去搞了1.22的kubectl工具:
大概十多分鐘後建置完成:
Worker機是兩台m5.large…貴的!!!!:
在EKS中建立為服務系統(多個微服務程式專案)的K8S元件:
Fork講師前面K8S課程中撰寫的Google的多個微服務專案的K8S元件:
我把這個檔案放到跟kubectl工具同個目錄下:
#這邊建置直接使用default的namespace:
kubectl apply -f config-best-practices.yaml
透過Helm安裝Prometheus:
首先找到透過Helm可以下載Prometheus的Chart的參考網站:
看README.md文件有提到要加掛helm的repo:
參考如上整理安裝指令如下
#安裝指令整理,增加Repo位置:
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts#更新Repo內容:
helm repo update#建立Prometheus專用的namespace:
kubectl create namespace monitoring#安裝Prometheus Chart,並給予名稱為monitoring,並安裝到monitoring ns裡面:
helm install {名稱,這邊一樣給monitoring} {Repo名稱}/{chart名稱,叫kube-prometheus-stack} -n {指定的namespace}
#整理上述對應的指令即如下:
helm install monitoring prometheus-community/kube-prometheus-stack -n monitoring(這邊大概看講師跳了9分鐘安裝)
瞭解Prometheus Stack元件:
簡單點直接去建立的namespac裡面看:
#直接看monitoring這個namespace有啥:
kubectl get all -n monitoring
如上我們有7個Pods,5個Services,1個Daemonset,3個Deployments,3個ReplicaSets,2個StatefulSets
以下將一一解析上述各元件(OverView):
1.StatefulSet部分:
- 首先是"prometheus-monitoring-kube-prometheus-prometheus",基本上這個StatefulSet即代表了以下整個架構 —Prometheus Server :
- 其中上面建立出來的Pod完全由Operator管理
- 另一個"alertmanager-monitoring-kube-prometheus-alertmanager"則是另外一塊架構(如下圖所示)
2.Deployment部分:
- 可以看到內含prometheus-operator(名稱太長,我後面都只貼關鍵部分),這個是負責建立prometheus與alertmanager的StatefulSets
- 另外就是Grafana
- 還有就是kube-state-metrics,這其實是一個獨立作用的Helm Chart,並且也是本Prometheus Helm Chart的依賴(dependency)的Helm Chart,這個本身是用來自己抓取K8S元件的metrics,也就是提供K8S元件的本身監控使用,也就是我們現在已經做到"K8S InfraStructure Monitoring!"
3.ReplicaSet部分:
4.DaemonSet部分:
- Node Exporter的DaemonSet,也就是運行在每一個Worker Node上
- 這個專門連線到Prometheus Server,並用來轉換每台Worker Node metrics變成Prometheus metrics,像是CPU使用率,負載…etc
5.Pod部分:
6.Service部分:
- 就對應各元件暴露各自服務
這部分結論:
- 1.我們完成了"Monitor Stack"的建立
- 2.連帶完成了Kubernetes Cluster本身的開箱即用的監控建置,監控以下:
- a.Woker node監控
- b.Kubernetes元件監控
相關設定檔案則另外來源於 — ConfigMap:
- 針對不同元件有各種不同的設定檔ConfigMap
- 這些ConfigMap也同樣由Operator管理
- 裡面也定義了如何連線到預設的Metrics
另外還有各元件使用機敏與憑證等資訊放在 — Secret:
- Grafana,Prometheus,Operator,Alert Manager等等的憑證,帳密
另外還可以注意到另一個被建立的東西 — CRD:
- CRD(Custom Resource Definitions)
- 我自己大概知道這似乎應該是跟Operator配合的東西,實際一些設定值的定義在這
接下來再更深入解析Prometheus,Alertmanager,Operator元件裡面的內容:
1.StatefulSet部分:
擷取出Prometheus,及Alertmanager的StatefulSet元件內容
另外也擷取Operator的Deployment元件內容
首先Prometheus得YAML分析:
其中第一個Container — prometheus:
第二個sidecar Container — config-reloader:
而實際一些設定檔對應還要往下看到
比如這邊取上面的Secret →"prometheus-monitoring-kube-prometheus-prometheus"出來看
#抓取上述的Secret出來看:
kubectl get secret -n monitoring prometheus-monitoring-kube-prometheus-prometheus -o yaml > secret.yaml
然後可以看到內容:
假設想看看上面的Alert Rule的設定:
#透過指令把內容取出來看:
kubectl get configmap -n monitoring prometheus-monitoring-kube-prometheus-prometheus-rulefiles-0 -o yaml > configmap.yaml
這個ConfigMap內就有很個設定內容,其中一個:
然後快速看看AlertManager部分:
然後快速看看Operator部分:
結論:
我們僅僅大致瞭解,但不用完全瞭解他背後複雜系統的編排
後面應該要著重在:
- 如何增加與調整Alert的規則
- 調整Prometheus的相關設定
簡單來說就是怎麼使用Prometheus!
