Комментарии 8
Хороший текст. Хорошо описано создание виртуальных машин с qemu, заведение в них tap-интерфейсов и их объединения при помощи бриджа. Настройка сетевой части куба с haproxy тоже весьма интересна. Попробую на досуге
Я бы советовал обратить внимание на firecracker, вот тут хорошо описано https://iximiuz.com/en/posts/iximiuz-labs-story/
Делал примерно то же самое на домашнем сервер но немного на других технологиях:
Вместо сырого QEMU - LXD, он позволяет управлять не только контейнерами, но и виртуальными машинами, поддерживает cloud-init. В принципе это отличная замена libvirt, с намного более user-friendly интерфейсом с несложными YAML вместо монструозных XML;
В качестве балансировщика нагрузки перед нодами - Nginx в режиме stream - в отличие от http это балансировка на уровне TCP, за счет этого должна работать быстрее;
Все это управляется Ansible, а внутри Kubernetes используется FluxCD - получается что вся система полностью работает за счет IaaC.
То есть прям гитерменизм и вот это всё? А для какой цели разворачивали?
Для двух целей: во-первых чтобы вынести сервисы, которые развернуты на нескольких машинах в докере в одно место, чтобы постоянно не вспоминать где что развернуто (ssh+docker compose). А во-вторых чтобы перенести те сервисы, которые развернуты не в докере и про которые достаточно быстро забывается, что и где ты настраивал. Вот эти бесконечные копания в /etc и т.п. После того как перешел на Ansible - небо и земля.
В некоторых случаях правда получается что для того чтобы развернуть что-то надо написать манифестов в 4-5 раз больше чем docker compose для той же цели.
А почему никого не смущает, что для коннект машин автор использует tap-device вместо ethernet?
Может я чего-то не понял, но разве оно будет так работать?
Как построить локальный self-managed Kubernetes-кластер