Я вижу странную проблему, когда трафик, исходящий из контейнера Docker, расположенный на виртуальной машине в облаке Google на западе европы1 и предназначенный для британской компании, базирующейся в Amazon Cloudfront, неправильно маршрутизируется через США, чтобы попасть в облако в Калифорнии, вызывая всевозможные нежелательные задержки и медлительность.
$ ping destination.host.co.uk
PING d3csmaahmfmvav.cloudfront.net (54.192.146.219) 56(84) bytes of data.
64 bytes from server-54-192-146-219.sfo4.r.cloudfront.net (54.192.146.219): icmp_seq=1 ttl=49 time=161 ms
ОДНАКО трафик, исходящий от виртуальной машины хоста, правильно направляется в европейское расположение Cloudfront:
$ ping destination.host.co.uk
PING d3csmaafmvavjz.cloudfront.net (54.230.12.31) 56(84) bytes of data.
64 bytes from server-54-230-12-31.ams1.r.cloudfront.net (54.230.12.31): icmp_req=1 ttl=54 time=10.5 ms
Я не могу найти в конфигурации сети для контейнеров Docker ничего, что указывало бы на то, почему контейнеры будут отправлять трафик на другую сторону планеты, когда сам хост отправляет его туда, где мы этого ожидаем.
На всю жизнь я не могу понять, почему это происходит, надеюсь, кто-нибудь поможет указать, что мне не хватает.
Спасибо!
Аааа! Я понял, что пошло не так. Контейнеры используют общедоступные DNS-серверы Google (8.8.8.8 и 8.8.4.4), а хост виртуальной машины использует внутренний DNS-сервер Google в своих соответствующих файлах resolv.conf. Я (и тот, кто настраивал эти контейнеры) совершал ошибку, доверяя собственным DNS-серверам Google, чтобы знать, где на самом деле находится чертовски хлам в собственном облаке Google. Как глупо с нашей стороны!
Когда я изменил resolv.conf в контейнере, чтобы поместить этот внутренний DNS-сервер наверху, внезапно ... Он больше не направляет трафик на другую сторону проклятой планеты, и, следовательно, время пинга снижается со 160 мс. до 10 мс. Так что это не так уж плохо.