Make. Build. Break. Reflect.

Зачем? Зачем в наше время вы ещё держитесь за свои ноды и эхи?

Работа работа работа.

Я так и не успел в суете работы купить оперативную память до всего этого хайпа и уж тем более нехватки оперативной памяти на рынке.
Теперь то, что я хочу, даже в наличии нет. Или под заказ на март. Возможно.

Ладно, буду, как и раньше со старым ПК от 2021 года ещё лет 10.😭

#kubernetes #devops

Последнюю неделю на работе игрался с KRO, AWS ACK и CrossPlane.
- https://github.com/crossplane/crossplane
- https://github.com/aws-controllers-k8s/community
- https://github.com/kubernetes-sigs/kro

Ну что я могу сказать.
Мне одновременно и очень понравилось - инструменты хороши.
Это потрясающие инструменты, выводящие инфраструктурную часть и операционную на совершенно иной уровень.
Не плохой, не хороший, он новый. Не буду приводить аналогий, это просто иной уровень для меня.
Да охрененный, если честно, буду честен.
И одновременно не понравилось - самостоятельно, в одиночку, в одно лицо, без помощи AI ассистентов я разобрался бы в лучшем случае через недели 3-4. Возможно бы и через месяц.

Сложность в том, что эти инструменты создают десятки уровней абстракций - от CRD в Kubernetes до специфических API провайдеров (AWS, GCP). Чтобы отладить ошибку, нужно пройти путь от kubectl describe до логов ACK controller, а потом до настоящего события в облаке. Рисуешь сперва диаграммы, зависимости, порядки деплоя - это колоссальная работа.

Вообще прикольно, конечно, один манифест и фигак, у тебя целые регионы, кластера, роли, рут таблицы, натгейтвеи и миллион сущностей в кубернетисах. Миллионы объектов и сущностей на сотнях уровней абстракций.
Круто. Мне понравилось.

Про KRO/ACK/CrossPlane я ещё напишу не одну глубокую техническую заметку/отзыв, а пока лишь общий отзыв - они хороши.

#costoptimization #newrelic

Итого:
- агенты по умолчанию включают довольно много фич (distributed tracing, logs in context и так далее), что увеличивает ingest
- из коробки агенты New Relic настроены довольно агрессивно с точки зрения объёма собираемых данных. Для продакшн всегда имеет смысл пройтись по дефолтам и подкрутить семплинг под свои бюджеты
- 5-20 строчек конфига/переменных в 3 стеках до снижение трат в .в 18 раз (финально, после всех тюнингов) - с $4200 до $230 в месяц на одной лишь инжестии, без учёта стоимости лицензий
- никто из Ops команды даже не заметил разницу, что 2000/10000 семплов в минуту было, что 200/500. Данных достаточно. Думаю можно было бы снизить и до 100 семплов в минуту, но команда побоялась упустить данные при авариях. С другой стороны, даже 100 событий в минуту на проде часто достаточно для детекции проблем в проде.
- траты выросли за последние месяцы, так как и приложений стало больше и количество реплик POD выше стало
- добавили в readme рекомендации проверять чейнджлог при обновлении агента, так как дефолты могут меняться между версиями (и это ещё одна история)
- golang агент самый мерзкий, чтобы убедиться, что переменные/агент сработал, пришлось поменять гошный код, включить debug левел, посмотреть дефолтные значения, добавить новые, убедится, что применилось в нужном месте, снова ревертнуть код для выключения дебаг левела. Иные способы не помогали узнать какой дефолт и помог ли фикс.

В слова защиты newrelic я скажу, что они сами дают советы как чего тюнить, если счета большие, например:
- https://docs.newrelic.com/docs/apm/agents/php-agent/troubleshooting/agent-overhead-reduction-tips/
- https://docs.newrelic.com/docs/infrastructure/infrastructure-troubleshooting/troubleshoot-infrastructure/reduce-infrastructure-agents-cpu-footprint/

Не знаю кто виноват:
- инженеры, что не тюнят сразу дефолт значения
- newrelic, что из коробки впаривает агрессивный Ingestion и включённые по-умолчанию фичи с высокими дефолтами

Скорее всего, это комбинация обоих: инженеры часто не читают доку по дефолтам, а New Relic заинтересована в высоком ingestion.
Но ясно одно: контролировать затраты нужно с первого дня.

