Здравствуйте! Да, вы верно подметили, что в статье много упрощенных примеров. Сделано это намеренно, а одна из основных целей выбора такого стиля — слегка "подтолкнуть" к использованию k8s тех, кто могли бы его использовать, но пока не решаются🙂
Но в статье есть ряд мыслей и для опытных пользователей. Вот одна из них: k8s стал не просто стандартным инструментом для sysadmins/ops/devops/sre/platform/\…(aiops?), но и для разработки. Так, вчера любой разработчик умел поместить свой сервис в докер, а сегодня опытные разработчики с легкостью запустят свой сервис в k8s самостоятельно, поскольку умеют им пользоваться и знают принципы работы.
А это означает, что еще до написания кода все участники доставки ценности понимают, где сервис будет запущен, каким принципам должен соответствовать, каковы принципы межсервисного взаимодействия. Таким образом, общий контекст разработчиков/тестировщиков/админов — важная составляющая, которая существенно сокращает time-to-market.
Всё зависит от ваших целей. Если в них входит стабильная работа на годы вперёд — да, натягивать кубер будет одним из способов достичь такого результата.
Спасибо за вопрос! На самом деле, никто не спорит с тем, что хороших инструментов существует великое множество. У большинства профессионалов не возникнет проблем ни с Messos, ни с Nomad, ни с libvirt-lxc 🙂 Весь вопрос в том, кто принимает решение об использовании инструмента, и для каких целей мы подбираем этот инструмент 😉
Если один отдельно взятый человек (возьмём для примера автора этой статьи) захочет в личных целях развернуть 10 микросервисов, то наверняка выберет какой-то более экзотический инструмент, чем Kubernetes — как минимум, просто потому что это интересно.
Но если мы ставим целью минимизировать затраты на поддержку и поиск специалистов, выбор с большой вероятностью падёт именно на кубер. Просто потому это уже давно де-факто стандарт в индустрии.
Привет! Мы тестировали ovn-bgp-agent, но решили его не запускать по нескольким причинам.
1. Не удалось полноценно разделить сервисный и клиентский трафик.
2. Несовместимость текущей версии openstack и той версии, которую мы запустили.
3. Как следствие, отсутствие достаточного тестирования перед вводом в продакшн.
В сторону OVN Fabric Integration смотрели — перспективно, но выглядит пока сыро, код еще дописывается. Подход в обновлении площадок у нас довольно консервативен и не совпадает с возможностью запуститься на последней версии, которая на несколько релизов свежее текущей.
Тесты c ovn-bgp-agent по трафику не проводили. Проблемы с высоким irq тоже пока не ловили.
Ньюанс с sr-iov — это ограничение на количество сетевых интерфейсов, а значит, и на количество ВМ на гипер.
Возможно, имеет смысл использовать для aaS сервисов, a DPDK для gateway нод.
Привет! Мы сменили вектор на Openstack для нивелирования рисков использования зарубежного ПО, а также для возможности дальнейшей поставки в контур собственных сервисов, которые уже работают на этом стеке.
Но мы действительно опустили множество деталей, чтобы не превращать статью в перечисление нормативных требований. Если подробности интересны, мы постараемся раскрыть их в дальнейшем.
Спасибо за вопрос! Это наш пятый кластер, и у нас уже есть команда опытных специалистов по openstack, его компонентам и интеграциям. Если говорить о размерах, то только один из наших кластеров — это примерно 25K vCPU и около 10K VM.
Здравствуйте! Всё так и есть, как вы говорите — если нарисовать «развесистую схему», то никто ничего не поймет и смысла в ней не будет. В статье мы как раз попытались рассказать, как этого избежать. В конце концов, UML — это только средство общения: кому-то он подходит, а кому-то нет. Например, стартапу, в котором всего три разработчика (и они же его основатели), то любое документирование будет казаться пустой тратой времени, потому что основатели и так свою систему знают до последней запятой. Другое дело, если перед нами большая корпорация, где есть несколько команд и люди периодически меняются. Тогда и нужен тот самый общий язык, чтобы у новичка хотя бы была возможность куда-то подсмотреть и понять, что сделали до него. Рунити — не гигантская корпорация, но нам UML как раз в похожих случаях помогает.
Как написали выше, у 19 версии в первую очередь лучше стабильность и производительность OSD. Основная цель нашего апдейта сейчас — изменения/фиксы в RGW и OSD. Фичи — это попозже.
Если не секрет, что за диски вы используете?
У нас Intel/Solidigm TLC
Какие формулы берете за основу?
Формула для SLA стандартная: (Общее время − Время простоя) / Общее время × 100%. Для SLA 99.95% допустимый простой в месяц — около 21 минуты. Цифры берем исходя из скорости аварийного поднятия инфраструктуры при тестировании и не берем в расчет выход компонентов (деградированное состояние кластера). У нас есть отдельное соглашение об SLA, если интересно: https://img.reg.ru/faq/SLA_18032025.pdf
Здравствуйте! Спасибо за поздравления! По поводу вопросов:
В версии 19.2.2 есть ряд полезных фичей в части S3, и одновременно с этим лучше производительность OSD. Когда-нибудь, возможно, сделаем материал про то, как мы бенчмаркаем кластеры.
Мигрировали по-разному :) Например, переносом пула между device class'ами, без смены EC-профиля, или через cache tiering — иначе нельзя перенести данные в пулы с разным EC-профилем.
Разделяем вланами, не боимся — LACP все стерпит, .1p всех сравняет.
Это зависит от (размера) кластера, количества фейлюр доменов. Обычно мы выставляем m=2 для обеспечения возможности потери двух доменов отказа + оставляем всегда запас по оборудованию, как минимум в один домен отказа, чтобы при утрате домена отказа было куда мигрировать данные. В итоге для нас типичные конфигурации это X+2, где X может быть 6, 8, 10, 12 и так далее.
Самый главный фактор — в мире существует крайне ограниченное количество производителей, которые делают SATA SSD грейда дата-центров объемом более 8 TБ и никто из них не представлен на российском рынке. Ну а менее 8 TБ уменьшают плотность, не давая по сути никаких плюсов при больших объемах (но если объем кластера небольшой, а нагрузка большая — это может, конечно же, иметь смысл).
SLA считаем на основе опыта эксплуатации всех облачных продуктов. Достигается за счет сочетания отказоустойчивой архитектуры, мониторинга, резервирования и быстрого реагирования, а расчет проводится на основе точного учета времени доступности сервиса.
Мы сравнивали с классическими подходами, используемыми в связке с OpenStack — ML2/OVS и Linux bridges. Dragonflow, OpenDaylight не рассматривали, поскольку либо неактуально, либо требуется несопоставимо больше усилий по интеграции и сопровождению. OVN оказался для нас наиболее рациональным и практичным выбором.
Будет интересно узнать про ваш опыт с OVN, когда попробуете.
Мы выбрали OVN, потому что он проще в использовании, надёжнее и лучше интегрирован в OpenStack. Это нативное решение от разработчиков Open vSwitch (OVS), что обеспечивает тесную интеграцию и предсказуемую работу с виртуальной сетевой инфраструктурой. У OVN есть довольно живое российское коммьюнити, что упрощает поиск решений и обмен опытом.
OpenSDN рассматривался как потенциальный вариант, но до этапа тестирования не дошёл. Мы пришли к выводу, что он избыточен и слишком сложен для наших задач. Особенно стоит отметить высокий порог вхождения, что делает его менее подходящим для небольших команд с ограниченными ресурсами.
Инструменты автоматизации и воспроизводимости мы, конечно, используем. Существует отдельная статья, где мы про это уже рассказывали (про rook там тоже есть). Но сейчас мы несколько о другом.
Привет! Согласны, что накрутки опыта — токсичная практика, которая не приведёт ни отрасль, ни рынок труда ни к чему хорошему. К сожалению, полностью искоренить это явление невозможно, но считаем, что ситуацию можно улучшить, если каждый (имеем в виду: как соискатель, так и компании) начнёт с себя.
Вот что делаем мы: не пользуемся автоматическими фильтрами, а читаем резюме кандидата и опираемся на его опыт и навык владения технологиями на всех этапах собеседования. Как правило, в наших вакансиях вакансиях указывается грейд, который выражается в годах работы и четко прописанных технологиях, необходимых под проект/вакансию. Ещё мы ценим откровенность и не видим ничего страшного, если кандидат покажет свои слабые места — тогда диалог будет строиться более прозрачно. И, если у команды действительно есть возможность на данном этапе пожертвовать неким опытом, которого у соискателя пока нет — они смогут поделиться им уже после выхода кандидата на вакансию. А вот обман со стороны кандидата, который (если имел место) с высочайшей вероятностью вскрывается на поздних этапах собеседования — однозначно красный флаг.
Понимаем ваши вопросы :) Со своей стороны хотели скорее поделиться, что в принципе есть такое исследование: нам тут показались интересными именно подход и ориентация на ширину возможностей. Видимо, теперь будем всем Хабром писать вопросы в Южную Корею!
В нашем случае акцент был сделан на простоте и готовности решения — Ollama уже использовалась в другом нашем недавнем продукте с ИИ-ассистентом.
Здравствуйте! Да, вы верно подметили, что в статье много упрощенных примеров. Сделано это намеренно, а одна из основных целей выбора такого стиля — слегка "подтолкнуть" к использованию k8s тех, кто могли бы его использовать, но пока не решаются🙂
Но в статье есть ряд мыслей и для опытных пользователей. Вот одна из них: k8s стал не просто стандартным инструментом для sysadmins/ops/devops/sre/platform/\…(aiops?), но и для разработки. Так, вчера любой разработчик умел поместить свой сервис в докер, а сегодня опытные разработчики с легкостью запустят свой сервис в k8s самостоятельно, поскольку умеют им пользоваться и знают принципы работы.
А это означает, что еще до написания кода все участники доставки ценности понимают, где сервис будет запущен, каким принципам должен соответствовать, каковы принципы межсервисного взаимодействия. Таким образом, общий контекст разработчиков/тестировщиков/админов — важная составляющая, которая существенно сокращает time-to-market.
Можно ли ответить популярной гифкой?
Например, для того, чтобы собрать инфраструктуру из 10 инстансов.
Всё зависит от ваших целей. Если в них входит стабильная работа на годы вперёд — да, натягивать кубер будет одним из способов достичь такого результата.
Спасибо за вопрос! На самом деле, никто не спорит с тем, что хороших инструментов существует великое множество. У большинства профессионалов не возникнет проблем ни с Messos, ни с Nomad, ни с libvirt-lxc 🙂 Весь вопрос в том, кто принимает решение об использовании инструмента, и для каких целей мы подбираем этот инструмент 😉
Если один отдельно взятый человек (возьмём для примера автора этой статьи) захочет в личных целях развернуть 10 микросервисов, то наверняка выберет какой-то более экзотический инструмент, чем Kubernetes — как минимум, просто потому что это интересно.
Но если мы ставим целью минимизировать затраты на поддержку и поиск специалистов, выбор с большой вероятностью падёт именно на кубер. Просто потому это уже давно де-факто стандарт в индустрии.
Привет! Мы тестировали ovn-bgp-agent, но решили его не запускать по нескольким причинам.
1. Не удалось полноценно разделить сервисный и клиентский трафик.
2. Несовместимость текущей версии openstack и той версии, которую мы запустили.
3. Как следствие, отсутствие достаточного тестирования перед вводом в продакшн.
В сторону OVN Fabric Integration смотрели — перспективно, но выглядит пока сыро, код еще дописывается. Подход в обновлении площадок у нас довольно консервативен и не совпадает с возможностью запуститься на последней версии, которая на несколько релизов свежее текущей.
Тесты c ovn-bgp-agent по трафику не проводили. Проблемы с высоким irq тоже пока не ловили.
Ньюанс с sr-iov — это ограничение на количество сетевых интерфейсов, а значит, и на количество ВМ на гипер.
Возможно, имеет смысл использовать для aaS сервисов, a DPDK для gateway нод.
Здравствуйте! Если не секрет, почему у вас сложилось такое впечатление?
Привет! Мы сменили вектор на Openstack для нивелирования рисков использования зарубежного ПО, а также для возможности дальнейшей поставки в контур собственных сервисов, которые уже работают на этом стеке.
Но мы действительно опустили множество деталей, чтобы не превращать статью в перечисление нормативных требований. Если подробности интересны, мы постараемся раскрыть их в дальнейшем.
Спасибо за вопрос! Это наш пятый кластер, и у нас уже есть команда опытных специалистов по openstack, его компонентам и интеграциям. Если говорить о размерах, то только один из наших кластеров — это примерно 25K vCPU и около 10K VM.
Здравствуйте! Всё так и есть, как вы говорите — если нарисовать «развесистую схему», то никто ничего не поймет и смысла в ней не будет. В статье мы как раз попытались рассказать, как этого избежать. В конце концов, UML — это только средство общения: кому-то он подходит, а кому-то нет. Например, стартапу, в котором всего три разработчика (и они же его основатели), то любое документирование будет казаться пустой тратой времени, потому что основатели и так свою систему знают до последней запятой. Другое дело, если перед нами большая корпорация, где есть несколько команд и люди периодически меняются. Тогда и нужен тот самый общий язык, чтобы у новичка хотя бы была возможность куда-то подсмотреть и понять, что сделали до него. Рунити — не гигантская корпорация, но нам UML как раз в похожих случаях помогает.
Как написали выше, у 19 версии в первую очередь лучше стабильность и производительность OSD. Основная цель нашего апдейта сейчас — изменения/фиксы в RGW и OSD. Фичи — это попозже.
У нас Intel/Solidigm TLC
Формула для SLA стандартная: (Общее время − Время простоя) / Общее время × 100%. Для SLA 99.95% допустимый простой в месяц — около 21 минуты. Цифры берем исходя из скорости аварийного поднятия инфраструктуры при тестировании и не берем в расчет выход компонентов (деградированное состояние кластера). У нас есть отдельное соглашение об SLA, если интересно: https://img.reg.ru/faq/SLA_18032025.pdf
Здравствуйте! Спасибо за поздравления! По поводу вопросов:
В версии 19.2.2 есть ряд полезных фичей в части S3, и одновременно с этим лучше производительность OSD. Когда-нибудь, возможно, сделаем материал про то, как мы бенчмаркаем кластеры.
Мигрировали по-разному :) Например, переносом пула между device class'ами, без смены EC-профиля, или через cache tiering — иначе нельзя перенести данные в пулы с разным EC-профилем.
Разделяем вланами, не боимся — LACP все стерпит, .1p всех сравняет.
Это зависит от (размера) кластера, количества фейлюр доменов. Обычно мы выставляем m=2 для обеспечения возможности потери двух доменов отказа + оставляем всегда запас по оборудованию, как минимум в один домен отказа, чтобы при утрате домена отказа было куда мигрировать данные. В итоге для нас типичные конфигурации это X+2, где X может быть 6, 8, 10, 12 и так далее.
Самый главный фактор — в мире существует крайне ограниченное количество производителей, которые делают SATA SSD грейда дата-центров объемом более 8 TБ и никто из них не представлен на российском рынке. Ну а менее 8 TБ уменьшают плотность, не давая по сути никаких плюсов при больших объемах (но если объем кластера небольшой, а нагрузка большая — это может, конечно же, иметь смысл).
SLA считаем на основе опыта эксплуатации всех облачных продуктов. Достигается за счет сочетания отказоустойчивой архитектуры, мониторинга, резервирования и быстрого реагирования, а расчет проводится на основе точного учета времени доступности сервиса.
Мы сравнивали с классическими подходами, используемыми в связке с OpenStack — ML2/OVS и Linux bridges.
Dragonflow, OpenDaylight не рассматривали, поскольку либо неактуально, либо требуется несопоставимо больше усилий по интеграции и сопровождению.
OVN оказался для нас наиболее рациональным и практичным выбором.
Будет интересно узнать про ваш опыт с OVN, когда попробуете.
Мы выбрали OVN, потому что он проще в использовании, надёжнее и лучше интегрирован в OpenStack. Это нативное решение от разработчиков Open vSwitch (OVS), что обеспечивает тесную интеграцию и предсказуемую работу с виртуальной сетевой инфраструктурой.
У OVN есть довольно живое российское коммьюнити, что упрощает поиск решений и обмен опытом.
OpenSDN рассматривался как потенциальный вариант, но до этапа тестирования не дошёл. Мы пришли к выводу, что он избыточен и слишком сложен для наших задач. Особенно стоит отметить высокий порог вхождения, что делает его менее подходящим для небольших команд с ограниченными ресурсами.
Инструменты автоматизации и воспроизводимости мы, конечно, используем. Существует отдельная статья, где мы про это уже рассказывали (про rook там тоже есть). Но сейчас мы несколько о другом.
Nextcloud поддерживает внешние хранилища. Например, в этой инструкции мы рассказали как подключить S3: https://help.reg.ru/support/servery-vps/obyektnoye-khranilishche-s3/podklyuchenie-hranilisha-s3-k-nextcloud
Привет! Согласны, что накрутки опыта — токсичная практика, которая не приведёт ни отрасль, ни рынок труда ни к чему хорошему. К сожалению, полностью искоренить это явление невозможно, но считаем, что ситуацию можно улучшить, если каждый (имеем в виду: как соискатель, так и компании) начнёт с себя.
Вот что делаем мы: не пользуемся автоматическими фильтрами, а читаем резюме кандидата и опираемся на его опыт и навык владения технологиями на всех этапах собеседования. Как правило, в наших вакансиях вакансиях указывается грейд, который выражается в годах работы и четко прописанных технологиях, необходимых под проект/вакансию. Ещё мы ценим откровенность и не видим ничего страшного, если кандидат покажет свои слабые места — тогда диалог будет строиться более прозрачно. И, если у команды действительно есть возможность на данном этапе пожертвовать неким опытом, которого у соискателя пока нет — они смогут поделиться им уже после выхода кандидата на вакансию. А вот обман со стороны кандидата, который (если имел место) с высочайшей вероятностью вскрывается на поздних этапах собеседования — однозначно красный флаг.
Спасибо за отзыв, постараемся учесть это пожелание!
Понимаем ваши вопросы :) Со своей стороны хотели скорее поделиться, что в принципе есть такое исследование: нам тут показались интересными именно подход и ориентация на ширину возможностей. Видимо, теперь будем всем Хабром писать вопросы в Южную Корею!