[Перевод] Перестаньте пытаться выучить весь Kubernetes сразу

Я архитектор и до сих пор отхожу от VMware: Kubernetes дался мне не сразу. Как выяснилось, я не один такой. С этим сталкиваются разработчики в нашей команде, которым нужно быстро освоить Kubernetes для повседневной работы. С этим же сталкиваются ИТ-специалисты широкого профиля у заказчиков: они десятилетиями эксплуатировали vSphere, а теперь уходят от него, потому что всё больше ПО поставляется в контейнерах.

Люди приходят к одному вопросу: с чего действительно начать изучение Kubernetes?

В поиске они получают примерно одинаковый набор бесполезных ответов: документацию Kubernetes, платный курс, пересказывающий ту же документацию, сертификационный трек, который слишком рано уходит в детали, подкасты с низкой плотностью полезной информации и подборки «лучших ресурсов» с десятками ссылок, которые невозможно прочитать за год. Многие из них ведут в корпоративные блоги.

Такие материалы редко помогают освоить ключевые концепции Kubernetes и собрать мысленную модель, на которую затем можно накладывать более глубокие знания.

Команда VK Cloud перевела статью о том, как начать изучать Kubernetes без попыток сразу охватить всю экосистему: сначала разобраться в базовых принципах работы кластера, а затем переходить к специализированным инструментам и сценариям эксплуатации. Все схемы взяты из оригинала статьи по ссылке.

Сначала выстройте каркас

Есть пять элементов каркаса, которые помогают выстроить эту мысленную модель, прежде чем погружаться в Kubernetes глубже.

Желаемое состояние и согласование. Это единственная идея, которая лежит в основе любого другого поведения Kubernetes. Вы не говорите ему запустить контейнер — вы объявляете, что контейнер должен существовать, и что-то постоянно сверяет реальность с этим объявлением, устраняя разрыв бесконечно, без каких-либо просьб с вашей стороны. Самовосстановление — это оно. Масштабирование — это оно. Rollout — это оно, только желаемое состояние меняется контролируемыми шагами. Если вы не разобрались с этим как следует, всё остальное выглядит как груда отдельных функций, которые нужно заучивать, а не как один и тот же механизм в разных обличьях.

Разделение control plane и worker-нод, и что на самом деле означает «disposable». Это тот момент, когда ваши годы работы с vSphere активно играют против вас. Заболевший хост ESXi выхаживают, переносят с него нагрузку, патчат, возвращают в строй. Заболевшую ноду Kubernetes заменяют. Любая здоровая нода может выполнять любую рабочую нагрузку, поэтому система не пытается спасти отказавшую — она просто прокладывает путь в обход неё. Это не второстепенная деталь реализации — это другие отношения с железом под вами. Если вы принесёте в кластер Kubernetes инстинкт vSphere нянчиться с конкретной машиной, вы потратите много сил, защищая то, что система спроектирована отпускать.

Четыре сетевых слоя, если считать от контейнера наружу. От контейнера к поду, от пода к Service, от Service к Ingress, от Ingress — во внешний мир. Большая часть путаницы с сетью в Kubernetes — это не сетевая проблема, а проблема «на каком слое это происходит на самом деле». IP-адрес пода реален, но непостоянен. IP-адрес Service виртуален и стабилен, и на нём напрямую никто не слушает. Знайте, на каком слое вы отлаживаете, и половина загадки исчезнет ещё до того, как вы тронете хоть одну команду.

Requests и limits как контракт на выживание, а не как рекомендация. Request — это то, что Scheduler использует, чтобы решить, куда поместится ваша рабочая нагрузка. Limit — это потолок, который нельзя пересекать. Ошибитесь в любую сторону — и получите один из двух исходов: впустую потраченные мощности, потому что вы заявили слишком много, или поды, вытесняемые в самый неподходящий момент, потому что вы заявили слишком мало и ноде не хватило места. Это самый распространённый разрыв между «работает в staging» и «падает в production», и он не имеет никакого отношения к коду вашего приложения.

Разворачивайте кластеры с Managed Kubernetes

Автоматизируйте деплой
и снижайте затраты на инфраструктуру
до 60%

Попробовать

Почему CNI и CSI вообще существуют как плагины. Kubernetes намеренно не поставляется с сетью или хранилищем «из коробки». Он определяет контракт и оставляет реализацию плагину. У маленького edge-кластера и мультизонального регулируемого окружения нет ничего общего в эксплуатации, а навязывание единого дизайна обоим было бы хуже, чем не выбирать ничего. Это важно не столько как технический факт, сколько как объяснение: это настоящая причина, по которой ландшафт инструментов разрастается именно так, как он разрастается. Как только вы поймёте, что эти пробелы намеренные, пятнадцать вариантов CNI на рынке перестают выглядеть хаосом. Они начинают выглядеть именно так, как и следовало ожидать от системы, которая выбрала гибкость вместо единого мнения.

Всё остальное — урок на другой день. Некоторые уроки следуют сразу же, например GitOps и Observability, другие могут подождать дольше. Рим строился не один день, как и полное понимание cloud-native. Нормально оставлять ответы на проблемы, которых у вас пока не было.

Не пытайтесь охватить всю карту

Если вам нужно выучить Kubernetes, но вы не знаете, с чего начать, — вот настоящий совет. Не начинайте с попытки охватить всю карту. Вам не нужен разговор о service mesh на первой неделе. Вам не нужно иметь мнение о policy engines², прежде чем вы развернули хотя бы одну работающую рабочую нагрузку.

Сначала выучите механизм: желаемое состояние, согласование — то, что заставляет всю систему вести себя именно так, как она себя ведёт. Затем — машину: control plane, worker-ноды и то, как именно «disposable» ломает ваши старые инстинкты. Затем — проводку: как запрос на самом деле доходит до контейнера и почему хранилище и сеть были оставлены плагинами, а не встроены изначально.

Этого достаточно, чтобы какое-то время выполнять работу. Остальное никуда не денется, и по пути вы будете сталкиваться с проблемами, которые помогут вам понять, что учить дальше. Всё это будет на месте в тот день, когда вы столкнётесь с конкретной проблемой, из-за которой service mesh или policy engine обретут смысл. К тому моменту вы всё равно выучите это быстрее, потому что наконец будете знать, какой вопрос задаёте.

Если эта публикация вас вдохновила и вы хотите поддержать автора — не стесняйтесь нажать на кнопку