#costoptimization #newrelic

И снова Newrelic.
"Алекс, у нас за последний год возрос биллинг за newrelic.
Можно ли как-то это оптимизировать?"

"Ну удалите его к херам" - думаю я.
Но вслух говорю, конечно же - "Да-да, конечно. ща-ща, сейчас гляну чего там, подождите, пожалуйста".

Зашёл в админ панель, а там и правда по делу меня дёрнули - ведь прайс уже $4200+ в месяц

Вернёмся к базе: за что чарджит newrelic?
- лицензии пользователей
https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/user-type/
- data ingestion
сколько трафика (любого) отправили от аппликешнов - за сколько и платим

Первым делом иду смотреть за что чарджит сейчас, скачиваем билл за последние 6 месяцев.
https://one.newrelic.com/admin-portal/plan-management/billing

Да, всё так и есть, лицензии и трафик.

Обговорил с боссами, урезал 4 из 10 юзеров.
Этот пункт готов.

Ingestion. Из чего ты состоишь?
https://one.newrelic.com/admin-portal/data-ingestion/home?account=
Top usage в данном случае это
- трейсы
- логирование
- ивенты (транзакции)
- кастом ивенты (кастом транзакции)
Всё остальное ничтожно.

Хорошо, понятно, но какие именно приложения какой именно трафик генерят?
Насколько невероятно крутой интерфейс и удобство у самого newrelic для приложений и насколько он убогий для usage вещей. С ходу понять кто именно и за что сложно.

На помощь мне приходит их встроенная в UI SQL консоль.
- топ апп по трейсингу

SELECT bytecountestimate()/10e8 FROM `Span`, `SpanEvent` WHERE instrumentation.provider != 'pixie' FACET appName OR service.name OR entity.name LIMIT 15 SINCE unixtimestamp UNTIL unixtimestamp

- топ ивентов

SELECT bytecountestimate()/10e8 FROM `Transaction`, `TransactionError` FACET appName LIMIT 15 SINCE unixtimestamp UNTIL unixtimestamp

- топ метрик

SELECT bytecountestimate()/10e8 FROM `Metric` WHERE instrumentation.provider != 'kentik' AND instrumentation.provider != 'pixie' FACET CASES (WHERE newrelic.source = 'agent' AS 'Metric Time Slices', WHERE newrelic.source != 'agent' OR newrelic.source IS NULL AS 'Dimensional Metrics') SINCE unixtimestamp UNTIL unixtimestamp

Делаю несколько запросов за последние 30/60/90/180 дней сперва по типу трафика.

Промежуточные итоги:
- апп1 пишет много трейсов
- апп2 и апп3 пишут много транзакций
- апп5 пишет много кастом ивентов
и так далее

В целом понятно, иду в документацию и утопаю в миллиарде информации.
Много терминологий, много названий, ничего не понятно, но очевидно одно:

newrelic выезжает на дефолтах

Дефолт значения высокие/включены по умолчанию и надо это дело вырубать.

Дальше точечно прохожу по всем топам, в разных стеках разное решение.
- в php вырубаем в 10 раз меньше семплирование

newrelic.span_events.max_samples_stored       = 200   # was 2000

- в golang, например

NEW_RELIC_SPAN_EVENTS_MAX_SAMPLES_STORED=200  # was 1000 (default)
NEW_RELIC_TRANSACTION_EVENTS_MAX_SAMPLES_STORED=2000  # was 10000 (default)
NEW_RELIC_APPLICATION_LOGGING_FORWARDING_ENABLED=false # was true (default)

+ обновил агента, так как старая версия не умела работать с этими переменными
Для других стеков были другие решения, в заметках не сохранилось.

Что же я сделал? Я уменьшил количество семплов в минуту.

Давайте поясняю ещё раз:
"Каждую минуту каждый POD каждого приложения отправляет условные 10000 ивентов (транзакций). Это количество ивентов нам не нужно, его слишком много и там по сути мусорная для нас дата. Она не нужна, её можно сократить. Если нам покажется, что её нехватает, но можно добавить. Снижение транзакций/трейсов в 5-10 раз дало снижение Ingestion в 5-10 раз.

Из минусов: результат подобной работы виден не сразу, а лишь спустя 5-7 дней, на графиках и в NewRelic UI SQL.

#бытовое

