Сравнение Draft, Gitkube, Helm, Ksonnet, Metaparticle и Skaffold

В последнее время Kubernetes пользуется большой популярностью, и разработчики ищут дополнительные способы и методы для развёртывания приложений в кластере этой системы. Даже командная строка kubectl стала восприниматься как инструмент низкого уровня, при этом пользователи продолжают искать ещё более простые способы взаимодействия с кластером. Draft, Gitkube, Helm, Ksonnet, Metaparticle и Skaffold — вот лишь некоторые инструменты, помогающие разработчикам создавать и разворачивать приложения в Kubernetes.

Draft, Gitkube и Skaffold упрощают разработку приложений, позволяя разработчикам как можно быстрее запускать их в кластере Kubernetes. Helm и Ksonnet помогают в процессе развёртывания, т.к. могут определять готовность приложения к отправке, а также управлять выпуском новых версий, обработки различных кластеров и т. д. Metaparticle — необычный инструмент, который позволяет вам в рамках собственного кода работать с любыми форматами (YAML, dockerfile).

Итак, что же использовать в конкретной ситуации?

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

Draft

Простая разработка приложений и их развёртывание в любом кластере Kubernetes.

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

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

Draft не рассчитан на продакшен-развёртывание, поскольку он предназначен исключительно для быстрой разработки приложений под Kubernetes. Однако этот инструмент хорошо интегрируется с Helm, так как использует его для выкладки изменений.

Архитектура

Draft: схема архитектуры

Как видно на схеме, CLI draft является ключевым компонентом. С его помощью определяется язык приложения, используемый в исходном коде, и применяется соответствующий пакет из репозитория. Пакет — это комбинация dockerfile и чарта Helm, которая определяет среду для приложения. Пакеты могут быть определены и добавлены в репозитории. Пользователи могут определять свои собственные пакеты и репозитории, так как они представлены в виде файлов на локальных системах или в репозитории Git.

Любой каталог с исходным кодом может быть развёрнут, если для этого стека есть соответствующий пакет. После того как каталог настроен при помощи команды draft create (добавляет dockerfile, чарт Helm и файл draft.toml), можно использовать команду draft up для создания docker-образа, его передачи в реестр и запуска приложения при помощи чарта Helm (при условии, что Helm установлен). Выполнение этой команды после каждого внесённого изменения приведет к развёртыванию новой сборки.

Кроме того, существует команда draft connect, которая может перенаправлять соединения в локальную систему, а также передавать потоки логов из контейнера. Её можно использовать вместе с командой nginx-Ingress для предоставления доменных имён каждому развёртываемому приложению.

С нуля и до k8s

Ниже приведены шаги, которые позволят запустить приложение, написанное на Python, в кластере k8s при помощи Draft (более подробное руководство есть в этом документе).

Требования:

• кластер k8s (следовательно, интерфейс kubectl);
• Helm CLI;
• Draft CLI;
• Docker;
• репозиторий Docker для хранения образов.

$ helm init
$ draft init
$ draft config set registry docker.io/myusername
$ git clone https://github.com/Azure/draft
$ cd draft/examples/example-python
$ draft create
$ draft up
## edit code
$ draft up

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

• Разработка приложений внутри кластера Kubernetes.
• Используется во «внутреннем цикле разработки» до того, как изменения в коде будут зафиксированы в системе управления версиями.
• Pre-CI: как только разработка с использованием Draft завершилась, применяется концепция непрерывной интеграции и доставки (CI/CD).
• Не подходит для развёртывания на продакшене.

Более подробно здесь.

Gitkube

Создание и развёртывание docker-образов в Kubernetes с помощью git push

Gitkube — это инструмент, с помощью которого можно создавать и развёртывать docker-образы в Kubernetes, используя команду git push. В отличие от Draft, у Gitkube нет интерфейса командной строки, а выполняется он исключительно в кластере.

