22.09.2019 12:27
aigrychev 11 2800 Источник
Прим. перев.: Повышенный интерес к «пакетному менеджеру Kubernetes» — Helm, — что наблюдается в последнее время, легко объяснить. В активной стадии — причём уже не только разработки, но и релизов — находится долгожданное крупное обновление Helm v3, о котором мы уже писали. Его последняя бета-версия — третья по счёту — вышла в начале сентября. А совсем недавно прошло довольно крупное (для столь специализированного Open Source- проекта) мероприятие, впечатлениями с которого и делятся его посетители из компании CloudARK, предлагающей iPaaS (integration platform as a service) для Kubernetes.


Оригинальное фото взято из Flickr-аккаунта CNCF

На прошлой неделе в Амстердаме прошел Helm Summit. На нем собрались около 150 энтузиастов, представляющих различных пользователей и поставщиков услуг по Kubernetes. Вот пять ключевых моментов с этого мероприятия.

1. В Helm 3.0 — лучшая безопасность, поддержка CRD и некоторые ломающие привычный подход изменения


В саммите принимали участие некоторые из ключевых членов основной команды разработчиков Helm. Из их выступлений и общения в кулуарах стало понятно, что Helm 3.0 станет важной вехой для проекта. Многие из вас, вероятно, уже слышали, что в третьей версии не будет Tiller — серверного компонента Helm. (Прим. перев.: Подробнее об этом можно почитать в этой статье.) В Helm 3.0 появятся и другие важные нововведения — например, более пристальный контроль безопасности и лучшая поддержка Custom Resource Definitions (CRDs). Вот три ключевых аспекта, которые особенно запомнились:

  • В области безопасности набор предварительно настроенных разрешений для пользователей по умолчанию будет минимальным. В отличие от Tiller'а, автоматом получавшего права администратора на весь кластер, в Helm 3.0 придется вручную наделять привилегиями пользовательские (User) и служебные (Service) учетные записи, предназначенные для работы с Helm. Такая перемена гарантирует осознанное принятие решений администраторами о безопасности своих кластеров.
  • Второе важное изменение — это расширенная поддержка CRD. В нынешней версии Helm установка CRD осуществляется через хук (hook) crd-install, определенный как аннотация. Однако не все разработчики CRD и операторов его используют. Это делает чарты Helm уязвимыми перед ошибками установки, поскольку для правильной установки чартов необходимо, чтобы CRD ставились перед манифестами Custom Resource. В Helm 3.0 поддержка CRD выйдет на новый уровень. В каталоге chаrts появится подкаталог crd. Пользователю будет достаточно сложить все YAML-файлы CRD в эту директорию. Helm обработает ее перед установкой остальных частей чарта. Подобный порядок действий будет гарантировать установку CRD перед установкой манифестов Custom Resource.
  • Серьезные изменения затронут работу с CLI. Например, сейчас в процессе установки чарта генерируется случайное имя релиза, если оно не указано в качестве входного параметра. В Helm 3.0 ситуация будет обратная: параметр с именем станет обязательным. Чтобы сохранить случайное именование релизов, потребуется указывать специальный флаг при вводе команды.

2. Консолидация cloud native-артефактов


Несколько сессий были посвящены проблемам хранения Helm-чартов. Эти сессии вел Josh Dolitsky — автор ChartMuseum. Он представил проблему, существующие решения и рассказал об общих веяниях в этом пространстве. Основной вывод состоит в том, что работа с различными артефактами, с которыми приходится иметь дело в подходе cloud-native (образами Docker, чартами Helm, патч-файлами Kustomize), должна вестись единообразно.

Обеспечить хранение всех этих артефактов в едином реестре призван проект ORAS — OCI Registry as Storage. Для пользователей Kubernetes это определенно шаг в правильном направлении, поскольку он позволит консолидировать различные артефакты в одном реестре, попутно обеспечив поддержку таких вещей, как разделение реестра, контроль доступа и т.п.

3. Helm и операторы


Несколько докладчиков затронули в своих выступлениях тему пользовательских контроллеров и операторов. В выступлении CloudARK основное внимание было уделено лучшим практикам при создании Helm-чартов для операторов. Команда Red Hat рассказала об операторах и Operator Hub.

Представители Workday, Weaveworks и University of Notre Dame в своих выступлениях обсудили «родной для Kubernetes» подход к непрерывному согласованию релизов на основе Helm-чартов в кластере с помощью процесса, называемого GitOps. (Прим. перев.: Подробнее о GitOps читайте здесь.)

Ключевым выводом всех этих выступлений стало то, что Helm и операторы хорошо дополняют друг друга. В то время как первый (Helm) фокусируется на шаблонизации и простоте управления артефактами, вторые (операторы) концентрируются на управлении задачами Day-2 (т.е. на стадии жизненного цикла системы, когда та начинает приносить плоды ее создателям — прим. перев.) для стороннего программного обеспечения, такого как реляционные/нереляционные базы данных, работающие в кластере Kubernetes.

4. Проблемы управления Helm-чартами


