Z>Ну проблема "технологии" является часть проблемы "люди". Z>Ведь от того насколько сложна технология зависит сколько тебе нужно Z>найти специалистов, какого уровня, сколько им платить и т.д.
Z>Поэтому отсутствие "специалистов" это естественно, сколько уровней абстракции Z>добавилось? Во скольких еще вещах нужно разбираться чтобы отладить почему Z>при незагруженном физическом CPU программы в контейнерах тормозят Z>или почему все контейнеры стали запускаться на одной физической машине из кластера, когда все другие Z>простаивают?
Z>А начнут внутри контейнеров внутри k8s запускать Z>"мили-контейрены" внутри "микро-контейренов" и специалистов вообще не найдется.
Пресловутое, "Если/когда".
Одни идут за теми, у кого получилось. Другие ищут повода, чтобы не начинать.
Как говорится "Слабый всегда ищет оправдания, сильный — возможности."
Для конструктива нужно "не почему у нас не получилось". А как у них получилось, интересные подходы и идеи.
Или, если не взлетело, "Как у известной компании XYZ не получилось с докером и/или кубернетес, что пошло не так и почему". Если ссылаться на "Некто с ником XYZ — у него не пошло". Здесь, или на собеседовании, то у собеседника возникает картинка "Лузер против облако-с-логотипами": "Госпади, откуда они берутся, пора закругляться и звать более перспективного"
Для вышеприведенных проблем,
1. Нужно знать пару базовых команд, docker exec / kubectl exec. Базовые знания Линукса и уметь пользоваться поиском. "Linux check IO load" или "Linux check network load". Если точно приложение "работает на моей машине"
2. Сразу, без поиска, вспомнилось когда читал хорошую книгу, Mario Luksa — Kubernetes in Action. "Part 3, Beyond the basics -> 11. Understanding Kubernetes internals, -> 11.1.5 Understanding the Scheduler
Предыдущее прочтение оставило в памяти, что эти компоненты взаимозаменяемы, включая планировщик. Направление поиска в зоне прямой видимости грамотного разработчика. И уж точно не причина для поиска повода для остановки в развитии.
Сегодня остановился, завтра через тебя переступили
