Хелм Чарты распространены повсеместно. Это де-факто метод упаковки и развертывания программного обеспечения в Kubernetes. Подобно программной библиотеке, диаграмма управления позволяет разработчикам не изобретать велосипед каждый раз, когда они запускают новое приложение. По мере роста вашей организации или продукта вы почти наверняка будете создавать внутренние диаграммы управления, которые позволят разработчикам быстро двигаться вперед и извлекать выгоду из лучших практик остальной организации. Это позволит разработчикам или конечным пользователям вашего программного обеспечения получить лучшие практики с точки зрения надежности, масштабируемости и развертывания. Я написал более 10 диаграмм руля, по крайней мере одна из которых имеет сотни установок внутри Mission Lane. Я также участвовал в различных диаграммах с открытым исходным кодом, включая Open Telemetry Collector, K6 Operator, BentoML/Yatai и другие. Вот мои 6 советов по написанию отличной диаграммы руля.

Не меняйте известную спецификацию API

Не перемещайте imagePullSecrets в image.pullSecrets. Не переходите, как я когда-то, от resources.limits.cpu/memory к resources.cpu.limits/requests и resources.memory.limits/requests. Не меняйте способ передачи переменных среды. Независимо от того, насколько, по вашему мнению, спецификация API улучшится благодаря вашим изменениям, это вызовет еще большую путаницу, потребует дополнительных переписываний и сделает недействительной всю внешнюю документацию.

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

Сгенерируйте schema.json

По крайней мере, с 2020 года диаграммы управления поддерживают использование schema.json для проверки схемы, автоматического завершения IDE и проверки типа. Используй это.

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

Если вы хотите автоматически сгенерировать схему, вы можете сделать это с помощью: https://github.com/knechtionscoding/helm-schema-gen. Автогенерация работает лучше всего, когда вы делаете это в первый раз. После первого раза вам почти наверняка придется управлять схемой вручную, чтобы получить от нее максимальную отдачу.

Добавьте типы к каждому из значений. Убедитесь, что установлено необходимое. Помните, что ваш тип должен включать какое-то нулевое значение, если оно не является обязательным. Убедитесь, что у вас есть полезные описания для каждого из значений.

Чем проще вы сделаете использование своей рулевой диаграммы, тем больше других инженеров будут ее использовать. Сделайте это как можно проще. Предоставление им проверки схемы в IDE и при запуске шаблона helm — большой шаг к этому.

Создать документацию

Используйте helm-docs для создания документации для вашего руля. Документация будет поддерживать его в актуальном состоянии, непротиворечивым и удобным для использования. Сделайте генерацию документов хуком перед фиксацией или частью конвейера непрерывной интеграции, чтобы обеспечить ее актуальность.

Установите разумные значения по умолчанию

Значения по умолчанию будут приемлемыми для более чем 80% пользователей вашей диаграммы управления. Жизненно важно убедиться, что они имеют смысл и разумны. Много написано о вменяемых дефолтах. Но в целом вы должны установить значения по умолчанию, которые будут соответствовать значениям, которые понадобятся большинству ваших пользователей, особенно при настройке.

Может возникнуть соблазн использовать «профили», которые в основном представляют собой групповые настройки или значения вместе. Например, у вас может возникнуть соблазн создать многоуровневую систему: уровень 0 (99,99 % SLA), уровень 1 (99,9 % SLA), уровень 2 (99 % SLA), а затем изменить значения по умолчанию в зависимости от значения профиля. Не делайте этого в своем графике. Сделайте это в интерфейсе командной строки, который создает экземпляр вашей диаграммы управления. Если вы сделаете это внутри значений и установите несколько значений на основе «профиля», вы в конечном итоге потеряете много настроек, необходимых для того, чтобы сделать использование вашей диаграммы простым и масштабируемым.

Разрешить переопределение версии API

