Как я могу компактно хранить общую конфигурацию с помощью Kubernetes Kustomize?

Во-первых, я не уверен, что этот вопрос достаточно конкретен для Stack Overflow. Рад удалить или отредактировать, если у кого-то есть предложения.

Мы используем Kubernetes для оркестровки нашего серверного кода, а недавно начали использовать Kustomize для модуляции кода.

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

Мы также используем TensorFlow Serving для развертывания моделей машинного обучения, каждая из которых обучена и на данный момент развернута для каждого из наших многочисленных клиентов. Единственный способ, которым эти конфигурации различаются, - это имя и аннотации метаданных (например, у нас может быть одна с именем classifier-acme, а другая с именем classifier-bigcorp), а также набор весов, которые извлекаются из нашего хранилища BLOB-объектов (например, один может извлекать из storage://models/acme/classifier а другой потянул бы от storage://models/bigcorp/classifier). Мы также назначаем разные пространства имен для разделения между разработкой, производством и т. Д.

Из того, что я понимаю о системе Kustomize, нам потребуется разная база и набор оверлеев для каждого из наших клиентов, если мы хотим закодировать все состояние нашего текущего кластера в файлах Kustomize. Это похоже на огромное количество каталогов, так как у нас много клиентов. Если у нас есть 100 клиентов и пять различных сред побега, это 500 каталогов с файлом kustomize.yml.

Есть ли инструмент или методика для кодирования этого повторения с помощью Kustomize? Или есть еще один инструмент, который поможет нам создавать конфигурации Kubernetes более систематическим и компактным способом?


person josephkibe    schedule 24.04.2020    source источник


Ответы (1)


У вас могут быть более сложные структуры наложения, чем просто подход с использованием прямой матрицы. Так, например, для одного приложения есть apps/foo-base, а затем apps/foo-dev и apps/foo-prod, которые оба имеют ../foo-base в своих базах, а затем они, в свою очередь, втягиваются overlays/us-prod и overlays/eu-prod и еще много чего.

Но если каждая комбинация клиента и среды действительно нуждается в своих настройках, вы действительно можете столкнуться с большим количеством наложений.

person coderanger    schedule 24.04.2020
comment
Это более или менее путь, по которому мы начали, прежде чем осознали, что произойдет взрыв каталогов с крошечными двухстрочными файлами. Я надеялся, что может быть инструмент, о котором мы не думали, который выводит это на другой уровень, почти. - person josephkibe; 24.04.2020
comment
Вы также можете написать собственный плагин генератора, если сможете сделать это процедурно. - person coderanger; 24.04.2020
comment
У меня была примерно такая идея - никто еще не делал что-то подобное? Отчасти это то, что я задавал его вопросом. Это не кажется особенно экзотическим требованием. Возможно, я наивен. - person josephkibe; 25.04.2020
comment
Большинству людей не нужен полный оверлей для каждого клиента, поэтому они получают только 4 или 5 и просто управляют им вручную. Вместо этого мы втиснули всю нашу логику для каждого клиента в оператора. - person coderanger; 25.04.2020