Пять главных итогов Helm Summit 2019 в Амстердаме

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

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

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

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

В саммите принимали участие некоторые из ключевых членов основной команды разработчиков Helm. Из их выступлений и общения в кулуарах стало понятно, что Helm 3.0 станет важной вехой для проекта. Многие из вас, вероятно, уже слышали, что в третьей версии не будет Tiller — серверного компонента Helm. (Прим. перев.: Подробнее об этом можно почитать в этой статье ^[1].) В 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 ^[5] — автор ChartMuseum ^[6]. Он представил проблему, существующие решения и рассказал об общих веяниях в этом пространстве. Основной вывод состоит в том, что работа с различными артефактами, с которыми приходится иметь дело в подходе cloud-native (образами Docker, чартами Helm, патч-файлами Kustomize), должна вестись единообразно.

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

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

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

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

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

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

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

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

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

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

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

CloudARK на саммите Helm

Наше выступление ^[18] на саммите было посвящено принципам и лучшим практикам создания 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 ^[19].

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

• «KubeCon Europe 2019: Как мы впервые посетили главное событие по Kubernetes ^[20]»;
• «Знакомство с Helm 3 ^[1]»;
• «Пакетный менеджер для Kubernetes — Helm: прошлое, настоящее, будущее ^[21]»;
• «Трезвый взгляд на Helm 2: „Вот такой, какой есть...“ ^[22]»;
• «Практическое знакомство с пакетным менеджером для Kubernetes — Helm ^[23]».

Автор: Алексей Игрычев

Источник ^[24]