sdnv's funk-hole

⌨️ Забудьте про 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 – это, в первую очередь, про людей и процесс, про культуру, а не про технологию. Вы можете нарисовать десятки дашбордов и сотни алертов, но какой в них толк, если их никто не увидит вовремя и они не помогут вам быстро докопаться до сути проблемы.

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


И вырожение для grafana alerts:
gitlab_project_access_token_expires_in_seconds > 0 and gitlab_project_access_token_expires_in_seconds < 14 * 24 * 3600


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

#monitoring