Make. Build. Break. Reflect.
前往频道在 Telegram
Полезные советы, всратые истории, странные шутки и заметки на полях от @kruchkov_alexandr
显示更多1 396
订阅者
无数据24 小时
+17 天
+2530 天
正在加载数据
吸引订阅者
十月 '2610月 '26
十月 '26
+28
在0个频道中
九月 '26
+17
在0个频道中
Get PRO
八月 '26
+44
在1个频道中
Get PRO
七月 '26
+23
在0个频道中
Get PRO
六月 '26
+27
在0个频道中
Get PRO
五月 '26
+86
在8个频道中
Get PRO
四月 '26
+48
在1个频道中
Get PRO
三月 '26
+141
在6个频道中
Get PRO
二月 '26
+96
在1个频道中
Get PRO
一月 '26
+55
在2个频道中
Get PRO
十二月 '25
+50
在0个频道中
Get PRO
十一月 '25
+48
在1个频道中
Get PRO
十月 '25
+54
在3个频道中
Get PRO
九月 '25
+73
在4个频道中
Get PRO
八月 '25
+66
在0个频道中
Get PRO
七月 '25
+51
在1个频道中
Get PRO
六月 '25
+37
在0个频道中
Get PRO
五月 '25
+577
在1个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 26 十月 | +1 | |||
| 25 十月 | 0 | |||
| 24 十月 | 0 | |||
| 23 十月 | 0 | |||
| 22 十月 | +2 | |||
| 21 十月 | +1 | |||
| 20 十月 | 0 | |||
| 19 十月 | +1 | |||
| 18 十月 | 0 | |||
| 17 十月 | +1 | |||
| 16 十月 | 0 | |||
| 15 十月 | +1 | |||
| 14 十月 | +1 | |||
| 13 十月 | +1 | |||
| 12 十月 | 0 | |||
| 11 十月 | +1 | |||
| 10 十月 | 0 | |||
| 09 十月 | 0 | |||
| 08 十月 | +1 | |||
| 07 十月 | +5 | |||
| 06 十月 | +1 | |||
| 05 十月 | 0 | |||
| 04 十月 | +4 | |||
| 03 十月 | +1 | |||
| 02 十月 | +4 | |||
| 01 十月 | +2 |
频道帖子
#всратость #ai
Читаю на днях слак, коллега пишет:
Вот и пришли в дивный новый мир: агент обманул всех. Я запустил фоновых агентов фиксить баги. Не знаю почему, но он решил, что лучше сделать всё от имени @коллеганейм, и теперь нельзя нажать approve😂Чегоооооо бл?? Захожу в гитлаб, смотрю коммиты: да, автор другая коллега! Агент просто подставил её имя и email в коммит! Проверки подписи у нас нет, так что гитлаб всё честно принял. Почему так вышло? Сначала я подумал, что агент решил, будто коммитить сюда может только она, и "представился" ею. Но, скорее всего, всё банальнее: предположу, что у фонового агента не был настроен/сбойнул git identity, гит ругнулся, и агент "починил" ошибку, взяв самое правдоподобное имя из истории git log и/или CODEOWNERS. Наверняка без злого умысла, просто убрал препятствие. И от этого как-то даже страшнее. Пздц, если честно 😣 А самое, сука, смешное, что сломался сам процесс ревью. В гитлабе включено правило: кто добавил коммиты в MR, тот не может его аппрувить. Для гитлаба коллега теперь автор этих коммитов, хотя она их в глаза не видела😁 Агент убрал препятствие для себя и тут же поставил его ей: человек, который должен проверить код, формально не может нажать approve, потому что "сам же его и написал". Защита "автор не аппрувит сам себя" сработала идеально, только против единственного человека, который этот код не писал 🤡🤡🤡 Какой следующий раунд? Агенту не хватило прав, он просто слёзно от меня напишет в слаке коллеге и спиздит у него токен от GH/GL и запустит пайплайн от его имени? Или с моими админ правами просто выдаст мне же доступ к гит репозитория и пропишет права на байпасс без аппрува? Сделает имперсонализацию в гитлабе, за коллегу выпишет себе апи токен и сделает что надо, а потом удалит токен и почистит логи, словно ничего не было? Что с этим делать ваще? Да и надо ли уже... Похоже, что всё идёт по женскому половому органу как будто бы 😢😢😢
| 2 |  Уникальный дизайн всех продуктов 2026 би лайк | 570 |
| 3 |  У самурая нет цели, есть только patch. И ещё patch. И ещё один. И ещё.. | 1 234 |
| 4 |  #devops
Обычный день инженера в 2026 - сраные CVE и факапы со всех сторон.
https://www.youtube.com/watch?v=mr834Cs9ncs
Бл, да дайте просто поработать 😢 | 1 075 |
| 5 | #всратость
Удивительное - рядом.
Упал GCP, и вместе с ним наш GitLab, CI/CD и вся AI-трансформация.
ИИ умеет хуярить код за секунды, а поднять чужой регион почему-то не может.
Как же так вышло?
- https://status.cloud.google.com/
---
Эй, Револют, оживай, родненький, мы тоже страдаем от гугла.💞 | 984 |
| 6 | Но на собесе тебя всё равно в тысячный раз спросят, что происходит, когда вводишь
kubectl apply -f pod.yaml
😀 | 1 008 |
| 7 | 没有文字... | 1 134 |
| 8 |  #tools #ai
Открыл для себя Remotion (им сто лет в обед).
https://github.com/remotion-dev/remotion
Вкратце: это React для видео, можно рисовать любые анимированные штуки.
План будущей миграции БД, диаграмма сети, как работают вебхуки, как работает TLS, как привлечь инвесторов, как у вас устроены кубер и облако.
Любые ваши фантазии.
Я, например, долго игрался с "как работают шедулер и кубелет", очень круто.
На выходе получаешь гифку или видео.
Шаблонов много.
Claude Code тоже свободно с этим работает.
Из минусов - на опытах и игрульках у меня безбожно сгорали токены.
Что, собственно, и отражено в видео к посту 😁
Шуточно-злободневный промпт для этого видео:
https://gist.github.com/kruchkov-alexandr/ceff15f054eb05c068c0422943b35ead | 1 135 |
| 9 |  С появлением нейросетей многие профильные телеграм-чаты почти затихли.
Редко кто что пишет.
Ни глупых вопросов, ни ссор, ни холиваров.
А в чат по терраформу и вовсе наконец-то пришла любовь ❤️ | 1 099 |
| 10 | #longread #aws #kubernetes #troubleshooting #devops
Ах, как сладок вкус раннего субботнего просыпания во время моего дежурства!
Суббота, 03:35 утра, алёрт на AWS RDS:
DBLoadRelativeToNumVCPUs p99 > 1.5 three minutes in a row, DB overload.
"Нагрузка на базу в субботу утром, когда клиентов почти нет и ничего не деплоят, это очень странно" - думаю я, всё ещё находясь под действием пятничных весёлых напитков, проснувшись на онколл алерт.
Открыл AWS Performance Insights, почти вся нагрузка шла от одного запроса:
SELECT * FROM job_batches WHERE id = ? LIMIT 1 FOR UPDATE
Я был весьма раздосадован нагрузкой БД, ничего не смог понять сам по квери и мне пришлось дёрнуть коллег разработчиков из другого часового пояса, кто не спал, кто мне смог пояснить за запрос и сраные батчи ларавелки.
Ниже цитаты коллег
В Laravel есть Bus::batch(): кидаешь в очередь пачку джобов и получаешь общий прогресс, коллбеки then/catch/finally и отмену всей пачки. Состояние пачки хранится в обычной таблице job_batches, одна строка на батч: total_jobs, pending_jobs, failed_jobs, failed_job_ids (JSON-ом в той же строке), cancelled_at, finished_at.
Когда любой джоб из батча завершается, успешно или с ошибкой, фреймворк обновляет счётчики примерно так:
BEGIN;
SELECT * FROM job_batches WHERE id = ? FOR UPDATE;
-- in PHP: pending_jobs - 1, append to failed_job_ids, etc.
UPDATE job_batches SET pending_jobs = ..., failed_jobs = ..., failed_job_ids = ... WHERE id = ?;
COMMIT;
Это честный пессимистичный лок на строку. Пока транзакция одного воркера не закоммитилась, остальные воркеры, у которых закончился джоб из этого же батча, стоят в очереди за той же строкой.
Пока в батче десять джобов и работает пара воркеров, всё нормально. Если в батче тысячи мелких джобов и их молотят десятки воркеров одновременно, все они выстраиваются в очередь к одной строке. Сам запрос летает, это выборка по первичному ключу. В Performance Insights ты видишь не медленный запрос, а время ожидания лока.
Запрос понятен, неясно, откуда в субботу ночью столько батчей, сука.
Нашёл быстро: за два дня до этого смержили новый недельный кронджоб.
По субботам в 02:00 UTC он проходит по всем клиентам, у которых подключена интеграция с внешней системой (их 480), и для каждого запускает очистку контактов, удалённых во внешней системе.
Режим --dry-run, ничего не удаляется, только собирается статистика.
Каждый клиент получает Bus::batch из джобов по 100 контактов в low-priority очереди.
Один прогон на клиента раз в неделю.
Звучит безобидно. Дааа, конечно.
В job_batches было:
- с 02:00 до 04:48 каждый клиент получил примерно по 30 батчей
- всего около 7 тысяч батчей
- у одного клиента 30 прогонов по 3200 джобов, это около 96 тысяч джобов
- на момент разбора около 1500 батчей ещё открыты, в очереди около 280 тысяч джобов
Недельный кронджоб отработал не один раз, а примерно 30 раз за ночь 🤡
Пока я просыпался, разбираясь с этим, я накидал стройную гипотезу: команда возвращает FAILURE, если хотя бы один клиент не встал в очередь, кубер считает это падением и перезапускает, каждый перезапуск заново ставит в очередь всех. Звучало вроде логично.
.
..
...
Да нет, хуйня какая-то.
Пью второй кофе и начинаю проверять.
Сначала что реально задеплоено, а не что написано в values:
backoffLimit: 6 (default)
restartPolicy: OnFailure
activeDeadlineSeconds: 1500
resources: {}
restartPolicy и backoffLimit в чарте не заданы вообще, поэтому дефолты.
К ним вернусь.
Чем заканчивались прогоны:
kube_pod_container_status_last_terminated_reason -> Error
kube_pod_container_status_last_terminated_exitcode -> 255
255. Так не выглядит штатный return FAILURE (это код 1), так выглядит процесс, который умер сам. В PHP это обычно fatal error.
Проверяю memory_limit в поде:
kubectl -n production exec deploy/<app> -- php -r 'echo ini_get("memory_limit");'
256M
Смотрю логи кронджоба: на каком клиенте процесс умирает каждый раз. Каждый раз примерно на середине списка, после ~230-го клиента. Следующий по списку клиент выглядит так:
contacts=~610000
Больше полмиллиона контактов😱, остальные клиенты в среднем сотни или тысячи.
Код команды для каждого клиента делает так:
$ids = Contact::where(...)->pluck('id');
Одним запросом забирает все id контактов клиента, потом map, sort, values, array_chunk по 100, и каждая операция создаёт ещё одну копию массива.
Воспроизвожу в свежем процессе: беру id контактов для этого клиента (прям в поде, а кто что мне сделает).
Allowed memory size of 268435456 bytes exhausted ... Connection.php:428
command terminated with exit code 255
Вот оно.
Заодно проверил, что это не утечка памяти. По ходу цикла память ровная, 60 > 92 MB. Единственный скачок был на клиенте со 160 тысячами контактов. Мемори лик нет, есть один очень большой клиент, и кому-то стоит знать, сколько весит массив из полумиллиона элементов в PHP. Не 4 мегабайта, как кажется по привычке из си, а намного больше: каждая строка из PDO превращается в отдельный объект, сверху пара копий, и.. ..и 256 мегабайт кончаются.
Итак, гипотеза про FAILURE отпала. Триггер другой: OOM на одном клиенте.
Всё, что я думал про цикл перезапусков и локи, оказалось верным, но если бы чинили по этой версии, то есть убрали бы FAILURE из кода, кронджоб в следующую субботу упал бы точно так же 😂😂😂
Теперь откуда ровно 30 прогонов.
restartPolicy: OnFailure значит, что упавший контейнер перезапускается внутри того же пода. Каждый перезапуск выполняет команду с нуля: клиенты 1-230 снова встают в очередь, на 230-м OOM, всё сначала.
Ивенты:
02:10:45 BackOff Back-off restarting failed container
02:25:01 DeadlineExceeded Pod was active on the node longer than the specified deadline
02:25:41 SuccessfulCreate Created pod: ...-h7sr2
Каждые 25 минут под упирается в activeDeadlineSeconds: 1500, Job его убивает и создаёт новый, и всё повторяется. Так прошло 7 подов, а в 04:48 пришёл BackoffLimitExceeded, и Job наконец сдался.
В логах первый клиент из списка встречается около 30 раз, примерно раз в 5,5 минуты.
30 × (первые ~230 клиентов) × тысячи джобов по 100 контактов, и всё в одну очередь!
Каждый джоб при завершении делает SELECT ... FOR UPDATE на строку своего батча. На каждом батче вереница воркеров ждёт лок. Отсюда и картинка в базе:
DBLoadRelativeToNumVCPUs (15m avg / max)
01:45 0.04 / 0.19
02:00 0.38 / 2.50 << кронджоб стартует
04:45 0.91 / 2.75
06:15 0.06 / 0.41 << очередь прочищена
Отдельно мне понравилось, что режим dry-run, который сам ничего не трогает:
- около 30 лишних полных проходов по API внешней системы для каждого подключённого клиента (их провайдер наверняка тоже порадовался😁😁😁)
- сотни тысяч джобов в очереди
- лок-контеншен на базе с 02:00 до 06:00
Dry-run для данных, но не для БД инфраструктуры.😁
Итог:
Внимательный читатель спросит "а что же ты чинил, Алекс?" и будет прав, ведь я ничего об этом не написал. Ведь я ничего и не чинил.😊
На тот момент принял решение ничего не трогать, само пройдет, так и вышло.
Причины простые:
- кронджоб к тому времени уже сам умер (BackoffLimitExceeded ), новых джобов не появлялось, значит очередь могла только уменьшаться
- это dry-run, данные никто не портил, ну локи в таблицу, ну и чо
- всё шло в low-priority, суббота утро, пользователи почти ничего не замечали
Спустя время алерт потух, проблема ушла сама.
Что починили в будни (до следующей субботы, иначе всё повторилось 😀):
- какую то залупу в коде ларавелки, я даже не смотрел в МР
- в кронджобе поставили restartPolicy: Never и backoffLimit: 0. Если команда снова упадёт, она упадёт один раз и громко, без 30 тихих повторов
Мораль.
- дефолты Job в кубере (OnFailure плюс backoffLimit: 6) превращают любой неидемпотентный кронджоб из "упал" в "упал и сделал всё ещё сто раз, сука".
Если команда ставит работу в очередь, а не выполняет её сама, ретраи в Job почти всегда ебаное зло
- Bus::batch с тысячами мелких джобов означает одну горячую строку в таблице и лок на каждый завершённый джоб. Батч это не бесплатный счётчик прогресса.
- иногда надо быть Улиточкой-дежурным-работником месяца | 978 |
| 11 |  #aws #пятница
2016 год.
AWS re:Invent. Под музыку прямо на сцену въезжает фура.
Это AWS Snowmobile: контейнер на 100 петабайт с охраной и GPS.
Зал аплодирует 😲😮😮.
Никто не понимает, зачем это нужно, но все снимают на телефон.
2024 год.
Snowmobile тихо убирают из списка сервисов, без пресс-релиза и без прощальной вечеринки.
Дальше о нём помнят только авторы вопросов к экзамену AWS и несчастные экзаменующиеся.
2032 год.
Дата-центры выходят из строя чаще, чем падают деплои по пятницам.
Единственный бэкап в соседнем регионе удалил ИИ-агент. Его попросили почистить неиспользуемые ресурсы, и бэкап выглядел весьма таким заманчиво неиспользуемым.
Кто-то в Сиэтле вспоминает старую мудрость: never underestimate the bandwidth of a truck full of disks 💪.
Грузовик находят на задворках склада в Неваде.
Обшивают железом и шипами, как в "Безумном Максе", и запускают программу "Snow-бэкап региона".
В 2016-м 100 петабайт казались бесконечностью.
Теперь же в них влезает целый регион, если не брать логи и стактрейсы джавы.
С современными же дисками влезает даже node_modules.
Он несётся по пустому шоссе из Техаса в Миннесоту.
Рулит ИИ-агент со своим роем сабагентов.
Каждые 50 миль он спрашивает:
- "Продолжить? (y/n)".
Охранник в кабине жмёт Y 🤪.
За грузовиком летят дроны. Чьи - никто уже не помнит.
Дронов сбивают беспилотные Waymo, впервые в истории никому не перегородив дорогу. Роботы Unitree забрасывают остальных сетками.
Кто согласовал эту поддержку, неизвестно.
Кажется, просто чёт так навайбкодилось 🤷.
Ночью помятый и в подпалинах грузовик с гирляндой на кабине въезжает в резервный дата-центр.
Играет "Праздник к нам приходит" из рекламы Кока-Колы.
Люди обнимаются. Кто-то плачет.
Восстановление из бэкапа прошло успешно.
Впервые в истории его кто-то реально проверил.
Вернулся даже Netflix. Первым делом он предложил продолжить просмотр с 2031 года.
В слаке инженер пишет:
- "Ашалеть, не думал, что вопрос про Snowmobile с экзамена мне когда-нибудь пригодится 😮"
На ближайшем re:Invent под музыку
The Chemical Brothers - Go прямо на сцену въезжает фура. С шипами.
На борту надпись
"Snowmobile AI. Now with AI agents. AI!".
Зал аплодирует 😲😮😮.
Никто не понимает, зачем там агенты, но все снимают на телефон. | 1 154 |
| 12 | #troubleshooting #devops #одинденьизжизни
Однажды пришёл на работу, я oncall, вижу алерт - поды рестартятся.
Смотрю, что там:
kubectl get pods -n <namespace> | grep redis
redis-ha-server-1 1/4 Running 7 10m
Ага, один под постоянно рестартится. 7 раз за 10 минут.
Смотрю логи:
kubectl logs -p redis-ha-server-1 -c redis -n <namespace>
1:S * MASTER <-> REPLICA sync started
1:S * Full resync from master
1:S * MASTER <-> REPLICA sync: receiving streamed RDB from master
1:signal-handler Received SIGTERM scheduling shutdown...
1:S * User requested shutdown...
Реплика начинает Full Resync, а через 27 секунд получает SIGTERM и умирает. А синхронизация большой базы занимает минуты.
Смотрю ивенты:
kubectl get events -n <namespace> --field-selector involvedObject.name=redis-ha-server-1 --sort-by='.lastTimestamp'
Normal Killing pod/redis-ha-server-1 Container redis failed startup probe, will be restarted
Warning Unhealthy pod/redis-ha-server-1 Startup probe failed: role=slave; repl=sync
Ага, контейнер убивает стартап проб.
Проверяю настройки:
kubectl describe pod redis-ha-server-1 -n <namespace> | grep -A1 Startup:
Startup: exec [sh -c /health/redis_readiness.sh] delay=5s timeout=15s period=10s #success=1 #failure=3
failureThreshold: 3, periodSeconds: 10, initialDelaySeconds: 5.
Первая проверка на 5-й секунде, дальше каждые 10: 5, 15, 25. Третья неудача подряд, и контейнер убивают. Плюс пара секунд на сам скрипт, отсюда и мои 27.
А база весит 550 мегабайт, и Full Resync идёт дольше.
Пока реплика синхронизируется, health check возвращает ошибку.
Через три неудачи подряд startup probe считает контейнер мёртвым, и кублет его перезапускает. Синк начинается заново, и так по кругу.
Проблема вроде бы понятна. Нужно увеличить failureThreshold.
Правлю StatefulSet:
kubectl edit statefulset redis-ha-server -n <namespace>
Меняю failureThreshold у контейнера redis с 3 на 120. Сохраняю.
Удаляю под:
kubectl delete pod redis-ha-server-1 -n <namespace>
Жду, смотрю логи.
Та же херня, рестарты продолжаются.
Сука.
Проверяю, что применилось в поде:
kubectl get pod redis-ha-server-1 -n <namespace>
-o jsonpath='{.spec.containers[?(@.name=="redis")].startupProbe.failureThreshold}'
3
Бл, под создался со старым значением.
А в StatefulSet что?
kubectl get statefulset redis-ha-server -n <namespace>
-o jsonpath='{.spec.template.spec.containers[?(@.name=="redis")].startupProbe.failureThreshold}'
120
В StatefulSet уже 120, а в поде 3.
Что за ебанная магия?
Проверяю, кто управляет StatefulSet:
kubectl get statefulset redis-ha-server -n <namespace> -o yaml | head -30
metadata:
annotations:
meta.helm.sh/release-name: <release>
meta.helm.sh/release-namespace: <namespace>
labels:
app.kubernetes.io/managed-by: Helm
Helm. Но сам по себе Helm ничего не откатывает: reconcile у него нет, ресурсы он трогает только на helm upgrade.
Кто именно подсунул поду старый шаблон, я так и не выяснил. Если поймаете такое, смотрите managedFields: там видно, кто и когда писал в объект.
kubectl get statefulset redis-ha-server -n <namespace> --show-managed-fields -o yaml
Ладно. Шаблон в StatefulSet правильный, значит, надо заставить контроллер пересоздать поды из него. Смотрю стратегию обновления:
kubectl get statefulset redis-ha-server -n <namespace> -o jsonpath='{.spec.updateStrategy}'
{"type":"OnDelete"}
При OnDelete контроллер обновляет под, только когда его удаляют. Я его и удалил, а он всё равно поднялся со старым шаблоном. Почему, честно, не знаю.
Переключаю на RollingUpdate, чтобы контроллер перекатил всё сам:
kubectl patch statefulset redis-ha-server -n <namespace> --type=json -p='[
{"op": "replace", "path": "/spec/updateStrategy/type", "value": "RollingUpdate"}
]'
Проверяю новый под:
kubectl get pod redis-ha-server-1 -n <namespace>
-o jsonpath='{.spec.containers[?(@.name=="redis")].startupProbe.failureThreshold}'
120
Отлично, теперь 120.
Смотрю логи: Full Resync завершился успешно, всё синхронизировалось.
Но дальше вижу, что сразу после успешной синхронизации соединение теряется.
Смотрю логи мастера:
kubectl logs redis-ha-server-0 -c redis -n <namespace> --tail=50
1:M * Connection with replica lost.
1:M # closed for overcoming of output buffer limits
Ага, мастер рвёт соединение, потому что переполнился output buffer.
Проверяю лимиты:
kubectl exec redis-ha-server-0 -c redis -n <namespace> --
sh -c 'redis-cli -a $AUTH CONFIG GET client-output-buffer-limit'
slave 268435456 67108864 60
Hard limit 256 MB, soft limit 64 MB на 60 секунд.
Буфер на мастере дорос до 152 MB. До hard limit не дотянул, но soft limit (64 MB) держался превышенным дольше 60 секунд. Этого достаточно, чтобы мастер убил соединение.
Пока мастер стримит RDB, все новые записи копятся в этом буфере. Большая база и активная запись дают ровно такую картину.
Увеличиваю лимиты:
kubectl exec redis-ha-server-0 -c redis -n <namespace> --
sh -c 'redis-cli -a $AUTH CONFIG SET client-output-buffer-limit "slave 1073741824 536870912 60"'
Теперь hard limit 1 GB, soft limit 512 MB. CONFIG SET применяется сразу, без рестарта. Важен он именно на мастере, но я прописал его на всех нодах: sentinel может переключить мастера в любой момент.
Заодно поднимаю repl-backlog-size до 512 MB. Full sync это не лечит: backlog нужен, чтобы после короткого разрыва реплика догналась частичным PSYNC, а не начинала полный синк заново. Но и памяти он съедает столько же, так что проверь лимиты, если не хочешь поймать OOMKill.
Перезапускаю реплику, чтобы она заново прошла full sync уже с новыми лимитами:
kubectl delete pod redis-ha-server-1 -n <namespace>
Смотрю логи: теперь всё ок. Соединение не теряется, реплика стабильна, никто не пиздит в канале алёртов.
Что сделать, чтобы всё это не слетело
Всё, что я накрутил руками, временное:
- kubectl edit, kubectl patch и смена updateStrategy слетят на следующем helm upgrade или sync
- CONFIG SET живёт до рестарта пода, потом конфиг снова берётся из ConfigMap
По-нормальному это должно жить в values чарта, в Git:
redis-ha:
redis:
startupProbe:
failureThreshold: 120
config:
client-output-buffer-limit: "slave 1073741824 536870912 60"
repl-backlog-size: "512mb"
Итог.
- дефолты редиса (или чарта редиса?) не рассчитаны на 550 MB кеша (на тот момент было около 25000+ аппилкейшнов)
- Helm не делает reconcile, но ручные правки в кластере всё равно не живут, всё постоянное должно лежать в values
- если под пересоздаётся со старым спеком, смотрите managedFields; RollingUpdate может помочь, но мастер тоже перекатится, будет failover
- CONFIG SET живёт до рестарта 🫠
Довольный, на дейли рассказываю, как героически победил редис.
Лид дослушивает, кивает и спрашивает:
- А нахера ты с этим возился? Это ж редис арго, там только кеш.
Дропнул бы базу, и всё.
- ...
Читаю интернеты, так и есть. Всё лечилось одной командой на мастере:
kubectl exec redis-ha-server-0 -c redis -n <namespace> --
sh -c 'redis-cli -a $AUTH FLUSHALL'
Реплика синкает пустую базу за секунды, арго сам заново греет кеш.
Справедливости ради, кеш снова дорастёт до 550 MB, так что values с лимитами всё равно пригодятся. Но это можно было сделать спокойно, а не под алертами!
Мораль: прежде чем героически чинить, спроси себя, что это вообще за данные и жалко ли их.🤡🤡🤡
Сгорая от стыда, пишу эту заметку и скрываюсь в тумане 🚶♀ | 899 |
| 13 |  #kubernetes #devops
Kubernetes не решает проблемы хуёвого софта.
Если приложение течёт по памяти, не умеет в пробы, не отдаёт метрик, не умеет в параллельность, падает от каждого чиха и хранит стейт в локальной папке, то в кубере оно будет делать то же самое, только теперь с регулярным рестартом и алертами в три ночи. | 1 026 |
| 14 |  Последние пару лет, и на этой работе, и на прошлой, каждая встреча у меня начинается одинаково: я либо игнорирую, либо радостно жамкаю "отклонить" всем ноттейкерам в лобби.
Позиция простая: либо приходите сами, либо сами нажимайте "разрешить" своим ботам и идите по своим делам.
Всю жизнь мечтал работать швейцаром у ботов в Zoom/Teams/Google Meet 🙂
На самом деле бесит пздц. | 1 233 |
| 15 |  Интересно, а что там внутри?
Типа полетели алёрты в слак из датадог/ньюрелик/алертменеджер.
Потом включается Claude on-call.
Caramelizing...
Flibbertigibbeting...
...
Cogitating
...
Contemplating...
Coalescing...
И потом типа он такой выдаёт
Found root cause...
It was ... Release!...
Opening a revert PR...
С вас 500k токенов, лол.
Так?
Ну я к тому, что когда агент работает от моего ПК, у меня есть скиллы, инструкции где что брать, настроен конфиг, есть MCP, есть VPN, ежедневно прохожу авторизацию для SSO, раз в пару недель для google аккаунта - и от меня всё работает так, как я хочу при траблшутинге по алертам.
Не очень хорошо, но терпимо работает агент в автономном режиме с моего пк, лишь ровно до тех пор, пока не слетят авторизации и VPN или пока он не начнёт нести херню в слаке коллегам, раздражая их (ему пофиг на запреты не писать в слак свои простыни текста моим коллегам, сука).
Только проблема далеко не всегда в релизе, а в куче других факторов.
Для анализа нужны метрики, логи, ивенты и так далее.
Всё это под SSO авторизацией, в закрытом контуре.
А если всё-таки проблема в релизе - простите, роллбек кривого релиза сделает любой инженер, который умеет считать дважды два и у него есть хотя бы один глаз.
Зачем тут агент?
А как это работает с клод онколлл?
Как он сможет траблшутить чего-либо, если у него физического доступа нет?
Предоставить доступ? Задеплоить сабагента в кубер и дать ему IRSA/pod identity на нужные ресурсы? Сделать мир прекраснее и открытее для всех агентов?
Короче маркетинговая коричневая магия какая-то.
Решил посмотреть документацию.
Оказалось, что живёт он не в наших кластерах, а в песочнице Антропика, так что IRSA мимо.
Креды берёт из сервисных учёток, которые мне надо завести и отдать им, и ходит только по HTTPS.
VPN, SSH, SMM и прямой доступ к базам ему недоступны, тоже мимо.😁
Если весь обсервабилити в SaaS (Datadog, New Relic) - ок, выдал read-only апи ключ и поехали.
А если Prometheus/VictoriaMetrics, логи и кубер живут за VPN - либо открывать ему всё наружу🤣, либо получаешь тот самый "It was Release… Opening a revert PR…".
Ну в общем пока поживём на локальных/кубер агентах (типа https://github.com/kagent-dev/kagent или http://github.com/mezmo/aura, тысячи их), без клод онколла. | 1 354 |
| 16 | 没有文字... | 1 248 |
| 17 |  #aws #AWScommunity #eks #kubernetes
Что выбрать при создании нового AWS EKS кластера в 2026 году: стандартный режим или Auto Mode?
Выбирайте стандартный режим (без Auto Mode), если вы:
- хотите разобраться в облачном кубере Амазона и изучить десяток компонентов (Karpenter, VPC CNI, CoreDNS, kube-proxy, EBS CSI, Load Balancer Controller…), которые вам теперь придётся обслуживать примерно всегда
- любите тюнить кубер или компоненты минимум раз в квартал
- боитесь, что вас заменят ИИ, и хотите оставить себе крепкий якорь, который помешает вас уволить
- любите читать матрицы совместимости и GitHub issues по каждому компоненту
- гоняете большой флот на спотах или сейвинг план и умеете считать деньги
- без своего AMI, софта прямо на ноде или собственного CNI жить не можете
- любите зайти на ноду по SSM и посмотреть чо там
- живёте на Windows- или Ubuntu нодах 😬
Выбирайте Auto Mode, если:
- у вас нет DevOps/Platform команды, которая бы поддерживала кубер, потому что вы стартап
- вы руководитель, всех уволили, заменив на ИИ, и теперь, как Дункан Маклауд, остались один и не знаете, что делать с вашим кубером ⚔️
- хотите тратить время на код и манифесты, а не на поддержку инфраструктуры
- готовы потерять последние крохи экспертизы по эксплуатации нод и аддонов для куба, ведь уже через год на автомод вы не сможете объяснить на собесе, как у вас апгрейдится CNI и что это такое
- у вас нормальная зрелая компания, которая ценит время инженеров дороже 12% к счёту за EC2 и не страдает ИИстерией
Лично я бы всегда по умолчанию брал автомод. | 1 195 |
| 18 |  #пятница
Ждём, чо.
А вообще да, заебали эти охринительно полезные новости с невероятными достижениями. | 1 284 |
| 19 |  #kubernetes
- https://laravel-news.com/laravel-health-kubernetes-prometheus
Жаль, что такого пакета не было, когда я работал с Laravel.
Раньше приходилось городить костыли: самописные эндпоинты, несколько разрозненных пакетов, ручная настройка liveness/readiness-проб и прометиус-метрик.
Был spatie/laravel-health с хорошим набором проверок, но отдельных эндпоинтов под кубер и прометиус из коробки в нём (раньше) не было.
Теперь есть новый пакет (по ссылке от cboxdk):
- много проверок: БД, кэш, очереди, редис, storage, диск, расписание (через heartbeat шедулера), окружение, CPU и память
- отдельные эндпоинты под кубер: /health (liveness), /health/ready (readiness), /health/startup (startup)
- встроенные прометиус-метрики на /health/metrics: статус и длительность каждой проверки плюс системные метрики
- container-aware метрики из cgroups v1/v2: лимиты и потребление памяти, CPU quota, CPU throttling и OOM kills
Пакет совсем молодой, звёзд с неба не хватает на гитхабе пока мало, так что в прод я бы тащил его после внимательного взгляда на код. И сначала стоит проверить, что именно попадает в liveness: если туда входит проверка БД, то при падении базы кублет начнёт перезапускать все поды разом😁.
Однако авторы, если не ошибаюсь, это https://cbox.dk/, у них точно есть опыт с PHP/Laravel и я уверен, что пакет будет весьма успешным.
В целом хорошая новость для владельцев Laravel стека, кто в кубере живёт.
Требования:
- PHP 8.3+
- Laravel 11-13 | 1 443 |
| 20 |  Но стоит взять задачу из смежной области, где общее понимание есть, а глубокой экспертизы нет, – и всё меняется до неузнаваемости, с ИИ из помощника превращается в пожирателя времени.
Действительно, а почему так выходит.😕
Непонятно, ведь ИИ всех заменит, а образование и экспертиза через время и опыт больше не нужны, да.
https://lnkd.in/p/d7JDGDdQ | 1 388 |
