Администрирование

Новые тарифы Kubernetes

Апгрейднули тарифы и добавили пояснение к каждому. Давайте знакомиться:

• 👉Тариф Dev. Подходит для тестирования функционала нашего Managed Kubernetes — 200 ₽/мес

Пример использования: небольшие пет-проекты

• 👉Тариф Base. Для кластеров со средней нагрузкой, где отказоустойчивость не критична — 2000 ₽/мес

Пример использования: корпоративные веб-сервисы или ML inference-сервисы

• 👉Тариф Custom. Для гибкой настройки — от 2520 ₽/мес

Пример использования: highload-платформы и BigData/ML пайплайны

Пара слов о тарифе Custom. В нем можно выбрать количество ядер, объем оперативы и диска, а также установку с одной мастер-нодой или с тремя для настройки отказоустойчивости.

Найти свой идеальный тариф →

Говорят, в Selectel появились GPU за рубль.

Проверить

SpaceWeb подключил Kubernetes к партнерской программе

Добавили Kubernetes к партнерской программе SpaceWeb для веб-мастеров. Теперь участникам будет начисляться 20% вознаграждения за каждого привлеченного пользователя, подключившего облачную услугу.

Сегодня партнерская программа SpaceWeb предлагает партнерам до 48% вознаграждения от стоимости хостинга за каждого вовлеченного клиента. Сейчас же программа расширена и для облачных услуг: Kubernetes, DBaaS, облачные бэкапы и балансировщик. 

Всем участникам «партнерки» доступен моментальный вывод средств и заключение партнерства без бумажных носителей, а партнерский статус может получить любой желающий. Напомним, что партнерская программа SpaceWeb существует уже более 10 лет. Запартнериться можно здесь.

Уязвимость в протоколе REALITY XTLS/Xray-core: быстрый фикс уязвимости Aparecium

На прошлой неделе была обнаружена уязвимость в известном ПО для создания прокси соединений XTLS/Xray-core, а именно в протоколе REALITY, позволяющая выявлять работу этого протокола.

Для тех, кто не в курсе: REALITY — это уникальный протокол прокси, который позволяет маскировать прокси-трафик под легитимное посещение реальных сайтов (например, google.com или любого другого), при этом не требуя покупки домена и настройки TLS-сертификата на своем сервере.

Обнаружение уязвимости

В начале июня 2025 года исследователь под ником ban6cat6 опубликовал утилиту под названием Aparecium. Ее цель — находить серверы, использующие протоколы вроде REALITY.

В чем была суть уязвимости?
Утилита обнаружила, что серверы на базе OpenSSL после завершения основного TLS-рукопожатия (handshake) обычно отправляют клиенту один или два служебных сообщения NewSessionTicket. Это стандартное поведение, позволяющее возобновлять сессии. Протокол REALITY в своей реализации это поведение не имитировал.

Это тонкое различие позволяло Aparecium с высокой точностью отличать настоящий веб-сервер от сервера с REALITY, просто проанализировав последовательность TLS-сообщений.

Быстрый фикс

Информация об уязвимости была опубликована в виде issue #4778 в репозитории Xray-core. Разработчики, в частности RPRX, отреагировали практически молниеносно.

Вместо того чтобы добавить отправку фейковых NewSessionTicket, они пошли по более правильному пути. Уже через несколько дней в версии Xray-core v25.6.8 появилось «предварительное» решение:

Теперь при первом запуске сервер REALITY, используя отпечаток клиента Chrome, сам подключается к целевому сайту (dest), «подсматривает», какие именно post-handshake сообщения и какой длины тот отправляет, кэширует эту информацию и в дальнейшем идеально имитирует именно это поведение.

На это «зондирование» уходит около 30 секунд при первом старте сервера, но оно по большей части решает основную проблему. Вместе с этим был исправлен и неприятный баг с производительностью из-за неработающего аппаратного ускорения AES-NI.

Глубокий анализ

Казалось бы, проблема решена, однако разработчики начали копать глубже, и вот что выяснилось:

