Пользовательские определения ресурсов

Эта часть руководства по лучшим практикам посвящена созданию и использованию объектов Custom Resource Definition.

При работе с Custom Resource Definition (CRD) важно различать две составляющие:

• Есть декларация CRD. Это YAML-файл с kind CustomResourceDefinition
• Есть ресурсы, которые используют CRD. Например, если CRD определяет foo.example.com/v1, то любой ресурс с apiVersion: example.com/v1 и kind Foo является ресурсом, использующим этот CRD.

Установите декларацию CRD перед использованием ресурса

Helm оптимизирован для максимально быстрой загрузки ресурсов в Kubernetes. Kubernetes спроектирован так, что может принять целый набор манифестов и привести в рабочее состояние (это называется циклом согласования).

Но с CRD есть одно отличие.

Для CRD декларация должна быть зарегистрирована до того, как можно будет использовать какие-либо ресурсы этого типа CRD. А процесс регистрации иногда занимает несколько секунд.

Метод 1: Позвольте helm сделать это за вас

С выходом Helm 3 мы убрали старые хуки crd-install в пользу более простой методологии. Теперь вы можете создать в своём чарте специальную директорию crds для хранения ваших CRD. Эти CRD не шаблонизируются, но устанавливаются по умолчанию при выполнении helm install для чарта. Если CRD уже существует, он будет пропущен с предупреждением. Если вы хотите пропустить шаг установки CRD, можете передать флаг --skip-crds.

Некоторые оговорки (и объяснения)

На данный момент обновление или удаление CRD с помощью Helm не поддерживается. Это было осознанное решение после длительного обсуждения в сообществе из-за опасности непреднамеренной потери данных. Кроме того, в настоящее время нет консенсуса в сообществе относительно того, как обращаться с CRD и их жизненным циклом. По мере развития ситуации Helm добавит поддержку этих сценариев использования.

Флаг --dry-run команд helm install и helm upgrade в настоящее время не поддерживается для CRD. Цель «Dry Run» — проверить, что вывод чарта действительно будет работать при отправке на сервер. Но CRD изменяют поведение сервера. Helm не может установить CRD при dry run, поэтому клиент обнаружения не будет знать об этом Custom Resource (CR), и валидация завершится неудачей. В качестве альтернативы вы можете вынести CRD в отдельный чарт или использовать helm template вместо этого.

Ещё один важный момент при обсуждении поддержки CRD — это то, как обрабатывается рендеринг шаблонов. Одним из существенных недостатков метода crd-install, использовавшегося в Helm 2, была невозможность правильной валидации чартов из-за изменения доступности API (CRD фактически добавляет ещё один доступный API в ваш кластер Kubernetes). Если чарт устанавливал CRD, у helm больше не было актуального набора версий API для работы. Это также причина удаления поддержки шаблонизации из CRD. С новым методом установки CRD через директорию crds мы теперь гарантируем, что helm имеет полностью достоверную информацию о текущем состоянии кластера.

Метод 2: Разделение на отдельные чарты

Другой способ — поместить определение CRD в один чарт, а все ресурсы, использующие этот CRD, — в другой чарт.

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