У меня есть кластер GKE с установленной istio. Входной шлюз Istio автоматически создает балансировщик нагрузки с IP.
Я поместил этот IP-адрес в облачный DNS, как показано на рисунке ниже (поддельный IP-адрес со скрытым DNS-именем). Все работает, и я могу получить доступ к своему кластеру, используя URL.
Я знаю, что могу уменьшить время TTL, чтобы попытаться сократить время распространения, если мне нужно изменить IP, как описано в документации.
Распространение изменений
Изменения распространяются на две части. Во-первых, изменения, которые вы отправляете через API или инструмент командной строки, должны быть отправлены на уполномоченные DNS-серверы Cloud DNS. Во-вторых, распознаватели DNS должны принять это изменение, когда истечет срок их кэша записей.
Кэш распознавателя DNS управляется значением времени жизни (TTL), которое вы задаете для своих записей, которое указано в секундах Например, если вы установите значение TTL 86400 (количество секунд в 24 часах), распознаватели DNS получат инструкцию кэшировать записи в течение 24 часов. Некоторые распознаватели DNS игнорируют значение TTL или используют свои собственные значения, которые могут задержать полное распространение записей.
Если вы планируете изменить службы, для которых требуется узкое окно, вы можете изменить TTL на более короткое значение до внесения изменений. Такой подход может помочь уменьшить окно кеширования и обеспечить более быстрое изменение ваших новых настроек записи. После изменения вы можете изменить значение обратно на предыдущее значение TTL, чтобы уменьшить нагрузку на распознаватели DNS.
Но, как вы можете видеть, это решение ненадежно, поскольку некоторые преобразователи DNS не могут следовать моим TTL. Есть ли способ уменьшить это время распространения до нуля? Я попытался создать балансировщик нагрузки и правило пересылки, но безуспешно.