Здравствуйте, Vetal_ca, Вы писали:

V_>Здравствуйте, Zhendos, Вы писали:

Z>>А начнут внутри контейнеров внутри k8s запускать
Z>>"мили-контейрены" внутри "микро-контейренов" и специалистов вообще не найдется.

V_>Пресловутое, "Если/когда".

Э... Вы же сами писали что специалистов по k8s очень сложно найти,
я предположил что усложнив технологию еще получим совсем куцое количество специалистов.
Неужели вы не согласны что чем сложнее какой-то предмет тем меньше количество людей
в нем разбираются до конца?


V_>Для вышеприведенных проблем,
V_>1. Нужно знать пару базовых команд, docker exec / kubectl exec. Базовые знания Линукса и уметь пользоваться поиском. "Linux check IO load" или "Linux check network load". Если точно приложение "работает на моей машине"

Совершенно бы не помогло. Дело было в баге в ядре Linux, из которого лимиты по CPU применялись неправильно,
и контейнерам время от времени не давали кванты времени хотя оно было в избытке.


V_>2. Сразу, без поиска, вспомнилось когда читал хорошую книгу, Mario Luksa — Kubernetes in Action. "Part 3, Beyond the basics -> 11. Understanding Kubernetes internals, -> 11.1.5 Understanding the Scheduler

Совершенно бы не помогло. Дело было в побитых данных в etcd, из-за которых неправильно распределялись
задачи по кластеру.

То есть общая информацию знать конечно хорошо, можно быстрее понять куда копать,
но пары книжек явно не хватит при отладке всей это хрени из сотен разных программ
размазанных на куче физических машин. Есть подходы и инструменты чтобы бороться
со сложностью, но довести до простоты: одна машина — одна ОС без всякой виртуализации и одна программа
никогда не получится, и намного больше случаев когда вся это сложность не нужна,
чем наоборот.