Кубертатный период

💡 А вы знали, что Trivy Operator может автоматически искать уязвимости в ваших workloads, сканируя используемые образы и предоставляя отчеты с CVE прямо в кластере. Дашборда правда не нашлось, пришлось сгенерить по шустрому — https://github.com/pashtet04/grafana-dashboards/blob/main/trivy-operator.json За короткое время были обновлены большая часть инфраструктурных сервисов CRITICAL ⬇️26% HIGH ⬇️20%

Еще один пример XY Problem В аппку летит кривой реквест (не тот хост, заголовок или еще что-то — неважно). И вместо того чтобы задаться вопросом почему начинается а давайте перепишем код, чтобы он переписывал реквест на правильный И это барахло вроде даже работает. Но проблема никуда не делась. Потом это всплывёт в самом тупорылом месте: на втором домене, в другом окружении, за CDN, после смены балансира, при переезде в другой ingress/controller/платформу. Не говоря уже о том что часто такое решение сопровождается кривым нечитаемым и неинтуитивным кодом. Не надо так делать — пытайтесь лечить причины, а не симптомы

🛰 STUNner: если вам нужен способ протащить WebRTC media в приватный Kubernetes... ...а у нод нет публичных IP, а приложению нужно принимать WebRTC media traffic по UDP/TCP. И с media traffic уже начинается боль: UDP, NAT traversal, TURN, ICE и прочие радости WebRTC 🫠 📡 STUNner как раз решает эту проблему: он работает как Kubernetes-native TURN Gateway и позволяет завести WebRTC media traffic в кластер, не открывая ноды наружу, без hostNetwork и без виртуалок с NAT/TURN.

fix(controller): preserve HPA-managed deployment replicas небольшой PR в Apache Superset Kubernetes Operator: исправил (конечно же с помощью ИИ 🤖) reconcile при включенном автоскейлинге Суть простая: если включен HPA, то оператор не должен управлять Deployment.spec.replicas. этим должен заниматься HPA. Иначе случается карусель, HPA скейлит вверх, а spec.replicas сразу терминирует поды. Еще один шильдик на GitHub за контрибьют в open source 🐘

Зацените какую штуку тут товарищ написал: https://github.com/crust-gather/crust-gather Она сохраняет стейт Kubernetes кластера в OCI-имадж (со всеми CRD, статусами, ивентами, подами и их логами) Потом его можно запустить локально и в нем покопаться обычным kubectl. Можно клода натравить, можно k9s, и т.п. Идеально подходит чтобы интегрировать в свой пайплайн. Написано на rust'е. Завтра будет рассказывать о ней на KCD https://kcd-czech-slovak-2026.sessionize.com/session/1195463 (есть прямая трансляция)

We’re excited to introduce opensource vmestimator, a new component in the VictoriaMetrics ecosystem. vmestimator measures metrics cardinality across arbitrary label dimensions and exposes the results as Prometheus-compatible metrics. It helps to understand where cardinality comes from, track how it evolves over time, and build early-warning alerts before cardinality becomes a problem. If you’re operating Prometheus-compatible monitoring systems and want realtime visibility into metric cardinality, give vmestimator a try. We’d love to hear your feedback and learn more about your use cases. Read more about its design and configuration in the documentation, or explore it yourself in the playground.

Наткнулся на очередную статью: «Zero-Downtime Deployments with Docker Compose — No Kubernetes Required». Автор прямо пишет - в индустрии, мол, массовое заблуждение, что для серьёзного прода нужен k8s. Не нужен. Тысячи проверок в минуту, мульти-регион, деплой по нескольку раз в день - и всё на компоузе. И тут он прав. Для одного хоста и пары сервисов Kubernetes - это из пушки по воробьям. Бесшовно перекатить контейнер умеет и nginx, никакой оркестратор для этого не нужен. Только это подмена тезиса. В k8s идут не за zero-downtime деплоем - за ним и так все умеют. Идут за другим. Первое - пул машин. Compose заперт в пределах одного хоста. В комментах это сразу и поймали: «тысячи проверок в минуту - это вообще немного, спокойно живёт на одной железке. Kubernetes берут, когда надо выйти за её пределы». Вот и весь спор. Второе - стандарт. k3s ставится за пять минут, и ты получаешь готовую вселенную типового тулинга. Новый человек приходит с любого облака и сразу в теме. А не разбирает полгода твой самодельный оркестратор из bash'а и скотча. Лучший коммент в треде - вообще не про технику. Человек честно признался: «взяли инструмент попроще, проект взлетел - и все эти "сложные" фичи k8s внезапно стали нужны. Зря не взяли сразу». Знакомо до боли. 🤡🤡 Короче. «Не нужен Kubernetes» - честный заголовок. Просто допишите в конце: «пока у тебя один хост». А на втором десятке нод поговорим заново. #kubernetes #docker #devops

