Prometheus pod не может вызвать конечные точки apiserver - PullRequest
Новая
       9

Prometheus pod не может вызвать конечные точки apiserver

1 голос
/ 12 апреля 2020

Я пытаюсь настроить стек мониторинга (prometheus + alertmanager + node_exporter et c) через helm install stable/prometheus на кластер raspberry pi k8s (1 мастер + 3 рабочих узла), который я настроил.

Удалось запустить все необходимые модули. 

pi-monitoring-prometheus-alertmanager-767cd8bc65-89hxt   2/2     Running            0          131m    10.17.2.56      kube2   <none>           <none>
pi-monitoring-prometheus-node-exporter-h86gt             1/1     Running            0          131m    192.168.1.212   kube2   <none>           <none>
pi-monitoring-prometheus-node-exporter-kg957             1/1     Running            0          131m    192.168.1.211   kube1   <none>           <none>
pi-monitoring-prometheus-node-exporter-x9wgb             1/1     Running            0          131m    192.168.1.213   kube3   <none>           <none>
pi-monitoring-prometheus-pushgateway-799d4ff9d6-rdpkf    1/1     Running            0          131m    10.17.3.36      kube1   <none>           <none>
pi-monitoring-prometheus-server-5d989754b6-gp69j         2/2     Running            0          98m     10.17.1.60      kube3   <none>           <none>

однако после переадресации порта через порт 9090 сервера prometheus и перехода на страницу Targets я понял, что ни один из node_exporters не зарегистрирован.

Копаясь в журналах, я нашел это 

evel=error ts=2020-04-12T05:15:05.083Z caller=klog.go:94 component=k8s_client_runtime func=ErrorDepth msg="/app/discovery/kubernetes/kubernetes.go:333: Failed to list *v1.Node: Get https://10.18.0.1:443/api/v1/nodes?limit=500&resourceVersion=0: dial tcp 10.18.0.1:443: i/o timeout"
level=error ts=2020-04-12T05:15:05.084Z caller=klog.go:94 component=k8s_client_runtime func=ErrorDepth msg="/app/discovery/kubernetes/kubernetes.go:299: Failed to list *v1.Service: Get https://10.18.0.1:443/api/v1/services?limit=500&resourceVersion=0: dial tcp 10.18.0.1:443: i/o timeout"
level=error ts=2020-04-12T05:15:05.084Z caller=klog.go:94 component=k8s_client_runtime func=ErrorDepth msg="/app/discovery/kubernetes/kubernetes.go:261: Failed to list *v1.Endpoints: Get https://10.18.0.1:443/api/v1/endpoints?limit=500&resourceVersion=0: dial tcp 10.18.0.1:443: i/o timeout"
level=error ts=2020-04-12T05:15:05.085Z caller=klog.go:94 component=k8s_client_runtime func=ErrorDepth msg="/app/discovery/kubernetes/kubernetes.go:262: Failed to list *v1.Service: Get https://10.18.0.1:443/api/v1/services?limit=500&resourceVersion=0: dial tcp 10.18.0.1:443: i/o timeout"

Вопрос: почему модуль Prometheus не может вызывать конечные точки apiserver? Не совсем уверен, где конфигурация была сделана неправильно

Следуя инструкциям Руководство по отладке , и понял, что отдельные узлы не могут разрешить службы на других узлах.

Прошло 1 день с поиска и устранения неисправностей при чтении различных источников, но, если честно, я даже не уверен, с чего начать.

Это модули, работающие в пространстве имен kube-system. Надеюсь, что это даст лучшее представление о том, как настроена моя система. 

