sdnv's funk-hole

Пятница только началась, а нетфликс уже отмечает

#пьятница

 Вышел релиз 0.33.1 SRE Learning Platform - крупнейшее обновление по Istio за всю историю проекта: полноценный курс для самостоятельного изучения + 4 новые практические лабы.

Если готовитесь к экзамену ICA или эксплуатируете Istio в проде - это для вас


- НОВОЕ:
- курс по Istio для самостоятельного изучения
32 главы, разбитые на две части:
• Часть 1 - подготовка к экзамену ICA
• Часть 2 - лучшие практики для прода

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

- 4 новые лабы по Istio:
• Лаба 32 - gRPC: балансировка нагрузки по запросам, именование портов, ретраи и таймауты
• Лаба 33 - производительность и эксплуатация control plane: discovery selectors, Sidecar scope, golden signals istiod, OPA Gatekeeper
• Лаба 34 - защита и модель угроз: STRICT mTLS, default-deny, контроль egress, RBAC для Istio CRD, NetworkPolicy
• Лаба 35 - мультикластерный mesh: multi-primary, multi-network, общий CA, east-west gateway, межкластерный discovery


⚙️ Улучшения:
• ping_pong теперь работает по gRPC (Echo + Health + reflection) со встроенным gRPC-клиентом / генератором нагрузки
• Debug-образы ставят kubectl-k8i через krew с автодополнением в shell; scratch/alpine-образы теперь кросс-компилируются нативно (BuildKit BUILDPLATFORM), а не под QEMU

Платформа бесплатная и с открытым исходным кодом. Ставьте звезду, форкайте и учитесь ⭐️
https://github.com/ViktorUJ/cks

Отличного настроения и пусть ваш прод живёт без падений!

#Istio #ServiceMesh #Kubernetes #SRE #DevOps #CloudNative #ICA #gRPC

🔄 Всё, что вы забыли обновить, будет использовано против стабильности

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

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

Поговорим про:

📌 первые SLI и дашборды
📌 error budget и почему он не всегда удобен в ежедневной работе
📌 бизнес-процессы, которые нельзя описать одной метрикой
📌 странные кейсы с Kafka, inbox/outbox и низким трафиком
📌 автогенерацию Grafana-дашбордов
📌 декларативные индикаторы и эскалации как код

🏃 Читайте на Хабре!

Зацените корейский spot-model 2007 года

Ibanez S620EX1

#девайсы

Загадка ядра Linux: почему на 36 vCPU Cilium падает, а на 32 — нет
https://habr.com/ru/companies/flant/articles/1043512/

Следуя нашему правилу вносить изменения в инфраструктуру максимально осторожно, мы сперва выкатили всё на стейдж. Развёртывание прошло успешно. Но спустя несколько недель начались спорадические сбои: примерно раз в неделю один из агентов Cilium падал так, что приходилось полностью перезагружать весь узел. Никаких явных паттернов или очевидных причин. Баг случался редко, но бил слишком больно, чтобы пускать такое в production.

Первая мысль — скорее всего, намудрили с конфигурацией, ведь Cilium — серьёзный, проверенный в бою проект, который используют тысячи компаний по всему миру. Наверняка мы допустили ошибку в конфигурации или столкнулись с пограничным случаем. Забегая вперед — догадка оказалась и верной, и неверной одновременно, причём весьма неожиданным образом.
. . .
Заметил кое-что интересное: упавшие агенты Cilium потребляли аномально много памяти во время запуска узлов, на которых они размещались. Причём потребление памяти не росло постепенно — на графиках были видны резкие всплески прямо при инициализации узла.
. . .
Я начал экспериментировать с различными параметрами Cilium: лимитами памяти, размерами eBPF-карт, различными настройками производительности. Затем попробовал отключить одну специфическую опцию, связанную с производительностью (bpf-distributed-lru: false), и перезапустил тест. Сбои прекратились. Включил её обратно — сбои вернулись. Снова отключил — всё стабильно. Многочисленные перезапуски теста показали: закономерность сохраняется.
Это была первая реальная зацепка: баг был напрямую связан с некой оптимизацией, которую мы включили, руководствуясь официальными гайдами Cilium.
. . .
При включённом distributed LRU ядро округляет вверх количество записей в карте до значения, кратного num_possible_cpus().
Вот где скрывалась проблема! Ядро автоматически корректировало размер любой карты так, чтобы он был кратен количеству ядер процессора. В конфиге Cilium мы жёстко прописали статический размер карты, как рекомендует официальная документация: bpf-ct-global-tcp-max: 131072

