Хабрахабр

[Перевод] Сравнение Draft, Gitkube, Helm, Ksonnet, Metaparticle и Skaffold

image

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

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

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

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

Draft

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

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

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

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

Архитектура

image

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

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

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

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

С нуля и до 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

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

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

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

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

Архитектура

image

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

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

Следующий шаг — создание объекта remote, который сообщает Gitkube, что должно произойти, когда выполняется команда git push в отношении конкретного удалённого адреса. После того как в кластере появились эти объекты, разработчик может создавать свои собственные приложения, используя kubectl. 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 и т. Чарты можно использовать для сложных приложений с множеством зависимостей. Они также поддерживают применение шаблонов, чтобы переменные можно было легко изменить.

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

Архитектура

image

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

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

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

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

Для создания образа потребуется любая система CI/CD, после чего можно использовать Helm для развёртывания. 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

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

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

Архитектура

image

Ksonnet: обзор

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

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

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

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

С нуля и до 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 — это стандартная библиотека для облачных приложений.

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

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

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

Архитектура

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

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

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

С нуля и до k8s

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

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

@containerize( 'docker.io/your-docker-user-goes-here', options=)
def main(): Handler = MyHandler httpd = SocketServer.TCPServer(("", port), Handler) httpd.serve_forever()

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

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

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

Skaffold

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

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

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

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

Архитектура

image

Skaffold: обзор

Мы обращаемся к файлу skaffold.yaml, в котором определены необходимые действия. Skaffold CLI выполняет всю работу. Этот процесс выполняется непрерывно, отвечая на каждое изменение в каталоге. Типичный пример — создание 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 можно найти здесь.

Теги
Показать больше

Похожие статьи

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

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

Кнопка «Наверх»
Закрыть