Хабрахабр

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

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


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

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

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), должна вестись единообразно.

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

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

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

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

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

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

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

В одном команда IBM представила свой внутренний инструмент, упрощающий поиск Helm-чартов по различным критериям. Было два интересных выступления, посвященных различным аспектам этой проблемы. В другом — команда Replicated рассказала о попытке решить проблему управления правками Helm-чартов без создания копий или форков. Они сосредоточились на решении проблемы DevOps-инженеров, вынужденных отбирать и устанавливать чарты в своих кластерах. В будущем мы можем стать свидетелями бурной деятельности в этом направлении по мере того, как различные провайдеры будут концентрироваться на различных аспектах Helm-чартов, влияющих на управление ими. Суть их подхода в том, чтобы отделить базовый Helm-чарт, а пользовательские Helm-чарты создавать, позаимствовав идею kustomize с патч-файлами. Например, мы в 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.

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

Показать больше

Похожие публикации

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»