Это степень двойки (131 072 = 217), как и рекомендуют гайды. И оно отлично работало… пока количество ядер тоже было степенью двойки. Но вот в случае 36, 48 или 72 ядер значение округлялось вверх, создавая несоответствие.

Последовательность событий, которая приводила к проблеме, выглядит следующим образом:

- Cilium настраивает карту на 131 072 записи.

- Ядро округляет это значение до 131 076 (на узле с 36 ядрами).

- Цикл согласования (reconciliation) Cilium проверяет размер карты.

- Обнаружено расхождение: в карте 131 076 записей, а должно быть 131 072.

- Cilium удаляет карту и пересоздаёт её с размером 131 072 записи.

- Ядро округляет значение до 131 076… и так до бесконечности!

Оригинал
Kernel Archaeology: Why 36 CPUs Crash Cilium But 32 Don’t
https://medium.com/qonto-way/kernel-archaeology-why-36-cpus-crash-cilium-but-32-dont-2007f6f6772a

Ставь лайк, если узнал в этой новости свою ИТ-инфраструктуру

Упала самописная приложенька в местном PaaS-е, потянув за собой продакшн, но клиенты ничего не заметили, потому что отработал Circuit Breaker

Вертикальный корпус оказался чудовищно неудобным (казалось бы)

Переезд в аквариум ✅
#девайсы

Надеялся, что мне оно не пригодится
Не думал, что отработает так скоро

На данной фотокарточке можно лицезреть все устройства умного дома которые я использовал (ну почти все)

В коридоре Панель S1 Plus, через которую я могу управлять всем умным домом, общаться с домофоном G4 и механически управлять светом в коридоре (под капотом есть двухкнопочный выключатель)

В каждой комнате используются выключатели H1 и Z1 Pro (2 и 4 клавиши. Да, я использую все 4, нет не пианино. Если конечно разобраться😃)
+ Ранее упомянутые в прошлом посте, два диммера H2
+ Беспроводной диммер который работает как проходной в коридоре
Стоят двухканальное и одноканальное реле прямо в щитке, они рулят светом на бра в спальне и гостиной
По всей квартире использую 19 спотов с лампами T2 RGB + линейные светильники из поста с диммированием + ещё пару спотов, но уже с обычными GU10 (зато с RA >90)
К подсветке кухни тоже прикрутил реле, повесил сверху кнопочный выключатель
В спальню для общего света взял светильник T1M, им рулит вышеупомянутый Z1 Pro (диммер на нем жутко неудобный, надо подкручивать чувствительность и привыкать)

У меня приходят два стояка, на кухню и на с/у
Пришлось ставить 2 комплекта защиты от протечек
К сожалению, не получилось поставить везде приводы шарового крана
В с/у стоит теперь двухканальное реле + гидролок для акары
На кухне 1 привод и 1 гидролок с одноканальным реле (вот такой вот зоопарк)
Ну и сами датчики протечки распиханы: под раковинами, за стиралкой, за инсталляцией

Умные розетки имхо не нужны (как и приводы для штор)
Но я поставил парочку для основного ПК и для серверной, чтобы мониторить аппетиты

Из климата это 3 регулятора теплого пола: входная группа, ванная и балкон
Только 1 датчик температуры и влажности, в мае заедет бризер+кондиционер и ещё пачка датчиков

Ну, а за подъездный домофон отвечает espdomofon v8

