LINUX.ORG.RU
решено ФорумAdmin

Перезагрузили — перестали ресолвиться имена

 , ,


0

1

Есть кластер 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 После восстановления старого файла, всё заработало.

★★

Я с миникубом тестил, УМВР, только после рестарта хоста маршрут слетает.

Вот мой мини отчет, может, пригодится:

Было выполнено на версиях:

OS: Ubuntu 18.04 bionic
Kernel: x86_64 Linux 4.15.0-65-generic

minikube version: v1.4.0
commit: 7969c25a98a018b94ea87d949350f3271e9d64b6

kubectl version
Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.1", GitCommit:"d647ddbd755faf07169599a625faf302ffc34458", GitTreeState:"clean", BuildDate:"2019-10-02T17:01:15Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.4", GitCommit:"67d2fcf276fcd9cf743ad4be9a9ef5828adc082f", GitTreeState:"clean", BuildDate:"2019-09-18T14:41:55Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

helm version
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Error: could not find tiller

gitlab-runner --version
Version:      12.3.0
Git revision: a8a019e0
Git branch:   12-3-stable
GO version:   go1.8.7
Built:        2019-09-20T08:27:24+0000
OS/Arch:      linux/amd64

# Ссылка на оригинальный мануал https://stevesloka.com/access-minikube-service-from-linux-host/

# Enable dnsmasq for lookups by editing the file /etc/NetworkManager/NetworkManager.conf and under the [main] section, add the following:
dns=dnsmasq

# Рестарт NetworkManager (если нужен):
sudo systemctl restart NetworkManager

# Запустить локально minikube:
# helm с новым api будет работать начиная с версии 2.15.3; на текущий момент доступна: v2.14.3, потому надо указать ключ --kubernetes-version=v1.15.4

############################################
minikube start --cpus 2 --memory 2048 --kubernetes-version=v1.15.4 --service-cluster-ip-range=10.96.0.0/24 --extra-config=kubelet.resolv-conf=/etc/resolv.conf
############################################

# настройка доступа по ssh в vm minikube:
vi /etc/ssh/sshd_config
PermitRootLogin yes
PermitEmptyPasswords yes

# Включить ingress в миникубе:
minikube addons enable ingress

# Просмотр настроек kubelet

kubectl describe cm -n kube-system kubelet-config-1.15

# адрес DNS сервера (ссылка на доку https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/)
kubectl exec -ti busybox -- nslookup kubernetes.default

# пример вывода:
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local # - адрес днс сервера

Name:      kubernetes.default
Address 1: 10.96.0.1 kubernetes.default.svc.cluster.local

# Add a file named svc.cluster.local to /etc/NetworkManager/dnsmasq.d with the following contents: 
server=/svc.cluster.local/10.96.0.10
local=/svc.cluster.local/ 

# Edit the file /etc/nsswitch.conf, find the path hosts: and change it to look like this:
hosts:      files dns myhostname mdns4_minimal

# Прописать маршрут:
sudo ip route add 10.96.0.0/24 via $(minikube ip)

# Проверить маршруты:
netstat -r

redwagon ()
Ответ на: комментарий от olegd

В логах ошибок нет, describe тоже ошибок не показывает. Как ещё проверить?

https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/#are-dns-queries-being-received-processed

kubectl -n kube-system edit configmap coredns , добавить в конфиг log и сохранить. Сразу посыпались ошибки. Обдумываем…

Что это может значить?

2019-11-07T13:57:57.861Z [ERROR] plugin/errors: 0 7513806063932652507.5197276893597520510. HINFO: read udp 10.244.0.13:58125->8.8.8.8:53: i/o timeout
2019-11-07T13:58:00.861Z [INFO] 127.0.0.1:53805 - 56827 "HINFO IN 7513806063932652507.5197276893597520510. udp 57 false 512" SERVFAIL qr,rd 57 2.000242827s
olegd ★★ ()
Последнее исправление: olegd (всего исправлений: 2)
Ответ на: комментарий от olegd

Вот что пишут, и это похоже на правду:

It looks like there is some kind of networking configuration problem in your Kubernetes cluster, not a configuration problem with CoreDNS. Your Kubernetes cluster is not creating a route to 8.8.8.8.

redwagon ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.