Kubernetes для сайта

Попробуй для начала посмотреть в сторону minikube.

В докере сайт умеешь запускать? Если да, то в композе? А оттуда рукой подать до куба - концепции похожи.

docker -> docker compose -> docker swarm -> kubernetes

Я тут писал специально для новичков: раз, два, три, четыре.

Только ты вопрос неправильно задаёшь. Кубернетес ради кубернетес → это какой-то странный путь. Ты уверен, что твоему сайту нужны кубы?

КМК, его цель — просто кубы палочкой потыкать. Для этого «сайт» вполне подходящий объект для деплоя, ну разве что фронт бы еще от бэка отделить и посмотреть, как взаимодействие между сервисами там работает

Этап первый: кубернетес на локалхосте. С помощью kubeadm развернуть kubernetes на одном сервере, в конфигурации с одним узлом. В качестве CNI использовать flannel. Создать deployment с nginx, опубликовать его на порту вроде 33080. Сайт должен быть доступен по адресу http://ip:33080.

Этап второй: ingress. Развернуть в кластере ingress controller, например ingress-nginx. Переделать первый deployment, чтобы он работал через ingress. Задача со звёздочкой - сделать то же через gateway API. Если есть внешний IP и домен, также неплохо добавить в кластер cert-manager и настроить HTTPS с Letsencrypt.

Этап третий: кластер. Найти 5 серверов, скорей всего виртуальных. На них развернуть кластер из пяти узлов. Три узла для control plane, два узла для worker nodes. Развернуть всё из предыдущего пункта. При установке использовать предпоследнюю версию kubernetes. После установки и настройки провести обновление кластера до последней версии. Задача со звёздочкой - реализовать схему с внешним балансировщиком нагрузки на основе MetalLB или haproxy+keepalived. Тут желательно постараться добиться того, чтобы во всей системе не было ни одной точки отказа.

Этап четвёртый. Автоматизация. Настроить flux. Все манифесты должны лежать в git репозитории, например в github. По пушу в ветку main всё должно моментально применяться в кластере.

Этап пятый. Облако. Выбрать любимое облако (AWS, GCP, Azure, Yandex, Selectel, Vultr, whatever), создать там managed kubernetes и развернуть сайт в нём, попутно проводя аналогии с предыдущим ручным трудом.

для изучения решил попробовать запустить сайт на своем железе с применением Kubernetes.

Смотря какое железо. Если localhost: k3s, minikube, microk8s. Если есть >= 3 серверов: развернуть кластер с помощью kubespray для быстрого старта; ручное разворачивание кластера с помощью kubeadm для лучшего понимания.

Первое время для управления лучше обойтись kubectl, графические интерфейсы, такие как lens, оставить на потом. Начать запускать контейнеры .yml-конфигами, продолжить используя helm или terraform.

графические интерфейсы, такие как lens, оставить на потом

Уже года 4 работаю с Kubernetes, необходимости в чём-либо кроме kubectl так и не ощутил. На lens я вообще наложил запрет, один товарищ его решил запустить, так эта гадость сразу наплодила каких-то мусорных подов в кластере, второй прометей попёрлась поднимать, конечно у неё ничего не получилось, но вычищать пришлось. Для нелюбителей консоли держу kubernetes-dashboard, но сам не пользуюсь.

Начать запускать контейнеры .yml-конфигами, продолжить используя helm или terraform.

Против описанного ничего не имею, но лично мне для нескольких десятков дейплойментов за глаза хватило kustomize, чего я бы и рекомендовал для начала. Оно ещё и в kubectl встроено. И в целом подход кажется более грамотным, чем использование текстового шаблонизатора, как в helm. Может с какого-то масштаба гибкость helm нужна, но начинать с него не обязательно, как по-мне.

продолжить используя helm или terraform.

ты точно понимаешь, для чего терраформ нужен? это там всякую облачную инфру поднимать, типа пачку виртуалок + сеть между ними + внешние адреса + пачку менеджед-сервисов, например, но точно не подики в кубах

за kubectl во все места вместо всяких lens-ов очень плюсую, сам так делаю уже тоже далеко не первый год. но про helm зря ты так, очень полезный инструмент

ты точно понимаешь, для чего терраформ нужен? это там всякую облачную инфру поднимать,

k8s и есть облачная инфра.

но точно не подики в кубах

grep 'resource "kubernetes' main.tf | head | awk '{print $2}'
"kubernetes_namespace"
"kubernetes_service"
"kubernetes_endpoints"
"kubernetes_secret"
"kubernetes_persistent_volume"
"kubernetes_persistent_volume_claim"
"kubernetes_deployment"
"kubernetes_service"
"kubernetes_deployment"
"kubernetes_service"

Что за ерунда? Времена когда для кибернетес юзали докер давно прошли.