Из автоматизаций у меня пока только рулёжка светом (в том числе задействуя датчик присутствия)
Жду климат, чтобы начинать эксперименты

#девайсы

⌨️ Забудьте про IPv6, он нам больше не нужен, тут IETF выкатил черновик IPv8

Пока индустрия 25 лет пыталась с плачем и болью пересадить нас на IPv6, заставляя учить наизусть шестнадцатеричные кракозябры с двоеточиями, умные люди в IETF поняли, что пациент скорее мертв, чем жив. Встречайте... опубликован официальный драфт IPv8. И с технической точки зрения это, мать его, абсолютный архитектурный шедевр 😮

Вместо 128-битной нечитаемой наркомании IPv6, авторы IPv8 предлагают элегантный костыль, возведенный в абсолют. Адрес IPv8 это ровно 64 бита. Читается он в формате r.r.r.r.n.n.n.n.

Первые 32 бита (r.r.r.r) это номер вашей автономной системы (ASN). Вторые 32 бита (n.n.n.n) это старый добрый, теплый и ламповый IPv4-адрес! 🖥

Выходит, что каждый владелец ASN в мире автоматически получает пул в 4,2 миллиарда белых IP-адресов. Проблема истощения IPv4 решается математически, без костылей вроде CGNAT. Для примера, адрес выглядит так... 64496.192.168.1.1 (где 64496 это ваш ASN).

Главный факап IPv6 заключался в требовании двойного стека. Нужно было переписывать софт, менять железо и страдать. В IPv8 обратная совместимость на 100%

IPv4 является нативным подмножеством IPv8. Если префикс r.r.r.r = 0.0.0.0, то пакет маршрутизируется по старым правилам IPv4. Никакого переписывания легаси. Весь старый софт продолжит работать через стандартный сокет AF_INET, а трансляцией займется ОС. Переход можно делать плавно, островками, туннелируя IPv8 поверх старых IPv4-сетей.

Сегодня глобальная таблица маршрутизации BGP4 пухнет от деагрегации префиксов (уже под миллион маршрутов), роутеры плачут и просят RAM. В IPv8 маршрутизация двухуровневая. На глобальном уровне (eBGP8) роутинг идет ТОЛЬКО по номеру ASN (r.r.r.r). Размер глобальной таблицы аппаратно ограничен количеством зарегистрированных автономных систем в мире (сейчас это около 175 тысяч). Таблица худеет в 5 раз, процессоры магистральных маршрутизаторов уходят в спячку 🛌

Авторы драфта решили перепахать не только адресацию, но и весь зоопарк сетевого управления. DHCP, DNS, NTP, логгирование и ACL объединяются в единую концепцию Zone Server, это когда девайс втыкается в сеть, делает один DHCP8-запрос и получает эндпоинты для ВООБЩЕ ВСЕХ сервисов разом 😮

Но самое крутое - это секурити. Авторизация всех сетевых узлов идет через токены OAuth2 JWT прямо на L3/L4 уровне! Узел физически не может выйти во внешний интернет, если у него нет DNS8-запроса на этот домен и валидного токена. Это на корню умножает на ноль 99% современных ботнетов и малвари, которые стучатся на хардкодные IP-адреса C&C-серверов. Пакет без DNS-лукапа просто дропается на выходе 💩

Да, в вопросах приватность есть нюансы, но перед нами невероятно прагматичный стандарт, который решает проблемы 30-летней давности, не заставляя ломать привычные паттерны мышления.

Типичный 🥸 Сисадмин

Ждите заморозков, это не учебная тревога, а самый настоящий пост в канале!

В попытках скоротать время в пути домой с DevOpsConf 2026 (а 4 часа в сидячем вагоне – это вам не шутки) я внезапно вспомнил, что у меня есть канал, в который надо бы что-то иногда писать, так что вот там поток сознания от докладчика конференции.


