Лучший способ описать различия - это ссылаться на них как на разные типы механизмов развертывания. Один из них - шаблонизатор , а другой - оверлейный движок .
Так что же это? Хорошо, когда вы используете шаблонизатор, вы создаете шаблонный пример вашего файла. Оттуда вы абстрагируете содержимое с помощью известных операторов, и в этих абстракциях вы предоставляете ссылки на переменные. Эти переменные обычно абстрагируются в другой файл, в который вы вставляете информацию, указанную 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. Это правильно, я должен был упомянуть об этом в своем оригинальном сообщении.