共计 5525 个字符，预计需要花费 14 分钟才能阅读完成。
简介
- 系列文章: 标签 – Prometheus – 东风微鸣技术博客 (ewhisper.cn)
- Prometheus Operator 的上一篇: Prometheus Operator 与 kube-prometheus 之一 – 简介 – 东风微鸣技术博客 (ewhisper.cn)
kube-prometheus-stack 捆绑了监控 Kubernetes 集群所需的 Prometheus Operator、Exporter、Rule、Grafana 和 AlertManager。
但要为应用 kubeadm 构建的 Kubernetes 集群定制 Helm 装置，还是有必要进行定制。
这一次联合近期比拟新的 Kubernetes 版本 v1.23+, 以及较为常见的装置形式 kubeadm, 来实战阐明:
- kubeadm 须要哪些非凡配置
- 如何装置 Prometheus Operator: 通过 kube-prometheus-stack helm chart
- 如何配置对 kubeadm 装置的集群的组件监控
开始!
前提条件
- kubeadm
- helm3
kubeadm 须要哪些非凡配置
为了前面可能失常通过 Prometheus Operator 获取到 kubeadm 搭建的 Kubernetes v1.23+ 集群的指标, 须要对 kubeadm 做一些非凡配置.
默认状况下，kubeadm 将它的几个治理组件绑定到 node 的 localhost 127.0.0.1 地址上, 波及到: Kube Controller Manager、Kube Proxy 和 Kube Scheduler。
然而，对于监控来说，咱们须要这些端点的裸露，以便他们的指标能够被 Prometheus 提取。因而，咱们须要将这些组件裸露在他们的 0.0.0.0 地址上。
当登录到 kubeadm 主节点时，运行以下批改:
Controller Manager 和 Scheduler 组件
默认状况下，kubeadm 并没有公开咱们要监控的两个服务(kube-controller-manager 和 kube-scheduler)。因而，为了充分利用kube-prometheus-stack helm chart，咱们须要对 Kubernetes 集群做一些疾速调整。前面咱们会监控 kube-controller-manager 和 kube-scheduler，咱们必须将它们的地址端口裸露给集群。
默认状况下，kubeadm 在你的主机上运行这些 pod，并绑定到 127.0.0.1。有几种办法能够扭转这一点。倡议扭转这些配置的办法是应用 kubeadm config file。上面是配置示例:
| apiVersion: kubeadm.k8s.io/v1beta2 | |
| kind: ClusterConfiguration | |
| ... | |
| controllerManager: | |
| extraArgs: | |
| bind-address: "0.0.0.0" | |
| scheduler: | |
| extraArgs: | |
| bind-address: "0.0.0.0" | |
| ... | |
| kubernetesVersion: "v1.23.1" | |
| ... |
🐾下面的 .scheduler.extraArgs 和 .controllerManager.extraArgs。这样就把 kube-controller-manager 和 kube-scheduler 服务裸露给集群的其余组件。
另外, 如果你把 kubernetes 外围组件作为 pods 放在 kube-system namespace，就要确保 kube-prometheus-exporter-kube-scheduler 和 kube-prometheus-exporter-kube-controller-manager service (这 2 个 service 是 kube-prometheus-stack 创立进去用于 Prometheus Operator 通过 ServiceMonitor 监控这两个组件用的) 的spec.selector 值与 pods 的值统一。
如果你曾经有一个部署了 kubeadm 的 Kubernetes，能够间接 kube-controller-manager 和 kube-scheduler 的监听地址:
| sed -e "s/- --bind-address=127.0.0.1/- --bind-address=0.0.0.0/" -i /etc/kubernetes/manifests/kube-controller-manager.yaml | |
| sed -e "s/- --bind-address=127.0.0.1/- --bind-address=0.0.0.0/" -i /etc/kubernetes/manifests/kube-scheduler.yaml |
Kube Proxy 组件
📝Notes:
个别状况下, kube-proxy 总是绑定所有地址的, 然而对应的metricsBindAddress可能并不一定会 follow 配置. 具体如上面的 ” 改变前 ”
对于 Kube Proxy 组件, 在应用 kubeadm 装置实现之后, 须要批改 kube-system 下的 configmap kube-proxy 的 metricsBindAddress.
改变如下:
改变前:
| ... | |
| kind: KubeProxyConfiguration | |
| bindAddress: 0.0.0.0 | |
| metricsBindAddress: 127.0.0.1:10249 | |
| ... |
改变后:
| kind: KubeProxyConfiguration | |
| bindAddress: 0.0.0.0 | |
| metricsBindAddress: 0.0.0.0:10249 |
并重启:
kubectl -n kube-system rollout restart daemonset/kube-proxy
Etcd 配置
Etcd 配置, 这里就不具体阐明了, 能够间接参见: Prometheus Operator 监控 etcd 集群 - 阳明的博客
然而下面链接提到的办法比拟麻烦, 举荐一个更简略的: 能够在 etcd 的配置中加上监听 Metrics URL 的 flag:
| # 在 etcd 所在的机器上 | |
| master_ip=192.168.1.5 | |
| sed -i "s#--listen-metrics-urls=.*#--listen-metrics-urls=http://127.0.0.1:2381,http://$master_ip:2381#" /etc/kubernetes/manifests/etcd.yaml |
验证 kubeadm 配置
小结一下, 通过之前的这些配置, Kubernetes 组件的 Metrics 监听端口别离为:
-
Controller Manager: (Kubernetes v1.23+)
- 端口: 10257
- 协定: https
-
Scheduler: (Kubernetes v1.23+)
- 端口: 10259
- 协定: https
-
Kube Proxy
- 端口: 10249
- 协定: http
-
etcd
- 端口: 2381
- 协定: http
能够通过 netstat 命令查看之前的配置是否全副失效:
在 master 和 etcd node 上执行:
| $ sudo netstat -tulnp | grep -e 10257 -e 10259 -e 10249 -e 2381 | |
| tcp 0 0 192.168.1.5:2381 0.0.0.0:* LISTEN 1400/etcd | |
| tcp 0 0 127.0.0.1:2381 0.0.0.0:* LISTEN 1400/etcd | |
| tcp6 0 0 :::10257 :::* LISTEN 1434/kube-controlle | |
| tcp6 0 0 :::10259 :::* LISTEN 1486/kube-scheduler | |
| tcp6 0 0 :::10249 :::* LISTEN 4377/kube-proxy | |
| # 测试 etcd 指标 | |
| curl -k http://localhost:2381/metrics | |
| # 测试 kube-proxy 指标 | |
| curl -k http://localhost:10249/metrics |
通过 kube-prometheus-stack 装置并定制 helm values
这里间接实现下面提到的 2 步:
- 如何装置 Prometheus Operator: 通过 kube-prometheus-stack helm chart
- 如何配置对 kubeadm 装置的集群的组件监控
在咱们用 Helm 装置 kube-prometheus-stack 之前，咱们须要创立一个 values.yaml 来调整 kubeadm 集群的默认 chart value。
为 Prometheus 和 AlertManager 配置长久化存储
举荐要为 Prometheus 和 AlertManager 配置长久化存储, 而不要间接应用 emptyDir.
存储具体如何配置依据您的集群的理论状况来, 这边就不做过多介绍.
- Prometheus 的配置改这里
- AlertManager 的配置改这里
etcd 相干配置
Kubeadm etcd 监控的端口是 2381（而不是 Helm chart 中指定的默认值: 2379）]，所以咱们须要明确笼罩这个值。
| kubeEtcd: | |
| enabled: true | |
| service: | |
| enabled: true | |
| port: 2381 | |
| targetPort: 2381 |
Controller Manger 相干配置
这里不须要做太多配置, 对于 https 和 端口, 如果相干 key 为空或未设置，该值将依据指标 Kubernetes 版本动静确定，起因是默认端口在 Kubernetes 1.22 中的变动。留神上面的: .kubeControllerManager.service.port 和 .kubeControllerManager.service.targetPort 以及 .kubeControllerManager.serviceMonitor.https 和 .kubeControllerManager.serviceMonitor.insecureSkipVerify.
如果配置后监控抓不到或有异样, 能够按理论状况调整.
| kubeControllerManager: | |
| enabled: true | |
| ... | |
| service: | |
| enabled: true | |
| port: null | |
| targetPort: null | |
| serviceMonitor: | |
| enabled: true | |
| ... | |
| https: null | |
| insecureSkipVerify: null | |
| ... |
Kubernetes Scheduler
同上, 这里不须要做太多配置, 对于 https 和 端口, 如果相干 key 为空或未设置，该值将依据指标 Kubernetes 版本动静确定，起因是默认端口在 Kubernetes 1.23 中的变动。留神上面的: .kubeScheduler.service.port 和 .kubeScheduler.service.targetPort 以及 .kubeScheduler.serviceMonitor.https 和 .kubeScheduler.serviceMonitor.insecureSkipVerify.
如果配置后监控抓不到或有异样, 能够按理论状况调整.
| kubeScheduler: | |
| enabled: true | |
| ... | |
| service: | |
| enabled: true | |
| port: 10259 | |
| targetPort: 10259 | |
| serviceMonitor: | |
| enabled: true | |
| ... | |
| https: true | |
| insecureSkipVerify: true | |
| ... |
Kubernetes Proxy
也是如此, 依据 是否 https 和 端口进行调整, 如下:
| kubeProxy: | |
| enabled: true | |
| endpoints: [] | |
| service: | |
| enabled: true | |
| port: 10249 | |
| targetPort: 10249 | |
| serviceMonitor: | |
| enabled: true | |
| ... | |
| https: false | |
| ... |
通过 Helm 装置 kube-prometheus-stack
增加 Helm 仓库:
| helm repo add prometheus-community https://prometheus-community.github.io/helm-charts | |
| helm repo list | |
| helm repo update prometheus-community |
装置:
| helm upgrade --install \ | |
| --namespace prom \ | |
| --create-namespace \ | |
| -f values.yaml \ | |
| monitor prometheus-community/kube-prometheus-stack |
验证
这里次要验证 kubeadm 的 Kubernetes 组件有没有失常监控到, 能够通过 Prometheus UI 或 Grafana UI 间接查看进行验证.
能够通过 Ingress 或 NodePort 将 Prometheus UI 或 Grafana UI 地址裸露进来, 而后拜访:
Status -> Targets 查看监控状态, 这里举几个组件来进行阐明:
Grafana 能够间接登录后查看对应的仪表板, 如下图:
🎉🎉🎉
📚️ 参考文档
- helm-charts/charts/kube-prometheus-stack at main · prometheus-community/helm-charts (github.com)
- Deploy to kubeadm – Prometheus Operator (prometheus-operator.dev)
- Prometheus Operator 监控 etcd 集群 - 阳明的博客
- Prometheus: installing kube-prometheus-stack on a kubeadm cluster | Fabian Lee : Software Engineer
本文由博客一文多发平台 OpenWrite 公布！
