Не пытайтесь выучить весь Kubernetes сразу¶
6.0/10
Контекст¶
Автор замечает, что у новичков в Kubernetes — от разработчиков до ИТ-специалистов с опытом vSphere — один и тот же вопрос: с чего начать. Обычные ответы (документация, курсы, сертификации, списки ресурсов) не дают ментального каркаса и уводят слишком глубоко и быстро.
Суть¶
По мнению автора, сначала нужно усвоить пять опор. Первая — желаемое состояние и сверка с реальностью: вы объявляете, что контейнер должен существовать, а система постоянно исправляет отклонения; так работают самовосстановление, масштабирование и раскатка. Вторая — разделение control plane и worker-узлов: больной узел не лечат, а заменяют, и это ломает привычку «нянчиться» с конкретным сервером. Третья — четыре сетевых уровня: контейнер→под, под→сервис, сервис→ingress, ingress→внешний мир; большинство путаницы — это вопрос «на каком уровне я отлаживаю». Четвёртая — requests и limits как контракт выживания: request определяет, куда планировщик поместит нагрузку, limit — потолок; ошибки дают либо перерасход ресурсов, либо выселение подов. Пятая — CNI и CSI существуют как плагины намеренно: Kubernetes задаёт контракт, а не реализацию, поэтому разнообразие инструментов — следствие выбора гибкости. Затем автор советует учить механизм, машину и plumbing, а не всю карту сразу; остальное появится, когда возникнет конкретная проблема.
Вывод¶
Главный вывод: не нужно пытаться охватить весь Kubernetes сразу. Достаточно построить ментальный каркас из нескольких базовых моделей, а детали изучать по мере появления реальных задач.