1. Загадка «лишнего пакета» от bilibili.com
   Один из разработчиков заметил, что при подключении к некоторым сайтам (например, bilibili.com) с отпечатком Chrome, сервер возвращает не только NewSessionTicket, но и еще один небольшой пакет. После анализа выяснилось, что это не TLS-сообщение, а кадр настроек HTTP/2 (settings frame). Это значит, что для идеальной маскировки нужно имитировать не только TLS-уровень, но и поведение прикладного протокола (HTTP/2), который был согласован в ходе рукопожатия.

2. Проблема разных отпечатков (fingerprints)
   Выяснилось, что один и тот же сайт может по-разному отвечать на ClientHello от разных клиентов. Например, на запрос с отпечатком Chrome он может отправить два NewSessionTicket и settings фрейм, а на запрос от Go-клиента — только один NewSessionTicket. Похоже, что статического зондирования недостаточно.

3. Идея «живого обучения»
   В ходе мозгового штурма родилась идея для долгосрочного решения, которое было оформлено в issue #4788. Суть в том, чтобы сервер REALITY, получив ClientHello от нового клиента, не просто использовал стандартный отпечаток для зондирования, а копировал отпечаток реального клиента и именно с ним обращался к целевому сайту. Это позволит динамически адаптироваться под любого клиента и достичь практически идеальной мимикрии.

Разработчики рекомендуют всем обновить сервера и клиенты, использующие Xray-core, до версии 25.6.8.

Вышла нейросеть для расшифровки скриншотов — Snippai. Работает Gemini или GPT-4. Умеет перегонять формулы со скринов в LaTeX-формат, решать задачи и примеры, генерировать код по скринам или тексту, преобразовывать таблицы в Markdown, извлекать, переводить и пояснять текст. Доступна на macOS, Windows и Linux.

Как уведомить Роскомнадзор об обработке персональных данных?

На Хабр вышла наша статья, прочтение которой поможет корректно подать уведомление в Роскомнадзор о намерении обрабатывать персональные данные. Особенно она будет полезна для ИТ-компаний и стартапов.

Из статьи вы узнаете:

• кто и в какие сроки должен подать уведомление

• как правильно заполнить уведомление

• как подготовиться к подаче уведомления и что нужно не забыть сделать после отправки

Выбрать облачный сервис с помощью ИИ не отходя от кассы

Когда заходите на наш сайт, можете увидеть симпатичный розовый шарик, который предлагает помочь в создании готовой инфры.

Через него можно ввести запрос и получить от нейронки варианты сборки, которые мы можем предложить для бизнеса и личного пользования (кстати, такая фича есть только у нашего облака 😏).

Пример: Подобрать отказоустойчивую облачную инфраструктуру для SaaS-платформы с 50 000 активных пользователей в сутки.

ИИ-помощник сразу даст варианты сборки и ее конечную стоимость. Нужен кастом? Тогда можете написать сюда.

Лайфхак: Советуем проверить актуальные решения, даже если вы уже юзаете наши сервисы в облаке — вдруг появилось что-то покруче?

Окей, подберите мне топовую сборку →

MongoDB + WARP + Xray = 💥 BSONError

У меня MongoDB начала выдавать ошибки:

BSONError: Invalid UTF-8 string in BSON document  

BSONError: bad embedded document length in bson

Документы в базе нормальные. Ошибки появлялись только при включённом Xray с WARP (через встроенный WireGuard). Когда VPN отключён — всё читается корректно.

Поначалу думал, что что-то с кодировкой или драйвером, но оказалось, что проблема в том, что Mongo работала через Cloudflare WARP.

Когда запросов было мало — срабатывало нормально.

Когда запускался алгоритм и начинались частые обращения к базе — Mongo валился с ошибками BSON.

Причина — искажение бинарного трафика при передаче через WARP.

Mongo использует бинарный протокол BSON, и даже один сбитый байт ломает парсинг.

Пофиксил так:

добавил в routing.rules Xray правило, чтобы трафик к Mongo шёл мимо WARP:

{

  "type": "field",

  "ip": ["<IP MongoDB>"],

  "outboundTag": "direct"

}

ping: permission denied (are you root?)

Знакомы ли с этим сообщением об ошибке? И знаете ли, как ее исправить?

Этот запрет на отправку ICMP-пакетов внутри контейнера можно получить при выполнении, например, такой задачи.