Кто-нибудь пользуется GnuCash? Мне как обычно было нехуй делать утром и я запилил дашборд. Вдохновлялся нейрослопом от вайбкодера в интернете — https://cashdera.com/ Тут все по-дефолту: вместо уже имеющихся инструментов, которые не смогли осилить, чел решил наваять что-то "свое" с ИИ. https://gist.github.com/pashtet04/ebd3d1a4e0f5253a835b622f7d8a9913

Зумеры — они такие

Кстати пост написан с применением ЕИ

полгода назад ко мне пришли с вопросом, мол, есть какой-то сервис что-то про «ембеддинги», я особо не разбирался: ну еще какой-то микросервис где-то, хотим масштабирование «scale to 0». вводная при этом звучала конкретно: скейлиться нужно на основе кастомной метрики очереди — в очереди есть сообщения, значит поднимаем сервис, нет сообщений — 0. ну и я в общем-то почти не думая сразу вкинул про Keda, обрисовал что такое как работает и зачем. я еще пару раз слышал, что с этим вопросом еще разбираются, попутно удивляясь, почему так долго: ведь очередь есть, сообщения там есть, сервис есть.. осталось лишь воткнуть ScaledObject и все.. но не так то просто! как я тогда это понял: есть queue-driven workload, которому просто не хватает autoscaler’а. Проходит 8 месяцев, в репо Helm чарт (там большой umbrella chart с одной зависимостью в виде default chart) вижу MR, в котором добавлена возможность описать «сайдкар» для того самого сервиса «ебмеддинг». я слегка охуев от такой задумки, пошел разбираться че за хуйня. Выяснилось: сервис «ембеддинг» не работает с Amqp, а идея была скейлиться на основе очереди, а значит был написан сервис адаптер на пайтоне, который читает очередь и отправляет запросы в ембеддинг. а работают они в одном поде, чтобы таким образом балансировать нагрузку. Я в очередной раз ахуев, пошел смотреть что это за сервис такой у них, и тут оказалось что это модель с hugging face которая сервится через тулкит на Rust, который называется text embedding inference, в который просто посылают http запросы и который по сути обычный прикол из интернета third-party (по сути готовый inference server, а не наш бизнес-сервис), а его воткнули в в релизный цикл со всеми другими разрабатываеми сервисами. Как же важна легкая осведомленность! Я взял Knative Serving, выкинул тот MR, добавил включение/выключение knative на описанном сервисе, перевел этот инференс на knative service, настроив масштабирование от нуля и все заработало. и внезапно задача, которая 8 месяцев обрастала адаптерами и сайдкарами, схлопнулась до нормального serverless HTTP-serving паттерна менее чем за сутки, а то и несколько часов.

SDLC который мы заслуживаем

ставит приложение в кубер helm чартом, через аргосд, в котором плагины на баше, которые через kustomize создают секреты из репо поиском по *.yaml с приправами башей для волта в какой момент чатгпт должен был встать и огреть его по голове?

Тут говорят, что какие-то новые инструменты появились на компьютере — Excel. Говорят, бухгалтера больше не нужны. Скоро и у нас руки освободятся.

Let’s Encrypt: Стали общедоступны короткоживущие сертификаты и поддержка IP-адресов #habr https://habr.com/ru/articles/986000/ Tags: ssl-сертификаты, letsencrypt, cicd, https, ip Author: rakhanau

сэкономил твою зарплату на дев стенде Мне тут было делать нехуй в отпуске и я сделал очередной ненужный дашборд про оверкоммит ресурсов (да и не только) о котором никто не просил Меня не устраивали дашборды из интернетов и дефолтные, потому что их нужно было каждый раз читать и интерпретировать. А мне хотелось иметь под рукой инструмент для принятия решения (decision making). тут сразу видно • cluster overview (total requests / total limits / total headroom) • node overview (requests allocation by node group / top requests by nodes) • namespace overview (top requests by namespaces / pod restarts + oom / top pods by cpu throttling / top overcommited namespaces) • pod overview (requests vs usage / recommendations) https://github.com/pashtet04/grafana-dashboards/blob/main/k8s-sizing.json p.s.: кое где удалось срезать до 60% костов сразу же

Пока вы спали - Майкрософт ввёл плату за self-hosted GA раннеры -> был разъёбан Хашимото-саном и OSS коммьюнити -> с хрустом врубил заднюю (https://x.com/github/status/2001372894882918548?s=20)