Comments 32
Зеленый деплой. Два раза ку.
PS: имхо многовато мемов, местами мешаются. Но расписано хорошо.
Да - расписано очень хорошо.
Только у меня вопрос, а почему не GitHub Actions или Argo Workflows + Argo CD + Argo Rollouts? C точки зрения цены - это все бесплатно, но уже не так лампово, это да...
Выбрал гитлаб я по нескольким причинам:
1. Все собрано в одном месте и не нужно бегать по разным сервисам.
2. Нравится, что в нем практически все работает из коробки (кроме тестирования =/ ).
3. Когда начинал с ним возиться (в начале года), то и цена использования была адекватна, сейчас это конечно уже минус.
4. И, наконец, примитивная вкусовщина.
Но, если задаться целью максимально сэкономить (не знаю насчет удобства использования и установки), то ваши варианты выглядят интересно, особенно Argo Workflows.
Прекрасная статья. Спасибо автору.
Но есть ошибка. 2к21 это 2210 год.
К - кило означает тысяча (10^3)
2.21 * 10^3 = 2210
Как вы правильно заметили К - тысяча. А значит 2к21 и говорится как - две тысячи двадцать один С:
альтернативная форма записи:
2210
2.21 * 10^3
2k21
2.21k
2.21e3
https://zone.ni.com/reference/en-XX/help/375482B-01/multisim/acceptableunitletters/
Вообще это не я придумал). Это уж довольно устойчивое из года в год выражение. И пошла она от игр NBA 2K** -> NBA 2K19, NBA 2K16, NBA 2K20 и тд. Вот например если погуглить эту фразу.
Спасибо за статью. Написано круто!
Можно на гитлабе сэкономить если разместить в кубере оператор ранеров и скалировать их, а тариф использовать бесплатный. Функционал сохранится, цена упадёт.
В качестве полу-спортивной экономии, при увеличении нагрузки, можно взять пару серваков в хетцнере, мощи там будет за глаза.
Спасибо за статью.
Как только нод становится больше одной - возникает проблема агрегации логов. Какие могут быть легковесные решения без использования elk стека?
Кластер решил делать минимальный, состоящий из двух узлов — master и worker.
А можно пояснить что означает это раздение на master и worker? На один узел идет деплой на другом билд?
Мастер нода отводится чисто для обслуживания и поддержки кластера, тут не запускаются ресурсы пользователя. А вот воркер ноды обслуживают чисто клиента, в том числе и билды (если gitlab runner развернуть).
Ещё вы могли использовать k3s, тогда хватило бы одного узла. А в случае расширения, можно было бы добавить новых узлов.
Выкатывают приложение (или все пользовательские ресурсы) только на worker ноды.
Например тут хорошо расписано:
Главный узел - это узел, который контролирует и управляет набором рабочих узлов. На мастер узле работают следующие процессы:
1. Kube-APIServer - Вся внешняя связь с кластером осуществляется через API-сервер.
2. Kube-Controller-Manager - контроллер-менеджер реализует управление в кластере.
3. Etcd - база данных состояний кластера.
4. Kube Scheduler - планирует действия для рабочих узлов на основе событий, происходящих в etcd.
Это все запускается только на мастер ноде и нужно для управления всем кластером.
Пример: есть кластер, он состоит из одной мастер ноды ив двух воркер нод. Если выйдет из строя мастер нода, то все до свидания кластеру и нашим сервисам. А вот если выйдет из строя воркер нода, то куб это заметит, и все пользовательские ресурсы перезапустит на второй рабочей ноде, таким образом будет небольшой простой в работе сервиса. Для надежности делают резервную мастер ноду - если вдруг выходит из строя главная, то резервная мастер нода перехватывает управление кластером на себя. Такие кластеры уже называют High-Availability cluster, HA cluster.
Или вот с офф сайта:
Мастер Kubernetes отвечает за поддержание желаемого состояния для вашего кластера. Когда вы взаимодействуете с Kubernetes, например, используя интерфейс командной строки
kubectl, вы работаете с мастером Kubernetes вашего кластера.Под "мастером" понимается совокупность процессов, которые управляют состоянием кластера. Обычно все эти процессы выполняются на одном узле кластера, и поэтому этот узел называется главным (master). Мастер также может быть реплицирован для доступности и резервирования.
ЕМНИП воркер-ноды могут совпадать с мастер-нодами, но так делать не рекомендуется. Проблема просто в количестве процессов, но строгой необходимости разнести мастер и воркер не вижу.
Осталось небольшое сомнение, что для мастер ноды нужен такой же по производительности VPS как для worker, но нигде данных по этому поводу не смог найти
Да, Вы правы, для master не нужна такая производительность как для woker. Минимальные требования: 2 CPU, 2Gb RAM.
https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/
Да, как правильно заметил @F1RST для мастера минимальные - 2 CPU, 2Gb RAM. А воркер нода может быть вообще любой. Хоть 1 CPU и 1GB RAM, но логично делать, конечно, рабочие машины производительными.
А можно сделать мощную мастер ноду, включить специальную настроечку в кубе, и тогда все рабочие нагрузки будут запускаться на мастер ноде, про это выше упомянул @vesper-bot.
А почему вы опираетесь на инструкции по установке k8s, где указано в качестве CRI Docker.
Вы же в курсе, что Docker как CRI в k8s deprected ?
Kubernetes is deprecating Docker as a container runtime after v1.20.
Точнее вопрос такой, а зачем использовать то, что уже объявлено deprecated ?
А какие рантаймы умеют запускать контейнеры докера, при этом имеют нормальный (v1alpha1 или выше, как по ссылке нааписано) CRI для кубера? А докер-контейнеры местами стали стандартом де-факто для запуска микросервисов.
Признаюсь, я просто не знал что Docker как среда выполнения контейнеров устарела С:, спасибо что подсветили. Ребята, разработчики куба, в своем блоге подробно расписали, почему они так делают и как жить дальше (тут и тут)
Кратко для тех, кто впервые слышит: не надо паниковать, Docker всё также будет использоваться для разработки. Просто при установке кластера теперь надо выбирать другую среду выполнения контейнеров типа containerd и CRI-O.
В версии куба 1.20 и 1.22 всё будет работать как и раньше. В этой статье конкретно они и ставятся.
Но для следующих версий куба надо будет изменить процесс установки немного.
К тому же, чтобы это заработало нужно для домена awesomeservice.tech уметь настраивать автоподдомены
A запись на *.domain.com и при необходимости на *.appname domain.com, что там настраивать)
Ультимативный гайд по созданию CI/CD в GitLab с автодеплоем в Kubernetes на голом железе всего за 514$ в год ( ͡° ͜ʖ ͡°)