Пауербанк делает бррр вбдыщ вжуу.

Самое время, перед новым годом, принудительно избавится от старых и любимых пауербанков.
Даже если не хочется. Надо, пришла пора, иначе будет как у меня.

Хорошо, что обошлось без травм и пожара 😭

#eks #aks #kubernetes

Апгрейд кластера кубернетис.
С чего начинать?

Начать сперва с проверки совместимости.
Время от времени некоторые ресурсы меняют версию API.
- что-то становится deprecated, например PSP
- что-то меняет версию с alpha, вырастая до v1
- что-то несёт с собой breaking changes

У AWS EKS есть собственные механизмы EKS Upgrade Insights/preflight‑checks, которые дают подсказки по deprecated API и аддонам прямо перед апгрейдом.
https://aws.amazon.com/blogs/containers/accelerate-the-testing-and-verification-of-amazon-eks-upgrades-with-upgrade-insights/

В OpenShift есть свои "pre‑update" проверки и рекомендации, но они более завязаны на платформу.
Значительная часть логики проверки касается операторов, etcd, сети и прочих специфичных для OpenShift компонентов.
https://docs.redhat.com/en/documentation/openshift_container_platform/4.14/html/updating_clusters/preparing-to-update-a-cluster

У Azure есть AKS Upgrade Readiness Check. AKS автоматически блокирует апгрейд, если обнаружены deprecated API. Так же проверяет не только deprecated API, но и всякие PDB, квоты, серты, IP адреса в сабнете​ и так далее.
https://learn.microsoft.com/en-us/azure/aks/upgrade-cluster

Это всё облачные куберы и их вендорлок решения.

Для bare-metal кластеров и для клауд куберов есть более универсальные решения:
- консольные утилиты для проверки всех сущностей куба (локально или в CICD):
- - https://github.com/doitintl/kube-no-trouble
- - https://github.com/kubepug/kubepug
- github action для CI/CD
- - https://github.com/FairwindsOps/pluto
- проверки аутдейт/депрекейтед helm чартов (НЕ связана с API/апгрейд, опциональная проверка)
- - https://github.com/FairwindsOps/Nova

Крайне важно понимать, что AKS проверяет deprecated API в течение 12 часов перед апгрейдом, а EKS использует 30-дневное окно, что важно для планирования процесса upgrade. То есть даже если вы исправили deprecated API, ошибка может оставаться в течении указанного времени. Планируйте заранее.

Всё эти проверки необходимо сделать ДО обновления кластера, иначе у вас будут весёлые часы после апгрейда.

#пятница

Ну почему бы и да

Да камон 😭

#linux

В эпоху активного использования AI, агентов и автокомплитов я стал чаще допускать ошибки.
Чёртовы AI не глядя могут дропнуть нужные файлы: херак раз - и нет важного файла.

С git‑файлами особых опасений нет, но дополнительные вещи вроде .env в репозитории, которые в гитигноре, или в системе типа ~/.kube/config всё ещё хочется сохранить.

Возвращаюсь к основам и просто запрещаю удаление файла:

sudo chattr +i .env

Проверить, что флаг установлен, можно так:

lsattr .env

Если я сам (а не нейронка) когда‑нибудь захочу удалить файл, сначала придётся снять флаг, а уже потом удалять:

sudo chattr -i .env
sudo rm .env

Флаг immutable защищает от:
- перезаписи файла
- случайного удаления
- случайного переименования
- случайного sudo rm -r по директории, где лежит этот файл*

* Будет ошибка типа Operation not permitted на файле, в то время как остальные файлы в директории будут удалены

Если immutable поставить на саму директорию через chattr +i dir, тогда уже нельзя будет ни создавать, ни удалять, ни переименовывать файлы внутри неё - это ещё более жёсткая защита, но это мне пока не надо.

Иногда очень полезно вернуться к базовым инструментам Linux и защитить важные файлы и от нейросетей, и от себя самого, который запускает команды, не глядя, как макака.

#пятница

Мои прогнозы на re:Invent 2025:
- AI
- GenAI
- MCP agents
- Agentic AI
- Generative AI Workflows
- Serverless-VPC-in-a-Container
Никто не знает, зачем, но звучит очень глубоко.
- Zero-ETL-to-Zero-Code
- The Data Lake House Lakehouse Warehouse Mesh Fabric
Просто потому, что Data Mesh уже недостаточно сложно.
- The Multi-Region-Multi-AZ-Multi-Cloud-Multi-Everything-Architecture
Зарезервировано 100% времени работы, но 1000% затрат.
- AI
Ну, а вдруг вы забыли?

