В чем разница между Хелмом и Кастомизе? - PullRequest
2 голосов
/ 04 марта 2020

Я какое-то время пользовался Kubernetes и Helm и теперь впервые столкнулся с Kustomize.

Но в чем именно разница между Kustomize и Helm?

Являются ли оба просто различными решениями для объединения элементов K8s, таких как службы, развертывания, ...? Или имеет смысл использовать одновременно Helm и Kustomize?

Ответы [ 2 ]

0 голосов
/ 28 марта 2020

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

Так что же это? Хорошо, когда вы используете шаблонизатор, вы создаете шаблонный пример вашего файла. Оттуда вы абстрагируете содержимое с помощью известных операторов, и в этих абстракциях вы предоставляете ссылки на переменные. Эти переменные обычно абстрагируются в другой файл, в который вы вставляете информацию, указанную c. Ваша среда Затем, во время выполнения, когда вы запускаете шаблонизатор, шаблоны загружаются в память и все переменные обмениваются их заполнителями. Результирующий файл затем сохраняется на диск или обрабатывается приложением.

Это отличается от механизма наложения несколькими нюансами. Обычно о том, как информация попадает в примеры конфигурации. Заметил, как я использовал слово examples вместо templates . Это было сделано намеренно, поскольку Kustomize не использует шаблоны. Вместо этого вы создаете файл Kustomization.yml . Этот файл затем указывает на две разные вещи. Ваша База и ваши Наложения . Во время выполнения ваша База загружается в память, и, если существуют какие-либо Оверлеи, они объединяются поверх вашей Базовой конфигурации.

Эта последняя схема лучше в нескольких отношениях. Самое главное, это позволяет вам легче масштабировать ваши конфигурации для большого количества вариантов. Представьте себе, что вы поддерживаете 10 000 различных файлов переменных для 10 000 различных конфигураций. А теперь представьте себе поддержку иерархии модульных и небольших конфигураций, которые могут быть унаследованы в любой комбинации или перестановке? Это значительно уменьшит избыточность и значительно улучшит управляемость.

Последнее важное различие, которое я избегал до сих пор, заключается в том, как они работают по-разному. Потому что это был не тот вопрос, о котором был ваш вопрос, а нечто вроде поляризационного топи c.

Helm традиционно развертывает приложения в кластере, поддерживая модуль с привилегиями супер-администратора в кластере, который называется Tiller. Тогда вы будете общаться с Tiller, и это создаст ваши рабочие нагрузки для вас. Это довольно плохая идея, потому что многие новички в экосистеме Kubernetes по умолчанию используют Helm для развертывания приложений, потому что это автоматизирует некоторые серьезные сложности. Проблема в том, что люди могут воспользоваться этим сценарием «черного ящика», но писать вредоносный код, который затем Тиллер будет выполнять в кластере наивного человека.

Kustomize отличается тем, что работает больше, чем шаблон Helm. Вместо того, чтобы напрямую взаимодействовать с сервером API Kubernetes, Kustomize просто объединяет файлы и производит вывод. Итак, после того, как вы определили все свои базы и патчи, вы просто запускаете kustomize build, и все патчи будут автоматически применены, и результирующие исправленные файлы будут созданы для STDOUT. Затем администратор сам должен оценить содержание этого вывода, чтобы определить, является ли он точным. А затем передайте его на сервер API сами.

Еще один нюанс, на который следует обратить внимание, - это право собственности на проекты. Шлем управляется третьей частью. Kustomize разрабатывается непосредственно командой Kubernetes. На самом деле, функциональность Kustomize напрямую поддерживается в Kubectl. Вы можете создать и выполнить проект Kustomize следующим образом: kubectl apply -k DIR.

В Kustomize есть и несколько других улучшений, которые несколько более незначительны, но о которых стоит упомянуть. Он может ссылаться на базы из inte rnet или других нестандартных путей. Он поддерживает генераторы для автоматического создания файлов конфигурации на основе файлов и строковых литералов. Он поддерживает надежное и гранулированное исправление JSON. Он поддерживает внедрение метаданных в файлы конфигурации.

РЕДАКТИРОВАТЬ: Следующее содержимое было удалено из моего ответа другим пользователем. Я согласен с тем, что предвзятость была введена здесь, однако я все еще верю, что информация должна быть представлена ​​в перефразированном формате, а не пропущена.

Список можно продолжить. * Я верю, что со временем Хелм будет становиться все менее и менее актуальным в сообществе, и люди будут все больше и больше стремиться к Kustomize, так как он продолжает развиваться и поддерживать все большую и более официальную поддержку со стороны сообщества Kubernetes.

Точнее, я имел в виду, что со временем использование Kustomize будет превосходить использование Helm, поскольку он изначально разрабатывался командой Kubernetes и одновременно не страдал от истории разработки игнорируемых проблем безопасности.

EDIT 2: было упомянуто, что Helm 3 больше не использует Tiller. Это правильно, я должен был упомянуть об этом в своем оригинальном сообщении.

0 голосов
/ 04 марта 2020

Почти все. Например, спрашивать, в чем разница между Apache и Nginx :). Они выполняют неопределенно схожие задачи, но количественно оценить различия невозможно.

Короткая версия заключается в том, что Helm - это система на основе шаблонов, основанная на децентрализованной системе. модель для обмена графиками. Kustomize основан на глубоких слияниях и других структурированных преобразованиях данных YAML.

В некоторых случаях целесообразно использовать оба этих параметра, например, передать выходные данные из шаблона helm в kustomize для наложений.

...