У нас есть кластер Kubernetes с 1 главным и 3 узлами, управляемыми kops, которые мы используем для развертывания нашего приложения. У нас минимальная возможность подключения от модуля к поду, но как и функции автомасштабирования в Kubernetes. Мы использовали это в течение последних нескольких месяцев, но недавно у нас возникла проблема, когда наши модули случайным образом не могут подключиться к нашему Redis или базе данных с ошибкой, например:
Set state pending error: dial tcp: lookup redis.id.0001.use1.cache.amazonaws.com on 100.64.0.10:53: read udp 100.126.88.186:35730->100.64.0.10:53: i/o timeout
or
OperationalError: (psycopg2.OperationalError) could not translate host name “postgres.id.us-east-1.rds.amazonaws.com” to address: Temporary failure in name resolution
Что странно, это происходит только иногда, затем, когда модуль воссоздается, он снова будет работать, и это приведет к его отключению вскоре после этого.
Мы безуспешно пытались следовать всем инструкциям Kube по отладке kube-dns, пробовали бесчисленное количество решений, таких как изменение конфигурации ndots, и даже экспериментировали с переходом на CoreDNS, но по-прежнему имеем те же периодические проблемы. Мы используем Calico для работы в сети, но трудно сказать, происходит ли это на сетевом уровне, поскольку мы не наблюдали проблем с какими-либо другими сервисами.
Есть ли у кого-нибудь идеи, где еще искать причину такого поведения, или, если вы испытали такое поведение раньше, не могли бы вы рассказать, как вы его разрешили?
Спасибо
Поды для CoreDNS выглядят нормально
⇒ kubectl get pods --namespace=kube-system
NAME READY STATUS RESTARTS AGE
...
coredns-784bfc9fbd-xwq4x 1/1 Running 0 3h
coredns-784bfc9fbd-zpxhg 1/1 Running 0 3h
...
Мы включили ведение журнала на CoreDNS и увидели, что запросы действительно проходят:
⇒ kubectl logs coredns-784bfc9fbd-xwq4x --namespace=kube-system
.:53
2019-04-09T00:26:03.363Z [INFO] CoreDNS-1.2.6
2019-04-09T00:26:03.364Z [INFO] linux/amd64, go1.11.2, 756749c
CoreDNS-1.2.6
linux/amd64, go1.11.2, 756749c
[INFO] plugin/reload: Running configuration MD5 = 7f2aea8cc82e8ebb0a62ee83a9771ab8
[INFO] Reloading
[INFO] plugin/reload: Running configuration MD5 = 73a93c15a3b7843ba101ff3f54ad8327
[INFO] Reloading complete
...
2019-04-09T02:41:08.412Z [INFO] 100.126.88.129:34958 - 18745 "AAAA IN sqs.us-east-1.amazonaws.com.cluster.local. udp 59 false 512" NXDOMAIN qr,aa,rd,ra 152 0.000182646s
2019-04-09T02:41:08.412Z [INFO] 100.126.88.129:51735 - 62992 "A IN sqs.us-east-1.amazonaws.com.cluster.local. udp 59 false 512" NXDOMAIN qr,aa,rd,ra 152 0.000203112s
2019-04-09T02:41:13.414Z [INFO] 100.126.88.129:33525 - 52399 "A IN sqs.us-east-1.amazonaws.com.ec2.internal. udp 58 false 512" NXDOMAIN qr,rd,ra 58 0.001017774s
2019-04-09T02:41:18.414Z [INFO] 100.126.88.129:44066 - 47308 "A IN sqs.us-east-1.amazonaws.com. udp 45 false 512" NOERROR qr,rd,ra 140 0.000983118s
...
Сервис и конечные точки выглядят нормально
⇒ kubectl get svc --namespace=kube-system
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 100.64.0.10 <none> 53/UDP,53/TCP 63d
...
⇒ kubectl get ep kube-dns --namespace=kube-system
NAME ENDPOINTS AGE
kube-dns 100.105.44.88:53,100.127.167.160:53,100.105.44.88:53 + 1 more... 63d
...
