company_banner

Garden v0.10.0: Вашему ноутбуку не нужен Kubernetes

Автор оригинала: Jon Edvald
  • Перевод
Прим. перев.: С Kubernetes-энтузиастами из проекта Garden мы познакомились на недавнем мероприятии KubeCon Europe 2019, где они произвели на нас приятное впечатление. Этот их материал, написанный на актуальную техническую тему и с заметным чувством юмора, — наглядное тому подтверждение, а посему мы решили его перевести.

Он рассказывает о главном (одноименном) продукте компании, идея которого — автоматизация рабочих процессов и упрощение разработки приложений в Kubernetes. Для этого утилита позволяет легко (буквально одной командой) разворачивать в dev-кластере новые изменения, сделанные в коде, а также предоставляет разделяемые ресурсы/кэши для ускорения сборки и тестирования кода командой. Две недели назад у Garden состоялся релиз 0.10.0, в котором стало возможным использовать не только локальный Kubernetes-кластер, но и удаленный: именно этому событию и посвящена данная статья.


Меньше всего я люблю работать с Kubernetes на своем ноутбуке. «Кормчий» поглощает его процессор и аккумулятор, заставляет кулеры вращаться без остановки и сложен в обслуживании.


Фотография со стока в тему для пущего эффекта

Minikube, kind, k3s, Docker Desktop, microk8s и т.д. — отличные инструменты, созданные для того, чтобы пользоваться Kubernetes было максимально удобно, и спасибо им за это. Серьезно. Но с какой стороны ни посмотри, ясно одно: Kubernetes не приспособлен для запуска на моем ноуте. Да и сам ноутбук не предназначен для работы с кластером контейнеров, разбросанных по слоям виртуальных машин. Бедняжка старается изо всех сил, но явно не любит это занятие, выказывая свое недовольство воем кулеров и норовя обжечь бедра, когда я опрометчиво ставлю его на колени.

Скажем же: ноутбуку — ноутбуково.

Garden — инструмент для разработчиков, занимающий ту же нишу, что и Skaffold, и Draft. Он упрощает и ускоряет разработку и тестирование Kubernetes-приложений.

С момента самого начала работы над Garden, около 18 месяцев назад, мы знали, что локальная разработка распределенных систем — временное решение, поэтому заложили в Garden значительную гибкость и прочную основу.

Теперь мы готовы поддерживать как локальные, так и удаленные Kubernetes-окружения. Работать стало гораздо проще: сборку, развертывание и тестирование теперь можно проводить в удаленном кластере.

Короче говоря:

С Garden v0.10 можно полностью забыть о локальном кластере Kubernetes и по-прежнему получать быструю реакцию на изменения в коде. Всё это — бесплатно и с открытыми исходниками.


Наслаждайтесь одинаковым удобством при работе с локальными и удаленными средами

Привлек ваше внимание?


И я рад этому, поскольку у нас есть еще много любопытных фишек! Общее использование dev-кластеров имеет более масштабные последствия, особенно для совместно работающих команд и CI-пайплайнов.

Как так?

Прежде всего, внутрикластерный сборщик — будь то стандартный демон Docker или Kaniko, — а также внутрикластерный реестр являются общими для всего кластера. Ваша команда может сообща использовать dev-кластер, при этом кэши сборок и образы доступны всем разработчикам. Поскольку Garden присваивает теги образам на основе хэшей исходников, теги и слои определяются однозначно и непротиворечиво.

Это означает, что как только разработчик создает образ, он становится доступен для всей команды. Изо дня в день мы скачиваем одни и те же базовые образы и делаем одни и те же сборки на компьютерах. Любопытно, сколько трафика и электричества тратится впустую?..

То же самое можно сказать о тестах: их результаты доступны всему кластеру и всем членам команды. Если один из разработчиков протестировал некую версию кода, отпадает всякая необходимость повторно проводить тот же тест.

Другими словами, дело не только в том, что не нужно запускать minikube. Этот скачок открывает для вашей команды дорогу ко множеству возможностей по оптимизации — больше никаких лишних сборок и тестовых прогонов!