Я имею в виду постижение концепций по возрастанию сложности.

Какой ужас :) k9s уже тодда уж, та же консоль, но интерфейс гораздо удобнее. Что за поды мог создать ленс - загадка, это по сути графический интерфейс поверх kubectl, не более.

Сварм уже не нужен, он по сути аналог куба вроде как :) а так стройный путь малых компаний в куб - где-то такой. Кто-то вовсе на композе и останавливается)

Прошло мимо меня как-то, значит. Хотя, возможно, где-то в managed имеет смысл? Но все равно я бы так делать не стал

swarm в разы проще, его можно поднять прочитав 1-2 страницы текста, и ему не требуется много ресурсов.

Куб - это уже совсем другой уровень затрат на всё: от изучения до развёртывания.

Знаю несколько очень высоконагруженных сайтов, которые до сих пор разворачиваются в сварме.

вот не в первый раз вижу, что людей пугают кубом, типа он такой сложный, не трогайте. ну да, абстракций побольше, но в целом-то и надежность повыше, и гибкость. с другой стороны, где вы видели managed swarm? не потому ли, что он не востребован?

lens эта гадость сразу наплодила каких-то мусорных подов

Ну чушь же. Это просто клиент, который сам по себе ничего не делает. k9s и kubectl у ентого товарища случаем никаких мусорных подов не плодили?

У нас народ пользуется примерно пополам Lens и k9s — подобной фигни замечено не было.

Но в любом случае, эти клиенты нужны либо для диагностики на dev-площадках, либо для ну очень маленьких инсталляций. Что-то более крупное надо обвешивать ArgoCD и подобным.

Автору же годных советов уже дали — загнать сперва просто в докер, потом отделить фронт от бека, написав сервисов в compose, потом запихать это в миникуб и попробовать масштабировать.

с другой стороны, где вы видели managed swarm? не потому ли, что он не востребован?

Потому что swarm давно объявлен «устаревшим», хотя ничего плохого в нём нет.

И потому что индустрия часто впадает в карго-культизм. Типа, «нам обязательно надо использовать тот же ЯП, те же библиотеки, те же СУБД, те же очереди, те же способы развёртывания приложений, что и в Google и в Facebook, потому что мы же не хотим быть хуже чем они, со своим-то одностраничным лендингом!»

Потому что swarm давно объявлен «устаревшим», хотя ничего плохого в нём нет.

Кем объявлен?

k8s и есть облачная инфра.

Bare metal смотрит на тебя с неодобрением. Как и кластера из малинок, например.

Куб - это уже совсем другой уровень затрат на всё: от изучения до развёртывания.

Ну изучить для минималки его можно и на миникубе или кайнде. А вот если прям полноценный кластер с отказоустойчивостью, то тут да, уже надо как минимум несколько машин.

Кем объявлен?

Мировым сообществом, да и сама компания Docker вроде таковым его считает. Тем не менее, поддерживает и не выкидывает.

Сейчас не нашёл это место в доке, но по-моему, несколько лет назад, было написано: «Это устаревшая фича, лучше переходите на кубер».

Но либо я глючу, либо они выкинули из доки, потому что сейчас в доке по Swarm подобного нет.

Мировым сообществом

Сомнительно. Кубернетес, конечно, лидирует, но какие-никакие альтернативы ему есть и это хорошо.

да и сама компания Docker вроде таковым его считает

Не считает.

Сейчас не нашёл это место в доке, но по-моему, несколько лет назад, было написано: «Это устаревшая фича, лучше переходите на кубер».

Устаревшим считался некий docker classic swarm, которому на замену сделали некий docker swarm. Насколько я понимаю, это как со старым docker-compose и новым docker compose. Какой-то компонент переписали, и старую версию объявили устаревшей. Сама технология остаётся поддерживаемой.

Ниже цитата из документации, видимо раньше они неудачно эту мысль формулировали.

Docker Swarm mode is built into the Docker Engine. Do not confuse Docker Swarm mode with Docker Classic Swarm which is no longer actively developed.

ничего плохого нет ни в одном инструменте, просто есть случаи, когда его уместно использовать, а есть, когда не очень. если сворм закрывает ваши потребности, то это вполне подходящий инструмент. но условно переезжать между облаками будет менее болезненно, если вы ориентируетесь на куб, потому что он есть везде. так же, как и популярная СУБД у вас в облаках будет в виде managed, а экзотика нет, что увеличивает затраты на поддержку. только и всего.

Слишком скучно. Попробуй хотя бы nextcloud. Ну что сайт? Статика, ingress. А тут и php в кубе, и minio, и оператор для баз, и собсна, базы. Для talk вроде вообще stun/turn надо будет. Ещё какой-нибудь cilium освоить с bgp, для куба без kube-proxy, но с нормальным виртуальным балансировщиком. Недельку повозиться точно надо будет.