K8s - Разрешение DNS между модулями в разных пространствах имен

У меня есть простой модуль в пространстве имен с именем "a" , а другой модуль в пространстве имен "b" ...

У меня также есть тестовый скрипт, который делает вызов grpc от "a" до "b" .

  1. Этот сценарий не работает при использовании полного доменного имени (например, «some-service.b.cluster.local»)
  2. Этот скрипт работает, если используется точный IP-адрес модуля в пространстве имен "b"

Я полагаю, что в DNS Resolution есть какая-то ошибка, но я не могу двигаться дальше.

Любая помощь?

kubectl exec -n a somepod-f647b7d95-mrvfr cat /etc/resolv.conf

nameserver 10.12.0.10
search chimera.svc.cluster.local svc.cluster.local cluster.local c.<company-name>-staging.internal <provider>.internal
options ndots:5
kubectl get pods -n kube-system

event-exporter-v0.2.4-6d4c69fbfb-f4xpf                           1/1     Running   0          24d
fluentd-gcp-scaler-6965bb45c9-mzvw6                              1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-2m2bf                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-2v6bq                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-4xpbc                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-7g5hm                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-8mqvc                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-f9hrs                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-fr58c                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-hzrsb                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-kq8hc                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-kt6p5                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-nsztm                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-qcl4r                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-qggv9                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-qkkp5                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-rm9hn                                         1/1     Running   0          5d5h
fluentd-gcp-v3.2.0-sv52h                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-t75fp                                         1/1     Running   0          7d6h
fluentd-gcp-v3.2.0-v49fv                                         1/1     Running   0          7d6h
kube-dns-6cd7bbdf65-jnntn                                        4/4     Running   0          24d
kube-dns-6cd7bbdf65-txmlj                                        4/4     Running   0          24d
kube-dns-autoscaler-8687c64fc-29jgq                              1/1     Running   0          7d6h
kube-proxy-gke-iceberg-api-v2-201908101259587443-01f0b55b-q0k3   1/1     Running   0          217d
kube-proxy-gke-iceberg-api-v2-201908101259587443-0d661dfb-3zhx   1/1     Running   0          217d
kube-proxy-gke-iceberg-api-v2-201908101259587443-92bbd393-w96w   1/1     Running   1          115d
kube-proxy-gke-iceberg-es-single-202003021919386-1b520a2e-sn9m   1/1     Running   0          5d6h
kube-proxy-gke-iceberg-es-single-202003021919386-bf6046bf-7wsp   1/1     Running   0          5d5h
kube-proxy-gke-iceberg-es-single-202003021919386-d64daa4e-1jqz   1/1     Running   0          5d5h
kube-proxy-gke-iceberg-general-20190810125958886-21ed2623-4m0p   1/1     Running   0          217d
kube-proxy-gke-iceberg-general-20190810125958886-8b185cf9-x1j2   1/1     Running   0          217d
kube-proxy-gke-iceberg-general-20190810125958886-eaf63d3c-k338   1/1     Running   0          217d
kube-proxy-gke-iceberg-kafka-2019081012595876540-429586da-m2qf   1/1     Running   0          217d
kube-proxy-gke-iceberg-kafka-2019081012595876540-76ebb654-z7xx   1/1     Running   0          217d
kube-proxy-gke-iceberg-kafka-2019081012595876540-c3abee6e-4q76   1/1     Running   0          217d
kube-proxy-gke-iceberg-rabbitmq-2019081012595876-552d6676-8z2k   1/1     Running   0          217d
kube-proxy-gke-iceberg-rabbitmq-2019081012595876-662980f7-76jc   1/1     Running   0          217d
kube-proxy-gke-iceberg-rabbitmq-2019081012595876-b269df22-6zqj   1/1     Running   0          217d
kube-proxy-gke-iceberg-redis-2019081012595877180-38264a5e-c0ch   1/1     Running   0          217d
kube-proxy-gke-iceberg-redis-2019081012595877180-9412d5f5-pt3w   1/1     Running   0          217d
kube-proxy-gke-iceberg-redis-2019081012595877180-947dc20b-c002   1/1     Running   0          217d
kube-state-metrics-67b67d8fdd-nkpt4                              2/2     Running   0          24d
l7-default-backend-fd59995cd-cvqwb                               1/1     Running   0          24d
metrics-server-v0.3.1-5c8f664b95-sthjz

Всего 1 ответ


Из вашего описания видно, что вы используете KubeDNS. Мой первый совет для вас - это перейти на CoreDNS, поскольку KubeDNS находится на пути устаревания .

Во-вторых, две вещи выпрыгивают из меня.

  1. Вы говорите о звонках между модулями вместо сервисов . В то время как Kubernetes обеспечивает обнаружение служб между вашими приложениями, он делает это через DNS, как вы знаете. Однако то, что модули могут разрешать друг друга , не означает, что у контейнера будут открытые порты за пределами модуля. Чтобы сделать это, даже для приложения в кластере, которое может его разрешить, вы должны объявить ресурс службы для каждого модуля или контроллера.

  2. Когда вы говорите о выполнении вызова, который ссылается на полное доменное имя вашего B-модуля / службы, вы не указываете схему полного доменного имени по умолчанию и не упоминаете, что настроили это.

Во-первых, не могли бы вы kubectl get svc -n NAMESPACE для обоих пространств имен, в которых kubectl get svc -n NAMESPACE ваши kubectl get svc -n NAMESPACE A и B, и подтвердить, что была создана служба типа ClusterIP и с этой службой был связан IP-адрес?

Во-вторых, можете ли вы попытаться выполнить попытку подключения из приложения A к службе приложения B, указав вместо этого следующий формат FQDN ?

some-service.b.svc.cluster.local

Обратите внимание на часть SVC . Вы упомянули some-service.b.cluster.local в своем OP.

Наконец, если все вернется в норму, мы можем приступить к устранению неполадок kube-dns . кажется, что все три модуля работают. Тем не менее, вы пытались описать их и / или захватить их журналы ? Не могли бы вы попробовать следующее и поделиться резюме, если что-то выглядит интересно?

kubectl describe pod -n kube-system kube-dns-6cd7bbdf65-jnntn
kubectl describe pod -n kube-system kube-dns-6cd7bbdf65-txmlj
kubectl describe pod -n kube-system kube-dns-autoscaler-8687c64fc-29jgq
kubectl logs -n kube-system kube-dns-6cd7bbdf65-jnntn
kubectl logs -n kube-system kube-dns-6cd7bbdf65-txmlj
kubectl logs -n kube-system kube-dns-autoscaler-8687c64fc-29jgq

Я предполагаю, что команды logs предоставят вам ответ, который вы ищете. Дайте мне знать, если вам нужны какие-либо дополнительные разъяснения или помощь по этому вопросу. Я рад помочь.