Задача: Организовать k8s-кластеры в ручном режиме с помощью kubeadm и kubectl на базе cri-o (1.28+) и использовать Calico как CNI-плагин.

Кластер доступен для взаимодействия через kubectl, команда возвращает корректную информацию о кластере. Есть возможность сделать ping 8.8.8.8 с образом busybox.

Если вы опытный DevOps и знаете, как решается эта «детская проблема» при работе с оркестратором, регистрируйтесь на спринт-оффер для девопсов. Сможете буквально играючи получить новую работу за 3 дня.

Если вы только начали изучать Kubernetes, читайте статью с подробным разбором этой ошибки → 

Воскрешаем YouTube новым видео 🎥

Если кто-то не знал, у нас есть свой YouTube-канал (и он даже не пустой). Раньше там выходили подкасты «Релиз в пятницу» и «Быть». Потом мы сделали паузу и сосредоточились на продукте.

Теперь возвращаемся с новыми видео — про облака, айти-сферу и даже с юмористическим контЭнтом.

На канале вас уже ждут два свежих видео:

1️⃣ Про наш любимый Kubernetes. Наши партнеры показали, как собрать и задеплоить микросервисное приложение в Таймвеб Клауд.

2️⃣ Про стартапы. Продакт-менеджер Артем Гаврилов и лид разработки Михаил Шпаков рассказали о профите облачных решений для бизнеса.

👉 А еще постим на канал забавные шортсы (да, таким мы тоже балуемся).

Ютуб · Рутуб · ВК

В Облаке Рег.ру появились облегченные образы ispmanager

На облачной платформе Рег.ру оптимизируем и прокачиваем работу ispmanager. Свежий апдейт — добавили облегченные образы. Теперь можно заказать панель управления в базовой конфигурации сервера: 1 vCPU, 1 ГБ RAM и 10 ГБ диска. Обновление доступно на ОС: AlmaLinux, Debian и Ubuntu.

Образ ispmanager Mini идет с ограниченным набором ПО и подойдет для быстрого решения несложных задач.

Напомним, что можно заказать сервер с уже установленным ispmanager, оплата происходит по часам, а не месяцам. Лицензия панели управления также оплачивается на почасовой основе.

Как обнаружить anycast-адреса сервисов при помощи неравенства треугольника

Технически, по одному и тому же IP-адресу может отвечать всякий интернет-узел, который находится на (двунаправленном) техническом пути следования пакетов. Чтобы такое работало без запинки для многих IP-источников - требуется согласовать пути следования пакетов на уровне IP-сети, то есть, средствами BGP. Штатный способ использования этой особенности называется Anycast. Настроить и поддерживать сложно, но, при грамотном подходе, метод отлично работает и достаточно широко используется в глобальной Сети. При Anycast один и тот же IP-адрес, наблюдаемый из разных точек Интернета, адресует разные физические узлы. Эти физические узлы могут быть географически распределены - ближе к пользователям. Обычно, так и делается, потому что это одно из основных практических преимуществ Anycast, но далеко не единственное преимущество - anycast-адреса могут быть разведены средствами BGP и коммутации сетевых сегментов из соображений устойчивости к DDoS-атакам, распределения прочей нагрузки, повышения надёжности и т.д. Примеры: 1.1.1.1, 8.8.8.8, многие корневые DNS-серверы.

Как подручными средствами проверить, что какой-то интернет-сервис стоит за anycast-адресами? Для этого нужно использовать неравенство треугольника. Тестируемый узел должен отвечать в рамках того или иного протокола, который позволяет измерить сетевое время доставки пакетов.

Методика. Пусть мы обнаружили IP-адрес сервиса (обычно, из DNS) и хотим его проверить. Пусть узел под этим адресом отвечает по ICMP - ping. Возьмём два опорных узла-источника, расположенных в совсем разных местах Интернета: например, узел в Амстердаме (обозначим его А) и узел во Владивостоке (соответственно - В). Тестируемый узел назовём Т. Принцип: если среднее время доставки ping между А, В (А <--> В) существенно превышает сумму ping для А --> Т и В --> Т, то сервис, работающий на узле T, скорее всего, использует Anycast. Поэтому измеряем время силами ping. Это и есть нарушение неравенства треугольника: если сумма расстояний (в смысле ICMP) от каждой из точек тестирования к тестируемому узлу меньше, чем расстояние между этими точками, то тестируемый узел - это, скорее всего, как минимум два узла, использующих один и тот же IP-адрес, то есть, это anycast-адрес.

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

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

