Использование Helm и Kubernetes

1. Обзор

Helm — это менеджер пакетов для приложений Kubernetes . В этом руководстве мы разберемся с основами Helm и узнаем, как они образуют мощный инструмент для работы с ресурсами Kubernetes.

За последние годы Kubernetes значительно вырос, как и поддерживающая его экосистема. Недавно Helm получил статус выпускника от Cloud Native Computing Foundation (CNCF) , что свидетельствует о его растущей популярности среди пользователей Kubernetes.

2. Фон

Хотя эти термины довольно распространены в наши дни, особенно среди тех, кто работает с облачными технологиями, давайте быстро пройдемся по ним для тех, кто не знает:

1. Контейнер : Контейнер относится к виртуализации на уровне операционной системы . Несколько контейнеров запускаются в операционной системе в изолированных пользовательских пространствах. Программы, работающие в контейнере, имеют доступ только к ресурсам, назначенным контейнеру.
2. Docker : Docker — популярная программа для создания и запуска контейнеров . Он поставляется с Docker Daemon, основной программой, управляющей контейнерами. Docker Daemon предлагает доступ к своим функциям через Docker Engine API, используемый интерфейсом командной строки Docker (CLI). Пожалуйста, обратитесь к этой статье для более подробного описания Docker .
3. Kubernetes : Kubernetes — популярная программа для оркестровки контейнеров . Хотя он предназначен для работы с разными контейнерами, чаще всего используется Docker. Он предлагает широкий выбор функций, включая автоматизацию развертывания, масштабирование и операции в кластере хостов. В этой статье есть отличное освещение Kubernetes для дальнейшего использования .

3. Архитектура шлема

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

Helm 2 был в основном основан на клиент-серверной архитектуре, состоящей из клиента и сервера в кластере:

• Tiller Server: Helm управляет приложением Kubernetes через Tiller Server , установленный в кластере Kubernetes. Tiller взаимодействует с API-сервером Kubernetes для установки, обновления, запроса и удаления ресурсов Kubernetes.
• Клиент Helm: Helm предоставляет пользователям интерфейс командной строки для работы с диаграммами Helm . Он отвечает за взаимодействие с сервером Tiller для выполнения различных операций, таких как установка, обновление и диаграммы отката.

Helm 3 перешел на полностью клиентскую архитектуру , где сервер в кластере был удален:

Как мы видим, клиент в Helm 3 работает почти так же, но взаимодействует напрямую с API-сервером Kubernetes, а не с сервером Tiller. Этот шаг упростил архитектуру Helm и позволил использовать безопасность пользовательского кластера Kubernetes.

4. Хелм-чарты, релизы и репозитории

Helm управляет пакетами ресурсов Kubernetes через Charts. Графики — это, по сути, формат упаковки для Helm. Инфраструктура диаграммы также претерпела некоторые изменения в Helm 3 по сравнению с Helm 2.

Вскоре мы увидим больше о диаграммах и изменениях в Helm 3, когда мы их создадим. Но на данный момент диаграмма — это не что иное, как набор информации, необходимой для создания приложения Kubernetes с учетом кластера Kubernetes:

• Диаграмма — это набор файлов, организованных в определенной структуре каталогов.
• Информация о конфигурации, связанная с диаграммой, управляется в конфигурации
• Наконец, работающий экземпляр графика с определенной конфигурацией называется релизом.

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

Helm отслеживает установленный чарт в кластере Kubernetes с помощью релизов . Это позволяет нам устанавливать одну диаграмму несколько раз с разными выпусками в кластере. До Helm 2 релизы хранились как ConfigMaps или Secrets в кластере в пространстве имен Tiller. Начиная с Helm 3, релизы хранятся как секреты по умолчанию непосредственно в пространстве имен релиза.

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

5. Предпосылки

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

Во-первых, для начала работы с Helm нам нужен кластер Kubernetes. В этом руководстве мы будем использовать Minikube , который предлагает отличный способ локальной работы с кластером Kubernetes с одним узлом . В Windows теперь можно использовать Hyper-V в качестве собственного гипервизора для запуска Minikube. Обратитесь к этой статье, чтобы более подробно разобраться в настройке Minikube .

