Что такое исходящий поток вызовов Kubernetes?

Я новичок в кубернете. Пытаюсь понять, что происходит, когда я пытаюсь получить доступ к google.com из модуля kubernetes.
Будет ли запрос напрямую доходить до google.com (конечно, нет) или какой-то поиск DNS будет происходить в файле /etc/hosts.allow, прежде чем вызов выйдет за пределы модуля? Каков поток или путь исходящего звонка?
PS: у меня уже запущен модуль coredns по умолчанию.


kubernetes kubernetes-pod hosts hosts-file
person gaurav sinha    schedule 05.07.2021    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Я думаю, что этот вопрос можно разделить на 2 разные темы:

  • DNS разрешение.
  • Pod сети при попытке доступа к внешним источникам.

Ответ на оба этих вопроса может быть довольно длинным, но я постараюсь дать вам базовую информацию и добавить дополнительную документацию, которая будет более подробной.

DNS разрешение, происходящее внутри/вне кластера:

Как вы уже сказали, вы используете CoreDNS. Он будет отвечать в вашей настройке за разрешение DNS. Ваш Pods будет запрашивать его при поиске доменов, которые не включены локально (например, /etc/hosts). После получения ответов они свяжутся с внешними источниками (подробнее об этом позже).

Дополнительное замечание!

Разрешение DNS (локальное, запрос) будет зависеть от инструмента, который вы использовали. curl проверит это, но, например, nslookup запросит DNS-сервер напрямую.

Ваш CoreDNS, скорее всего, доступен под одним из Services в вашем кластере:

  • $ kubectl get service --all-namespaces
NAMESPACE     NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
default       kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP                  79m
kube-system   kube-dns     ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   79m

Я думаю, вы можете найти много полезной информации в официальной документации:

Вы также можете следовать этому руководству, чтобы получить больше практического опыта:

Сеть Pod при попытке доступа к внешним источникам:

Каждое решение Kubernetes может отличаться тем, как именно работает с сетью. Пожалуйста, обратитесь к документации вашего решения для получения более подробной информации. Основная предпосылка этого заключается в том, что Pod не будет напрямую связываться с внешними источниками. Ниже вы можете найти более подробную информацию о причинах этого:

исходящий NAT

Преобразование сетевых адресов (NAT) — это процесс сопоставления IP-адреса в пакете с другим IP-адрес при прохождении пакета через устройство, выполняющее NAT. В зависимости от варианта использования NAT может применяться к исходному или целевому IP-адресу или к обоим адресам.

В контексте выхода Kubernetes NAT используется, чтобы разрешить модулям подключаться к службам за пределами кластера, если модули имеют IP-адреса, которые не маршрутизируются за пределами кластера (например, если сеть модуля является наложением).

Например, если модуль в оверлейной сети пытается подключиться к IP-адресу за пределами кластера, то узел, на котором размещается модуль, использует SNAT (преобразование исходного сетевого адреса) для сопоставления немаршрутизируемого исходного IP-адреса пакета с IP-адрес узла перед пересылкой пакета. Затем узел сопоставляет ответные пакеты, приходящие в противоположном направлении, с исходным IP-адресом модуля, поэтому пакеты передаются из конца в конец в обоих направлениях, при этом ни модуль, ни внешняя служба не знают, что происходит сопоставление.

-- Docs.projectcalico.org: О: О Kubernetes Egress

Короче говоря, при отсутствии других факторов (например, дополнительных NAT, используемых вашим облачным провайдером), ваш Pod попытается связаться с внешними источниками с помощью Node IP (используя Source NAT).

Вы можете найти более подробное объяснение жизни пакета (некоторые аспекты специфичны для GKE) следующим образом:

Дополнительные ресурсы

person Dawid Kruk    schedule 06.07.2021