Комментарии 22
https://github.com/MusicDin/terraform-kvm-kubespray
Все тоже самое и даже больше.
Меня одного смутило "Bare-metal" в названии и рассказ о том как запустить всё на виртуалках?..
Ещё конечно бы хотелось услышать обоснование аж трёх мастеров для тестового кластера, тогда как и продакшн справится с одним. Ведь вы же знаете что мастер не критичен для работы кластера, это control-plane. Им кластер управляется, то есть если мастера выключить, то всё мгновенно не исчезент в варпе, просто пропадёт возможность что-то менять и вообще доступ к API. но поды всё так же будут запущены и будут работать и отвечать? Знаете же да? Что в кластере с одним мастером если его перегрузить пока он перегружается особо ничего не произойдёт? Ну так зачем в тестовом кластере ТРИ мастера?
Bare-metal имеется ввиду не готовое решение в облаке, а уставка кубернетес на ноды (в домашних условиях виртуалку проще создать, чем собирать железные сервера).
Три мастера - в статье говорилось что это эмуляция кубернетеса в продакшн. И кофигурация трех мастеров это не одно и тоже, что кофигурация одного мастера
В статье говорится про "production ready" кластер или если по умному high-available. Основное условие такого кластера это резервные мастер ноды, то есть необходимо иметь в запасе дополнительные ноды, которые могут быть вообще неактивными.
Почему три мастер ноды? Есть такое понятие как кворум, необходимо всегда иметь в кластере нечетное количество мастер нод, чтобы они могли между собой проголосовать кто сейчас будет "главным". Кворум используется и kubernetes кластере и в etcd кластере. Я немного упростил про выбор "главного", если интересно можно почитать про lease.
В статье говорится про тестовый кластер для экспериментов.
И давайте ещё раз, как high-available соотносится с мастерами? мастер это control-plane, если он выключится, high-availability данных не изменится, всё что в кластере запущено так и будет работать и отвечать. Пропадёт возможность управлять кластером, но это всё. На доступность данных это не повлияет.
high-availability данных не изменится
Это уже не будет high-availabe кластер, если у него один мастер. Никто не спорит с тем, что при выходе из строя мастера запущенные приложения продолжат работу. В лучшем случае хост с мастер нодой "моргнёт", ребутнется, затем поднимется и нода восстановится. А если мастер не самополечится? Полезную нагрузку (приложения и сервисы) больше нельзя будет обновить, откатить, а в случае выхода из строя нельзя будет запланировать на другую worker ноду. И толку тогда от такого кластера?
Я уже ставил кластер с одной мастер нодой на VPS серверах, они не жили больше 4 месяцев, причем ставил у разных облачных провайдеров.
И это всё так же не имеет смысла для домашнего стенда описанного в статье.
Не представляю что надо делать с кластером чтобы убить его мастер за 4 месяца.
У меня есть тестовый стенд с которым я что только не делал, и сертификаты на нём кончались, и неудачное обновление CNI выводило из строя всю сеть, но мастер это просто пара процессов и файлы в двух директориях на диске. Причём не так много. Пока эти файлы целые - ничего с мастером не случиться.
Все эти мануалы о том как надо бахнуть три мастера обязательно, а то развернуться ворота в ад это безусловно классно, если вы делаете кластер для сбербанка. Но для домашней лаборатории три виртуалки для задачи с которой справляется raspberrypi просто потому что так написано в документациях которые писали люди которые прочли другие документации - это чистый карго культ и шаманизм делания ради делания без понимания что вы делаете.
>>> Устанавливаем на bm kubernetes
>>> Долистал до половины - все еще мануал по созданию виртуалок
>>> Ура, устанавливаем куб - ну кароч кубспрей там в паре мест конфиги поправили и кароч оно работает, если что потом можете конфиги поправить
Ну тупо топ инструкция я считаю, дайте еще
Спасибо за k9s, шикарно!
Создание ВМок и инвентори для ансибла можно автоматизировать через https://github.com/virt-lightning/virt-lightning
А почему не терраформ и опенстек?
Скрипткидди гораздо проще бездумно скопировать .tf чем из статьи выдергивать команды и запускать в консоли 🤣
Ставим на железо убунту.
Ставим microk8s
Готово, у вас k8s bare metal. Хотите ВМок? Без проблем, kubevirt)
Если виртуалка ставилась с какогото кастомного модифицированного имиджа, как у меня, то кьюбспрей может и не отработать. Нужна именно ванильная ось. С дебианом были проблемы, нужно переключить iptables в легаси режим.
Насколько я понимаю в качестве CNI у вас Calico? Тогда зачем нужен MetalLB, если bird в составе calico-node отлично анонсирует по iBGP весь диапазон ClusterIP, а если очень надо - то и дальше? Я дома ради общего развития упоролся и развернул куберовский кластер с мастером на сервачке на антресоли и несколькими воркерами, в том числе на еще одном совсем маленькой машинке, которая заодно играет роль роутера - и сервисы, которые деплоятся с обычным ClusterIP отлично видны с любого устройства во внутренней сети - даже если там кубера нет. При том никакой оверлейной сети нет, всё работает за счет маршрутизации.
Ну у меня не было задачи куда-то это открывать во внешнюю локалку дальше моей рабочей машины. Всё же в рамках одной и той же локальной машины использовать iBGP - это лишнее, наверное. Но можно, если хочется.
Локально с виртуалками всё еще проще - по идее должно быть достаточно просто прописать на хосте маршрут до подсетки ClusterIP через любую из куберовских нод, а маршрут обратно с виртуалок скорее всего уже есть. Это действительно будет простым решением, а не MetalLB, который в L2-режиме активно рассылает ARP-анонсы, а в L3 - это тот же iBGP.
К слову - даже iBGP далеко не такой монстр, как может показаться из названия, и например в моем случае вообще не потребовал никакой конфигурации - как только поднялись поды calico-node на всех узлах "волшебным" образом возникли нужные маршруты.
Официальная документация рекомендует использовать для этого minikube. Canonical продвигает свой MicroK8s. Есть ещё k0s, k3s, kind — в общем, инструменты на любой вкус.
Все эти игрушечные кластеры подходят максимум для целей разработки или проверки концепций.
Игрушечные? Конечно же нет. Когда слышу, что K3s подходит только для локальной машины и не серьёзных задач, то сразу понимаю, что серьезного опыта работы у вас с ним нет.
Тут выход один — поднять нормальный кластер на виртуалках.
Виртуалки - это прекрасная возможность потратить кучу системных ресурсов на ОС каждой из виртуалок и в целом много лишних действий, но зачем это делать, если есть, например, K3D (не путать с K3s) где можно прекрасно запустить сколько хотите master'ов и worker'ов в docker контейнерах? Говорю про Linux, где для docker не нужна никакая виртуализация.
Можно даже поднять рядом в виртуалке, допустим, Gitlab CE, подцепить к нему ваш кластер и обкатывать CI/CD.
Для этого достаточно поставить Gitlab runner в ваш кластер Helm'ом и это 2 строчки кода и никаких виртуалок. Впрочем, если хотите поставить целый self hosted Gitlab, то это тот же helm install в тот же кубер.
В целом статьи на Хабре всё больше разочаровывают тем, что они про каких-то сферических коней в вакууме и совершенно не понятно в какие же такие ограничения дистрибутива того или иного кубера кто-то вообще упирается со своим hello world?
Виртуалки - это прекрасная возможность потратить кучу системных ресурсов
на ОС каждой из виртуалок и в целом много лишних действий, но зачем это
делать, если есть, например, K3D (не путать с K3s) где можно прекрасно
запустить сколько хотите master'ов и worker'ов в docker контейнерах?
Если задача состоит в том, чтобы быстро был кубер и в нём что-то запустить "двумя строчками кода", то пойдёт любой из десятка вариантов для локальной разработки. Об этом я сказал в начале статьи. Цель всех этих заморочек с виртуалками - чтобы хотя бы формально ваш демо-стенд был приближен к реальности, в которой будут работать приложения. Допустим, надо имитировать нештатную ситуацию. Например, проверить на практике, как ваше приложение поведёт себя, если отвалится один из воркеров из-за сетевых проблем, на некоторое время, а потом опять подключится?
Я достаточно внимательно прочёл вашу статью и мой комментарий выше остаётся в силе.
Цель всех этих заморочек с виртуалками - чтобы хотя бы формально ваш демо-стенд был приближен к реальности, в которой будут работать приложения.
Приложения работающие в кубере работают в контейнерах. Контейнеры обрели такую популярность в том числе потому, что они, упрощённо говоря, максимально приближенно работают и на локальной машине в докере и в Kubernetes в облаке. Ваш локальный демо стенд может отличаться от облака только количеством памяти (может и нет), скоростью дисков (может и нет) и т.п. и естественно отсутствием таких облачных ресурсов как elastic load balancer & etc.
Используя K3D вы можете поднять несколько master и worker нод в docker контейнерах и даже несколько кластеров одновременно и играться с их конфигурацией сколько угодно (да, даже с сетью), только с K3D вы можете себе позволить больше чем с виртуалка и значительно проще, т.к., в отличие от виртуалки, докер контейнер не тратит столько ресурсов системы для запуска полноценной ОС и настройка крайне проста.
Ну, у вас несколько не bare metal, крутите то в тяжелой VM. А раз крутите убунту то вообще лучше сделать кубер типа k3s в LXC/LXD - без VM оверхеда и в 10 раз проще.
https://github.com/corneliusweig/kubernetes-lxd/blob/master/README-k3s.md
убунтовкий microk8s крайне не рекомендую... падуч без внятного объяснения причин, ставится через snap - который может его начать обновлять без спроса и прибьет в процессе кластер к чертям, о чем много ругани в гитхабе, и на что забила убунта
А раз крутите убунту то вообще лучше сделать кубер типа k3s в LXC/LXD - без VM оверхеда и в 10 раз проще.
Естественно, можно было. Мы сознательно добавляем оверхед, чтобы стенд был более-менее похож на продакшн, вряд ли на проде будет использоваться lxc. Взамен получаем возможность тренироваться и отрабатывать разные сценарии, например, ломать и шатать кластер.
Как вариант вместо kvm и libvirt можно использовать lxc. Ресурсов меньше требуется.
https://habr.com/ru/post/420913/
Bare-metal kubernetes-кластер на своём локальном компьютере