Комментарии 9
Во всех статьях по развертыванию различными инструментами по мотивам документации к этим инструментам - всегда опускается момент преднастройки хостов. А в случае с той же убунтой, у которой довольно маленькие дефолты, это прям очень актуально. Потом неожиданно может оказаться что все почему-то тупит. Лучше бы этому уделить внимание. Чем пересказ документации по установке.
Через DNS так себе вариант. А если один узел лежит?
Чтобы вручную не париться есть неплохая готовая роль под ансиблу: https://github.com/lablabs/ansible-role-rke2
Там и нормальные варианты HA через keepalived или kubevip.
В принципе почти без допилинга годится.
У Rancher, кстати есть ещё особенность - если кластер развернул не он, то функционал по управлению не совсем весь доступен, например управление бакапами.
Поправил финальный абзац в главе про балансировку внешнего трафика: написал там не то, что хотел. Безусловно, в пуле адресов нужно указывать IP узлов и использовать health чеки, а не ту DNS запись.
А вариант с DNS в качестве fixed registration address, кажется, не так критичен, учитывая, что узел обращается к нему только разово, когда мы делаем его join в кластер. Соответственно, по round-robin он доберется до рабочего узла и подключится к кластеру. Но соглашусь, что даже тут лучше рассмотреть другой вариант для HA.
Спасибо за комментарий, роль для Ansible попробую. Круто, что ей же можно сразу задеплоить кастомные манифесты на этапе установки RKE.
Rke2 и ансибл - это конечно хорошо. Но работает так себе, порой через раз. Нормальной идемпотентностью там и не пахнет.
На rke я могу сколь угодно долго крутить версию куба туда сюда хоть на 5 релизов, на rke2 откатываться крайне сложно (понятно, что кейс редкий, но все же) да и обновлять его весело, одна операция systemctl restart rke2-server чего стоит.
И не очень понимаю доводы против rke, когда зависимость от докера вдруг стала проблемой ?
Отсаживаешь cp+etcd компоненты на отдельные три легкие ноды, воркер нагрузку на остальные жирные ноды. И живут себе такие кластера долго и счастливо.
Ага. Очень грущу от того что они во второй версии отказались от механизма управления кластером и конфигурацией из одной точки. Отличное было решение для gitops подхода.
И не очень понимаю доводы против rke, когда зависимость от докера вдруг стала проблемой ?
Видимо в тот момент, когда K8s перевел Docker в статус deprecated и он перестал быть индустриальным стандартом как container runtime. По этой же причине, по заявлению SUSE, разработка и поддержка RKE первой версии завершится в 2025 году и всем придется мигрировать на RKE2 для дальнейшей поддержки и обновлений.
на rke2 откатываться крайне сложно (понятно, что кейс редкий, но все же) да и обновлять его весело, одна операция systemctl restart rke2-server чего стоит.
А вот это печально. Надо попробовать в ближайшее время. А если в этом плане RKE2 сравнивать с другими инструментами, например с kubeadm?
сравнивать rke2 можно разве что с kubespray - и там и там ансиблом хоть как-то можно гитопсить. все что делается руками и из консоли - это какие-то хоум-лабы (hard way k8s если хотите) и не имеет отношения к продуктовой работе, где 30-50-100 кластеров (и разрабам постоянно надо новые\временные катать).
я сейчас начал присматриваться к k0s (ноль) и talos - подобным решениям.
на счет deprecated - с одной стороны, да, грустно. с другой - там все еще живые обновления и куб v1.30.3, а бежать вперед паровоза пока не охота.
Настройка self-hosted K8s кластера с помощью RKE2 (Rancher)