Коротко и по делу

в чем поинт ограничивать себя в инструментах?

Хорошо, давай не будем. Я думаю будет весело даже с pwndbg)

вообще спасибо за темку для ознакомления, над поиграться

что знает, то и двигает, как и дб2

любопытно, а что не так в селектеле? а то у них иногда бывают вкусные вакансии

вывалить в ответ про ХА, про "выключил любой сервер, как вы запоете?" и это для начала

если бы у селектела не работало, не думаю, что они доросли бы до размещения облигаций на бирже

https://vc.ru/tinkoff_invest/208177-keys-selectel-kak-rossiyskiy-data-centr-nachinaet-put-k-ipo

не проблема дорастать если у тебя половина вконтакте на серверах лежит и постоянная прибыль есть

Так получается, on premise аналогом AWS Fargate является OpenNebula ?

https://fosdem.org/2021/schedule/event/vai_serverless_opennebula/

Тогда вопрос, как к этому on premise serverless решению от  OpenNubula прикрутить on premise Kubernetes, чтобы получить локальный аналог "EKS on Fargate" ?

https://www.mobiquity.com/insights/four-differences-between-eks-fargate-and-node-managed

Т.е. чтобы локальный мастер Kubernetes делал скайлинг нагрузки в контейнерах не на обычных предопределенных рабочих узлах своего кластера, а в serverless custom docker OpenNebula. Т.е. чтобы каждый контейнер стартовал в персональной микровиртуалке OpenNebula, а не на общих виртуалках для нескольких подов Кубера. И чтобы ненужно было заранее резервировать рабочие узлы для локального Кубера.

https://opennebula.io/opennebula-firecracker-building-the-future-of-on-premises-serverless-computing/

Тогда у нас получились бы локальные on premise заменители Amazon сервисов для:
1) Lambda - Kubeless
2) EKS on Fargate - K8S on OpenNebula Firecracker

Все верно?

И правильно ли я понимаю, что в случае НЕ serverless ECS можно провести такую аналогию с Кубером:
Узел EC2 - рабочий узел Кубера
Task ECS - pod Кубера
?

Почему это может быть нужно?
1) Потому что на сегодняшний день с одной стороны, Кубер - это общепринятый индустриальный стандарт для деплоя из Helm charts.
2) А с другой стороны не хочется головняка с предварительным резервированием фиксированного числа локальных узлов  только под Кубер.
3) Больше безопасности в персональных микровиртуалках Firecracker on OpenNebula по сравнению со стеллажами подов на общих рабочих узлах обычного Кубера.

Ну и зачем, когда есть Fargate? - потому что нужен путь для отступления из проприетарного облака в локалку как обычно :)

А OpenStack+K8S или OpenShift такое умеет?
А GCP умеет аналог EKS on Fargate? Т.е. некий GKE on Container as a Service (CaaS) also called "serverless for containers".

Интересно, типовые шаблонные контейнеры Kubeless тоже можно стартовать в таком локальном Кубере + OpenNebula?

Еще интересное описание Fargate:
https://www.freecodecamp.org/news/amazon-fargate-goodbye-infrastructure-3b66c7e3e413/

@sanyo_devops Ты и дома сам с собой разговариваешь ? А есть внутренние голоса которые отвечают ?

Хом это серьёзно ,прям из жизни пример?

Просто я заранее формулирую свои вопросы. Пока народ еще спит.
Некоторые вопросы типа "А зачем это нужно" - я просто предвижу от чатика и заранее на них отвечаю :)

А без подробного описания моего хода мыслей, я боюсь, что простой вопрос, "где взять on premise аналог EKS on Fargate", может остаться без ответа.

PS: внутренних голосов нет (в отличии от других подконтрольных людей), но я считаю, что многие из окружения targetted individuals управляется псиопами (чтобы попытаться воздействовать на самих targetted individuals, которые ускользают из под общематричного управления), поэтому есть голоса или нет, в целом происходит как бы матричное управление игрушками https://en.wikipedia.org/wiki/Toy_Story
Т.е. по сути те самые "голоса" возникают не в голове targetted individual, а приходят из его окружения, например из чатика ;)
Иногда даже анонимные звонки, "надписи на заборе" например на аватарах форумов и т.п.

https://upload.wikimedia.org/wikipedia/en/thumb/1/13/Toy_Story.jpg/220px-Toy_Story.jpg