Дока и у нас появляется в начале проекта, но на этом этапе ее пишут аналитики, архитекторы и разработчики. Уже потом появляются техписы и документируют всё в подробностях: со схемами, сценариями — и как раз ссылками на Swagger. Так коллеги смогут обратиться к этому документу, когда запланируют изменения в каких-то процессах. Можно было бы в самом начале прописать контракт и архитектуру, чтобы это стало актуальной документацией, но это все-таки не наш вариант — нам нужно расширять и структурировать проектную доку так, чтобы потом было легче понять бизнес-процесс и быстрее в нём сориентироваться, чтобы внести изменения.
Понятно, что у нас есть не только Swagger — документация логики взаимодействия сервисов между собой есть в виде текста, пользовательских сценариев, UML-диаграмм, на которых как раз обозначены методы. В некоторых случаях мы помечаем, что в конкретных ситуациях передается и что возвращается. Такая документация и Swagger дополняют друг друга.
Спасибо за совет! Мы подходили к процессу как к эксперименту — и в статье описывали его так же. Понимаем, что он требует доработки, раз решили придерживаться этого направления. Возможно, придем к чему-то похожему.
Привет, спасибо за комментарий! В нашем случае проблема была в том, что у разработчиков не хватало времени на доскональное описания параметров, методов, ошибок в Swagger. Статья больше про то, как мы совместными усилиями решали эту проблему.
Здравствуйте! Да, вы верно подметили, что в статье много упрощенных примеров. Сделано это намеренно, а одна из основных целей выбора такого стиля — слегка "подтолкнуть" к использованию 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, когда попробуете.
Привет, спасибо за советы! Это мы изучим.
Привет, спасибо)
Дока и у нас появляется в начале проекта, но на этом этапе ее пишут аналитики, архитекторы и разработчики. Уже потом появляются техписы и документируют всё в подробностях: со схемами, сценариями — и как раз ссылками на Swagger. Так коллеги смогут обратиться к этому документу, когда запланируют изменения в каких-то процессах. Можно было бы в самом начале прописать контракт и архитектуру, чтобы это стало актуальной документацией, но это все-таки не наш вариант — нам нужно расширять и структурировать проектную доку так, чтобы потом было легче понять бизнес-процесс и быстрее в нём сориентироваться, чтобы внести изменения.
Понятно, что у нас есть не только Swagger — документация логики взаимодействия сервисов между собой есть в виде текста, пользовательских сценариев, UML-диаграмм, на которых как раз обозначены методы. В некоторых случаях мы помечаем, что в конкретных ситуациях передается и что возвращается. Такая документация и Swagger дополняют друг друга.
Смотря какой и смотря зачем — финал всё равно всегда проверяют разработчики перед коммитом.
Спасибо за совет! Мы подходили к процессу как к эксперименту — и в статье описывали его так же. Понимаем, что он требует доработки, раз решили придерживаться этого направления. Возможно, придем к чему-то похожему.
Привет, спасибо за комментарий! В нашем случае проблема была в том, что у разработчиков не хватало времени на доскональное описания параметров, методов, ошибок в Swagger. Статья больше про то, как мы совместными усилиями решали эту проблему.
Привет! Добавили расшифровку в самое начало, но если вы ощущаете себя станцией технического обслуживания, мы принимаем ваш выбор.
В нашем случае акцент был сделан на простоте и готовности решения — 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, когда попробуете.