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

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

У меня также есть тестовый скрипт, который выполняет вызов grp c из * От 1005 * до "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 Ответ

3 голосов
/ 28 марта 2020

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

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

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

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

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

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

some-service.b.svc.cluster.local

Обратите внимание на часть sv c. Вы упомянули 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 дадут вам ответ, который вы ищете. Дайте мне знать, если вам нужны какие-либо дополнительные разъяснения или помощь по этому вопросу. Я рад помочь.

...