关于linux:Prometheus-Operator与kubeprometheus之二如何监控123-kubeadm集群

1次阅读

共计 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 公布！

正文完
linux
发表至： linux
2022-11-24
 0
日志服务器搭建之多服务器日志转发与格式化处理
基于Rainbond实现微服务的滚动发布蓝绿发布及灰度发布
关于linux:Linux常用命令
关于linux:Linux命令后台运行

站内搜索

-「」