Есть кластер Kubernetes, на котором запущен kube-state-metrics. Его слушает Metricbeat, который всё отправляет в ElasticSearch. Всё было настроено по мануалу: https://www.elastic.co/guide/en/beats/metricbeat/7.3/running-on-kubernetes.html
https://github.com/kubernetes/kube-state-metrics
https://raw.githubusercontent.com/elastic/beats/7.3/deploy/kubernetes/metricbeat-kubernetes.yaml
После нескольких перезагрузок сбор данных перестал работать. Логи метрикбита, слушающего kube-state-metrics, показывают кучу однотипных предупреждений и ошибок:
# kubectl -n kube-system logs metricbeat-655fb5c85f-4zxqp
...
2019-11-07T11:24:41.356Z ERROR [kubernetes.state_deployment] state_deployment/state_deployment.go:98 error making http request: Get http://kube-state-metrics:8080/metrics: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
2019-11-07T11:24:41.357Z WARN transport/tcp.go:53 DNS lookup failure "kube-state-metrics": lookup kube-state-metrics on 10.96.0.10:53: read udp 172.30.200.5:36826->10.96.0.10:53: i/o timeout
...
(На всякий случай: metricbeat 7.4.* не использую из-за ошибок с правами, а образа для 7.5 пока нет.)
Сам kube-state-metrics работает, вроде, нормально:
# kubectl -n kube-system logs kube-state-metrics-5458dddb44-nkzgt
I1107 10:19:08.608278 1 main.go:86] Using default collectors
I1107 10:19:08.608328 1 main.go:98] Using all namespace
I1107 10:19:08.608338 1 main.go:139] metric white-blacklisting: blacklisting the following items:
W1107 10:19:08.608371 1 client_config.go:541] Neither --kubeconfig nor --master was specified. Using the inClusterConfig. This might not work.
I1107 10:19:08.609575 1 main.go:184] Testing communication with server
I1107 10:19:08.615311 1 main.go:189] Running with Kubernetes cluster version: v1.14. git version: v1.14.3. git tree state: clean. commit: 5e53fd6bc17c0dec8434817e69b04a25d8ae0ff0. platform: linux/amd64
I1107 10:19:08.615644 1 main.go:191] Communication with server successful
I1107 10:19:08.615739 1 main.go:225] Starting metrics server: 0.0.0.0:8080
I1107 10:19:08.615901 1 metrics_handler.go:96] Autosharding disabled
I1107 10:19:08.616285 1 builder.go:144] Active collectors: certificatesigningrequests,configmaps,cronjobs,daemonsets,deployments,endpoints,horizontalpodautoscalers,ingresses,jobs,limitranges,namespaces,nodes,persistentvolumeclaims,persistentvolumes,poddisruptionbudgets,pods,replicasets,replicationcontrollers,resourcequotas,secrets,services,statefulsets,storageclasses
I1107 10:19:08.616887 1 main.go:200] Starting kube-state-metrics self metrics server: 0.0.0.0:8081
Диагностика kube-dns, как описано в мануале:
# for p in $(kubectl get pods --namespace=kube-system -l k8s-app=kube-dns -o name); do kubectl logs --namespace=kube-system $p; done показывает ошибки сутки назад, но свежих ошибок нет.
Адреса coredns 10.244.0.13 и 10.244.0.10.
Что означает lookup kube-state-metrics on 10.96.0.10:53: read udp 172.30.200.5:36826->10.96.0.10:53: i/o timeout ?
172.30.200.5 — адрес ноды, на которой работают Metricbeat и kube-state-metrics. Куда и зачем он лезет? Ищет DNS там, где его нет?
Ответ: причина глюков — неверная информация в /run/flannel/subnet.env После восстановления старого файла, всё заработало.
