Между прошлым и будущим

В апрельском дайджесте мы приветствуем Yandex Database, смотрим на очередной buzzword — AIOps, узнаём о будущей версии Kubernetes и обновленном инструментарии Vault от Hashicorp. Бонусом обращаемся к опыту DevOps-инженеров Postmark, столкнувшихся с проблемой бутылочного горлышка в сетевой инфраструктуре.

Нужно больше Open source

В апреле 2022 года Yandex выложил в открытый доступ свою разработку — СУБД YDB. На Github появился репозиторий, где доступен сам исходный код, документация, SDK и всё остальное. 

Изначально YDB разрабатывалась под жёсткие требования Yandex для применения в ключевых сервисах, таких как Алиса, Такси, Метрика. Выдерживание высоких нагрузок и легкое масштабирование закладывались ещё на этапе проектирования.

Разработчики вдохновлялись концепцией, появившейся в 2010 году — NewSQL. Этот термин достаточно обширный и включает в себя лучшее из двух миров. Масштабируемость и отказоустойчивость NoSQL, но при этом с поддержкой ACID и наличием SQL-диалекта. Сейчас такие СУБД чаще всего называют Distributed SQL Databases.

YDB решает множество проблем из коробки. Ручное шардирование не требуется, БД самостоятельно масштабируется на чтение/запись при добавлении новых нод в кластер. Вместе с YDB разработчики создали множество дополнительных инструментов для обработки и хранения данных. Фактически это целая экосистема управления данными, вставшая в один ряд с MySQL, PostgreSQL и ClickHouse.

AIOps — взгляд в будущее

Во времена железных серверов все задачи по созданию, настройке и поддержанию ΙΤ-инфраструктуры ложились на системных администраторов. Виртуализация значительно изменила этот процесс, но всё же оставила существующий порядок. Контейнеризация рабочих нагрузок внесла серьезные коррективы и положила начало новому подходу к управлению. Акцент был сделан на объединении эксплуатации и разработки — DevOps. Спустя некоторое время была выделена отдельная категория специалистов DevSecOps. Здесь тема безопасности проходит сквозь весь жизненный цикл продукта.

Аналитики предсказывают очередную цифровую трансформацию, где задачи по управлению ΙΤ-инфраструктурой лягут на плечи нейронных сетей. Непрерывный анализ больших объемов данных позволит автоматизировать процессы принятия решений. Методология получила название ΑΙOps — Artificial Intelligence for IT Operations. Такие платформы разрабатывают многие крупные корпорации, такие как ΙΒΜ, HPE и SAP.

Движение в сторону AIOps обусловлено тем, что сложность современной гибридной или мультиоблачной ΙΤ-инфраструктуры постоянно растёт. Количество генерируемых данных увеличивается экспоненциально. Полноценный мониторинг с ручным или полуавтоматическим реагированием на события уже не представляется возможным. Здесь надо обращаться к возможностям машинного обучения, где нейросеть сама будет принимать решения по отдельным инцидентам. Бизнес будет ставить задачи, а DevOps декомпозировать их и описывать для AIOps. Само же конечное состояние будет достигаться и поддерживаться автоматически, включая реакцию на сбои. 

Что нас ждет в Kubernetes 1.24

До релиза новой версии Kubernetes остаётся всё меньше времени. Пора взглянуть, что апдейт несёт для пользователей и стоит ли обновляться. Наиболее тревожная часть — удаление dockershim. Этот компонент изначально был временным решением. Увы, нет ничего более постоянного, чем временное. И вот теперь пришла пора с ним попрощаться. В качестве замены предлагается использовать связку из containerd и CRI-O. Цель благая — повысить надежность и дать гарантии стабильной работы.

Ещё одной фичей обновления станет поддержка CSI volume health monitoring — мониторинга здоровья физических томов (PV — Physical Volume). Это предотвратит кучу неприятных ситуаций, связанных с недоступностью тома (например, по причине недоступности узла). Теперь же можно будет получать метрики VolumeStats и отслеживать их в используемой системе мониторинга.

Non-graceful node shutdown — также поможет сделать работу кластера Kubernetes стабильнее. Эта фича — рубильник помогающий бороться с подвисанием подов со статусом Terminating. Такое случается, если Node Shutdown Manager пытается выполнить запуск подов на выключенном узле. Теперь это не станет досадной проблемой и не вызовет проблем с томами, привязанных к зависшим подам.

Network Policy Status улучшит отладку сетевых проблем. Эта фича добавляет одноимённое поле. Так что теперь можно будет понимать, что политика сконфигурирована неверно, а не гадать на кофейной гуще. Узнать ещё больше о нововведениях версии 1.24 можно из этой статьи на Хабре.

Управляем секретами

Работа с Kubernetes каждый раз ставит неприятные вопросы безопасности. Где и главное как правильно хранить секреты? Инструмент Vault от HashiCorp был создан как раз для безопасного управления паролями, ключами API и иными данными, которые следует держать вдали от посторонних. В конце прошлого месяца вышел новый релиз 1.10.0, значительно расширяющий возможности.

В новой версии появилась многофакторная авторизация TOTP, Okta, Duo и PingIdentity. Агенты Vault научились отдавать телеметрию, которая может быть обработана связкой из Prometheus и Grafana. etcd v2 API более не поддерживается, так что для апдейта на новую версию etcd также потребуется обновить до v3.

Механизм OpenLDAP Vault теперь позволяет рулить секретами в IBM Db2, взяв на себя весь жизненный цикл учётных данных. Ещё Vault научился быть поставщиком OpenID Connect, что позволит использовать его возможности в своих приложениях. Разумеется, это не исчерпывающий список изменений. Полный Changelog доступен в репозитории проекта.

Занимаемся интерконнектом

Абстракции захватили мир. Чем сложнее становятся задачи, тем больше слоёв абстракции добавляется в инфраструктуру. Реальность же часто может «щёлкнуть по носу» и напомнить о необходимости понимания работы физической инфраструктуры. В частности о том, как функционирует сеть. Начинающие DevOps-инженеры, глубоко погружаясь в изучение виртуальных сущностей, напрочь упускают из вида ограничения физических ресурсов.

Ярким примером может быть инфраструктура, построенная на базе избыточной пропускной способности сети, но не учитывающая общую производительность файервола. Даже если интерконнект между коммутаторами 20 Гбит/с, а пропускная способность межсетевого экрана 9 Гбит/с — достичь показателя в 20 Гбит/с не выйдет. Обратный пример — когда пиковая нагрузка превышает пропускную способность канала связи.

Компания Postmark столкнулась с этой задачей и для решения они подробно проанализировали каждый фактор, влияющий на общую производительность своей платформы. Полученный опыт описали в своём блоге. Решение — детальный анализ логических маршрутов прохождения трафика и расчёт необходимой пропускной способности на их основе. Это помогло максимально утилизировать доступные ресурсы и сохранить высокую производительность.

Обучение

Конкурсы для разработчиков