Microk8s on RaspberryPI: Prometheus服务发现没有正确地找到主节点作为目标，重复一个工作节点

Question

作为培训平台，我在3个microk8s 4s上设置了一个RaspberryPI集群。原则上，它工作得很好，我可以部署应用程序等等。因为它是由3个节点组成的，它也自动使高可用性成为可能。

master node 192.168.1.225
worker node1 192.168.1.226
worker node2 192.168.1.227

https://microk8s.io/high-availability是说microk8s正在使用所有节点--甚至是主节点--来执行工作负载。为了验证，我安装了prometheus/grafana堆栈来查看集群度量。

但是，看起来主节点只被prometheus正确地发现为目标，参见下面prometheus的截图。禁用&重新启用prometheus没有修复该问题。

显然，在Grafana中，我也可以看到工作节点，而不是master。它感觉有点像主节点没有被视为工作节点-但是它应该是因为它提供了集群的能力。

知道怎么修吗？

kube api目标看起来不错

kubelet不是概述主节点，而是重复工作节点

节点导出仅在工作节点上

microk8s状态的输出：

microk8s statusmicrok8s is running
high-availability: yes
  datastore master nodes: 192.168.1.225:19001 192.168.1.226:19001 192.168.1.227:19001
  datastore standby nodes: none
addons:
  enabled:
    dashboard            # The Kubernetes dashboard
    dns                  # CoreDNS
    ha-cluster           # Configure high availability on the current node
    helm3                # Helm 3 - Kubernetes package manager
    ingress              # Ingress controller for external access
    metallb              # Loadbalancer for your Kubernetes cluster
    metrics-server       # K8s Metrics Server for API access to service metrics
    prometheus           # Prometheus operator for monitoring and logging
  disabled:
    dashboard-ingress    # Ingress definition for Kubernetes dashboard
    helm                 # Helm 2 - the package manager for Kubernetes
    host-access          # Allow Pods connecting to Host services smoothly
    linkerd              # Linkerd is a service mesh for Kubernetes and other frameworks
    openebs              # OpenEBS is the open-source storage solution for Kubernetes
    portainer            # Portainer UI for your Kubernetes cluster
    rbac                 # Role-Based Access Control for authorisation
    registry             # Private image registry exposed on localhost:32000
    storage              # Storage class; allocates storage from host directory
    traefik              # traefik Ingress controller for external access

普罗米修斯命名空间中的豆荚：

microk8s.kubectl get pods -n monitoring
NAME                                   READY   STATUS    RESTARTS      AGE
node-exporter-dkhks                    2/2     Running   2 (11d ago)   11d
prometheus-adapter-5b7fb5c557-2bbqs    1/1     Running   2 (11d ago)   11d
prometheus-operator-667757c7b9-7ll9v   2/2     Running   4 (24h ago)   11d
alertmanager-main-0                    2/2     Running   4 (24h ago)   11d
node-exporter-qc467                    2/2     Running   4 (24h ago)   11d
grafana-59f6895cb8-28dmn               1/1     Running   2 (24h ago)   11d
blackbox-exporter-5c4d9867d6-57wxv     3/3     Running   6 (24h ago)   11d
prometheus-k8s-0                       2/2     Running   3 (24h ago)   11d
prometheus-adapter-5b7fb5c557-dfx6v    1/1     Running   3 (24h ago)   11d
kube-state-metrics-bbd47c478-4qb54     3/3     Running   7 (24h ago)   11d

Answer 1

看起来，在加入第三个节点后，高可用性被自动激活，但是仍然是原始的主节点被不同的对待(例如。是节点出现在“获取节点”中)。

离开并加入集群后，所有节点现在都按预期工作，节点运算符将在所有节点上执行。但是worker node1在prometheus目标中是复制的，所以我将检查是否重新加入修复了这个问题。

microk8s.kubectl get pods -n monitoring

名称就绪状态重新启动

年龄prometheus-适配器-5b7fb5c557-cqxsw 1/1运行0 22h

节点-出口商-mxdjw 2/2运行0 22h

prometheus-operator-667757c7b9-5724x2/2运行0 22h

prometheus-k8s-0 2/2运行1(22 h前)22 h

黑匣子-出口商-5c4d9867d6-ct9q7 3/3运行0 22h

警报管理器-主-0 2/2运行0 22h

prometheus-适配器-5b7fb5c557-xjn2s1/1运行0 22h

节点-出口商-dpkgg 2/2运行0 22h

kube状态度量-bbd47c478-82vkk 3/3运行0 22h

格拉法纳-59f6895cb8-qkx7p1/1运行0 22h

节点-出口商-5 5tgfw 2/2运行0 4 h45m