pi@kube4:~ $ kubectl get pods -n kube-system -o wide
NAME                            READY   STATUS    RESTARTS   AGE   IP              NODE    NOMINATED NODE   READINESS GATES
coredns-66bff467f8-nzvq8        1/1     Running   0          13d   10.17.0.2       kube4   <none>           <none>
coredns-66bff467f8-z7wdb        1/1     Running   0          13d   10.17.0.3       kube4   <none>           <none>
etcd-kube4                      1/1     Running   0          13d   192.168.1.214   kube4   <none>           <none>
kube-apiserver-kube4            1/1     Running   2          13d   192.168.1.214   kube4   <none>           <none>
kube-controller-manager-kube4   1/1     Running   2          13d   192.168.1.214   kube4   <none>           <none>
kube-flannel-ds-arm-8g9fb       1/1     Running   1          13d   192.168.1.212   kube2   <none>           <none>
kube-flannel-ds-arm-c5qt9       1/1     Running   0          13d   192.168.1.214   kube4   <none>           <none>
kube-flannel-ds-arm-q5pln       1/1     Running   1          13d   192.168.1.211   kube1   <none>           <none>
kube-flannel-ds-arm-tkmn6       1/1     Running   1          13d   192.168.1.213   kube3   <none>           <none>
kube-proxy-4zjjh                1/1     Running   0          13d   192.168.1.213   kube3   <none>           <none>
kube-proxy-6mk2z                1/1     Running   0          13d   192.168.1.211   kube1   <none>           <none>
kube-proxy-bbr8v                1/1     Running   0          13d   192.168.1.212   kube2   <none>           <none>
kube-proxy-wfsbm                1/1     Running   0          13d   192.168.1.214   kube4   <none>           <none>
kube-scheduler-kube4            1/1     Running   3          13d   192.168.1.214   kube4   <none>           <none>

Ответы [ 3 ]

0 голосов
/ 16 апреля 2020

Фланельная документация состояния:

ПРИМЕЧАНИЕ. Если используется kubeadm, тогда передайте --pod-network-cidr=10.244.0.0/16 в kubeadm init, чтобы убедиться, что установлен podCIDR.

Это потому, что фланель ConfigMap по умолчанию настроен для работы на "Network": "10.244.0.0/16"

Вы настроили свой kubeadm с --pod-network-cidr=10.17.0.0/16, теперь его необходимо настроить во фланели ConfigMap kube-flannel-cfg чтобы выглядеть так: 

kind: ConfigMap
apiVersion: v1
metadata:
  name: kube-flannel-cfg
  namespace: kube-system
  labels:
    tier: node
    app: flannel
data:
  cni-conf.json: |
    {
      "name": "cbr0",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "flannel",
          "delegate": {
            "hairpinMode": true,
            "isDefaultGateway": true
          }
        },
        {
          "type": "portmap",
          "capabilities": {
            "portMappings": true
          }
        }
      ]
    }
  net-conf.json: |
    {
      "Network": "10.17.0.0/16",
      "Backend": {
        "Type": "vxlan"
      }
    }

Спасибо @ kitt за помощь в отладке.

0 голосов
/ 17 апреля 2020

После долгих проблем я понял, что не могу пропинговать другие модули из других узлов, но могу пинговать только те из них внутри узла. Кажется, проблема связана с конфигурацией iptables, описанной здесь https://github.com/coreos/flannel/issues/699.

tl; dr: running iptables --policy FORWARD ACCEPT решил мою проблему. до обновления политика iptables 

Chain FORWARD (policy DROP)
target     prot opt source               destination
KUBE-FORWARD  all  --  anywhere             anywhere             /* kubernetes forwarding rules */
KUBE-SERVICES  all  --  anywhere             anywhere             ctstate NEW /* kubernetes service portals */
DOCKER-USER  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

проблема была решена сейчас. спасибо @kitt за помощь ранее!

0 голосов
/ 12 апреля 2020

Я подозреваю, что есть проблема с сетью, которая мешает вам связаться с сервером API. «dial tcp 10.18.0.1:443: время ожидания ввода-вывода» обычно означает, что вы не можете подключиться или прочитать данные с сервера. Вы можете использовать следующие шаги, чтобы выяснить проблему: 1. Разверните один модуль busybox, используя kubectl run busybox --image=busybox -n kube-system 2. Войдите в модуль, используя kubectl exec -n kube-system -it <podname> sh 3. Попробуйте сделать te lnet из tty, как telnet 10.18.0.1 443, чтобы выяснить проблемы с подключением

Дайте мне знать выход.

...