Когда речь заходит о крупных корпоративных приложениях, одного Helm-чарта недостаточно. Требуются несколько чартов. Презентация GitLab стала настоящим открытием в этом смысле. У них множество чартов, при этом средний размер чарта также достаточно велик (несколько тысяч строк). Управление всеми этими чартами само по себе является непростой задачей.

Было два интересных выступления, посвященных различным аспектам этой проблемы. В одном команда IBM представила свой внутренний инструмент, упрощающий поиск Helm-чартов по различным критериям. Они сосредоточились на решении проблемы DevOps-инженеров, вынужденных отбирать и устанавливать чарты в своих кластерах. В другом — команда Replicated рассказала о попытке решить проблему управления правками Helm-чартов без создания копий или форков. Суть их подхода в том, чтобы отделить базовый Helm-чарт, а пользовательские Helm-чарты создавать, позаимствовав идею kustomize с патч-файлами. В будущем мы можем стать свидетелями бурной деятельности в этом направлении по мере того, как различные провайдеры будут концентрироваться на различных аспектах Helm-чартов, влияющих на управление ими. Например, мы в CloudARK фокусируемся на Helm-чартах операторов, которые получают специальные аннотации platform-as-code для облегчения обнаружения и повышения простоты использования Custom Resources.

5. Гостеприимное сообщество


Разработчики Helm'а и ключевые члены сообщества оказались весьма приветливыми людьми. Они были открыты и доступны для любых обсуждений и вопросов, таких как сроки выхода, мысли о Helm'е и kustomize'е, совместное проведение мероприятий с KubeCon и т.п.

Также они рассказали о процессе участия в разработке Helm'а. Он не показался слишком сложным. Проект Helm пока еще не принял процесс KEP (Kubernetes Enhancement Proposal). Впрочем, это может измениться после того, как завершится стадия его инкубации.

CloudARK на саммите Helm


Наше выступление на саммите было посвящено принципам и лучшим практикам создания Helm-чартов для операторов. Мы предлагаем iPaaS, который позволяет DevOps-командам собирать свои собственные стеки платформы Kubernetes без какой-либо привязки с провайдеру Kubernetes или проприетарным интерфейсам. Необходимые CRD/операторы упаковываются в виде Helm-чартов с особым акцентом на совместимость Custom Resources от различных операторов.

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

Амстердам




Место проведения конференции может похвастаться живописным видом на один из многочисленных каналов Амстердама.

Заключение


Helm стоит на пороге превращения в CNCF-проект высшего уровня. За последние несколько лет он стал более зрелым, обрел крепкое сообщество и высокую популярность. Если вы еще не используете его — попробуйте. Он предлагает один из простейших способов шаблонизации и управления артефактами Kubernetes. У тех же, кто его уже активно использует, Helm 3.0 должен развеять многие опасения, связанные с безопасностью, и обеспечить явную поддержку расширяемости Kubernetes с помощью CRD.

P.S. от переводчика


Другие впечатления о прошедшем Helm Summit и его докладам можно найти в Twitter по тегу #HelmSummit.

Читайте также в нашем блоге:

Комментарии (11)


  1. VolCh
    22.09.2019 18:58
    #20654881

    А кто-то из тех, кто использует Helm для деплоя единственной системы из пары десятков контейнеров в выделенный для неё кластер в разных окружения от дев до прод, использует его возможности менеджера пакетов, а не шаблонизатора? Я пока даже придумать особо не смог для таких кейсов.


    1. gecube
      23.09.2019 00:46
      #20655987

      Поясните, пожалуйста, мысль.
      У меня пока складывается ощущение, что


      1. Хельм хорош, чтобы попробовать в кластере какой-то софт. Так же как и докер хорош именно для запуска некоей софтины в изолированном окружении в тестовом контуре.


      2. Мы деплоим в куб либо ручками, либо используя хельм как темплейтер и его выхлоп на kubectl apply.


      3. Фундаментальные две проблемы — что-то более сложное, чем получение и применение куб манифеста, например, роллинг релиз некоего продукта или очистку устаревших ресурсов — насколько я понял, хельм не решает.



      1. aigrychev Автор
        23.09.2019 03:25
        #20656131

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

        Чем вас не устраивает helm для выката и в другие контуры, если не секрет?


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

        Вы используете исключительно kubectl или у вас есть ещё дополнительные инструменты?


        роллинг релиз некоего продукта

        Может быть я неправильно вас понимаю, но, а как иначе?
        В helm даже сущность была новая введена — release. При первой инсталляции чарта создаётся релиз, а при последующих он обновляется.


        очистку устаревших ресурсов

        А что вы подразумеваете под устаревшими ресурсами и почему эта задача не может быть решена командой helm delete и, при необходимости, дополнена соответствующими хуками?


      1. VolCh
        23.09.2019 16:06
        #20658911

        В целом я имел в виду активное использование как чартов из публичных репозиториев, так и создание своих репозиториев чартов на уровне организации/проекта в рамках реальных проектов. Пока встречался только с подходом таким: папка деплоя проекта c подпапкой charts, где описаны все-все темплейты для разворачивания, то есть ни одного ни то что стороннего чарта, а даже ни одного обособленного от проекта (кроме вложенного charts), хотя в теории что-то можно было бы и сгруппировать, например, стандартный для проекта подход для подов с реверс-прокси/веб-сервером со статикой перед апп-сервером на каждый сервис, только некоторые значения меняя


        1. aigrychev Автор
          23.09.2019 18:31
          #20659991

          Chart repository — это то, кмк, что позволяет Helm обладать таким большим сообществом и оставаться всё ещё на плаву, несмотря на местами спорные приоритеты в развитии продукта.


          В Helm хорошо подошли к управлению зависимостями:


          dependencies:
- name: subchart1
  repository: http://localhost:10191
  version: 0.1.0
  condition: subchart1.enabled,global.subchart1.enabled
  tags:
  - front-end
  - subchart1

- name: subchart2
  repository: http://localhost:10191
  version: 0.1.0
  condition: subchart2.enabled,global.subchart2.enabled
  tags:
  - back-end
  - subchart2

          Condition и tags отличная альтернатива для организации выката в различные окружения велосипедам на go шаблонах. К примеру, в тестовом окружение поднимаем базу данных и очередь в кластере, а в проде используем внешние — две/три дополнительные опции в .gitlab-ci.yml и чистые чарт шаблоны.


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


    1. aigrychev Автор
      23.09.2019 02:15
      #20656085

      Если правильно понял вопрос, то речь идёт об использовании helm исключительно для генерации манифестов:


      helm template . | kubectl apply --wait -f -

      При использовании helm становится удобным сопровождение инсталляций. Помимо таких базовых операций, как установка, обновление и удаление, вдобавок доступен откат до определённой версии командой helm rollback (полезно, к примеру, при неудавшемся выкате).


      Всегда есть возможность посмотреть какие релизы установлены в кластере (helm list), а также посмотреть текущее состояние ресурсов конкретного релиза (helm status).


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


      1. gecube
        23.09.2019 08:10
        #20656345

        1. Хуки — будут работать только с тиллером. Без него — я попросту не понимаю, кто их будет выполнять. Про тиллер уже только ленивый не высказался


        2. Так как насчёт канареечного релиза? Без простыней в 100500 команд в пайплайне снаружи куба (если писать такое, то очевидно, что тиллер тоже не нужен, но выглядит как закат солнца вручную). Так же очевидно, что если есть миграция бд, то хельм, ну, никак не сделает ее из блокирующей бд в неблокирующую
          Виноват — неудачно ляпнул про роллинг — куб сам умеет в него с определенными ограничениями.
          Мое мнение — тип релиза должен описываться в некоем crd внутри кластера. Пока видится, что наиболее близко к этому подошли service mesh типа istio.


        3. Про паттерны. Если в ПО есть ломающее изменение (например, переход от v1 api к v2 api и это именно api для внешних клиентов), то есть большой соблазн оформить его как не два релиза одного пакета, а как два разных пакета. Интересно — как коллеги в таких случаях действуют.



        1. SlavniyTeo
          23.09.2019 10:14
          #20656733

          1. Tiller не так страшен, если его спрятать. Я, к примеру, использую следующий скрипт:

          helm wrapper

          Disclaimer: скрипт пишу без проверки, чтобы передать суть


          #!/bin/bash

# здесь я упрощаю, на самом деле пространство имен берется из ~/.kube/config
TILLER_NAMESPACE=test /usr/local/bin/tiller --storage secret & 
TILLER_PID="$!"

# 44134 -- порт по-умолчанию
HELM_HOST=localhost:44134 /usr/local/bin/helm "$@"

kill "$TILLER_PID"


        1. aigrychev Автор
          23.09.2019 11:07
          #20657031
          +1

          Хуки

          — это исключительно про порядок. Вы с тем же успехом можете выкатывать *хуки, используя kubectl apply, дожидаться их завершения и выполнять следующий шаг (в Helm поддерживается около десяти типов хуков и организация подобного на bash выглядит не очень перспективным занятием). В Helm 2 tiller используется для установки ресурсов, в Helm 3 все функции выполняет клиент, поэтому мне совсем непонятно негодование будут работать только с тиллером.


          Helm 2 можно использовать без tiller в кластере, если это для вас проблема. Этой теме посвящено много статей, они сгруппированы таким термином как tillerless (по сути всё сводится к тому, что описал коллега в первом комментарии). Мы пошли дальше и встроили helm в наше собственное решение, werf.


          Канареечный релиз

          У вас нет никаких ограничений при построенние процесса выката на основе helm и istio хороший тому пример.


          Если есть миграция бд, то хельм, ну, никак не сделает ее из блокирующей бд в неблокирующую

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


      1. VolCh
        23.09.2019 16:08
        #20658921

        Получается не точно выразился. Имеется в виду использование механизма шаблонизации и релизов, но без использования зависимостей


        1. aigrychev Автор
          23.09.2019 18:48
          #20660075

          Это во многом зависит от проектов. Большинство web-студий используют единный стек технологий для всех своих продуктов, поэтому им уместно свести настройку выката к описанию файла с настройками, values.yaml, для своего или официального чарта:


          helm install --name my-release -f values.yaml stable/drupal