☸️ Как проверить содержимое чарта Helm |
Главная » Мануал

☸️ Как проверить содержимое чарта Helm

Мануал
На чтение 10 мин Опубликовано
Содержание
  1. Введение
  2. Зачем валидировать чарты Helm?
  3. Использование команды helm lint
  4. Проверка одного чарта
  5. Проверка всех графиков в каталоге
  6. Использование шаблона helm с проверкой Kubernetes
  7. Использование kubeconform для проверки схем
  8. Базовая валидация с помощью kubeconform
  9. Работа с CRD с помощью kubeconform
  10. Указание версии Kubernetes
  11. Проверка с помощью values.schema.json
  12. Определение схемы
  13. Вложенные свойства и ограничения
  14. Заключение

Введение

Чарт Helm – важнейший инструмент для управления приложениями Kubernetes.

Они объединяют все ресурсы Kubernetes, необходимые для развертывания приложения, в единое целое, что делает развертывание более простым и воспроизводимым.

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

В этом руководстве мы рассмотрим различные методы проверки содержимого чартов Helm.

Это гарантирует, что наши развертывания будут надежными и без распространенных ошибок.

Мы рассмотрим такие инструменты и методы, как helm lint, helm template, расширенные методы проверки схем и некоторые лучшие практики.

Зачем валидировать чарты Helm?

Валидация чартов Helm очень важна по нескольким причинам.

Во-первых, она гарантирует правильность и полноту наших конфигураций.

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

Проверка чартов Helm позволяет выявить эти проблемы на ранних этапах разработки.

К распространенным ошибкам в чартах Helm относятся синтаксические ошибки, отсутствие полей и неправильные спецификации ресурсов.

Эти ошибки могут быть сложны для диагностики, если их не обнаружить на ранней стадии.

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

Более того, тщательная проверка приносит пользу как при разработке, так и в пайплайнах CI/CD.

Во время разработки валидация помогает поддерживать качество и согласованность кода.

Использование команды helm lint

Команда helm lint – это простой способ проверить наши чарты Helm на наличие потенциальных проблем.

Она анализирует структуру и содержимое чарта, выявляя проблемы, которые могут привести к сбоям в развертывании.

Проверка одного чарта

Давайте посмотрим на helm lint в действии, запустив ее на конкретном чарте:

helm lint ./mychart
==> Linting ./mychart
[ERROR] Chart.yaml: version is required
[INFO] Chart.yaml: icon is recommended
Error: 1 chart(s) linted, 1 chart(s) failed

Как видно из нашего вывода:

  • [ERROR] Chart.yaml: version is required – указывает на критическую проблему, которую мы должны исправить
  • [INFO] Chart.yaml: icon is recommended – показывает некритичное предложение по улучшению.

Использование helm lint помогает нам выявлять общие проблемы на ранних этапах разработки.

Это гарантирует, что наши чарты хорошо структурированы и соответствуют лучшим практикам.

Проверка всех графиков в каталоге

Мы можем расширить утилиту helm lint, чтобы проверить все графики в каталоге, включая все подграфики.

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

Предположим, что у нас есть следующая структура каталогов:

charts/
├── chart1
│ ├── Chart.yaml
│ ├── templates/
│ └── ...
├── chart2
│ ├── Chart.yaml
│ ├── templates/
│ └── ...
└── subcharts/
├── subchart1
│ ├── Chart.yaml
│ ├── templates/
│ └── ...
└── subchart2
├── Chart.yaml
├── templates/
└── ...

Мы можем использовать цикл for для запуска helm lint для каждого подкаталога (chart) в каталоге charts:



for chart in charts/*; do helm lint $chart; done
==> Linting charts/chart1
[INFO] Chart.yaml: icon is recommended
1 chart(s) linted, 0 chart(s) failed
==> Linting charts/chart2
[ERROR] Chart.yaml: version is required
[INFO] Chart.yaml: icon is recommended
1 chart(s) linted, 1 chart(s) failed
==> Linting charts/subcharts/subchart1
[INFO] Chart.yaml: icon is recommended
1 chart(s) linted, 0 chart(s) failed
==> Linting charts/subcharts/subchart2
[ERROR] Chart.yaml: version is required
[INFO] Chart.yaml: icon is recommended
1 chart(s) linted, 1 chart(s) failed

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

Следует отметить, что лучшей практикой для линтинга чартов Helm является регулярный запуск helm lint во время разработки.

Мы также должны устранять все ошибки и рассматривать возможность устранения предупреждений.

Кроме того, мы можем интегрировать helm lint в пайплайны CI/CD для автоматизации проверки.

Использование шаблона helm с проверкой Kubernetes

Команда helm template отображает наши шаблоны чартов Helm локально, позволяя нам проверять полученные манифесты Kubernetes.

Объединив это с функцией “драй ран” Kubernetes, мы можем проверять сгенерированные манифесты без их фактического развертывания.

Давайте посмотрим пример:

helm template ./mychart | kubectl apply --dry-run=client -f --
error: error validating “STDIN”: error validating data: ValidationError(Deployment.spec.template.spec.containers[0]): unknown field “imagePullSecrets” in io.k8s.api.core.v1.Container

В нашей команде helm template ./mychart отрисовывает чарт Helm, расположенный в каталоге ./mychart.

Затем kubectl apply -dry-run=client -f – проверяет отрендеренные манифесты на соответствие схемам Kubernetes API без их применения.

Давайте лучше разберем наш пример вывода:

  • ValidationError(Deployment.spec.template.spec.containers[0]) – указывает на ошибку в первой спецификации контейнера в ресурсе Deployment
    неизвестное поле “imagePullSecrets” – показывает, что поле imagePullSecrets размещено неверно
  • Использование шаблона helm с проверкой Kubernetes помогает нам убедиться, что отображаемые манифесты являются корректными ресурсами Kubernetes.

По сравнению с helm lint, helm template with Kubernetes validation выявляет проблемы, которые helm lint может пропустить.

Он также предоставляет подробные сообщения об ошибках из API Kubernetes и гарантирует, что визуализированные манифесты соответствуют стандартам Kubernetes.

Использование kubeconform для проверки схем

kubeconform – это мощный инструмент для проверки манифестов Kubernetes на соответствие их соответствующим JSON-схемам.

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

Базовая валидация с помощью kubeconform

Давайте посмотрим, как можно использовать kubeconform для базовой проверки схем:



helm template ./mychart | kubeconform -strict
/path/to/manifest.yaml - Deployment my-deployment is valid
/path/to/manifest.yaml - Service my-service is valid

Здесь helm template ./mychart рендерит чарт Helm в каталоге ./mychart.

Затем kubeconform -strict проверяет отрисованные манифесты с помощью строгих проверок схем.

Наш пример показывает, что ресурсы Deployment и Service соответствуют ожидаемым определениям схемы.

Работа с CRD с помощью kubeconform

kubeconform также предоставляет дополнительные опции для обработки сложных сценариев, таких как CRDs (Custom Resource Definitions).

Так, если наш чарт включает CRD, мы можем использовать флаг -ignore-missing-schemas, чтобы пропустить проверку для неизвестных схем:



helm template ./mychart | kubeconform -strict -ignore-missing-schemas
/path/to/manifest.yaml - Deployment my-deployment is valid
/path/to/manifest.yaml - CustomResourceDefinition my-crd is ignored (schema missing)
[simterm]
Здесь -ignore-missing-schemas пропускает проверку для CRD или любых типов ресурсов без известной схемы.
Это особенно полезно, когда мы работаем с пользовательскими ресурсами, которые могут не иметь предопределенной схемы в базе данных kubeconform.
Указание версии Kubernetes
Чтобы обеспечить совместимость с определенными версиями Kubernetes, мы также можем использовать флаг -kubernetes-version:
[simterm] $ helm template ./mychart | kubeconform -strict -kubernetes-version 1.18
/path/to/manifest.yaml - Deployment my-deployment is valid
/path/to/manifest.yaml - Service my-service is valid

Здесь -kubernetes-version 1.18 проверяет манифесты на соответствие схемам для Kubernetes версии 1.18.

Примечательно, что для более полного процесса проверки мы можем объединить обработку CRD и спецификацию версии:



helm template ./mychart | kubeconform -strict -ignore-missing-schemas -kubernetes-version 1.18
/path/to/manifest.yaml - Deployment my-deployment is valid
/path/to/manifest.yaml - CustomResourceDefinition my-crd is ignored (schema missing)
/path/to/manifest.yaml - Service my-service is valid
   


Эта команда сочетает строгую проверку схем с пропуском неизвестных схем и указанием версии Kubernetes.


Одним словом, использование kubeconform повышает надежность нашего процесса проверки, гарантируя, что наши чарты Helm генерируют манифесты, соответствующие стандартам Kubernetes.


Проверка с помощью values.schema.json


Хотя базовые методы валидации, такие как helm lint и kubeconform, покрывают большинство случаев использования, продвинутые методы валидации могут помочь нам выявить еще более сложные проблемы.


Одним из таких методов является values.schema.json.


Файл values.schema.json позволяет нам наложить структуру на наш файл values.yaml, гарантируя, что предоставленные пользователем значения соответствуют предопределенной схеме.


Определение схемы


В файле values.schema.json содержатся подробные спецификации для нашего файла values.yaml.


Это очень важно для поддержания согласованности и корректности.


Давайте посмотрим пример схемы:


{
  "$schema": "https://json-schema.org/draft-07/schema#",
  "properties": {
    "image": {
      "description": "Container Image",
      "properties": {
        "repo": {
          "type": "string"
        },
        "tag": {
          "type": "string"
        }
      },
      "type": "object"
    },
    "name": {
      "description": "Service name",
      "type": "string"
    },
    "port": {
      "description": "Port",
      "minimum": 0,
      "type": "integer"
    },
    "protocol": {
      "type": "string"
    }
  },
  "required": [
    "protocol",
    "port"
  ],
  "title": "Values",
  "type": "object"
}



В нашем примере схемы определены свойства образа, имени, порта и протокола.


В ней также указано, что протокол и порт являются обязательными полями.


Кроме того, она гарантирует, что repo и tag являются строками, port – целым числом, и предоставляет описания для каждого свойства.


Теперь, когда мы используем такие команды, как helm install, helm upgrade, helm lint или helm template, Helm автоматически проверяет файл values.yaml на соответствие этой схеме.


Вложенные свойства и ограничения


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


{
  "$schema": "https://json-schema.org/draft-07/schema#",
  "properties": {
    "image": {
      "description": "Container Image",
      "properties": {
        "repo": {
          "type": "string"
        },
        "tag": {
          "type": "string"
        },
        "pullPolicy": {
          "type": "string",
          "enum": ["Always", "IfNotPresent", "Never"]
        }
      },
      "type": "object",
      "required": ["repo", "tag"]
    },
    "resources": {
      "description": "Resource requests and limits",
      "properties": {
        "requests": {
          "properties": {
            "cpu": {
              "type": "string"
            },
            "memory": {
              "type": "string"
            }
          },
          "type": "object",
          "required": ["cpu", "memory"]
        },
        "limits": {
          "properties": {
            "cpu": {
              "type": "string"
            },
            "memory": {
              "type": "string"
            }
          },
          "type": "object"
        }
      },
      "type": "object"
    },
    "name": {
      "description": "Service name",
      "type": "string"
    },
    "port": {
      "description": "Port",
      "minimum": 0,
      "type": "integer"
    },
    "protocol": {
      "type": "string"
    }
  },
  "required": [
    "protocol",
    "port",
    "name"
  ],
  "title": "Values",
  "type": "object"
}



Давайте лучше разберемся в этой схеме:


    

  • Вложенные свойства: Добавляет pullPolicy под образа и ресурсы с вложенными запросами и ограничениями
    • 

  • Перечисления: Поле pullPolicy ограничено определенными значениями – Always, IfNotPresent или Never.
    • 

  • Дополнительные требуемые поля: репо и тег для образа, а также cpu и память для запросов являются обязательными.
    • 



Как и в предыдущем случае, такие команды, как helm install, helm upgrade, helm lint или helm template, проверят файл values.yaml на соответствие этой схеме.


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


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


Заключение


В этой статье мы рассмотрели различные методы и лучшие практики проверки чартов Helm.


Мы обсудили такие инструменты, как helm lint, helm template и kubeconform, которые позволяют выявлять ошибки на ранней стадии и гарантировать, что наши диаграммы генерируют корректные манифесты Kubernetes.


Мы также рассмотрели продвинутые техники, такие как использование values.schema.json и пользовательских скриптов проверки для дополнительных уровней проверки в сложных сценариях.


Интегрировав эти шаги по проверке в рабочие процессы разработки и пайплайны CI/CD, мы сможем повысить надежность и стабильность наших приложений и развертываний Kubernetes.


см .также:



 


    









devops DevSecOps Kubernetes 




    

		
        		            







    


Пожалуйста, не спамьте и никого не оскорбляйте.

Это поле для комментариев, а не спамбокс. 

Рекламные ссылки не индексируются!





    	

		
Добавить комментарий