Роль "докладчика" на этой конференции была для меня весьма условной в этом году, доклада у меня не было (но скоро будет, ждите анонс), я поучаствовал в одном из воркшопов в качестве эксперта (я – эксперт, сам не верю) и члена жюри. Отдельное спасибо Кириллу и Денису за приглашение, это первый подобный опыт для меня и сразу такая удача: крупнейшая конференция, крутая команда, необычный формат. Еще и попал на доклады к ребятам из своей команды – а они невероятно классные, обязательно поделюсь с вами записью их выступлений.

Немного контекста о воркшопе: Пять команд, каждой достался свой кейс для работы в группе – описание некого высоконагруженного сервиса, его архитектуры, требований SLA и сценарий инцидента. За 30 минут командам предстояло спроектировать систему наблюдаемости своего продукта: описать метрики, логи, трейсы и SLO для сервисов, придумать алерты и дашборды. Каждому столу дали по 5 минут на презентацию и защиту своего решения, затем оценка от соперников и экспертного жюри. Нашей задачей, как экспертов, стала фасилитация обсуждения – мы помогали участникам, направляя их в нужную сторону, не давая растекаться мыслью по древу и углубляться в лишние детали.

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

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

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

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

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

SRE – это, в первую очередь, про людей и процесс, про культуру, а не про технологию. Вы можете нарисовать десятки дашбордов и сотни алертов, но какой в них толк, если их никто не увидит вовремя и они не помогут вам быстро докопаться до сути проблемы.

Нужен райтап

https://habr.com/ru/companies/amnezia/articles/1013320/

Написал небольшой exporter на go. C его помощью можно реализовать мониторинг истечения срока дейтсвия access token в проектах. Обычно они сплошь и рядом используются в CI, когда проектов много, забываешь что и где добавлял. Экспортер умеет собирать все токены и отдвать метрики в виде prometheus по gitlab группе или отдельным проектам.
Если будете использовать групповой токен, например чтобы собирать одним токеном сразу по всем проектам группы, то "сам себя" он видеть не будет, у группового токена другое API. Но мониторить все же можно, например задать статично переменную gitlab с timestamp вида:

<gitlab_domain_name> : <timestamp> ,<gitlab_domain_name> : <timestamp>, <gitlab_domain_name> : <timestamp>

И далее получить так:

vector(${gitlab:value} - time())

Если используется точечный проект из конфига exporter-а, то токен доступа видит сам себя.

Код тут.

Также приложу статичный scrape для витории на всякий случай

- job_name: gitlab-access-token-exporter
  kubernetes_sd_configs:
    - role: endpoints
  relabel_configs:
    - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name, __meta_kubernetes_endpoint_port_name]
      action: keep
      regex: monitoring;gitlab-access-token-exporter;http
    - source_labels: [__meta_kubernetes_namespace, __meta_kubernetes_service_name]
      replacement: ${1}/${2}
      target_label: kubernetes_service
    - target_label: gitlab
      replacement: <you gitlab domain name>

И вырожение для grafana alerts:

gitlab_project_access_token_expires_in_seconds > 0 and gitlab_project_access_token_expires_in_seconds < 14 * 24 * 3600

Тут алерт придет по токену, которому осталось 14 дней.

#monitoring

godap - удобный и мощный TUI для LDAP



Возможности:
— поддерживает аутентификацию с помощью пароля, NTLM-хеша, тикетов Kerberos или сертификата PEM/PKCS#12
— преобразует дату/время, логические значения и другие категориальные атрибуты в читаемый текст
— красивые цвета и крутые эмодзи
— поддержка LDAPS и StartTLS
— быстрый проводник, загружающий объекты по запросу
— рекурсивный поиск объектов в сочетании с полезными сохраненными поисковыми запросами
— гибкий поиск участников групп и групп пользователей
— поддерживает создание, редактирование и удаление объектов и атрибутов
— поддерживает перемещение и переименование объектов
— поддерживает поиск удаленных и переработанных объектов
— поддерживает экспорт определенных поддеревьев каталога в файлы JSON.
— интерактивный редактор userAccountControl
— интерактивный просмотрщик + редактор DACL
— интерактивный просмотрщик + редактор ADIDNS (базовый)
— просмотрщик групповых политик
— поддержка SOCKS