Часто рекомендуется установить наиболее совместимую версию Kubernetes , поддерживаемую Helm . Мы также должны установить и настроить инструмент командной строки Kubernetes kubectl, который позволит нам эффективно работать с нашим кластером.

И нам понадобится базовое приложение для управления в кластере Kubernetes. В этом руководстве мы будем использовать простое приложение Spring Boot, упакованное в виде контейнера Docker. Более подробное описание того, как упаковать такое приложение в качестве Docker-контейнера, можно найти в этой статье .

6. Установка шлема

Существует несколько способов установки Helm, которые подробно описаны на официальной странице установки Helm . Самый быстрый способ установить helm в Windows — использовать Chocolaty , менеджер пакетов для платформ Windows.

Используя Chocolaty, установить Helm можно с помощью простой однострочной команды:

choco install kubernetes-helm

Это устанавливает клиент Helm локально. Это также предоставляет нам инструмент командной строки Helm, который мы будем использовать для работы с Helm в этом руководстве.

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

kubectl cluster-info

Теперь, до Helm 2, приходилось еще и инициализировать Helm. Это эффективно устанавливает сервер Tiller и настраивает состояние Helm в кластере Kubernetes. Мы могли бы инициализировать Helm через интерфейс командной строки Helm с помощью команды:

helm init

Но, начиная с Helm 3, поскольку сервера Tiller больше нет, инициализировать Helm не нужно . Фактически, эта команда была удалена. Следовательно, состояние Helm создается автоматически, когда это необходимо.

7. Разработка нашей первой диаграммы

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

7.1. Создание диаграммы

Первым шагом, конечно же, будет создание новой диаграммы с заданным именем:

helm create hello-world

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

Давайте быстро посмотрим созданную для нас структуру каталогов:

hello-world /
  Chart.yaml
  values.yaml
  templates /
  charts /
  .helmignore

Давайте разберемся в актуальности этих созданных для нас файлов и папок:

• Chart.yaml : это основной файл, содержащий описание нашего графика.
• values.yaml : это файл, содержащий значения по умолчанию для нашей диаграммы.
• templates : это каталог, в котором ресурсы Kubernetes определены как шаблоны.
• диаграммы : это необязательный каталог, который может содержать вложенные диаграммы.
• .helmignore : здесь мы можем определить шаблоны, которые следует игнорировать при упаковке (концепция аналогична .gitignore).

7.2. Создание шаблона

Если мы заглянем внутрь каталога шаблонов, то заметим, что для нас уже создано несколько шаблонов для общих ресурсов Kubernetes :

hello-world /
  templates /
    deployment.yaml
    service.yaml
    ingress.yaml
    ......

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

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

