Спасибо за статью, круто видеть, что появляется больше материала по теме ML-инфры
Хотел бы отметить, что динамическая нарезка профилей MIG реализуется DRA, а не только через HAMi (как минимум я интерпретировал слова статьи будто это именно их бенефит).
Говоря про Volcano тоже хотел бы прокомментировать, что HAMi и Volcano - два разных проекта, хотя у них и есть нативная интеграция. Мне вообще кажется, что если использовать NVIDIA DRA-driver для динамической и гибкой выдаче ресурсов и Volcano для сложной логики щедулинга подов (как уже сказано в другом комментарии для простой достаточно воспользоваться Kueue, чтобы избегать оврехеда), то HAMi не так уж востребован. Кажется, что он нужен только в тех кейсах, где DRA не возможен физически. Встречались ли какие-то кейсы, которые без HAMi не получалось решить? Было бы интересно о них узнать
Также было бы интересно увидеть статью по переходу с Device Plugin на DRA, тк этот процесс кажется не таким уже простым. Из-за того, что они будут конкурировать за управление GPU делать это видимо необходимо с поочерёдным дрейном ноды.
Спасибо за статью, было интересно узнать, как организован процесс обнаружения уязвимостей. Однако интересно заглянуть на следующий этап, который здесь меньше описан: есть ли у вас (или, может, планируется) какая-то автоматизация устранения уязвимостей? Например, использование renovate/dependabot в случае патча через обновление. Подобные инструменты как-то включены в этот процесс?
И не возникает ли у вас проблемы с долгим фиксом уязвимостей, при котором тестирование новой версии занимает столько времени, что в ней успевают найти следующую CVE?
Есть способ заставить тф игнорировать отдельные поля при tf plan, без указания target вручную? Есть большой риск что модуль просто пересоздаст виртуалку с нуля.
Для игнорирования полей можно использовать ignore_changes. Например, если нужно игнорировать изменение IP: lifecycle { ignore_changes = [ ipconfig0 ] }
Также можно использовать prevent_destroy, в блоке lifecycle, чтобы гарантировать, что ресурс не будет пересоздан.
Есть ли опыт миграции уже существующих виртуалок в тф, без риска пересоздания виртуалок модулем?
Лично я не пробовал это делать, однако в Terraform есть возможность использовать блок import и затем выполнить команду:
terraform plan -generate-config-out="generated_resources.tf"
Спасибо за дополнение! Согласен, что при выборе любого инструмента стоит изучить GitHub Issues.
В статье я делюсь именно своим практическим опытом: в моих кейсах провайдер отработал стабильно, хотя это и не отменяет наличия багов в других сценариях. На мой взгляд, даже с учетом нюансов, декларативный подход Terraform удобнее, чем прямая работа с API. Надеюсь, интерес к теме поможет провайдеру развиваться быстрее.
Рад что понравилось! На самом деле пока что не планировал, но если есть какие-то предложения или какая-то боль, которая пересекается со статьёй, то напишите, возможно стоит подумать над этим.
1. У нас есть группа приложений, которые выкатываются вместе и можно задеплоить их все в новую версию. Этот случай как раз расписан во второй части моей статьи, пункт «Деплой нескольких приложений с помощью werf bundle». Поскольку для каждого приложения мы указываем {{ .Chart.Name }}{{ $deploy_version }}, то и в переменных окружения можем указать сервис с нужной deploy_version. Таким образом, все приложения А, Б, В и другие будут обращаться к своей версии (синие на синие, а зелёные на зелёные). Я бы посоветовал подумать над этим вариантом.
2. Можно управлять трафиком до приложений не на Ingress, а непосредственно на Service. У нас будут 2 версии Deployment и 1 версия Service, в которой указываются нужные лейблы в секции selector. Из нюансов стоит отметить, что деплоить Service я бы советовал в этом случае отдельно от Deployment, иначе можем потерять одно из преимуществ blue-green - минимизацию простоя.
Я бы начал с того, что собрал требования, которым должна соответствовать инфраструктура, и уже от них отталкивался при выборе реализации. Как вариант, можно посмотреть в сторону реализации blue/green с помощью istio (если нужен именно blue/green).
Конечно, можно использовать какое-либо специализированное ПО, здесь всё зависит от конкретного кейса и потребностей заказчика. Если уже используется GitLab для деплоя в кубы, то принести эту реализацию может быть удобнее, чем дополнительно внедрять и поддерживать что-то новое. Например, если мы применяем blue-green только для одного приложения/группы приложений, то внедрение специализированного ПО, может только усложнить схему. Особенностью данного способа является как раз отсутствие необходимости переписывания пайплайнов под тот же Argo CD.
Что касается других паттернов, например, упомянутого canary - у него чуть другая задача. При blue-green мы не переключаем никакую часть пользователей на новый функционал, минимизируя тем самым простой и обеспечивая возможность быстрого отката к предыдущей версии. Это важно при необходимости поддержки критической инфраструктуры. Canary же больше подходит в случаях, когда необходимо протестировать новый функционал на ограниченной группе пользователей.
Спасибо за статью, круто видеть, что появляется больше материала по теме ML-инфры
Хотел бы отметить, что динамическая нарезка профилей MIG реализуется DRA, а не только через HAMi (как минимум я интерпретировал слова статьи будто это именно их бенефит).
Говоря про Volcano тоже хотел бы прокомментировать, что HAMi и Volcano - два разных проекта, хотя у них и есть нативная интеграция. Мне вообще кажется, что если использовать NVIDIA DRA-driver для динамической и гибкой выдаче ресурсов и Volcano для сложной логики щедулинга подов (как уже сказано в другом комментарии для простой достаточно воспользоваться Kueue, чтобы избегать оврехеда), то HAMi не так уж востребован. Кажется, что он нужен только в тех кейсах, где DRA не возможен физически. Встречались ли какие-то кейсы, которые без HAMi не получалось решить? Было бы интересно о них узнать
Также было бы интересно увидеть статью по переходу с Device Plugin на DRA, тк этот процесс кажется не таким уже простым. Из-за того, что они будут конкурировать за управление GPU делать это видимо необходимо с поочерёдным дрейном ноды.
Буду ждать следующей части!
Спасибо за статью, было интересно узнать, как организован процесс обнаружения уязвимостей. Однако интересно заглянуть на следующий этап, который здесь меньше описан: есть ли у вас (или, может, планируется) какая-то автоматизация устранения уязвимостей? Например, использование renovate/dependabot в случае патча через обновление. Подобные инструменты как-то включены в этот процесс?
И не возникает ли у вас проблемы с долгим фиксом уязвимостей, при котором тестирование новой версии занимает столько времени, что в ней успевают найти следующую CVE?
Для игнорирования полей можно использовать
ignore_changes. Например, если нужно игнорировать изменение IP:lifecycle {ignore_changes = [ipconfig0]}Также можно использовать
prevent_destroy, в блокеlifecycle, чтобы гарантировать, что ресурс не будет пересоздан.Лично я не пробовал это делать, однако в Terraform есть возможность использовать блок
importи затем выполнить команду:terraform plan -generate-config-out="generated_resources.tf"Спасибо за дополнение! Согласен, что при выборе любого инструмента стоит изучить GitHub Issues.
В статье я делюсь именно своим практическим опытом: в моих кейсах провайдер отработал стабильно, хотя это и не отменяет наличия багов в других сценариях. На мой взгляд, даже с учетом нюансов, декларативный подход Terraform удобнее, чем прямая работа с API. Надеюсь, интерес к теме поможет провайдеру развиваться быстрее.
Рад что понравилось! На самом деле пока что не планировал, но если есть какие-то предложения или какая-то боль, которая пересекается со статьёй, то напишите, возможно стоит подумать над этим.
Добрый день, тут есть несколько вариантов:
1. У нас есть группа приложений, которые выкатываются вместе и можно задеплоить их все в новую версию. Этот случай как раз расписан во второй части моей статьи, пункт «Деплой нескольких приложений с помощью werf bundle». Поскольку для каждого приложения мы указываем
{{ .Chart.Name }}{{ $deploy_version }}, то и в переменных окружения можем указать сервис с нужнойdeploy_version. Таким образом, все приложения А, Б, В и другие будут обращаться к своей версии (синие на синие, а зелёные на зелёные). Я бы посоветовал подумать над этим вариантом.2. Можно управлять трафиком до приложений не на Ingress, а непосредственно на Service. У нас будут 2 версии Deployment и 1 версия Service, в которой указываются нужные лейблы в секции
selector. Из нюансов стоит отметить, что деплоить Service я бы советовал в этом случае отдельно от Deployment, иначе можем потерять одно из преимуществ blue-green - минимизацию простоя.Я бы начал с того, что собрал требования, которым должна соответствовать инфраструктура, и уже от них отталкивался при выборе реализации. Как вариант, можно посмотреть в сторону реализации blue/green с помощью istio (если нужен именно blue/green).
Конечно, можно использовать какое-либо специализированное ПО, здесь всё зависит от конкретного кейса и потребностей заказчика. Если уже используется GitLab для деплоя в кубы, то принести эту реализацию может быть удобнее, чем дополнительно внедрять и поддерживать что-то новое. Например, если мы применяем blue-green только для одного приложения/группы приложений, то внедрение специализированного ПО, может только усложнить схему. Особенностью данного способа является как раз отсутствие необходимости переписывания пайплайнов под тот же Argo CD.
Что касается других паттернов, например, упомянутого canary - у него чуть другая задача. При blue-green мы не переключаем никакую часть пользователей на новый функционал, минимизируя тем самым простой и обеспечивая возможность быстрого отката к предыдущей версии. Это важно при необходимости поддержки критической инфраструктуры. Canary же больше подходит в случаях, когда необходимо протестировать новый функционал на ограниченной группе пользователей.