Шаг 1. Составьте карту сервисов и зависимостей

• Что включить: микросервисы, БД, очереди (Kafka, RabbitMQ), сторонние API (платежки, SMS).

• Зачем: чтобы понять, как падение одного компонента влияет на систему.

«Падение Redis "уронит" кэширование и увеличит нагрузку на БД».

Шаг 2. Разделите симптомы проблем: срочные vs важные

Срочные (реагировать немедленно!)

• БД: connections > 90%, replica lag > 10 сек.

• Платежный шлюз: 5xx errors > 1% за 5 мин, latency p99 > 3 сек.

• Kubernetes: pod restarts > 5/час, node CPU > 95%.

Инструменты: Grafana OnCall, PagerDuty.

Важные (требуют анализа)

• Рост ошибок 4xx > 5% за сутки.

• Увеличение времени ответа API на > 20% за неделю.

• Падение успешных сессий (Google Analytics).

Решение: алерты в Slack/Email.

Шаг 3. Автоматизируйте рутину

Сбор логов: стек EFK (Elastic + Fluentd + Kibana).

Kubernetes:

• Liveness-пробы → авто-перезапуск пода при сбое.

• Readiness-пробы → остановка трафика на проблемный под.

Redis: настройка политик очистки кэша.

Совет для ленивых:

«Используйте Coroot — он автоматически строит карту зависимостей и предлагает алерты»

Шаг 4. Тестируйте устойчивость

Chaos Engineering раз в месяц:

• Отключайте случайные ноды в кластере.

• Эмулируйте нагрузку в 10 раз выше обычной (Locust).

«Мониторинг должен не только сообщать о проблемах, но и подсказывать, что делать».

Подключайтесь к вебинару про производительность 1С 🔍

Ровно через час, в 12:00 мск, встретимся, чтобы обсудить тест Гилева и другие методики тестирования 1С. Ответим на главные вопросы:

✔️ как выбрать подходящий метод,

✔️ как настроить тестовое окружение,

✔️ как проанализировать результаты и провести оптимизацию на основе полученных данных.

Вебинар будет полезен администраторам 1С и системным администраторам, руководителям IT-отделов, разработчикам, а также специалистам по производительности. 

Подключайтесь к трансляции:
➡️ в VK
➡️ на YouTube

Как развернуть в облаке ERP и маркетплейс для 5000 строительных компаний

Рабочие задачи бывают разные: настроить CI/CD, провести рефакторинг кода или развернуть маркетплейс для 1,5 млн товаров на отказоустойчивой инфраструктуре — как раз последним кейсом стал совместный проект команд Облака Рег.ру и IT-разработчика Stworka. 

С компанией Stworka мы сотрудничаем уже 6 лет — и сегодня продолжаем строить проект вместе. На старте нам нужно было помочь запустить ERP-систему и сократить time-to-market для запуска платформы. Облачная инфраструктура включает в себя распределенные облачные серверы, dev- и stage-контуры, виртуальные машины для мониторинга и управления разработкой. Для хранения и обработки больших объемов информации обеспечили проект отказоустойчивой базой данных. 

Что внутри системы: NVMe-диски и контейнерная архитектура с Docker. Отдельные виртуальные машины развернули для инстанта GitLab и Grafana. Сбор метрик клиент настроил через Prometheus.

Что реализовано на платформе: 

• стабильность системы — в 90% случаев время отклика бэкенда ниже 300 мс;

• прайсы и 1,5 млн товаров обрабатываются каждый день за несколько часов;

• отказоустойчивость за счет внедрения автоматического резервного копирования нод.

Больше о кейсе — рассказали на сайте.

Обновления в Terraform 🆕

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

Рассказываем, где и какие фичи теперь доступны:

1. Kubernetes. Добавили поддержку конфигуратора воркер-нод, тейнтов и лейблов для групп нод, установку аддонов и редактирование манифестов. А также теперь можно передавать идентификатор VPC-сети при создании кластера и фильтровать пресеты по локациям.