Подробнее: https://github.com/Macmod/godap

src: @devops_memops

Мы бы никогда не увидели такую картину, если бы я не захотел реализовать диммируемое LED-освещение через механический диммер от Aqaraпростихоспаде

И да, оно работает
И да, без жуткого ШИМа

Изначально я пытался сделать все на трековом освещении, но:
1. Нет нормальных БП/драйверов которые умеют конвертировать TRIAC в 1-10V (может такое физически нереализуемо?)
2. Не бывает диммируемых линейных трековых светильников в 220V
3. Есть возможность использовать только 220V споты со сменной лампой. В таком случае трек бесполезен для меня

Решил взять накладной линейный LED-светильник и нашел у того же вендора драйвер позволяющий диммировать через TRIAC ヽ⁠(⁠｡⁠◕⁠o⁠◕⁠｡⁠)⁠ﾉ

Диммер: Aqara Dimmer Switch H2
Светильник: Maytoni C133CL-12W4K-W
БП/Драйвер: Maytoni PSL-TR40-300mA
БП можно заменить на PSL-TR40-150-300mA

Все что нам нужно сделать это снять термоусадку с родного драйвера светильника и отпаять сам драйвер/срезать кабель (рис.2)

Затем снять штекер с БП (он подписан LED) и скоммутировать светильник с БП любым удобным способом соблюдая полярность блеат ಠ⁠_⁠ʖ⁠ಠ

Вывод на нагрузку от диммера подключаем к БП и вуаля вы прекрасны

Из интересного:
Диммером можно управлять через Алису/приложение, но область диммирования от 75 до 100%
75% это фактически минимальная яркость светильника
Скорей всего это минимальная напруга которую можно дать на этот светильник
На других светильниках нижняя граница диммирования на 83% яркости

#девайсы

🖨 3D-модель корпуса для ESPDomofon v8 — теперь доступна!

Выкладываем STL-файлы корпуса для платы ESPDomofon v8. Модель состоит из двух деталей — основание и крышка — и печатается на любом FDM-принтере без поддержек. Спасибо за создание модели https://t.me/sdnv_funkhole

Что внутри:
— Посадочное место точно под плату v8
— Вырез под USB Type-C питание
— Окно для индикаторных светодиодов
— Защёлкивается без винтов

Параметры печати:
Материал: PLA или PETG
Слой: 0.1 мм
Заполнение: 20–30%
Время печати: ~40–60 мин

Скачать можно тут: https://wiki.smartintercom.ru/ru/needs/3d-model-v8

#SmartIntercom #ESPDomofon #3Dprint #DIY #умныйдомофон

Некоторые может помнят, что я в процессе ремонта и постройки умного дома

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

Один из продуктов которые я себе заимел - espdomofon
Железка позволяющая превратить ваш глупый координатный домофон в умный

Платка ставится в разрыв между подъездом и трубкой
Позволяет открывать дверь через телегу, Алису и тд, можно нарулить скрипты открывания и подключить к HA/SprutHub

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

Мы с товарищем слегка подзаморочились и запилили 3D-модельку корпуса для espdomofon v8
С отверстиями под светодиод и винты клеммы

Чем и хочется с вами поделиться

Творение рук @AlexFly87
Смоделирует и напечатает🔥

#девайсы

witr (Why is this running?)

Утилита witr отвечает на один-единственный вопрос:

Почему это запущено?

Когда что-либо работает в системе, будь то процесс, служба или что-то, привязанное к порту, всегда есть причина. Эта причина часто бывает косвенной, неочевидной или распределена по нескольким уровням, таким как контейнеры, службы или оболочки.

Существующие инструменты (ps, top, lsof, ss, systemctl, docker ps) предоставляют доступ к состоянию и метаданным. Они показывают, что запущено, но оставляют пользователю возможность самостоятельно определить причину, вручную сопоставляя результаты работы разных инструментов.

Репыч на Гитхаб

src: @usr_bin_linux