#aws #eks #kubernetes #troubleshooting #одинденьизжизни #argocd

"Алекс, у нас что-то приложение не раскатывается, деплой завис. Кластер новый, вроде ты деплоил, посмотри плиз".

Ну раз я, значит мне и смотреть.
Смотрю в арго что там зависло, перехожу в аппликейшнсет - вижу процессинг.
Processing, что же ты за зверь такой?
Это означает, что ArgoCD обнаружил разницу между желаемым состоянием (в гите) и текущим состоянием (в кластере) и активно пытается синхронизировать ресурсы.
Есть проблема, которая мешает завершить развертывание (например, нехватка ресурсов, неправильная конфигурация, ожидание завершения работы пода или борьба между контроллерами).

На самом деле самый дебильный статус, потому что в практике это может быть что угодно 🐒.
Ладно, надо чинить.

Смотрю сперва "а не может ли кто сражаться за ресурсы?"
Вдруг опять арго и оператор вцепились как два деда.
Я как-то выше писал старый пример про #dapr.

Смотрю:

kubectl get applicationsets APPSET1 \
  -n NAMESPACE \
  -o jsonpath='{.metadata.managedFields[*].manager}' \
  | tr ' ' '\n' | sort | uniq -c

      1 argocd-applicationset-controller
      1 helm

А тут всё нормально:
- helm один раз создал/обновил сам ApplicationSet
- argocd-applicationset-controller дальше управляет этим ApplicationSet и генерит Application(ы)
Значит дело не в конфликте.

Иду дальше, что с самим аппликейшн

kubectl get applications -n NAMESPACE \
  -o wide | grep APP1

APP1             Synced        Progressing

И нет ли там конфликтов

kubectl get applications APP1 -n NAMESPACE \
  -o jsonpath='{.metadata.managedFields[*].manager}' \
  | tr ' ' '\n' | sort | uniq -c

      1 argocd-application-controller
      1 argocd-applicationset-controller

Конфликтов нет, ведь:
- argocd-applicationset-controller следит за соответствием шаблону ApplicationSet.
Он не ходит в кластерные ресурсы (Deployment, Service и т.д.), только создаёт/обновляет/удаляет сами Application CR.​
- argocd-application-controller следит за тем, чтобы ресурсы в кластере совпадали с Git, и считает health (если хоть один дочерний ресурс не равен Healthy, приложение остаётся Progressing).

Идём дальше. Так какие же ресурсы генерируются и какой у них статус?

kubectl get applications APP1 -n NAMESPACE -o json \
  | jq '.status.resources[] | select(.health.status != "Healthy")'

...
{
  "kind": "ConfigMap",
  "name": "CM1",
  "namespace": "NAMESPACE",
  "status": "Synced",
  "version": "v1"
}
...
{
  "health": {
    "status": "Progressing"
  },
  "kind": "Service",
  "name": "SVC1",
  "namespace": "NAMESPACE",
  "status": "Synced",
  "version": "v1"
}
...

Ага! Попался!
Какой-то service в процессинге.

Что там с тобой:

kubectl get service SVC1 -o yaml -n NAMESPACE
...
  type: LoadBalancer
status:
  loadBalancer: {}

Визуально вроде ок,
Стоп, нет,не ок.
Ведь это означает, что контроллер, отвечающий за provision (создание) AWS Load Balancer, не смог выполнить свою работу, и поэтому поле status.loadBalancer.ingress не заполнено IP-адресом или Hostname.
* У нас LoadBalancer создаётся контроллером AWS.

Ещё раз проверяю в дескрайб:

kubectl describe service SVC1 -n NAMESPACE
...
Events:
  Type    Reason                Age   From                Message
  ----    ------                ----  ----                -------
  Normal  EnsuringLoadBalancer  55m   *****               Ensuring load balancer

Ладно, иду в неймспейс, где обычно лежит AWS Load Balancer, логи смотреть.
А там нет ничего! Удивляюсь, смотрю

kubectl get pods -A | grep -i load

