Комментарии 11
По моему жуткий перебор для тех задач, которые вы описали. Можно обойтись без кубера, просто докером и обычным vpn
Человек же написал — лаборатория для экспериментов. Обучение, тренировка, тесты. Как для такого может быть перебор? Скорее, чего-то не хватит.
Вы правы. Более того, предложенные вами технологии я в различных комбинациях продолжительное время использовал. Но слишком много неизведанных технологий не давало мне покоя и аппетиты непреклонно росли.
Вероятно, имеется ввиду совместное использование докера с docker-compose . Несколько стеков + два отдельных прокси сервера для публичных и приватных приложений, в которых прописаны нужные домены. Можно использовать caddy и делегировать ему управление сертификатами.
Вопрос лишь: как в докере обеспечить сетевые политики безопасности? Верю, что вполне возможно на L3, но на L7 - сомневаюсь. Не то, чтобы это сильно принципиально, конечно, но внутреннему параноику гораздо спокойнее, когда недавно поднятое опенсорсное приложение ходит только туда, куда должно.
Что касается традиционных VPN, то непонятна их судьба в ближайшем будущем в России. У меня периодически возникали проблемы с WireGuard-ом, особенно в мобильных сетях, при том, что клиент и сервер были внутри страны. OpenVPN мне показался очень сложным в понимании и настройке - попытки настроить его для перенаправления трафика в другой VPN-сервис оканчивались неудачей.
Динамические VPN же способны самостоятельно определять какой маршрут между устройствами лучше всего проложить. Часто у меня Tailscale строил прямой вайргард тунель до сервера, когда обычный wireguard блокировался. Подозреваю, что первый использует какие-то нестандартные заголовки, чтобы прорубить NAT, которые DPI не могут отследить. В крайних случаях оно также способно тунелировать трафик через TCP/TLS.
Я допускаю, что в итоге могу просто настроить своим друзьям VLESS/VMESS на пк и телефонах как ультимативное решение, но пока динамические VPN мне интереснее, как минимум в исследовательских целях.
Почему не k3d?
Зачем сделали микс из TF + Polumi ?
Зачем кластер per node? Звучит ооочень странно.
Зачем certmanager manager, если CloudFlare выполняет TLS терминацию и предоставляет серты? Без proxy не будет ddos защиты, а с проксей у вас из коробки серты от CF/
Спасибо за вопросы!
В чем-то вроде k3d необходимости просто не возникло, готовый в NixOS модуль прекрасно справился с этой задачей.
Про микс TF + Pulumi ответил в предпоследнем разделе - в первом просто были нужные провайдеры, которых еще не было в Pulumi. В планах оставить только один инструмент.
Размышления над per-node кластерами тоже есть в статье. Прямо сейчас у меня нету таких масштабов нагрузки, над которыми имел бы смысл кластер с несколькими нодами. Зато есть потребность в нескольких серверах, развернутых в разных окружениях с разными приложениями. А для этого наиболее оптимальны single-node кластеры. Если в будущем у меня появится небходимость в одном из таких окружений масштабировать нагрузку, то я смогу в существующий кластер добавить worker-ноды.
Cloudflare, очевидно, не способен выполнять TLS-терминацию в приватных сетях, а публичные TLS-сертификаты там все равно нужны, чтобы всегда из коробки были зеленые замочки. + проксирование от Cloudflare мне нужно не везде, а еще я опасаюсь, что это создаст еще одну серьезную внешнюю зависимость по аналогии с Tailscale. DNS-провайдеров, поддерживающих ACME DNS-01 достаточно много, а вот бесплатное проксирование трафика как в Cloudflare, вероятно, предлагают единицы.
Спасибо, интересная статья и решение поставленных задач. Особенно полезны дальнейшие планы, так как это именно то, что хотелось бы посоветовать. Я про Pulumi как единое решение для IaC, а также замена TailScale на self-hosted решение.
Не очень понятно, что дает pulumi, по сравнению с тем же argocd (в частности для этой задачи).
Создается новый кластер (допускаю, что кластер не на один день и не для разового теста из дев-бранча), подключается к арго, который из appset привозит все хельмы (cert, metalb, nginx, traefik, longhorn, etc). Индивидуальные настройки (адреса, днс, диапазоны сетей и тд) все равно прописывать руками, так ничего не мешает в отдельных папках с названиями кластеров создавать оверрайды для хельмов, а appset сделает всю магию.
Плюс в том, что мы не просто разово создаем ресурсы, мы наблюдает их состояние в процессе жизни и можем обновлять версии сразу везде (или выборочно).
И немного не понял про nixos (даже почитав у них на сайте). Что в итоге она дала тут и что дает в принципе? И что мешает мне скриптом раскатить нужные пакеты, нежели учить новый язык, выдуманный отдельным вендором?
До ArgoCD еще руки не дошли, но когда я "примерял" его в качестве кандидата на какую-нибудь роль в этом проекте, мне показалось, что он выполняет несколько иную функцию - непрерывное развертывание приложений на большом флоте машин.
допускаю, что кластер не на один день
В данном случае, допущение верно лишь отчасти. Данная система скорее была спроектирована, чтобы как таракан перемещаться между серверами в практически автоматическом режиме. Это делалось с благой целью - избежать vendor-lock'a, но по факту периодически пересоздавать серверы чаще приходится в угоду разного рода экспериментам :D. Но, справедливости ради, случаи переезда серверов между разными провайдерами тоже были.
Плюс в том, что мы не просто разово создаем ресурсы, мы наблюдает их состояние в процессе жизни и можем обновлять версии сразу везде
Ну эта способность есть во всех IaC-инструментах. И Pulumi это скорее альтернатива Terraform, нежели ArgoCD. Хотя пересечения в их функциональности конечно тоже есть.
И немного не понял про nixos (даже почитав у них на сайте). Что в итоге она дала тут и что дает в принципе?
NixOS в данном случае - это альтернатива SaltStack и Ansible. Можно было автоматизировать развертывание кластера поверх той же Ubuntu с помощью этих инструментов. С рядом оговорок это тоже позволило бы получить воспроизводимую установку.
В целом NixOS дает новый подход к построению воспроизводимых Linux-систем. Ansible и SaltStack способны гарантировать выполнение определенных стейтов в определенном порядке, которые за счет различных мутаций (поставить пакет, записать файл) приводят систему в искомое состояние. В NixOS же система изначально существует в искомом состоянии и атомарно (с рядом оговорок) переходит от одного состояния к другому. Она практически не способна меняться за счет императивных действий, что одновременно можно рассматривать как плюс и как минус.
нежели учить новый язык, выдуманный отдельным вендором?
Лично мне этот язык показался гораздо приятнее YML-файликов в Ansible и SLS-стейтов в SaltStack. И уж всяко приятнее старого доброго Bash. А отдельного вендора тут нет: NixOS это Linux-дистрибутив, такой же как Ubuntu со всеми вытекающими.
по nixos - спасибо, значит не внимательно вчитался.
по argocd - добавлю. наблюдаемость - это не просто tf plan - то есть мы не только видим стейт, мы можем с ним взаимодействовать. как вы логи в только что развернутом nginx посмотрите ? а тут - пожалуйста. а так придется идти в куб, выполнять ряд команд. опять же дебажить как ? вот вкатили вы через pulumi ingres-nginx, да в настройках указали не тот балансировщик. как быстро вы об это узнаете (не ходя при этом в куб)? Ну и все в таком духе.
на счет переездов - меняем в коде setApps название куба (дестынейшин) и все NS нашего куба поехали раскатываться на свежий куб. Ну и никто не мешает после развертывания теми же апсами запускать зависивмые джобы с рестором стейтов и удалением старого (если вообще надо это делать в убиенном кубе).
Home Lab мечты в Kubernetes