Несколько приложений в одном развертывании K8S
Я изучаю возможности K8S, и мне интересно, есть ли способ создать развертывания для двух или более приложений в одном развертывании, чтобы это было транзакционным - когда что-то не так после развертывания, все приложения откатываются. Также я хочу упомянуть, что Я не говорю о подах с несколькими контейнерами., потому что дополнительные боковые контейнеры скорее предназначены для некоторых сквозных задач, таких как мониторинг, аутентификация (например, kerberos) и другие, но не рекомендуется размещать разные приложения в одном модуле. Имея это в виду, возможно ли иметь одно развертывание, которое может создавать 2+ типа модулей?
Вы можете поместить подготовительные задачи в контейнер инициализации, и если это не удастся, остальные контейнеры не будут созданы. но вам все равно придется откатиться вручную.
Ответы 2
Шлем
Как указано в комментариях, один из способов сделать это — использовать что-то вроде Helm.
Helm — это своего рода клиент (начиная с версии 3. Предыдущая также включала «румпель», контроллер, работающий в вашем кластере kubernetes: давайте забудем об этом / устарело).
Helm использует «диаграммы» (более или менее: шаблоны со значениями по умолчанию, которые вы можете переопределить).
настроить
Другое решение, похожее на Helm, — это Kustomize. Работа с обычными текстовыми файлами (а не с шаблонами), при этом упрощается переопределение/настройка объектов перед их применением в кластере Kubernetes.
АргоCD
Хотя Kustomize и Helm являются автономными клиентами, мы также можем упомянуть такие решения, как ArgoCD.
Контроллер ArgoCD будет работать внутри вашего кластера Kubernetes, что позволит вам создавать объекты «Приложение».
Эти приложения обрабатываются ArgoCD, управляя развертыванием ваших рабочих нагрузок (обычными источниками для этих приложений могут быть Helm Charts, репозитории Git и т. д.).
Преимущество ArgoCD в том, что их контроллер может (в зависимости от вашей конфигурации) нести ответственность за обновление ваших приложений с течением времени (например, если вашим источником является репозиторий git, ветка XXX, и кто-то вносит изменения в эту ветку: argocd применит эти симпатичные много сразу)
Операторы
Хотя большинство этих решений практически не знают, как работает ваше приложение. Скажем, вы обновляете развертывание, управляемое Helm, Kustomize или ArgoCD, и в итоге некоторые модули базы данных застревают в аварийном цикле: ваши модули приложений, тем не менее, будут обновлены, автоматический откат к предыдущей рабочей конфигурации невозможен.
Это подводит нас к другому способу доставки приложений в Kubernetes: операторам.
Операторы осведомлены о состоянии ваших рабочих нагрузок и могут исправить распространенные ошибки (в зависимости от того, как это было закодировано, ... нет никакого волшебства).
Оператор — это приложение (может быть в Go, Java, Python, Ansible playbooks, ... или в зависимости от того, что поставляется с какой-либо библиотекой, взаимодействующей с API кластера Kubernetes)
Оператор постоянно подключен к API вашего кластера Kubernetes. Обычно вы найдете некоторые CustomResourceDefinitions, характерные для вашего оператора, что позволит вам описать развертывание некоторого компонента в вашем кластере. (например: оператор elasticsearch вводит тип объекта «ElasticSearch» и некоторый «Kibana»)
Оператор отслеживает экземпляры управляемых им объектов (например, ElasticSearch), в конечном итоге создавая Deployment/StatefulSets/Services... Если кто-то удалит объект, созданный вашим оператором, он будет/должен быть воссоздан этим оператором своевременно (пробег может варьироваться в зависимости от того, о каком операторе мы говорим...)
Идеальным образцом для операторов будет что-то вроде OpenShift 4 (OKD4). Кластер Kubernetes с десятками операторов (SDN, DNS, конфигурации компьютеров, входной контроллер, сервер API kubernetes, база данных etcd и т. д.). Весь кластер представляет собой набор операторов: при обновлении вашего кластера каждый из них будет управлять обновлением соответствующих служб организованным образом, ... один за другим, ... если что-то выйдет из строя, вы все равно обычно осталось с достаточным количеством запущенных реплик для устранения проблемы, ...
В зависимости от того, что вы ищете, каждый вариант имеет свои преимущества и недостатки. Теперь, если вы ищете «одно развертывание, которое может создавать 2+ типа модулей», то вам подойдет ArgoCD или какой-нибудь доморощенный оператор.
Спасибо за подробный ответ. Подводя итог, если я правильно понял - для моих требований «одно развертывание, которое может создавать 2+ типа модулей» не существует способа сборки, и мне приходится использовать третью сторону, такую как ArgoCD, или собственный код в операторах. Вы упомянули Kustomize, но, насколько я знаю, он дает какие-то патчи или структуру наследования, но не более того.
Верно, я упомянул Kustomize, следуя первоначальным рекомендациям Helm: но, хотя оба могут создавать несколько развертываний за один запуск, это не совсем то же самое, что «одно развертывание, которое может создавать 2+ типа модулей». Если я не понял, что вы хотели этим сказать? Читая это назад: вы имели в виду одно развертывание, в котором две реплики не будут делать одно и то же / использовать отдельные образы? может быть?
Я еще не знаю helm, но я чувствую, что это даст мне два отдельных развертывания, но я спрашивал о сценарии: набор реплик компонента с типом модуля A и другой набор реплик другого компонента B - одно развертывание (транзакция) может дать мне откат, когда после развертывания A возникает проблема со связью с B, и обе откатываются к предыдущим версиям (я знаю, что они не должны быть сильно связаны, но мир не идеален ;)) )
Is it possible to have single deployment that can produce 2+ kind of pods?
Нет. Развертывание создает только один тип пода. Вы можете обновить содержимое развертывания, и оно постепенно заменит существующие поды новыми, которые соответствуют обновленной спецификации пода.
Ничто не мешает вам создать несколько развертываний, по одному для каждого типа модуля, и, вероятно, именно такой подход вы ищете здесь.
... when something is wrong after deployment all apps are rollbacked.
Core Kubernetes сам по себе не имеет такой возможности; действительно, у него есть несколько ограниченные возможности для определения того, что что-то пошло не так, за исключением того, что контейнер не проходит проверку работоспособности или завершается.
Из различных инструментов в Ответ @SYN я по крайней мере имею некоторый опыт работы с Helm. Он не совсем «транзакционный» в том смысле, который вы могли бы взять из СУБД, но у него есть возможность управлять набором связанных ресурсов («выпуск» «диаграммы») и возможность отката всего версию выпуска для нескольких развертываний, если это необходимо. См. helm rollback команда.
Это более или менее проблема, которую шлем призван решить, со звездочкой, что то, что делает «откат», зависит от вас, полного удаления выпуска или попытки
helm upgrade --version $old_versionв случае сбоя.