Блог

Мне нужно развернуть несколько контейнеров в кластере Kubernetes. Целью является автоматизация развертывания Kafka, Kafka Connect, PostgreSQL и других. Некоторые из них уже предоставляют оператора управления, которого мы могли бы использовать. Поэтому мой вопрос в том, можем ли мы каким-то образом использовать этих операторов управления внутри нашего оператора? Если да, то каков был бы наилучший подход?

Единственный метод, который я могу придумать до сих пор, — это вызов команд консоли настройки helm из приложения развертывания. Другой подход, без использования этих файлов управления, заключался бы в реализации функциональности каждого оператора в моем собственном операторе, что, похоже, не имеет особого смысла, поскольку то, что мне нужно, уже разработано и является общедоступным.

Я очень новичок в разработке операторов, поэтому, пожалуйста, извините меня, если это глупый вопрос.

Правка: Основная цель оператора-развернуть базы данных X. Наряду с этим мы хотели бы иметь одного оператора/пакет, который сразу же развертывает всю систему. Имеет ли вообще смысл использовать оператора для связывания, даже если у нас есть дополнительные задачи для некоторых контейнеров? При этом пользователь должен указать в файле yaml:

 databases
  - type: "postgres"
    name: "users"
  - type: "postgres"
    name: "purchases"
 

и будут созданы 2 базы данных PostgreSQL. Затем эти базы данных могут быть упомянуты в других файлах yaml или далее в том же файле yaml. Дело на руках: информация из баз данных будет извлечена Debezium (другим контейнером), поэтому Debezium должен знать их адреса. Таким образом, оператор должен создать службу и связать адрес службы с именем базы данных.

Это часть системы ETL. Идея заключается в том, что оператор позволит легко развернуть всю систему, позаботившись о большей части конфигурации. Имея это в виду, мы подумали, нельзя ли выбрать существующих операторов Helm (или операторов другого типа) и развернуть их с небольшими изменениями в конфигурациях, таких как разные порты для разных баз данных.

Но после прочтения ответа F1ko у меня появились новые перспективы. Возможно, это невозможно с оператором, как первоначально ожидалось?

Правка 2: Разъяснение правки 1.

Просто в целях разъяснения:

• Helm-это менеджер пакетов, с помощью которого вы можете установить приложение в кластер в комплекте: он в основном предоставляет вам все необходимые YAML, такие как карты конфигурации, Службы, развертывания и все остальное, что необходимо для правильной работы и запуска нужного приложения.
• Оператор-это, по сути, контроллер. В Kubernetes существует множество различных контроллеров, которые определяют «логику» всякий раз, когда вы что-то делаете (например, контроллер репликации добавляет больше копий модуля, если вы решите увеличить replicas поле). Просто существует слишком много контроллеров, чтобы перечислять их все и запускать по отдельности, поэтому они скомпилированы в один двоичный файл, известный как куб-контроллер-менеджер. Специально созданные контроллеры называются операторами для более легкого различения. Эти операторы просто следят за состоянием определенных «вещей» и собираются выполнить действие, если это необходимо. Большую часть времени этими «вещами» будут пользовательские ресурсы (CRS), которые по сути являются новыми объектами Kubernetes, которые были введены в кластер путем применения пользовательских определений ресурсов (CRD).

С учетом сказанного, нередко используется helm для развертывания операторов, однако старайтесь избегать термина «оператор управления», поскольку на самом деле он относится к очень конкретному оператору и может привести к путанице в будущем: https://github.com/fluxcd/helm-operator

Поэтому мой вопрос в том, можем ли мы каким-то образом использовать этих операторов управления внутри нашего оператора?

Хотя вы можете создать свой собственный оператор с помощью operator-sdk, который затем позволит вам развертывать или запускать определенные события от других операторов (например, путем редактирования их CRD), для этого нет причин.

Единственный метод, который я могу придумать до сих пор, — это вызов команд консоли настройки helm из приложения развертывания.

Скорее всего, то, что вы ищете, — это правильный рабочий процесс CI/CD. Просто зафиксируйте диаграмму управления и values.yaml файлы, которые вы используете во helm install время работы в репозитории Git, и попросите инструмент CI/CD (например, GitLab) развертывать их в вашем кластере каждый раз, когда вы делаете новую фиксацию.

Обновление: Поскольку другой отредактировал свой вопрос и оставил комментарий, я решил обновить этот пост:

Основной целью оператора является развертывание X баз данных. Наряду с этим мы хотели бы иметь одного оператора/пакет, который сразу же развертывает всю систему.

Как вы думаете, имеет ли смысл объединять операторы вместе в другом операторе, как это было бы с Helm?

Нет, это вообще не имеет смысла. Это именно то, для чего существует хелм. С помощью helm вы можете объединять материалы, вы даже можете объединять несколько диаграмм управления, которые могут быть тем, что вы на самом деле ищете. У вас может быть одна диаграмма управления, которая передает необходимые значения в фактические диаграммы управления оператора, и поэтому вы можете использовать что-то вроде имени службы в нескольких местах.

В случае операторов внутри операторов по-прежнему необходимо настраивать каждого подоператора индивидуально при настройке оператора?

Как упоминалось выше, делать это подобным образом не имеет никакого смысла, это просто чрезмерно продуманный подход. Однако, если вы действительно хотите использовать подход оператора, вы можете использовать в основном два подхода:

• Напишите оператор, который настраивает других операторов, изменяя их сок, ConfigMaps и т. д. ; с таким подходом у вас будет довольно легким оператора, однако вам нужно будет убедиться в его совместимости во все времена с разных операторов вы хотите, чтобы мешать (когда они меняются на новые apiVersion с критические изменения, вводятся новые CRS или что-нибудь в этом роде, вам будет адаптироваться снова).
• Извлеките всю логику из существующих операторов в свой оператор (т. Е. Восстановите то, что уже существует); при таком подходе у вас будет большое монолитное приложение, которое будет очень сложно поддерживать, поскольку вам постоянно придется обновлять свой код всякий раз, когда в вышестоящем операторе происходит обновление

Надеюсь, к настоящему времени уже ясно, что создание собственного оператора для «работы» с другими операторами сопряжено с множеством болезненных зависимостей и не должно быть правильным решением.

Можно ли развернуть различные конфигурации образов? Например, базы данных, настроенные с разными портами?

Хорошие операторы и диаграммы управления позволяют вам делать это из коробки, либо с помощью соответствующей карты CR / конфигурации, либо values.yaml файла, однако теперь это зависит от того, какие решения вы собираетесь использовать. Так что в целом ответ таков: да, это возможно, если поддерживается.