Тут вопрос по инфраструре kubernates можно задать ? Я в

этой теме имею некую кашу в голове от всего узученного мной
Или киньте пожалуйста линк чата где можно обратиться с таки вопросом


Опишу пример

Интернет магазин

Разбит на микросервисы:
1- микросервис аунтификации
2- микросервис товаров
3- микросервис корзины(процесс покупки)
4- микросервис организации доставки
5- микросервис возврата товаров

Размещается это все в кластер ,kubernates на EKS


Создается 3 ноды (хосты)

В ноде расположены поды

Под содержат docker ,контейнер с соответствующим микросервисом


Тут k8s заметил,что на под  который содержит микросервис (2-) списка товаров идет большая нагрузка


Что он сделает дальше создаст копию этого Pod и разместит на Node2 ,а если и она перегрузится создаст Node3

Т.e всего в ручную создано 3 Ноды

А может ли kubernates создавать сам новые ноды ,если уже 3 заняты для новых копий подов?

Т.е если у меня нагрузка возникает только в некоторые дни

Зачем мне создавать ноды на облаке и постоянно за них платить если они ничего не делают

Хочется чтобы они создались сами когда это будет нужно

Вот это такой простой пример ,немогу найти внятной информации как это сделать

Куча воды но  конкретного примера нет

А на амазон экспериментировать не особо хочется дабы не попасть на деньги)

Ну и еще к этому нужно добавить балансировщик

Где он в этой схеме будет тоже не совсем понятно

ChatGpt пишет что вообще за приделами k8s ...

1. Зачем ты деплоишь микросервисы, если ты не знаком с кубером? 2. Autoscaling kubernetes - первая страница гугла. И да, ты должен быть в облаке

Хочу понять как на нем инфраструктуру строить когда нет в команде devops

посмотри на GKE Autopilot, там тебе ни с нодами, ни с виртуалками работать не нужно. гугл сам поскейлит. либо иди в сторону serverless контейнеров, с тз инфры это будет проще, но менее удобно

Микросервисы можно деплоить и без кубера , например тот же AWS EC2

самому изучать сисадминство и девопс практики

Их можно деплоить и по FTP, но у тебя вопрос был про кубер. Это к чему?

Не мне нужно с кубером разобраться

тебе не ноды создавать надо, а ресурсы докидывать на них

Называется cluster autoscaling, работает с автоскейлинг группами

Если я размещу весь проект ( 5 микросервисами- проект для примера)) В одном поде чем это плохо ? Ну все равно же это одна рабочая нода и запросы идут на нее ,как хост машина А вторую рабочую ноду создать как резервною с копией всего проекта в одном поде в котором содержится 5 докер имиджей проекта (тобеж 5 микросервисов) Как я понимаю лягла нада 1 ,перейшли запросы на noda2 И там весь проект и все работает А если я раскидаю эти микросервисы по разным нодам ,то у меня тогда случится так что половина проекта будет не рабочей е,ли ляжет какая-то нода Вот этот момент я не очень понимаю

В одном поде?)

Ресурсы ввиде чего? Когда внутри ноды создавать новые поды ,как копии инстансов?

для этого тебе надо жить в опенстеке каком-нибудь, или gke, aws. запросишь еще цпу или памяти и все

Если свой пет проект сделат,хочется чтобы было дешевле

так.... класстер - это логическая такая штука куда ты деплоишь ноды - это именно физические виртуалки со своими ресурсами. Например у тебя может быть класстер из 3-х нод, каждая 8 ядер и 64 гига оперативки. В сумме класстер 24 ядра и 192 гига оперативки. поды - это юнит репликации. Под всегда крутится на одной ноде. когда ты деплоишь ты деплоишь под. Когда ты скейлишь ты скейлишь под. Точнее ты скейлишь деплоймент, а деплоймент рулит подами. контейнера. контейнера крутятся в подах на одной машине внутри своей сети. У контейнеров есть resource requests. тип "этому контейнеру надо 2 ядра и 4 гига оперативки, этому 0.1 ядро и 128 метров. Сумма ресурсов пода учитывается кубером при масштабировании и принятии решений куда на какую ноду его запихнуть, где ресурсов достаточно. Если в класстере ресурсов недостаточно - кубер может новую ноду поднять как ты ему сказал и где. Исходя из этого.... запихнуть все в один под = у тебя нет смысла в кубере больше. Один под = одна нода. Если у тебя их три будет простаивать. Скейлить все одновременно - не оч эффективно с точки зрения утилизации ресурсов. На случай когда нода падает у тебя кубер вопервых переподнимет под на живых нодах, а во вторых надо иметь реданденси какой-то что бы кубер трафик перенаправил. Иначе у тебя все живет на одной ноде и все разом упало.

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

ну не разом, по дефолту ж rolling upgrade. причем дефолтны сначала поднимут все а потом потушат все. Когда новый под ready

с роллинг апдейт так вообще, если +1, то это требование 2x ресурсов или жить без грейсфул

емнип отдельно контейнер в поде не перезапустить, я про это. Что типа убивать целиком под придётся, даже если ты env поменял ток в одном сервисе

да, поды целиком прибивают

Учить девопс

девопс это философия, ее нельзя учить. выучить кубер это не про дэвопс)

Почему нет смысла запихивать все в один под не совсем понял Скажем условно если у меня в поде сервер на Go там один процесс на запросы ,которве обрабатываются в пуле потоков этого процесса (гоурутинами) На этой же Work - Node я если создам втоторой под я смогу просто запустить втрой ,третий ... процесс на barmetal ? Ну типа один под обрабатывает не больше 10 000 запросов ,как kvm Разве так не эффективно будет использовать ресурсы?

разные процессы разные процессы, они не шарят ресурсы. Если ты их сделал разными процессами то для них разница на одной ноде они или нет только в IPC и насколько плотно они должны общаться (лэтенси потому что). При этом тебе никто не запрещает сказать куберу "эти поды клади вместе всегда на одну ноду" (афинити всякие).

Если нет опыта с k8s возможно проще деплоить serverless, пока денег на девопса не хватит. По моему опыту имеет смысл заводить k8s, когда количество сервисов приближается к 20. Автоскейл нодов и подов можно настроить достаточно легко. Обычно критериями для скейла являются память или CPU, потому что количество запросов не всегда коррелирует с необходимостью скейла

Он там дрочит на CPU и кэш мисы. Хотя по факту у него там какие-то проблемы с выбором алгоритмов и структур данных.

Это я видел :-)

Философию тоже можно учить. Как раз даёт понять что отмазки я не знаю кубер, не катят в Девопс. Хотя я бы не назвал это философией, скорее подход или методология, на крайний случай mindest