Действительно, если покрытие публичного dns провайдера достаточное, то это расширение и не нужно. Благодаря anycast ваш запрос к 8.8.8.8 улетит на ближайший гугловский dns сервер. А тот, в свою очередь, будет обращаться к авторитетному dns серверу с локального ip.
Тут интересный комментарий от представителя Cloudflare, почему они вообще отказались от этого расширения. От себя могу добавить, не представляю как вообще ответы при этом расширении кешировать.
У себя частично решил это admission контроллером, который добавляет подам с определенной аннотацией preStop хук с простой задержкой. Получается такая схема при остановке пода:
- кубы исключают endpoint с этим подом - выполняется preStop задержка. За это время информация из api сервера распределяется по нодам и балансировщикам - приложению отправляется SIGTERM, и далее его очередь продолжить graceful shutdown, т.е. закончить обработку текущих запросов
Таким образом не надо менять код приложения и добавлять в него лишние знания об окружении. Во время preStop задержки приложение продолжает работать штатно, обрабатывая трафик из мест, до которых ещё не дошла информация об изменениях в кластере. Я замерял эти задержки. В GKE время доходило до нескольких секунд. До использования этой схемы, пользователи неизбежно получали 502-е ошибки при деплоях. Сейчас же всё проходит бесшовно.
Admission контроллер позволяет управлять этой логикой централизованно, но вполне можно обойтись и без него.
Точно. Не довёл до конца свою мысль. При небольших нагрузках на CPU, основным потребителем будет экран. А при серьезных нагрузках, что ARM, что x86 будут жрать батарею очень быстро. Существенное преимущество ARM только в режиме ожидания. И этот кейс имеет место только в смартфонах при выключенном экране. А ноутбук обычно закрываем и он уходит в глубокий сон или гибернацию.
Не думаю, что энергопотребление прямо таки существенно снизится. Всё таки основной потребитель энергии — это экран.
А вот проблем совместимости со старым софтом огребём не мало
У кого нибудь есть опыт обращения по этой проблеме к официалам? У меня не-РСТ mbp 2016, наверное и не стоит рассчитывать? Кроме того, я на нем пробел выломал когда пытался почистить…
Настройки стандартные. ENGINE='django.db.backends.postgresql_psycopg2'. Для эксперимента добавлял в OPTIONSconnect_timeout=1, но видимо в psycopg2 стоит ограничение в минимум 5 секунд, т.к. ничего не изменилось. Да и в доке по libpq написано, что ставить меньше 2 секунд — не рекомендуется.
Это точно не gethostbyname. Это было проверено первым делом.
Есть еще такой вариант https://aliexpress.ru/item/1005001556524755.html (но без часов вроде)
Действительно, если покрытие публичного dns провайдера достаточное, то это расширение и не нужно. Благодаря anycast ваш запрос к 8.8.8.8 улетит на ближайший гугловский dns сервер. А тот, в свою очередь, будет обращаться к авторитетному dns серверу с локального ip.
Тут интересный комментарий от представителя Cloudflare, почему они вообще отказались от этого расширения. От себя могу добавить, не представляю как вообще ответы при этом расширении кешировать.
Есть расширение EDNS Client Subnet, но не все его поддерживают...
У себя частично решил это admission контроллером, который добавляет подам с определенной аннотацией preStop хук с простой задержкой. Получается такая схема при остановке пода:
- кубы исключают endpoint с этим подом
- выполняется preStop задержка. За это время информация из api сервера распределяется по нодам и балансировщикам
- приложению отправляется SIGTERM, и далее его очередь продолжить graceful shutdown, т.е. закончить обработку текущих запросов
Таким образом не надо менять код приложения и добавлять в него лишние знания об окружении. Во время preStop задержки приложение продолжает работать штатно, обрабатывая трафик из мест, до которых ещё не дошла информация об изменениях в кластере. Я замерял эти задержки. В GKE время доходило до нескольких секунд. До использования этой схемы, пользователи неизбежно получали 502-е ошибки при деплоях. Сейчас же всё проходит бесшовно.
Admission контроллер позволяет управлять этой логикой централизованно, но вполне можно обойтись и без него.
А вот проблем совместимости со старым софтом огребём не мало
curl -H 'Host: example.com' localhost:3000
На практике не встречал, и судя по коду, который выполняется после каждого запроса, это предусмотрели.
Настройки стандартные.
ENGINE='django.db.backends.postgresql_psycopg2'
. Для эксперимента добавлял вOPTIONS
connect_timeout=1
, но видимо вpsycopg2
стоит ограничение в минимум 5 секунд, т.к. ничего не изменилось. Да и в доке по libpq написано, что ставить меньше 2 секунд — не рекомендуется.Это точно не
gethostbyname
. Это было проверено первым делом.