Давайте отредактируем файл deployment.yaml внутри каталога шаблонов , чтобы он выглядел следующим образом:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "hello-world.fullname" . }}
  labels:
    app.kubernetes.io/name: {{ include "hello-world.name" . }}
    helm.sh/chart: {{ include "hello-world.chart" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ include "hello-world.name" . }}
      app.kubernetes.io/instance: {{ .Release.Name }}
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ include "hello-world.name" . }}
        app.kubernetes.io/instance: {{ .Release.Name }}
    spec:
      containers:
        - name: {{ .Chart.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP

Аналогичным образом отредактируем файл service.yaml , чтобы он выглядел так:

apiVersion: v1
kind: Service
metadata:
  name: {{ include "hello-world.fullname" . }}
  labels:
    app.kubernetes.io/name: {{ include "hello-world.name" . }}
    helm.sh/chart: {{ include "hello-world.chart" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
spec:
  type: {{ .Values.service.type }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: {{ include "hello-world.name" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}

Теперь, когда мы знаем Kubernetes, эти файлы шаблонов выглядят довольно знакомо, если не считать некоторых странностей. Обратите внимание на свободное использование текста в двойных скобках {{}}. Это так называемая директива шаблона.

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

7.3. Предоставление ценностей

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

В Helm доступно множество таких объектов, таких как Release, Values, Chart и Files.

Мы можем использовать файл values.yaml в нашей диаграмме для передачи значений в механизм рендеринга шаблонов через встроенные значения объектов. Давайте изменим values.yaml , чтобы он выглядел так:

replicaCount: 1
image:
  repository: "hello-world"
  tag: "1.0"
  pullPolicy: IfNotPresent
service:
  type: NodePort
  port: 80

Однако обратите внимание, как доступ к этим значениям в шаблонах осуществляется с помощью точек, разделяющих пространства имен. Мы использовали репозиторий изображений и тег «hello-world» и «1.0», это должно соответствовать тегу образа докера, который мы создали для нашего приложения Spring Boot.

8. Управление диаграммами

Теперь, когда все сделано, мы готовы поиграть с нашей диаграммой. Давайте посмотрим, какие различные команды доступны в Helm CLI, чтобы сделать это увлекательным! Обратите внимание, что мы рассмотрим только некоторые команды, доступные в Helm.

8.1. Шлем Линт

Во-первых, это простая команда, которая выбирает путь к диаграмме и запускает ряд тестов, чтобы убедиться, что диаграмма правильно сформирована:

helm lint ./hello-world
==> Linting ./hello-world
1 chart(s) linted, no failures

В выходных данных отображается результат линтинга с обнаруженными им проблемами.

8.2. Шаблон шлема

Кроме того, у нас есть эта команда для локального рендеринга шаблона для быстрой обратной связи:

helm template ./hello-world
---
# Source: hello-world/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: release-name-hello-world
  labels:
    app.kubernetes.io/name: hello-world
    helm.sh/chart: hello-world-0.1.0
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/managed-by: Tiller
spec:
  type: NodePort
  ports:
    - port: 80
      targetPort: http
      protocol: TCP
      name: http
  selector:
    app.kubernetes.io/name: hello-world
    app.kubernetes.io/instance: release-name

---
# Source: hello-world/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: release-name-hello-world
  labels:
    app.kubernetes.io/name: hello-world
    helm.sh/chart: hello-world-0.1.0
    app.kubernetes.io/instance: release-name
    app.kubernetes.io/managed-by: Tiller
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: hello-world
      app.kubernetes.io/instance: release-name
  template:
    metadata:
      labels:
        app.kubernetes.io/name: hello-world
        app.kubernetes.io/instance: release-name
    spec:
      containers:
        - name: hello-world
          image: "hello-world:1.0"
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP

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

8.3. Установка шлема

Наконец, убедившись, что диаграмма в порядке, мы можем запустить эту команду, чтобы установить диаграмму в кластер Kubernetes:

helm install --name hello-world ./hello-world
NAME:   hello-world
LAST DEPLOYED: Mon Feb 25 15:29:59 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Service
NAME         TYPE      CLUSTER-IP     EXTERNAL-IP  PORT(S)       AGE
hello-world  NodePort  10.110.63.169  <none>       80:30439/TCP  1s

==> v1/Deployment
NAME         DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
hello-world  1        0        0           0          1s

==> v1/Pod(related)
NAME                          READY  STATUS   RESTARTS  AGE
hello-world-7758b9cdf8-cs798  0/1    Pending  0         0s

Эта команда также предоставляет несколько параметров для переопределения значений в диаграмме. Обратите внимание, что мы назвали выпуск этого графика флагом –name. Команда отвечает сводкой ресурсов Kubernetes, созданных в процессе.

8.4. Шлем получить

Теперь мы хотели бы увидеть, какие графики установлены в каком выпуске. Эта команда позволяет нам запрашивать названные выпуски:

helm ls --all
NAME            REVISION        UPDATED                         STATUS          CHART               APP VERSION NAMESPACE
hello-world     1               Mon Feb 25 15:29:59 2019        DEPLOYED        hello-world-0.1.0   1.0         default

Для этой команды доступно несколько подкоманд для получения расширенной информации. К ним относятся «Все», «Крюки», «Манифест», «Примечания» и «Значения».

8.5. Улучшение шлема

Что, если мы изменили нашу диаграмму и нам нужно установить обновленную версию? Эта команда помогает нам обновить выпуск до указанной или текущей версии диаграммы или конфигурации:

helm upgrade hello-world ./hello-world
Release "hello-world" has been upgraded. Happy Helming!
LAST DEPLOYED: Mon Feb 25 15:36:04 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Service
NAME         TYPE      CLUSTER-IP     EXTERNAL-IP  PORT(S)       AGE
hello-world  NodePort  10.110.63.169  <none>       80:30439/TCP  6m5s

==> v1/Deployment
NAME         DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
hello-world  1        1        1           1          6m5s

==> v1/Pod(related)
NAME                          READY  STATUS   RESTARTS  AGE
hello-world-7758b9cdf8-cs798  1/1    Running  0         6m4s

Обратите внимание, что в Helm 3 при обновлении выпуска используется трехсторонний стратегический патч слияния. Здесь он учитывает старый манифест, рабочее состояние кластера и новое при создании исправления. В Helm 2 использовался двусторонний стратегический патч слияния, который отбрасывал изменения, примененные к кластеру за пределами Helm.

8.6. Откат руля

Всегда может случиться так, что релиз пошёл не так, и его нужно вернуть. Это команда для отката выпуска до предыдущих версий:

helm rollback hello-world 1
Rollback was a success! Happy Helming!

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

8.7. Шлем Удалить

Хотя это менее вероятно, мы можем захотеть полностью удалить выпуск. Мы можем использовать эту команду для удаления выпуска из Kubernetes:

helm uninstall hello-world
release "hello-world" deleted

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

9. Распространение диаграмм

Хотя шаблоны — это мощный инструмент, который Helm привносит в мир управления ресурсами Kubernetes, это не единственное преимущество использования Helm. Как мы видели в предыдущем разделе, Helm выступает в качестве менеджера пакетов для приложения Kubernetes и позволяет довольно легко устанавливать, запрашивать, обновлять и удалять выпуски.

В дополнение к этому мы также можем использовать Helm для упаковки, публикации и извлечения приложений Kubernetes в виде архивов диаграмм. Мы также можем использовать для этого Helm CLI, так как он предлагает несколько команд для выполнения этих действий. Как и прежде, мы не будем рассматривать все доступные команды.

9.1. Пакет «Шлем»

Во-первых, нам нужно упаковать созданные нами диаграммы, чтобы иметь возможность их распространять. Это команда для создания версионного архивного файла графика:

helm package ./hello-world
Successfully packaged chart and saved it to: \hello-world\hello-world-0.1.0.tgz

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

9.2. Хелм Репо

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

Мы можем создать репозиторий git и использовать его в качестве репозитория диаграмм. Единственное требование — наличие файла index.yaml .

Мы можем создать index.yaml для нашего репозитория диаграмм:

helm repo index my-repo/ --url https://<username>.github.io/my-repo

Это сгенерирует файл index.yaml , который мы должны отправить в репозиторий вместе с архивами диаграмм.

После успешного создания репозитория диаграмм мы можем удаленно добавить этот репозиторий:

helm repo add my-repo https://my-pages.github.io/my-repo

Теперь мы должны иметь возможность напрямую устанавливать графики из нашего репозитория:

helm install my-repo/hello-world --name=hello-world

Для работы с репозиториями графиков доступно несколько команд.

9.3. Поиск руля

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

helm search repo <KEYWORD>

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

10. Миграция с Helm 2 на Helm 3

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

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

Но есть несколько вариантов для проекта, который использует Helm 2 и хочет перейти на Helm 3. Во-первых, мы можем использовать Helm 2 и Helm 3 для управления одним и тем же кластером и медленно сливать выпуски Helm 2, используя Helm 3 для новых. релизы. В качестве альтернативы мы можем решить управлять выпусками Helm 2 с помощью Helm 3. Хотя это может быть сложно, Helm предоставляет плагин для обработки этого типа миграции .

11. Заключение

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

Затем мы рассмотрели несколько команд, доступных как часть Helm CLI, для управления приложением Kubernetes как пакетом Helm. Наконец, мы обсудили варианты распространения пакетов Helm через репозитории. В процессе мы увидели изменения, которые были сделаны в рамках Helm 3 по сравнению с Helm 2.