Prometheus部署以及问题解决

Prometheus作用：

Prometheus监控（Prometheus Monitoring）是一种开源的体系监控和警报工具。它最初由SoundCloud开发并于2012年发布，并在2016年加入了云原生计算基金会（CNCF）。Prometheus监控旨在网络、存储和查询各种指标数据，以资助用户监督其应用步伐和体系的性能和运行状态。
部署流程：

本文采用Prometheus来监控k8s集群资源状态，并解决alertmanager 9093端口连接拒绝的问题
1.根据k8s集群版本下载对应矩阵的Prometheus版本

1. # 我的k8s集群版本为1.26.9，所以我下载0.13版本
3. wget https://mirror.ghproxy.com/https://github.com/prometheus-operator/kube-prometheus/archive/refs/tags/v0.13.0.zip
6. # 下载完成后解压即可使用
8. unzip v0.13.0.zip

复制代码

2.进入解压出来的目录，自定义配置告警规则和邮件推送（看需求）

1. cd kube-prometheus-0.13.0/manifests/
3. # 该文件配置告警规则
5. vim prometheus-prometheusRule.yaml
7. # 该文件配置告警推送
9. vim alertmanager-secret.yaml

复制代码

3.部署Prometheus监控和删除

1. kubectl apply --server-side -f manifests/setup -f manifests
3. # 移除Prometheus
5. kubectl delete --ignore-not-found=true -f manifests/ -f manifests/setup
8. # 以下为部署完成后正常的资源状态

复制代码

1. # 如果没有部署ingress则需要更改以下几个svc配置文件，将svc类型改为NodePort才能对外访问
3. kubectl -n monitoring edit svc alertmanager-main
5. kubectl -n monitoring edit svc prometheus-k8s
7. kubectl -n monitoring edit svc grafana
10. # 删除对应的网络策略，它默认限制了出口和入口流量，即便使用了 NodePort 类型的 svc 或者 ingress 也无法直接访问
12. kubectl -n monitoring delete networkpolicy --all

复制代码

4.接下来说一下我之前碰到的问题

1. # 在我部署Prometheus监控服务的时候，我的alertmanager一直无法正常启动，查看状态发现了报错信息
3. kubectl -n monitoring describe pod alertmanager-main-1
5. # dial tcp 10.244.135.151:9093 connection refused

复制代码

1. # 最开始在github官网查看issue时，发现有人遇到了相同的问题，并且也有人给出了解决办法，我试着按照他的方法解决，没成功。他要修改sts里的文件内容，你改了就会发现不管你怎么改，它都不会生效，并且你还删不掉它的sts，该sts是由（crd）自定义资源alertmanager main所控制的，你只有修改这个或者删除这个资源才能停掉sts
3. kubectl -n monitoring edit alertmanager main
5. kubectl -n monitoring delete alertmanager main

复制代码