Нет ничего!
Спрашиваю коллег, а мне ехидно говорят "да ты же сам не задеплоил лоадбалансер в этом новом кластере".
https://github.com/kubernetes-sigs/aws-load-balancer-controller

Смотрю свои коммиты, MR - и правда, именно в этом кластере я забыл добавить AWS LB.🐒
Пилю новый MR, добавляю LB, жду, когда всё поднимется - всё, проблема решена!
У проблемного applicationsset статус стал Healthy.

Добавляю в документацию по кластеру, что "не забыть про LB и иду работать дальше".
Ну хорошо, хоть это не продуктовый кластер, без клиентского ворклоада 🤡

#aws #costoptimization #devops

Затем я включил логирование (Standard log destinations) и положил все логи в S3 бакет.
Оставил на полдня, потом написал Bash-скрипт, который сделал простую выборку, например, top 20 requests by path с сортировкой по пути.
Тут меня ждало очередное удивление - в топе были не файлы S3, а балансировщик нагрузки (ALB) и поды Kubernetes🤡.
То есть, у нас топ трафика - это НЕ кэшируемый трафик! 🤬Через клаудфронт! 🤬
Написал еще пару скриптов - да, у нас внезапно в этой схеме просто трафик шел в EKS и пару мест.

Собрали консилиум с коллегами, рассказал о своей, находке, чтобы спросить "а зачем так?".
Ответ был очевидным типа "ну так было исторически, нам надо было как-то роутить трафик по пути, мы в своё время сделали это через клаудфронт, чтобы не поднимать ещё один балансер или Nginx".
"Пздц" - подумал я и пошёл дальше изучать.
Да, действительно так и оказалось - часть трафика, и это 98% от всего в клаудфронте, шло НЕ для кеша.
Просто в поды кубернетиса.

Быстро напилил альтернативное решение, пару днс записей, проверили на dev - всё работает ок, без клаудфронта.
Дальше стейдж, прод, никаких проблем.

Сижу пишу postmortem.
Понимаю, что надо сослаться на саппорт амазона, типа они негодяи не присылали кост аномали детекшн письма - но нет, присылали.
Думаю может не было реакции - нет, обсуждали повышения цен, даже текстов в чате.

Как так мы пропустили этот момент?
Подняли исторически все данные и за последние пару лет и только тогда картина полностью стала ясна.
- Изначально был временный костыль в одном из клаудфронтов - если путь /path1 то трафик отправлять в X, а если /-path2, то временно в Y.
- этого трафика была изначально мало и он вовсе попадал во free tier.
- затем его стало больше, стали платить 40 баксов, что было допустимо, затем 80 и так далее.
- пока не вырос до 1000 и 1250 долларов на момент кост инцидента.

Почему не обращали внимание раньше?
Потому что рост цены был медленным:
- кост аномали детекшн ловил рост цены примерно раз в неделю, и сумма каждый раз была небольшая
При постоянном медленном росте кост аномали детекшн начал отправлять всё реже и реже письма - это же очевидное поведение стало.
- все дефолт ссылки ведут на "cost and usage report" с коротким промежутком времени типа последние 30-40 дней
- на графиках и в письмах был небольшой рост - ну кто будет заниматься, если на прошлой недели мы платили 9 баксов день, а теперь 11 долларов в день, копейки же

Лишь взглянув на графики за полгода/год/два года/три года, стало ясно, что цена увеличивались постоянно.
Временный костыль начал в итоге вырабатывать 14 терабайт данных трафика.

Косяк девопса? Да.
Косяк костменеджера? Несомненно.
Косяк "временного решения"? Конечно.

Иногда, чтобы узнать, что проблема есть, надо нырнуть чуть глубже, чем "да вроде по делу списывают да не много же".
Иногда, чтобы узнать, что проблема есть, надо расширить графики больше, чем на две недели.

Суммарные потери последних 8 месяцев до этого кост инцидента - 4400 долларов.
Этот path в клаудфронте и не нужен был, просто поленились много лет назад сделать сразу нормально.

#aws #costoptimization #devops

А иногда вообще ничего из существующих финансовых алертов не помогает.
Нужен глубокий, живой человеческий анализ.