Любой репозиторий исходного кода с dockerfile можно развернуть с помощью Gitkube. После того как Gitkube установлен и открыт в кластере, разработчик может создать пользовательский ресурс remote, который предоставляет удалённый URL-адрес Git. Теперь можно отправлять изменения на этот адрес, после чего в кластере будет развёрнута kubectl-сборка Docker. Манифесты приложений могут быть созданы с помощью любого инструмента (kubectl, helm и т. д.)

Тут все сосредоточено на установке по типу plug and play и на использовании популярных инструментов (Git и kubectl). Гибкости в отношении развёртываемого репозитория не допускаются. Контекст сборки Docker, путь dockerfile, а также обновляемые деплои можно настраивать.

Аутентификация для выполнения команды git remote основана на открытом ключе SSH. Каждый раз, когда внесённые в код изменения фиксируются и применяются с помощью Git, запускаются процессы сборки и развёртывания.

Архитектура

Gitkube: схема архитектуры

В кластере есть 3 компонента: remote CRD, который определяет, что должно произойти при отправке на удалённый URL; gitkubed, который создаёт Docker-образы и обновляет процесс развёртывания; а также gitkube-контроллер, который отслеживает CRD для настройки gitkubed.

После того как в кластере появились эти объекты, разработчик может создавать свои собственные приложения, используя kubectl. Следующий шаг — создание объекта remote, который сообщает Gitkube, что должно произойти, когда выполняется команда git push в отношении конкретного удалённого адреса. Gitkube записывает удалённый URL обратно в поле объекта remote.

С нуля и до k8s

Требования:

• кластер k8s (kubectl);
• Git;
• Gitkube, установленный в кластере (команда kubectl create ).

Ниже приведены шаги, необходимые для развёртывания приложений в Kubernetes, включая установку Gitkube:

$ git clone https://github.com/hasura/gitkube-example
$ cd gitkube-example
$ kubectl create -f k8s.yaml
$ cat ~/.ssh/id_rsa.pub | awk '$0="  - "$0' >> "remote.yaml"
$ kubectl create -f remote.yaml
$ kubectl get remote example -o json | jq -r '.status.remoteUrl'
$ git remote add example [remoteUrl]
$ git push example master
## edit code
## commit and push

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

• Простое развёртывание с использованием Git (без сборки Docker).
• Разработка приложений на Kubernetes.
• Во время разработки текущую ветку (WIP, work in progress) можно «пушить» множество раз, чтобы быстро получить результаты.

→ Более подробно здесь

Helm

Менеджер пакетов для Kubernetes

Инструмент Helm, как и говорится в описании, позволяет управлять приложениями на Kubernetes с помощью чартов. Helm занимается созданием манифестов Kubernetes и управлением их версиями, обеспечивая возможность отката для любого объекта (а не только для развёртываний). Чарты могут включать деплой, службы, интерфейсы ConfigMap и т. д. Они также поддерживают применение шаблонов, чтобы переменные можно было легко изменить. Чарты можно использовать для сложных приложений с множеством зависимостей.

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

Архитектура

Helm: схема архитектуры

Сначала рассмотрим сами чарты. Как упоминалось ранее, чарт — это набор информации, необходимой для создания экземпляра приложения Kubernetes. Он может содержать деплой, службы, интерфейсы ConfigMap, плагины Secret, контроллер ingress и т. д. Все они определяются как файлы YAML, которые, в свою очередь, являются шаблонами. Разработчики могут также определить зависимость одних чартов от других или включать одни чарты в состав других. Чарты могут быть опубликованы или объединены в репозиторий чартов.

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

Tiller — это компонент, выполняемый в кластере, который обменивается данными с сервером k8s API для создания и управления реальными объектами. Он также воспроизводит чарты для сборки выпуска. Когда разработчик выполняет команду helm install <chart-name>, клиент связывается с сервером и сообщает имя чарта. После этого Tiller находит чарт, создаёт шаблон и разворачивает его в кластере.