Одной из самых полезных функций helm является функция Возможности. Если вы не использовали его, возможности позволяют вам запросить у кластера k8s версию API, которую он поддерживает. Функция возможностей избавляет вас от необходимости управлять отдельной версией — › сопоставлением возможностей для каждого API. В большинстве случаев это реализуется как условие if/else со значением по умолчанию. Но есть и обратная сторона использования Capabilities — в частности, это работает, только если вы используете установку helm. Если вы используете шаблон helm (сначала выполнить diff) или подключаетесь к другому инструменту, или если вы используете посредника, такого как customize, то возможности не работают, потому что Helm не имеет прямого доступа к API кластера. . В подобных случаях [что], разрешите переопределение APIVersion в values.yaml. У руля Renovate есть отличный пример

Пишите модульные тесты

Большинство людей, пишущих диаграммы руля, не доходят до этого шага. Однако написание тестов действительно важно, когда вы начинаете писать сложные взаимодействия между условиями. Возможность гарантировать, что заполняются правильные переменные, создаются правильные объекты (особенно когда вы группируете их вместе под одним условным выражением), существуют правильные аннотации или метки, выводятся правильные схемы именования и имена или требуется любое количество других параметров. , особенно если ваша диаграмма становится довольно большой и изменения затрагивают несколько объектов одновременно.

К счастью, кто-то написал инструмент, который позволяет проводить модульные тесты рулевых диаграмм. Я использовал его почти 3 года, написал около 400 тестов и нашел множество ошибок в своих собственных диаграммах, и он стал незаменимым инструментом. Helm-unittest действительно прост в использовании и позволяет вам писать небольшие компонуемые тесты, которые гарантируют, что ваши объекты будут выглядеть так, как вы ожидаете. Он не позволяет вам тестировать функциональность — встроенная команда helm test может вам в этом помочь — но я считаю, что это все равно не так важно. Ваши функциональные тесты должны либо быть доступны в вашей фактической кодовой базе, либо быть настолько простыми, что на самом деле не имеют смысла. Модульные тесты, однако, позволяют вам убедиться, что вы написали шаблоны helm с ожидаемым результатом.

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

Напишите хорошие примечания к выпуску

Это должно быть понятно. Не делайте свою диаграмму эквивалентом примечаний к выпуску мобильного приложения: исправления ошибок. Используйте систематический метод создания примечаний к выпуску, убедитесь, что пользователи знают, что изменилось и почему, и опубликуйте их вместе с выпуском. Я предпочитаю обычные коммиты в качестве метода написания моих сообщений коммитов, а для генерации моих версий, однако, вы можете выбрать любой стиль, который вам нравится. Убедитесь, что инженеры, использующие вашу диаграмму, знают, что меняется между версиями.

Всегда разрешайте следующие 4 настройки

  1. Добавление дополнительных контейнеров в поды. Существует множество причин, по которым пользователь диаграммы может захотеть добавить в модуль дополнительный контейнер или даже больше. Sidecar для подключений к БД, контейнер инициализации, сервисная сетка, контейнер секретов и т. д. Каждый из них представляет собой реальные варианты использования для изменения количества контейнеров — так что упростите его.
  2. Добавление меток и аннотаций глобально (к каждому объекту в одном месте) и к каждому объекту в отдельности. Требования к маркировке и аннотациям будут становиться все более строгими по мере того, как компании используют контроллеры доступа, такие как Kyverno или Gatekeeper, требуют точного учета расходов и работают над обеспечением права собственности на услуги. Позвольте пользователям легко передавать пользовательские метки и аннотации.
  3. Разрешить пользовательские переменные env. Следуйте спецификации API и разрешите передачу пользовательских переменных env всем контейнерам и каждому контейнеру конкретно. Необходимость выяснить, как и зачем получать переменные среды, которые могут потребоваться в контейнере, может быть мучительной, если это не легко доступно через envVars.
  4. Убедитесь, что ресурсы можно настроить для каждого модуля. Также не стоит жестко кодировать, какие ресурсы можно настроить. Не разрешайте только процессор/память. По мере того, как команды используют эфемерное хранилище или сетевые запросы/лимиты, вы хотите, чтобы ваша диаграмма была совместима с переадресацией.

Заключение

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

  1. Не меняйте известную спецификацию API
  2. Сгенерируйте schema.json
  3. Создание документации
  4. Установите разумные значения по умолчанию
  5. Разрешить переопределение версии API
  6. Пишите модульные тесты
  7. Напишите хорошие примечания к выпуску
  8. Всегда разрешать стандартные настройки