1. # 起初想着可能是探针超时时间太短了导致它一直无法通过检测，就修改了alertmanager main的文件，更改超时时间为300s，但还是有问题。后面把探针给它注释掉，不让它检测发现还是有问题。最后是直接把容器的端口给注释掉了，让它通过域名查找，发现了真正的问题
3. kubectl -n monitoring get alertmanager main -o yaml >
4. dump-modify.yaml
7. vim dump-modify.yaml
9. apiVersion: monitoring.coreos.com/v1
10. kind: Alertmanager
11. metadata:
12.   creationTimestamp: "2024-08-19T08:12:24Z"
13.   generation: 1
14.   labels:
15.     app.kubernetes.io/component: alert-router
16.     app.kubernetes.io/instance: main
17.     app.kubernetes.io/name: alertmanager
18.     app.kubernetes.io/part-of: kube-prometheus
19.     app.kubernetes.io/version: 0.26.0
20.   name: main
21.   namespace: monitoring
22.   resourceVersion: "510527"
23.   uid: ee407f56-bffa-4191-baa7-e458e7a1b9ff
24. spec:
25.   image: quay.io/prometheus/alertmanager:v0.26.0
26.   nodeSelector:
27.     kubernetes.io/os: linux
28.   podMetadata:
29.     labels:
30.       app.kubernetes.io/component: alert-router
31.       app.kubernetes.io/instance: main
32.       app.kubernetes.io/name: alertmanager
33.       app.kubernetes.io/part-of: kube-prometheus
34.       app.kubernetes.io/version: 0.26.0
35.   portName: web
36.   replicas: 3
37.   logLevel: debug
38.   resources:
39.     limits:
40.       cpu: 100m
41.       memory: 100Mi
42.     requests:
43.       cpu: 4m
44.       memory: 100Mi
45.   retention: 120h
46.   securityContext:
47.     fsGroup: 2000
48.     runAsNonRoot: true
49.     runAsUser: 1000
50.   serviceAccountName: alertmanager-main
51.   version: 0.26.0
52.   containers:
53.   - args:
54.     - --config.file=/etc/alertmanager/config_out/alertmanager.env.yaml
55.     - --storage.path=/alertmanager
56.     - --data.retention=120h
57.     - --cluster.listen-address=[$(POD_IP)]:9094
58.     - --web.listen-address=:9093
59.     - --web.route-prefix=/
60.     - --cluster.peer=alertmanager-main-0.alertmanager-operated:9094
61.     - --cluster.peer=alertmanager-main-1.alertmanager-operated:9094
62.     - --cluster.peer=alertmanager-main-2.alertmanager-operated:9094
63.     - --cluster.reconnect-timeout=5m
64.     - --web.config.file=/etc/alertmanager/web_config/web-config.yaml
65.     env:
66.     - name: POD_IP
67.       valueFrom:
68.         fieldRef:
69.           apiVersion: v1
70.           fieldPath: status.podIP
71.     image: quay.io/prometheus/alertmanager:v0.26.0
72.     imagePullPolicy: IfNotPresent
73.     livenessProbe:
74.       failureThreshold: 10
75.       httpGet:
76.         path: /
77.         port: 443
78.         scheme: HTTPS
79.         host: example.com
80.       periodSeconds: 10
81.       successThreshold: 1
82.       timeoutSeconds: 3
83.     name: alertmanager
84.     # ports:
85.     # - containerPort: 9093
86.     #   name: web
87.     #   protocol: TCP
88.     # - containerPort: 9094
89.     #   name: mesh-tcp
90.     #   protocol: TCP
91.     # - containerPort: 9094
92.     #   name: mesh-udp
93.     #   protocol: UDP
94.     readinessProbe:
95.       failureThreshold: 10
96.       httpGet:
97.         path: /
98.         port: 443
99.         scheme: HTTPS
100.         host: example.com
101.       initialDelaySeconds: 3
102.       periodSeconds: 5
103.       successThreshold: 1
104.       timeoutSeconds: 3
105.     resources:
106.       limits:
107.         cpu: 100m
108.         memory: 100Mi
109.       requests:
110.         cpu: 4m
111.         memory: 100Mi
112.     securityContext:
113.       allowPrivilegeEscalation: false
114.       capabilities:
115.         drop:
116.         - ALL
117.       readOnlyRootFilesystem: true
118.     terminationMessagePath: /dev/termination-log
119.     terminationMessagePolicy: FallbackToLogsOnError
120.     volumeMounts:
121.     - mountPath: /etc/alertmanager/config
122.       name: config-volume
123.     - mountPath: /etc/alertmanager/config_out
124.       name: config-out
125.       readOnly: true
126.     - mountPath: /etc/alertmanager/certs
127.       name: tls-assets
128.       readOnly: true
129.     - mountPath: /alertmanager
130.       name: alertmanager-main-db
131.     - mountPath: /etc/alertmanager/web_config/web-config.yaml
132.       name: web-config
133.       readOnly: true
134.       subPath: web-config.yaml
135. # status:
136. #   availableReplicas: 0
137. #   conditions:
138. #   - lastTransitionTime: "2024-08-19T08:12:28Z"
139. #     message: |-
140. #       pod alertmanager-main-1: containers with incomplete status: [init-config-reloader]
141. #       pod alertmanager-main-2: containers with incomplete status: [init-config-reloader]
142. #     observedGeneration: 1
143. #     reason: NoPodReady
144. #     status: "False"
145. #     type: Available
146. #   - lastTransitionTime: "2024-08-19T08:12:28Z"
147. #     observedGeneration: 1
148. #     status: "True"
149. #     type: Reconciled
150. #   paused: false
151. #   replicas: 3
152. #   unavailableReplicas: 3
153. #   updatedReplicas: 3
156. # 删除已有的main资源
158. kubectl -n monitoring delete alertmanager main
160. # 重新创建main资源
162. kubectl -n monitoring apply -f dump-modify.yaml

复制代码

1. # 查看sts的日志发现报错信息提示说dns解析有问题，于是就去查看k8s组件coredns的信息，发现了问题所在，我的k8s集群采用的高可用部署方案，网络插件为calico，集群地址为10.10.40.100-105，service网段为10.96.0.0/16，pod网段为10.244.0.0/16，而这个coredns网段却是10.88.0.0/16网段的
3. kubectl -n monitoring logs sts alertmanager
5. kubectl get pod -A -o wide

复制代码

1. # 于是查看cni网络组件信息，看到所有节点都有这个cni0的网卡，这个网卡是安装了flannel网络组件才会提供的，问题就出在这里，calico网络组件提供的网卡是calic741a2df36d@if2的网卡名称，所以将原本的coredns删除掉后，网络就恢复正常了
3. # 此时再将整个Prometheus服务删除重新部署就恢复正常了
6. ls -l /etc/cni/net.d/
9. # 两个都要删
11. kubectl -n kube-system delete pod coredns-5bbd96d687-gtl9r
14. kubectl -n kube-system get pod -o wide

复制代码

总结

1. # 不管部署一套什么服务，pod能跑起来，跨节点pod和pod之间能互相访问就不是网络问题，像这种个别pod有问题的，就查看报错，只要发现是端口拒绝之类的优先检查k8s组件coredns的问题，有奇效，当然还是得根据实际情况而论。
3. # 如果部署集群有问题的时候，给它改成单节点测试也是很好的排错方式。

复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。