Блог

Как это работает с посланником?

Допустим, я настроил восходящий кластер следующим образом:

   clusters:
    - 
      name: "service_a_cluster"
      connect_timeout: "0.25s"
      type: "strict_dns"
      lb_policy: "ROUND_ROBIN"
      hosts:
        - 
          socket_address: 
            address: "service_a"
            port_value: 8786
 

Как мой экземпляр посланника (ClusterManager?) собираетесь решать service_a ?
Кому он будет отправлять DNS — запросы?

У посланника есть внутренние механизмы для принятия решений, и все они доступны через конфигурацию. Похоже, что вы используете API-интерфейсы Envoy v2, поэтому соответствующая конфигурация высокого уровня находится в объекте кластера здесь.

Если вы прочтете это, вы заметите hosts , что поле ссылается на type поле. В этом type поле указано, как обрабатывать обнаружение/разрешение. Полная информация об этом механизме находится здесь.

В установке kubernetes по умолчанию встроены DNS и обнаружение служб. Вы можете найти соответствующие модули в kube-system пространстве имен.

 $ kubectl get pods -n kube-system

[...]
kube-dns-6c7b8dc9f9-ngdq2                                  4/4     Running   0          25h
kube-dns-6c7b8dc9f9-pctnl                                  4/4     Running   0          26h
kube-dns-autoscaler-844c9d9448-sswll                       1/1     Running   0          27h
[...]
 

До версии 1.12 kubernetes использовался kube-dns для разрешения DNS и обнаружения служб (отсюда и название модуля). В настоящее время он использует CoreDNS.
Примечание об именовании:

Примечание kube-dns . В этом поле указана служба metadata.name CoreDNS.
Это делается для обеспечения большей совместимости с рабочими нагрузками, которые полагались на устаревшее имя службы kube-dns для разрешения внутренних адресов кластера. Использование службы с именем kube-dns абстрагирует детали реализации того, какой поставщик DNS работает под этим общим именем.

Таким образом, все DNS-запросы на самом деле отправляются в эти модули и решаются ими.

Когда дело доходит до Истио, все немного сложнее. Вышеизложенное работает для служб kubernetes по умолчанию ,любые пользовательские ServiceEntry функции (например, добавленные Istio) не будут распознаны.

В дополнение к захвату трафика приложений Istio может также захватывать DNS-запросы для повышения производительности и удобства использования вашей сети. При проксировании DNS все DNS-запросы от приложения будут перенаправлены в боковую панель, в которой хранится локальное сопоставление доменных имен с IP-адресами. Если запрос может быть обработан боковой тележкой, он будет напрямую возвращать ответ приложению, избегая обратной связи с вышестоящим DNS-сервером. В противном случае запрос пересылается вверх по потоку в соответствии со стандартной /etc/resolv.conf конфигурацией DNS.

В то время как Kubernetes предоставляет разрешение DNS для Kubernetes Service s из коробки, любые пользовательские ServiceEntry s не будут распознаны. С помощью этой функции erviceEntry адреса могут быть разрешены без необходимости пользовательской настройки DNS-сервера. Для Kubernetes Service s ответ DNS будет таким же, но с уменьшенной нагрузкой kube-dns и повышенной производительностью.

Эта функция также доступна для служб, работающих за пределами Kubernetes. Это означает, что все внутренние службы могут быть разрешены без неуклюжих обходных путей для предоставления записей DNS Kubernetes за пределами кластера.
Источник