У нас есть довольно обширный набор файлов конфигурации yaml, которые мы используем для определения развертываний, наборов с отслеживанием состояния, пространств имен, служб и т. Д. Ресурсов, которые должны быть созданы в kubernetes API в кластере.
Мы экспериментировали с несколькими инструментами, такими как terraform и ansible, для развертывания базовых вычислений и кластера k8s, и они отлично работают для применения управления конфигурацией на этом уровне.
Чего я не нашел, так это хорошего способа разумно автоматизировать развертывание и обновление этих ресурсов. Мы используем систему управления версиями для управления изменениями в этих определениях ресурсов и передачи этих изменений в тестовый и производственный кластеры с помощью kubectl apply -f.
Часто изменение представляет собой что-то простое, например обновление тега изображения для модуля в развертывании. В этом случае простой патч правильного image имущество при развертывании - это все, что нужно.
Для некоторых канонических ресурсов я немного поиграл поставщик терраформ kubernetes. Это довольно круто, поскольку он осведомлен о свойствах и может делать такие вещи, как выбор между удалением / восстановлением объекта и простым патчем.
Однако он падает в скорости развития. Трудно что-либо сделать, кроме ванильного релиза k8s. Это делает инструмент бесполезным для пользовательских ресурсов, таких как операторы. Есть аналогичные провайдеры, которые будут применять ваши определения yaml k8s, открывая kubectl, но они не осведомлены о свойствах.
Любые указатели на решения будут оценены, прежде чем я начну применять bash-fu.
Это звучит как довольно стандартный вариант использования шлем. Хотя, с одной стороны, это полезный менеджер пакетов для кубернетов, с другой стороны, моя команда добилась огромного успеха, используя его для управления нашими объектами API кубернетов в нашем кластере. Вы можете поместить свои манифесты в одну или несколько «диаграмм», и helm будет использовать диаграмму для установки и / или обновления всех ваших развертываний, карт конфигурации и т. Д. Для вас. Вы даже можете указать разные файлы значений для каждой среды. У нас есть values.prod.yaml, values.staging.yaml и т. Д., Который содержит все конфигурации, специфичные для нашей среды, поэтому мы можем повторно использовать одни и те же файлы манифеста во всех средах.