2. S3. Добавили поддержку конфигуратора для стандартного и холодного хранилища.

3. Балансировщики. Добавили поддержку плавающих IP-адресов и новые параметры для гибкой настройки: maxconn, connect_timeout, client_timeout, server_timeout, httprequest_timeout.

4. И, конечно, не обошлось без багфиксов и улучшений. Оставим для вас списком:

• Теперь можно менять логин в twc_database_user

• Поправили создание сервисов с токеном доп пользователя

• Добавили обработку ошибок при устаревших типах баз данных

• Исправили проблемы с кластерами PostgreSQL и Redis

• is_autoscaling в Kubernetes больше не обязателен

• В документации по базам данных добавили пример привязки к приватной сети

Уже бегу тестить обновы →

Расскажите, какие материалы вам интересны? Запускаем опрос и дарим призы за участие

Привет, Хабр! Мы хотим создавать в наших блогах — на Хабре и в Академии Selectel — контент, который действительно вам интересен. Будь то обзоры железа, инструкции или подборки полезных команд. Но для этого нам важен ваш фидбэк. Пройдите короткий опрос — расскажите, что вы читаете, что вам интересно и чего не хватает.

Это займет около пяти минут.

А среди участников, которые корректно и развернуто заполнят анкету, мы разыграем призы:

• 10 сертификатов на 1500 ₽ на маркетплейсе,

• 10 легендарных плюшевых Тирексов.

Пройти опрос ➡️

Дайджест Облака Рег.ру за май

Для многих май оказался расслабленно-праздничным месяцем, но не для команды Облака Рег.ру! Мы выпустили стопку свежих фич и новинок, которыми спешим поделиться. 

• Подключили услугу бэкапирования 

Сделали большой шаг навстречу полноценного Backup as a Service — добавили возможность резервного копирования и управления копиями для облачных серверов. Теперь создавать бэкапы можно вручную или по расписанию, а также настраивать политику хранение резервных копий, восстанавливать удаленные серверы или откатывать состояние до нужной версии. Обеспечивает организацию бэкапов в Облаке Рег.ру инструмент restic, а храним копии в выделенном объектном хранилище S3. Подробнее об этапе разработки рассказывали в статье. 

• Прокачали DBaaS

Продолжаем улучшать наш сервис DBaaS. В мае — увеличили лимит на создание пользователей для СУБД PostgreSQL и MySQL до 95.

• Добавили управление ключами доступа S3

Теперь пользователям облака доступны новые действия: создание, генерация, удаление. Установить политики можно самостоятельно через S3 API. Мы подготовили подробную инструкцию, как это делать. А пока — продолжаем активно работать над функционалом управления.

• ispmanager доступен на новой ОС

Повысили стабильность панели управления облачными серверами и хостингом. Теперь ispmanager доступен на Ubuntu 24.04 LTS — свежей версии с поддержкой до 2034 года. 

• Обновили версии образов Astra Linux

Обновили две версии операционной системы и Astra Linux SE «Орел» и Astra Linux SE «Воронеж». «Орел» подойдет для базового уровня защиты информации, а «Воронеж» — для усиленного контроля. 

Таким для нашей облачной команды Рег.ру был май, а теперь — вперед к летним релизам! 

Как защитить данные без полных бэкапов: разбираем косвенную адресацию в СХД

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

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

Со временем в родительском томе заполняются новые блоки данных. Некоторые данные у родительского тома и снапшота начинают различаться, но данные, на которые уже ссылается снапшот, не перезаписываются и не освобождаются. Оригинальный физический блок данных считается занятым до тех пор, пока снапшот, который на него ссылается, не будет удален. После удаления снапшота блоки данных, которые он не разделял с другими ресурсами, освобождаются и могут быть использованы для последующих операций записи. Такой вариант реализации снапшотов называют Redirect-On-Write (RoW).

В своей статье Алексей Шушарин, главный эксперт по разработке ПО в департаменте СХД YADRO, подробно рассказал о снапшотах, клонах и всех процессах, связанных с косвенной адресацией. А также о том, как грамотно вписать эту функциональность в стек хранилища.