Contents
Введение
Helm Chart — это программное обеспечение для управления пакетами, позволяющее писать шаблоны Kubernetes и упаковывать их в виде диаграмм со всеми зависимостями. Одна диаграмма может использоваться для развертывания nginx, memcache или любого полнофункционального веб-приложения. Вы можете развернуть любую диаграмму приложений, просто выполнив следующую команду.
helm install my-release bitnami/nginx
Сфера
В этой статье не содержится подробной информации о разработке Helm Chart, вместо этого у Helm Chart есть очень хорошая документация, которую вы можете просмотреть, чтобы узнать о нем больше.
Я собираюсь рассказать о том, как тестировать диаграммы управления как часть разработки и какие различные типы инструментов тестирования можно использовать для тестирования диаграмм от модульных тестов до интеграционных тестов.
Разработка Helm Chart — неприятный опыт
Helm Chart написан на шаблонах go, и написание этих шаблонов для рендеринга манифестов Kubernetes — болезненный опыт. Нет хорошей поддержки отладчика, и ошибки невежественны, поэтому иногда вам нужно потратить часы, чтобы исправить незначительные проблемы, связанные с отступами. Helm предоставляет флаг отладки при рендеринге шаблонов, хотя он не указывает точную строку кода, где находится ошибка, поэтому найти проблемы сложно. Я надеюсь, что в будущем у нас появятся лучшие инструменты для разработки диаграмм руля, которые облегчат жизнь разработчикам.
Правильны ли ваши шаблоны диаграмм?
Как упоминалось ранее, шаблоны Helm Chart используют шаблоны go, поэтому в рамках разработки вам необходимо быть уверенным в синтаксических ошибках, чтобы не получить сюрпризов в последнюю минуту, когда вы выпускаете свою диаграмму.
Helm предоставляет команду lint, которая находит и сообщает обо всех этих проблемах, связанных с шаблонами, поэтому вы можете часто выполнять эту команду, чтобы найти ошибки времени компиляции как часть вашей разработки.
Вот шаблон развертывания диаграммы управления с ошибками.
Helm lint сообщит о следующих ожидаемых проблемах.
➜ mychart helm lint . ==> Linting . [INFO] Chart.yaml: icon is recommended[ERROR] templates/: parse error at (mychart/templates/deployment.yaml:19): function “Values” not defined[ERROR] templates/: template: mychart/templates/deployment.yaml:7:16: executing “mychart/templates/deployment.yaml” at <include “namespace” .>: error calling include: template: no template “namespace” associated with template “gotpl”Error: 1 chart(s) linted, 1 chart(s) failed
Я знаю, что это очень простой пример, но он достаточно хорош для понимания того, как работает lint.
Проверка по манифестам Kubernetes
Шаблон Helm — это команда, которую вы можете использовать для рендеринга/генерации манифестов/шаблонов Kubernetes из ваших шаблонов диаграммы helm.
Существует команда Helm install для установки/развертывания чартов в кластере Kubernetes. Внутри он сначала выполняет команду шаблона helm, а затем развертывает сгенерированные выходные данные шаблона в кластере.
helm template . > deployment.yaml
Действительны ли ваши манифесты Kubernetes?
Если вы делаете ошибки при разработке диаграммы, возможно, сгенерированные манифесты Kubernetes генерируют ошибки при применении к кластеру Kubernetes, но я хочу знать об этих ошибках перед развертыванием.
Кубевал — спасательный инструмент. Это инструмент для проверки сгенерированных манифестов на соответствие официальной спецификации Kubernetes и сообщения о проблемах, если таковые имеются.
Можете ли вы обнаружить какую-либо проблему в этом шаблоне развертывания?
Запустите kubeval для этого манифеста развертывания и посмотрите на проблемы.
➜ mychart kubeval deployment.yamlWARN — mychart/templates/deployment.yaml contains an invalid Deployment (myservice.nginx-deployment) — selector: selector is requiredWARN — mychart/templates/deployment.yaml contains an invalid Deployment (myservice.nginx-deployment) — containerPort: containerPort is requiredWARN — mychart/templates/deployment.yaml contains an invalid Deployment (myservice.nginx-deployment) — spec.replicas: Invalid type. Expected: [integer,null], given: string##### This is the output if it was valid deployment ##### PASS — mychart/templates/deployment.yaml contains a valid Deployment (myservice.nginx-deployment)
Кроме того, вы можете указать версию Kubernetes, относительно которой вы хотите проверять сгенерированные шаблоны, используя опцию «— kubernetes-version v1.20.4».
Пользовательские проверки манифестов Kubernetes
Допустим, у меня есть следующие простые требования.
- Контейнеры не должны запускаться с правами root.
- Образы Docker должны поступать из репозитория моей организации.
Вы можете решить эту проблему, внедрив контроллер допуска в Kubernetes, когда ресурсы развертываются в кластере, но было бы неплохо, если бы мы могли применить эту пользовательскую проверку перед развертыванием?
Conftest — это фреймворк, который позволяет вам писать правила с использованием политик OPA и запускать их против манифестов Kubernetes.
Запустите эти настраиваемые правила для манифестов развертывания с помощью conftest, который будет сообщать о проблемах на основе настроенных правил.
➜ mychart conftest test — policy . deployment.yamlFAIL — deployment.yaml — main — Containers must not run as root FAIL — deployment.yaml — main — image ‘nginx’ doesn’t come from myorg.com repository2 tests, 0 passed, 0 warnings, 2 failures, 0 exceptions
Вы можете написать любые настраиваемые политики для всех ваших ресурсов, которые вы можете выполнить для манифестов Kubernetes перед развертыванием. Это круто.
Проверка схемы для пользовательских значений
Как я объяснил, вы можете проверить манифесты Kubernetes с помощью инструментов Kubeval и Conftest, но когда вы создаете диаграмму управления, вам нужно разрешить пользователям, использующим диаграмму, добавлять некоторые пользовательские значения для любой новой функции. вам необходимо убедиться, что эти пользовательские значения имеют правильный формат для использования диаграммой, в противном случае произойдет сбой рендеринга диаграммы, что является очень сложной задачей для отладки. как мы можем применить первый уровень защиты, чтобы убедиться, что предоставленные пользовательские значения имеют правильный формат, в противном случае это приведет к ошибке с правильным сообщением проверки.
Helm Chart предоставляет функцию проверки схемы , для которой вам необходимо предоставить файл схемы в диаграмме, содержащей правила для всех ваших пользовательских значений. Он сначала проверяет эту проверку схемы перед выполнением любой из этих команд.
– helm lint
– шаблон
helm – установка
helm – обновление helm
Это несколько вариантов использования с использованием пользовательских значений.
- Пользователи должны иметь возможность указывать требования к памяти и процессору.
- Некоторые пользователи хотят указать разные местоположения журналов для журналов приложений.
- Пользователи хотят предоставить переменные среды для контейнера приложения.
Давайте реализуем первый вариант использования, где, если пользователь укажет пользовательские значения для памяти и процессора, тогда он примет значения по умолчанию, в противном случае.
Вот файл values.schema.json для проверки пользовательских значений.
Это custom-values.yaml, который пользователи могут предоставлять при использовании диаграммы.
Поскольку пользователь указал неверные пользовательские значения, это должно завершиться ошибкой.
➜ mychart helm template . -f custom-values.yamlError: values don’t meet the specifications of the schema(s) in the following chart(s): mychart: - memory: Does not match pattern ‘^[0–9.]+[M|G]i$’ - cpu: Does not match pattern ‘^[0–9.]+m*$’
Вы можете выполнять любой тип проверки, если он поддерживается спецификациями схемы json, хотя единственным условием является то, что все правила схемы json должны быть доступны в файле с именем values.schema.json на диаграмме.
Модульное тестирование
Как и любой другой язык программирования, модульные тесты — это первое, что разработчики должны учитывать на ранней стадии разработки. Я вижу нехватку хороших фреймворков для модульного тестирования, доступных для Helm Charts.
Существует фреймворк модульного тестирования helm-unittest . Это очень хороший фреймворк для модульного тестирования, и в настоящее время ведется активное развертывание, поэтому обязательно стоит его использовать.
Существует еще один хакерский способ тестирования диаграмм Helm, который представляет собой смесь модульных тестов и регрессионных тестов.
Идея очень проста. вам нужно добавить файл привязки, содержащий пользовательские значения для каждой новой функции, которую вы реализуете, в диаграмме helm, и сгенерировать файл фиксации из него с помощью команды шаблона helm. Вам нужно зафиксировать привязку и файл фиксации в репозитории. Теперь создайте простой сценарий оболочки, который будет выполняться в CI, который создаст файл фикстуры из файла привязки на лету в соответствии с вашими изменениями в диаграмме и сравнит его с существующим файлом фикстуры. вы просто не пройдете тест, если есть разница в файлах фикстур, тогда вам нужно либо исправить вашу диаграмму руля, либо обновить существующий файл фикстур, если это ожидаемое поведение.
Тестирование с использованием фикстур очень полезно при рефакторинге кода, а также может быть рассмотрено для модульных тестов при написании новых функций.
Интеграционные тесты с использованием Kubetest
До сих пор мы тестировали шаблоны диаграмм helm и манифесты Kubernetes с помощью различных инструментов, но мы ничего не проверяли, фактически развертывая манифесты Kubernetes в кластере Kubernetes.
Зачем нужны интеграционные тесты?
Я упомянул несколько вариантов использования, которые можно проверить, только развернув ресурсы в кластере.
- Я смонтировал том как доступный для записи, что я хочу проверить, создав файл в томе.
- Есть некоторые пользовательские ресурсы, которые я хочу проверить.
- Я хочу проверить работоспособность внутреннего балансировщика нагрузки, созданного в рамках создания службы Kubernetes.
Доступно много инструментов, но мне очень понравился Kubetest — плагин для pytest. Kubetest упрощает написание интеграционных тестов, предоставляя абстракцию поверх клиента Kubernetes.
Он предоставляет множество вспомогательных функций, поэтому вам не нужно писать сложный код с использованием клиента Kubernetes, если в этом нет крайней необходимости.
Написание интеграционных тестов с помощью Kubetest очень интуитивно понятно и увлекательно. У меня возникло искушение пропустить и не помещать здесь какой-либо пример кода, потому что он говорит сам за себя, как только вы посмотрите на этот пример кода.
Резюме
Я рассказал об основах рулевых диаграмм, различных инструментах, которые мы можем использовать для различных типов тестирования, включая модульное тестирование и интеграционные тесты в течение жизненного цикла от разработки до выпуска рулевых диаграмм.
Не упустите возможность взглянуть на мой github , который я использовал в качестве примера в статье, если что-то непонятно.