Helm не обрабатывает исходный код. Для создания образа потребуется любая система CI/CD, после чего можно использовать Helm для развёртывания.

С нуля и до k8s

Требования:

• кластер k8s;
• Helm CLI;

Пример развёртывания WordPress в кластере k8s с использованием Helm:

$ helm init
$ helm repo update
$ helm install stable/wordpress
## make new version
$ helm upgrade [release-name] [chart-name]

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

• Компоновка комплексных приложений (со множеством объектов k8s).
• Репозиторий чартов для многократного использования.
• Легкое развёртывание в нескольких средах.
• Вложение чартов: зависимости.
• Шаблоны: простота изменения параметров.
• Дистрибуция и возможность многократного использования.
• Развёртывание на последней стадии: непрерывная доставка.
• Развёртывание уже созданного образа.
• Совместное обновление и откат множества объектов k8s — управление жизненным циклом.

Более подробно здесь.

Ksonnet

Инфраструктура с поддержкой CLI для создания гибких конфигураций кластера Kubernetes

Инструмент Ksonnet предоставляет альтернативный способ определения конфигурации приложения для Kubernetes. Для определения манифестов k8s в нём используется Jsonnet (язык создания шаблонов JSON), а не стандартные файлы YAML. Командная строка Ksonnet генерирует окончательный YAML-файл и затем применяет его в кластере.

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

Архитектура

Ksonnet: обзор

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

Можно выделить три основных этапа работы Ksonnet: создание каталога приложения (команда ks init), автоматическая генерация манифеста (или написание своего) для компонента (команда ks generate), развёртывание приложения в кластере/среде (команда ks apply <env>). Управление различными средами осуществляется при помощи команды ks env.

Если коротко, Ksonnet помогает управлять приложениями как группой компонентов с помощью Jsonnet, а затем разворачивать их в различных кластерах Kubernetes.

Как и Helm, Ksonnet не обрабатывает исходный код. Это инструмент для определения приложений для Kubernetes при помощи Jsonnet.

С нуля и до k8s

Требования:

• кластер k8s;
• Ksonnet CLI.

Пример гостевой книги:

$ ks init
$ ks generate deployed-service guestbook-ui 
     --image gcr.io/heptio-images/ks-guestbook-demo:0.1 
     --type ClusterIP
$ ks apply default
## make changes
$ ks apply default

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

• Гибкость в написании конфигураций за счёт использования Jsonnet.
• Компоновка: комплексные приложения можно собрать при помощи комбинирования и согласования компонентов.
• Библиотека прототипов и возможность многократно использовать компоненты (устранение дупликации).
• Легкое развёртывание в нескольких средах.
• Развёртывание на последней стадии: этап непрерывной доставки.

Более подробно здесь.

Metaparticle

Стандартная библиотека для облачных приложений, выполняемых в контейнерах и Kubernetes

Metaparticle — это стандартная библиотека для облачных приложений. Она помогает применять стандартные паттерны для внедрения проверенных моделей разработки распределённых систем при помощи интерфейсов языка программирования.

Metaparticle предоставляет интерфейсы идиоматических языков, которые помогают создавать системы, способные контейнеризировать и развёртывать приложения в Kubernetes, разрабатывать тиражируемые сервисы, сбалансированные по нагрузке, и многое другое. При этом не требуется определять dockerfile или манифест Kubernetes. Все обрабатывается с помощью идиом, характерных для используемого языка программирования.

Например, чтобы создать веб-приложение на Python, необходимо добавить декоратор containerize (импортируется из пакета Metaparticle) в основную функцию. После выполнения кода Python в кластере Kubernetes собирается и развёртывается docker-образ в соответствии с параметрами, заданными в декораторе. Для подключения к кластеру используется стандартный контекст kubectl. Таким образом, смена среды будет означать и изменение текущего контекста.

Аналогичные примитивы доступны для NodeJS, Java и .NET. Ведется работа по добавлению поддержки большего количества языков.

Архитектура