Был случай: проект, всё на AWS, стартап.
Постепенно рос, изменялся, но изначально у всех всюду был root-доступ (а как иначе в стартапе из 4 человек?). Набирались люди, улучшались процессы, разграничивались доступы, всё заносилось в IaC.
В целом стоимость услуг AWS была сравнительно небольшой, от 2к до 5к долларов, и держалась года полтора-два.
Раунд за раундом, компания выросла, трафика и сервиса стало больше, увеличился и счет.
Затем начали оптимизировать затраты: внедрили RI, SP (Reserved Instances, Savings Plans) и другие методы.
Обвешали обычным алертингом и FinOps-инструментами вроде Cost Anomaly Detection.
Каждые 1-3 месяца проводились Cost Review meetings, на которых обсуждались траты, предстоящий рост и многое другое. Каждая, повторюсь, позиция в биллинге детально разбиралась и для каждого участника команды и руководителя была очевидна, понятна и разумна.

Всё вышенаписанное лишь для того, чтобы подчеркнуть, что ничего нестандартного тут не было, всё как у всех.

Каждый месяц счет всё рос и рос. Где-то разумно за Compute - воркеры в EKS, где увеличилось количество реплик.
Где-то за RDS, потому как и размер БД увеличивается, и инстансы примерно раз в полгода-год увеличивали, да бэкапы (snapshots) также увеличивают стоимость хранения.
Где-то CloudFront, потому как количество клиентов и трафика стало больше.

Приходили и письма от Cost Anomaly Detection: "сервис А увеличился на 20% - теперь 21 доллар", "сервис Б увеличился на 47% и теперь 11 долларов".
И такие письма приходили регулярно.
Визуально - всё разумно и понятно:
- увеличивается количество кастомеров
- увеличивается трафик и нагрузка
- немного растет стоимость услуг

Однако пришел момент, когда счет за услуги CloudFront вырос до умопомрачительной отметки в 1000 долларов в месяц.
На очередном Cost meeting поставили задачу проверить корректность настроек, везде ли правильно включено кэширование, заголовки и так далее.
Триггернулись лишь потому, что на старте компании платили порядка 30 баксов, спустя год 150, затем 400 через два года, а тут сразу $1000 - слишком большой скачок.

Задачу поручили мне, и я начал копать.
Признаюсь - я ничего на тот момент не понял.
Ну ALB, CloudFront да API Gateway.
Много ресурсов, разные.
Поверхностно изучил еще раз - да, вроде очевиден рост как клиентов, так и трафика и биллинга.
Отписался "да всё норм", закрываю таску.

Спустя месяц счет стал уже 1250 долларов, и это напрягло всех.
Руководство попросило сделать анализ: как тут можно сэкономить, ведь ожидали рост клиентов x20, а это значит, что потенциально счет будет невероятно огромным.
Требовалось исследование альтернативных архитектурных решений.

Начал я повторно изучать, уже в процессе расписывая куда какой трафик идет, спрашивая разработчиков, смотря DNS, балансировщик, все файлы веб-страницы и многое другое.
Я это изучал лишь чтобы понять, как сейчас что работает, чтобы понять, как и на что мне надо заменить, чтобы снизить косты.

В процессе анализа для переноса архитектуры мне пришел неожиданный вопрос в голову:
а счет за CloudFront это с одного Distribution или с разных?
Начал включать аналитику и овервью.
Определились, что траты лишь с двух Distribution из 25.
Вопреки тому, что все думали изначально, что с 10-15.

Ок, копаю дальше, стало интересно, ведь именно у этих двух Distribution было несколько источников (Origins) и несколько правил поведения (Behaviors).
Мне же надо их на что-то менять, надо копнуть глубже.

#пятница

Ну почему бы и не поучаствовать в этом нескончаемом челлендже

#aws #ecr #kubernetes

Представим себе, что у нас есть некий софт.
Он разрабатывается внутри компании и версионируется.
Результат сборки это готовый имадж в реджистри провайдера.
Затем мы этот софт предоставляете клиентам.
У софта есть версии и он разворачивается на одном регионе AWS.
Прям буквально клиенты тыкают в веб-интерфейсе, выбирают версию софта и регион(ы), в котором хотят видеть и дальше ваша, ну допустим назовём её "платформа" раскатывает софт нужной версии на нужных регионах.

Всё очень просто:
- собрали новый софт с новой версией
- готовый имадж положили в реджистри
- кастомер может задеплоить в доступный(е) регион(ы)