Как насчет CI?


Большинство из нас привыкли к тому, что CI и локальный dev — это два самостоятельных мира, которые нужно настраивать отдельно (и они не используют общий кэш). Теперь их можно объединить и избавиться от лишнего:

Можно выполнять одни и те же команды в CI и в процессе разработки, а также использовать единую среду, кэши и результаты тестов.

По сути ваша CI превращается в бота-разработчика, работающего в той же среде, что и вы.


Элементы системы; беспрепятственная разработка и тестирование

Можно существенно упростить конфиги CI-пайплайнов. Для этого достаточно запустить Garden из CI для сборок, тестов и деплоев. Поскольку вы и CI используете одно и то же окружение, вероятность столкнуться с проблемами CI гораздо ниже.

Копание в бесчисленных строках конфигов и скриптов, затем push'и, ожидание, надежда и бесконечные повторы… Все это в прошлом. Вы просто занимаетесь разработкой. Никаких лишних движений.

И чтобы окончательно прояснить ситуацию: когда вы или другой представитель команды собрал или протестировал что-то с помощью Garden, то же самое произошло и для CI. Если вы ничего не меняли после тестовых прогонов, то не нужно проводить тесты (или даже сборки) для CI. Garden все делает сам, а затем переходит к другим задачам, таким как организация среды предварительного запуска, pushing артефактов и т.д.

Звучит заманчиво. Как попробовать?


Добро пожаловать в наш репозиторий GitHub! Устанавливайте Garden и играйтесь с примерами. Тем, кто уже использует Garden или желает познакомиться с ним поближе, предлагаем Remote Kubernetes Guide. Присоединяйтесь к нам в канале #garden в Slack'е Kubernetes, если у вас есть вопросы, проблемы или вы просто хотите пообщаться. Мы всегда готовы помочь и приветствуем обратную связь от пользователей.

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


В скором времени мы также опубликуем обзор полезных утилит для разработчиков приложений, функционирующих в Kubernetes, куда помимо Garden попали и другие интересные проекты… А пока — читайте также в нашем блоге:

Флант
325,44
Специалисты по DevOps и Kubernetes
Поделиться публикацией

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

    –4

    Если Kubernetes не стоит запускать на ноутбуке, то его не стоит запускать нигде.

      +1
      Если болид Ф1 не стоит запускать на пересеченной местности российской деревни, то не стоит его запускать нигде? Чем вы руководствуетесь, заявляя подобное?
        –1

        Компьютеры, это не автомобили. Если программа жрет ресурсы немеряно и потребляет много энергии – это дорого и на ноутбуке и на кластере. Только на ноутбуке, это сразу видно. А не кластере охлаждение получше и энергия не кончается. Но КПД ведь одинаково.


        non_effective: 
                jmp  non_effective    ; let waste some energy.
          0
          Не стоит думать, что основная нагрузка (столь заметная на условном ноутбуке) создаётся самой системой Kubernetes, а не запущенными в ней workloads.
            0

            Ну я, вообще то не люблю гадать что хотел автор сказать читателям.

            0
            Продолжая аналогию, если магистральный тягач жрет тонну топлива, то он не нужен нигде. Ведь есть садовая тачка, которая отлично справляется со своей задачей на моём садовом участочке. КПД ведь одинаково, О!
        0

        Сначала подумал, что ошиблись в написании Gardener

          0

          Идея звучит не здраво!

            0
            Вы про быстрый и автоматизированный деплой изменений в приложении в удалённый кластер или какую идею? Почему?
              0
              Идея о распределенном вычислительном процессе и объединении удалынных ресурсов с локальными, в частности при билдах и тестах. Правда, вопрос с безопасностью возникает и доработки интерфейса пользователя.

              Вот как сейчас, можно прогнать тесты локально или запушить и ждать ответа билд-сервера. А в идеале было бы хорошо при каждом сохранении кода видеть состояние тестов и не грузить этими тестами локальную машину.
            0
            Ура, ещё один слой абстракции! (Теперь со вкусом TypeScript)

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

            Самое читаемое