Библиотека Metaparticle для соответствующего языка требует шаблоны и зависимости для создания кода в виде docker-образов, отправки его в реестр, создания YAML-файлов k8s и развёртывания в кластере.

Пакет Metaparticle содержит языковые идиоматические привязки для создания контейнеров. Metaparticle Sync представляет собой библиотеку внутри Metaparticle для синхронизации нескольких контейнеров, выполняемых на разных платформах.

На текущий момент поддерживаются JavaScript/NodeJS, Python, Java и .NET.

С нуля и до k8s

• Требования:
• кластер k8s;
• библиотека Metaparticle для поддерживаемого языка;
• Docker;
• репозиторий Docker для хранения образов.

Пример для Python (только соответствующая часть) — создание docker-образов и развёртывание в кластере k8s:

@containerize(
    'docker.io/your-docker-user-goes-here',
    options={
        'ports': [8080],
        'replicas': 4,
        'runner': 'metaparticle',
        'name': 'my-image',
        'publish': True
    })
def main():
    Handler = MyHandler
    httpd = SocketServer.TCPServer(("", port), Handler)
    httpd.serve_forever()

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

• Разработка приложений без необходимости использования файлов YAML или dockerfile.
• Больше не нужно осваивать множество инструментов и форматов файлов, чтобы использовать все преимущества контейнеров и Kubernetes.
• Быстрое развитие тиражируемых, сбалансированных по нагрузке сервисов.
• Управление синхронизацией, например, блокировкой и выбором мастер-копии в распределённых сетях.
• Простая разработка облачных паттернов, таких как сегментированные системы.

Более подробно здесь.

Skaffold

Простая и воспроизводимая разработка в Kubernetes

Skaffold управляет процессом создания, хранения и развёртывания приложений в Kubernetes. Skaffold, как и Gitkube, позволяет развернуть любой каталог с dockerfile в кластере k8s.

Skaffold создаёт локальный docker-образ, отправляет его в реестр и разворачивает, используя инструмент командной строки skaffold. Он также следит за состоянием каталога и при изменении кода внутри него осуществляет сборку и повторное развёртывание. В дополнение он передает логи из контейнеров.

Процесс создания, передачи и развёртывания настраивается при помощи YAML-файла, поэтому разработчик на этих этапах может использовать наиболее удобные комбинации инструментов. Например, можно выбрать docker build или Google Container Builder для создания, kubectl или Helm для развёртывания и т. д.

Архитектура

Skaffold: обзор

Skaffold CLI выполняет всю работу. Мы обращаемся к файлу skaffold.yaml, в котором определены необходимые действия. Типичный пример — создание docker-образа с помощью dockerfile в каталоге, где выполняется skaffold dev, тегирование с помощью хеша sha256, передача образа, его установка в манифест k8s, указывающий на файл YAML, и применение манифеста к кластеру. Этот процесс выполняется непрерывно, отвечая на каждое изменение в каталоге. Логи из запущенного контейнера передаются в то же окно просмотра.

Skaffold очень похож на Draft и Gitkube, но это более гибкий инструмент, так как он позволяет управлять разными цепочками процессов build-push-deploy, как показано на примере выше.

С нуля и до k8s

Требования:

• кластер k8s;
• Skaffold CLI;
• Docker;
• репозиторий Docker для хранения образов.

Шаги, которые необходимо выполнить для развёртывания приложения, выводящего на экран строку hello-world:

$ git clone https://github.com/GoogleCloudPlatform/skaffold
$ cd examples/getting-started
## edit skaffold.yaml to add docker repo
$ skaffold dev
## open new terminal: edit code

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

• Быстрое развёртывание.
• Циклическая сборка — непрерывный цикл сборки-развёртывания.
• Разработка приложений на Kubernetes.
• Определение цепочек build-push-deploy в потоке CI/CD

Более подробно здесь.

***

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

Обсуждение статьи на Hacker News можно найти здесь.

Автор: vchernov

Источник