Время, чтобы оставить вещи в гардеробе, получить бейдж, выпить кофе и осмотреться

Приветственное слово и краткий рассказ о том, что будет в течение дня

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

Однако, несмотря на её универсальность, существуют специфические сценарии использования сети, которые не вписываются в стандартную схему, что закрывает существенному количеству приложений путь в Kubernetes. В докладе познакомим с подобными сценариями и предложим решения.

KubeVirt доказал, что Kubernetes позволяет оркестрировать виртуальные машины так же просто, как и контейнеры. Но что нужно сделать, чтобы ВМ под управлением привычного оркестратора была по-настоящему надёжной и лёгкой в управлении?

В докладе ответим на эти вопросы на основе опыта разработки Deckhouse Virtualization Platform. Вы узнаете, как виртуальная машина работает внутри пода и что нам понадобилось сделать для её стабильности. Вместе посмотрим, как обеспечить живую миграцию ВМ между гипервизорами, а дисков — между хранилищами.

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

Наличие дашбордов для всех компонентов — обязательное требование в продуктах Deckhouse. За 8 лет мы набили немало шишек в процессе разработки и оптимизации дашбордов. В итоге научились делать их одновременно информативными и удобными в использовании. В докладе я поделюсь опытом: как мы выбираем, что должно быть на дашборде, какие подходы используем при проектировании и как делаем графики понятными. В конце составим чек-лист, который поможет вам создавать красивые и, главное, полезные дашборды и эффективно доставлять их в кластеры.

Кажется, что для закрытых контуров по умолчанию нужна лицензия на Enterprise-редакцию платформы, выделенное железо в стойке и строгий air-gap. Но на практике proof of concept часто начинается с нескольких пользовательских машин, Open Source-продукта и очень ограниченного доступа в интернет.

Мы расскажем, как подняли Deckhouse Kubernetes Platform Community Edition на пользовательских ПК, пережили шатдауны и сюрпризы конфигурации, а потом аккуратно «перенесли» всё это в закрытый сегмент. На нашем примере вы узнаете, чем такой подход к прототипированию архитектуры полезен (и опасен) для реальных команд.

Работать с SDS в Kubernetes непросто — особенно если использовать изначально не предназначенные для облачных сред инструменты. В прошлом мы сознательно выбрали LINSTOR, понимая его архитектурные особенности: требование внешней базы данных, push-модель управления, зависимость от Java. В процессе эксплуатации ограничения и сложности подтвердились. Экспериментальный режим с etcd оставлял реплики в подвешенном состоянии, а баги при ресайзе томов, эвакуации узлов и обновлениях мешали работе, да и патчить Java-код Go-команде было попросту неэффективно.

С учётом полученного опыта мы написали кастомный control plane с нуля, и он стал ядром SDS в продуктах Deckhouse. В докладе покажем архитектурные решения, которые стали его основой: отсутствие внешних СУБД, надёжную pull-модель и полную интеграцию с Kubernetes. Вы узнаете, как они помогли избавиться от зависания ресурсов, остановок томов и ручных вмешательств и как мы планируем действовать дальше. Если вы строите или эксплуатируете SDS, наш опыт поможет разобраться, какие подходы действительно работают.

Когда компании переходят в K8s, они готовы инвестировать во многое, но никто по-настоящему не закладывает налог на безопасность — совокупность скрытых расходов, без которых защита контейнерной среды невозможна. На конкретных примерах из внедрения Runtime Radar покажу, что нужно учитывать: от потребления ресурсов до необходимой квалификации сотрудников.

Также разберём, что можно оптимизировать и автоматизировать, чтобы снизить «налог» и быть уверенными, что система безопасности работает, а не просто «горит зелёным».