И всё бы хорошо, но как быть, когда у нас добавляются новые регионы?
Подняли новый регион, кастомер может задеплоить новую версию - всё работает.
Однако стоит выбрать старую версию продукта - поды падают с ошибкой пуллинга имаджа.
Старого имаджа в новом регионе ещё нет.

Katastrofa!

Варианты, которые сходу приходят в голову:
1) ECR Replication - автоматическая репликация имаджей между регионами.
Классная шутка, работает, но не покрывает кейс со "старыми имаджами", работает только для новых имаджей и всех последующих.
Да и она уже включена.
2) Pull-Through Cache - великолепная штука, работает для всех внешних реджистри (ghcr.io, dockerhub, quay.io и тп).
Фича так же уже включена.
3) скрипт на питоне, которые будет синкать старые/имаджи при подключении нового региона
Только не в Слизерин! Лишь бы не скрипт, лишь бы не скрипт 🎩
4) не разрешать кастомеру деплоить на новые регионы старые версии
5) AWS event bridge + Lambda (не сработает, лямбда вроде не умеет работать с PTC)
6) схемы типа "ECR-to-ECR PTC"
https://docs.aws.amazon.com/AmazonECR/latest/userguide/pull-through-cache-private.html (именно приват)
Pull-Through Cache для private-ECR-to-ECR-private работает (с 2023 года) с IAM аутентификацией.
Там есть пара ограничений, но для нашей задачи это подходит.
7) уход от парадигмы "один регион = имаджи только из регионального ECR", пуллить все из us-east-1
Смотрю
- как часто происходят релизы софта
- размер этих внутренних имаджа(ей)
- биллинг хранения и трафика ECR
- как часто будут разворачиваться новые регионы и как часто в новых регионах захотят старый софт
Дополнительно ресёрч:
- политики/доступы из других регионов в дефолт ECR из разных EKS
- kyverno policy (не будет ли перетирать путь)
- пулл секрет в новом регионе содержит правильный путь?

Минусы последнего решения понятны:
- цена: хранение/трафик (спойлер - увеличение на 13 баксов в месяц)
- latency на первый пулл

Мне нравятся оба варианта:
- Private Registry Upstream
- дефолт ECR для разных EKS

Дальше все факты, аргументы, расчёты, плюсы и минусы руководству.
Первый вариант это элегантность и оптимизация, второй это простота.
А какой уж вариант выберет руководство мы пока и не знаем. (знаем 👍)

Чего только не пере изобретают.
Осуждаю.

Уволюсь, если кто такое внедрит на работе.
(нет, кого я обманываю, буду есть ложкой, если заставят 😭)

https://github.com/toon-format/toon

Из новостей мира AI.

1) Скачал тут IDE от Google и поработал пару часов. (да-да, там внутри всё равно VSCode style).
Первое впечатление - очень круто, в том числе за счет бесплатности моделей.
Даже новейшая Gemini 3 в комплекте🔥.
Типичные сложнейшие таски по топикам террагрант/хелм/авс/секьюрити попросил - все отвечает ровно так, как я и хочу и код на 99% рабочий. Сами таски/вопросы написаны давно, часто на них проверяю новые IDE/модели.

После Kiro, Claude Code и Cursor всё выглядит на высшем уровне.
Рекомендация 10/10. *

* Особенно если нет возможности платить за альтернативный софт.

https://antigravity.google

2) Невероятно впечатлён моделью Kimi K2 Thinking на Perplexity (у меня прошка).
Если нужно очень глубоко нырнуть в задачу - самый сок и топ.

Таски:
- ресерч архитектуры
- сравнение подходов разработки и флоу
- глубочайшее(чуть ли не побайтовое) погружение в сорс код, чтобы понять где бага

Рекомендация 10/10.

Из минусов - ну вооооооооообще не быстро отвечает.
Подходит для задач, где не нужна спешка.
На сегодня это моя любимая модель для длительного ресёрча и подумать.

https://www.perplexity.ai

Никогда такого не было, но кладуфлёр опять упал.

В статуспейдж пишут, что недоступен только саппорт и портал.
На самом деле он весь упал и у меня упал весь мой пет проект.
Печаль.

- https://www.cloudflarestatus.com/
- https://www.reddit.com/r/CloudFlare/comments/1p09n2i/cloudflare_issuesdown/