Kubernetes простыми словами: что это, зачем нужен и как запустить с нуля

Что такое контейнер и почему вообще понадобился KubernetesСкопировано

Когда разработчик пишет приложение у себя на ноутбуке — у него своя версия Python, свой набор библиотек, свой Linux. Когда это же приложение надо запустить на сервере — там другая версия Python, других библиотек половина не поставлена, и ядро вообще от 2018 года. Классическая боль: «у меня всё работает», а в продакшене падает.

Контейнер закрывает эту проблему. Это такая лёгкая коробка, в которой лежит код приложения плюс всё, что ему нужно для запуска: библиотеки, конфиги, зависимости, минимальное окружение. Запускаешь контейнер — и код везде ведёт себя одинаково: на твоём макбуке, на сервере, в облаке у Selectel или в Yandex Cloud. Это не виртуальная машина с целой ОС внутри — контейнер использует ядро хоста и весит десятки мегабайт вместо гигабайтов.

Главный инструмент для упаковки и запуска контейнеров — Docker. Он делает образ (image — шаблон контейнера) и потом из него поднимает один или несколько работающих контейнеров. Если ты только начинаешь разбираться в этом, посмотри сперва обзор профессии DevOps-инженер — там простыми словами разобрано, кто и зачем со всем этим возится.

Пока приложение маленькое и контейнеров три-четыре — Docker’а хватает. Запустил, пошёл пить кофе, всё работает. Но как только вместо одного сайта у тебя десяток микросервисов, каждый в нескольких копиях для отказоустойчивости, плюс базы данных, плюс кэши — ручной запуск превращается в кошмар. Кто следит, что контейнер упал и его надо перезапустить? Кто решает, на какой сервер поставить новую копию, если первый перегружен? Кто переключит трафик, если одна нода умерла?

Эту работу и делает Kubernetes — оркестратор контейнеров. Если Docker — это про «упаковать и запустить одну штуку», то Kubernetes — про «управлять сотнями таких штук на десятках серверов так, чтобы оно само поднималось, само лечилось и само масштабировалось». В подборке курсов по Kubernetes у нас собрано всё, где этому учат с нуля и до продакшен-уровня — пригодится в конце статьи.

Главная мысль раздела. Контейнер — это коробка с приложением и его окружением. Docker эти коробки делает. Kubernetes — управляет десятками и сотнями коробок одновременно: следит, чтобы все были живы, и распределяет их по серверам.

Что такое Kubernetes простыми словами и для чего его придумалиСкопировано

Kubernetes (произносится «кубернетес», на сленге часто пишут K8s — это сокращение, где 8 — количество букв между «K» и «s») — это система с открытым кодом, которая автоматизирует развёртывание, масштабирование и управление контейнеризированными приложениями. По-человечески — это автопилот для парка контейнеров.

Историю K8s стоит знать хотя бы кратко, потому что она объясняет, почему он стал стандартом. Внутри Google в нулевых работала система Borg — она крутила миллионы контейнеров в дата-центрах поиска, gmail и YouTube. В 2014 году Google открыл наследника Borg — Kubernetes — и передал его в фонд CNCF (Cloud Native Computing Foundation). С тех пор это open source, который поддерживают десятки компаний: Red Hat, Microsoft, IBM, VMware, Mail.ru Group и так далее.

Что Kubernetes делает за тебя:

• Запускает приложения одной командой. Описал в YAML-файле (это такой простой текстовый формат с отступами — типа упрощённого JSON для людей), что хочешь — пять копий веб-сервера на трёх серверах — отдал K8s, он сам разнёс контейнеры и поднял.
• Сам перезапускает упавшее. Если контейнер вылетел — Kubernetes поднимет его заново на той же или другой ноде (так называется отдельный сервер в кластере K8s). Тебя в три ночи не разбудят.
• Масштабирует под нагрузку. Пришли пользователи под Чёрную пятницу — K8s сам добавит копий приложения. Ушли — погасит лишнее, чтобы не платить за простаивающие мощности.
• Балансирует трафик. Запросы автоматически распределяются между копиями приложения. Одна упала — трафик уйдёт на живые.
• Раскатывает обновления без даунтайма. Новая версия выкатывается копия за копией. Если сломалось — откат на предыдущий релиз одной командой.
• Хранит секреты и конфиги отдельно от кода. Пароли к БД и ключи API не лежат в репозитории, а подкладываются в контейнер при запуске.

Есть свежая статистика, на которую любят ссылаться: по данным CNCF Annual Survey за 2024 год, Kubernetes используют 96% компаний, у которых вообще есть контейнеры, а в продакшене он стоит у 84% из них. В России картина похожая — Kubernetes стал отраслевым стандартом для всего, что хоть немного крупнее одного сервера. Поэтому DevOps без K8s — это уже не DevOps, и в обзоре зарплат DevOps-инженеров видно, насколько этот навык поднимает доход.

Когда Kubernetes реально нужен, а когда — лучше обойтисьСкопировано

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

Простой чек-лист на 10 пунктов. Чем больше пунктов про тебя — тем сильнее аргумент за K8s.

1. У тебя больше пяти микросервисов, которые надо деплоить независимо друг от друга.
2. Тебе нужна отказоустойчивость: одна нода падает — сервис продолжает работать.
3. Нагрузка сильно меняется во времени — днём пик, ночью пусто, по праздникам ×10.
4. Команда выкатывает несколько релизов в день, и хочется catch-and-release без даунтайма.
5. Приложение должно работать одинаково в dev, staging и проде, чтобы перестало «у меня работает».
6. Ты планируешь multicloud или гибрид — часть нагрузки в Yandex Cloud, часть на своих серверах.
7. В команде несколько разработчиков, и каждому нужно своё окружение для тестов.
8. Ты собираешь CI/CD-пайплайн и хочешь, чтобы деплой был просто шагом в нём.
9. В проекте есть stateful-нагрузки вроде баз и кэшей, которые надо запускать рядом с сервисами.
10. Ты готов выделить инженера или команду на поддержку K8s — это не «поставил и забыл».

А вот когда K8s — оверкилл и забирает время, которое можно потратить на продукт:

• Один сайт на одном сервере — VPS с Docker Compose решит задачу за вечер.
• Маленький стартап на ранней стадии, где гипотезы важнее инфраструктуры — выбирай serverless или PaaS вроде Vercel, Render, Cloud Run.
• Монолит, который никогда не превысит одного сервера — нет смысла в оркестрации.
• Команда из одного-двух человек без выделенного DevOps — операционная нагрузка съест всё время.
• Бюджет «лишь бы запустить» — managed K8s в облаке стоит от 5–10 тысяч рублей в месяц минимум за рабочий кластер, и это без приложений.

Принцип, проверенный на практике. K8s имеет смысл, когда боль от ручного управления контейнерами уже выше, чем боль от изучения и эксплуатации Kubernetes. До этого момента — не торопись.

Архитектура Kubernetes — control plane и рабочие узлыСкопировано

Кластер Kubernetes — это группа серверов, которые работают как одно целое. Серверы делятся на два типа: те, что управляют (control plane, она же управляющая плоскость), и те, что работают (worker nodes, рабочие узлы).

Control plane — мозг кластера

Это набор сервисов, которые принимают решения за весь кластер. Если control plane умер — кластер какое-то время ещё работает по инерции, но управлять им и катить релизы уже нельзя. Поэтому в продакшене мастеров обычно три или больше — для отказоустойчивости.

В control plane живут четыре главных компонента:

• API Server. Единая точка входа. Любая команда — от kubectl (это утилита командной строки, которой инженер общается с кластером с ноутбука) до запроса от внутреннего сервиса — приходит сюда. Это тот сервис, через который вообще всё происходит.
• etcd. Распределённая key-value база данных. В ней хранится вся желаемая конфигурация кластера: какие приложения должны быть запущены, в каком количестве копий, с какими настройками. Без etcd ничего нет.
• Scheduler (планировщик). Решает, на какую ноду посадить новый под (под — минимальный объект K8s, дальше расскажем). Учитывает свободные CPU и память, особые требования вроде GPU, правила affinity и anti-affinity.
• Controller Manager. Следит, чтобы реальное состояние кластера совпадало с тем, что записано в etcd. Если ты сказал «должно быть 5 копий», а одна вылетела — controller manager заметит и попросит scheduler поднять новую.

Worker nodes — рабочие лошадки

На воркерах крутятся сами приложения. Каждая нода — это виртуальная или железная машина с Linux, на которой стоит три обязательных компонента:

• Kubelet. Агент, который подключается к API Server, забирает оттуда задания (запусти такой-то под) и контролирует их выполнение на этой конкретной ноде.
• Container runtime. Софт, который реально запускает контейнеры. Раньше это был Docker, сейчас обычно containerd или CRI-O — они легче и заточены именно под K8s.
• Kube-proxy. Сетевой модуль, который занимается маршрутизацией трафика внутри кластера. Когда приложение А обращается к приложению Б по имени сервиса — вот этот ребёнок переводит имя в IP и направляет пакеты куда надо.

Аналогия для запоминания. Control plane — это диспетчерская такси: принимает заявки, распределяет машины, следит за статусом. Worker nodes — сами машины с водителями, которые везут пассажиров. Без диспетчерской машины не поедут осмысленно. Без машин диспетчерская будет принимать заявки в пустоту.

Главные объекты Kubernetes — мини-глоссарийСкопировано

Чтобы дальше не запутаться в терминах, разложим главные объекты K8s в одном месте. Объект в Kubernetes — это сущность, которую ты описываешь в YAML-файле и отдаёшь кластеру. Дальше K8s сам следит, чтобы реальность соответствовала описанию.

• Pod (под). Минимальный исполняемый объект. Внутри пода — один или несколько контейнеров, которые делят сеть и хранилище. Чаще всего один под = один контейнер. Поды — недолговечные: упал, удалился, заменился новым.
• ReplicaSet. Следит, чтобы в кластере всегда было ровно N копий конкретного пода. Если меньше — поднимает новые. Если больше — гасит лишние.
• Deployment. Уровнем выше ReplicaSet. Описывает, какое приложение и в скольких копиях ты хочешь, и умеет катить плавные обновления (rolling update) с откатом на предыдущую версию. Это тот объект, который в реальной жизни ты пишешь чаще всего.
• Service. Стабильная точка входа к набору подов. Поды постоянно меняются (умирают, пересоздаются с новыми IP), а Service даёт постоянное DNS-имя и IP, через который другие приложения обращаются к этой пачке подов.
• Ingress. Шлюз для трафика снаружи кластера в нужный Service. Тут описываются роутинг по доменам, TLS-сертификаты, базовые правила вроде «трафик с /api отправляй на сервис api, остальное на frontend».
• ConfigMap. Хранилище конфигурационных данных в открытом виде — настройки приложения, фиче-флаги, URL зависимостей.
• Secret. То же, что ConfigMap, но для чувствительных данных: паролей, ключей API, токенов. Хранятся в etcd в base64 и могут быть зашифрованы.
• Namespace. Логическая папка внутри кластера. Делит ресурсы между командами или окружениями (dev / stage / prod в одном кластере).
• Volume. Том с данными, который монтируется в под. Бывает временный (умирает с подом) и постоянный (PersistentVolume — переживает пересоздание подов).
• StatefulSet. Аналог Deployment, но для приложений с состоянием — баз данных, очередей. Гарантирует стабильные имена подов и привязку к конкретным дискам.
• DaemonSet. Гарантирует, что на каждой ноде кластера запущена ровно одна копия пода. Используется для системных штук вроде агентов мониторинга или сборщиков логов.
• Job и CronJob. Одноразовые и периодические задачи. Например, ночной бэкап базы или ежечасный пересчёт отчётов.
• Helm chart. Не объект K8s, но критичная штука рядом. Helm — это пакетный менеджер для Kubernetes, который позволяет описать целое приложение со всеми зависимостями одним пакетом и ставить его в кластер одной командой helm install.

Не нужно зубрить всё сразу. Pod, Deployment, Service, Ingress — четыре кита, без которых первый кластер не поднять. Остальное доберёшь по ходу.

Запускаем первый кластер локально через Minikube — пошаговоСкопировано

Самый безопасный способ потрогать K8s — поднять его у себя на ноутбуке. Для этого есть Minikube — облегчённая версия Kubernetes, которая запускает однонодовый кластер прямо в виртуальной машине или Docker-контейнере на твоей машине. Сломать продакшен оттуда невозможно — отличный полигон.

Что понадобится

• Компьютер с минимум 2 ядрами CPU, 4 ГБ RAM (свободных), 20 ГБ на диске.
• macOS, Linux или Windows 10/11.
• Установленный Docker Desktop (или просто Docker на Linux).
• Терминал и базовое умение в нём работать. Если с командной строкой Linux пока сложно — глянь обзор профессии Администратор Linux, там разобраны базовые команды.

Шаг 1. Установить Minikube и kubectl

На macOS проще всего через Homebrew:

brew install minikube kubectl

На Linux (Ubuntu/Debian):

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

На Windows — через chocolatey: choco install minikube kubernetes-cli.

Проверь, что обе утилиты встали:

minikube version
kubectl version --client

Если обе команды вывели версии без ошибок — едем дальше.

Шаг 2. Поднять кластер

minikube start --driver=docker

Команда говорит Minikube’у запустить однонодовый кластер K8s в Docker-контейнере. Первый запуск занимает 1–3 минуты — Minikube скачает образ ноды и поднимет внутри control plane плюс рабочую часть на одной машине. На выходе ты увидишь надпись «Done!» и подсказку, что kubectl теперь настроен на этот кластер.

Проверим, что кластер живой:

kubectl get nodes

Должна появиться одна нода со статусом Ready. Если статус NotReady и висит долго — обычно дело в нехватке оперативки или в том, что Docker не запущен. Проверь docker ps.

Шаг 3. Запустить первое приложение

Развернём в кластере веб-сервер nginx — простой тестовый стенд:

kubectl create deployment hello-nginx --image=nginx

Эта команда говорит K8s: «создай Deployment с именем hello-nginx из образа nginx с Docker Hub». Minikube стянет образ, scheduler выберет ноду (в нашем случае единственную), kubelet запустит контейнер. Через 10–30 секунд проверь:

kubectl get pods

Должен появиться под hello-nginx-xxxxx со статусом Running. Если status Pending дольше минуты — посмотри подробности через kubectl describe pod hello-nginx-xxxxx, там будет причина.

Шаг 4. Открыть приложение в браузере

Под работает, но снаружи кластера он недоступен. Чтобы достучаться, создадим Service типа NodePort:

kubectl expose deployment hello-nginx --type=NodePort --port=80

И откроем в браузере через minikube:

minikube service hello-nginx

Команда сама пробросит порт и откроет браузер на странице приветствия nginx. Поздравляю — у тебя только что отработал первый Kubernetes-кластер.

Шаг 5. Поэкспериментировать и убрать за собой

Попробуй увеличить количество копий приложения:

kubectl scale deployment hello-nginx --replicas=3
kubectl get pods

Должны появиться три пода вместо одного. Удали один из них — K8s тут же поднимет замену:

kubectl delete pod hello-nginx-xxxxx
kubectl get pods

Когда наигрался — потуши кластер, чтобы не есть память:

minikube stop
# или совсем удалить:
minikube delete

Совет на старт. Не пытайся сразу учить YAML-манифесты. Сначала покрути kubectl create, scale, expose руками — почувствуй, как K8s реагирует. Манифесты пишутся в один файл уже потом, когда понимаешь, что хочешь получить.

Запускаем Kubernetes в облаке: Yandex Cloud, VK Cloud, SelectelСкопировано

Minikube хорош для практики, но в продакшене нужен полноценный кластер из нескольких нод. Есть три варианта: ставить руками через kubeadm на свои серверы (долго и больно), брать managed Kubernetes у облачного провайдера (быстро, чуть дороже), или использовать платформенные решения вроде Deckhouse поверх своего железа. Для 95% случаев первый облачный кластер стоит брать managed — провайдер сам поднимает control plane, обновляет его, чинит ноды.

Для российского рынка три рабочих варианта.

Yandex Managed Service for Kubernetes

Самый известный российский managed K8s. Интегрирован с другими сервисами Яндекса — Yandex Object Storage для хранилищ, Cloud DNS для доменов, Cloud Logging для логов.

Что делать пошагово:

1. Зарегистрироваться в Yandex Cloud, создать платёжный аккаунт, активировать пробный период.
2. Перейти в раздел Managed Service for Kubernetes, нажать «Создать кластер».
3. Выбрать версию K8s (обычно одна из последних трёх стабильных), регион (ru-central1) и сетевые настройки.
4. Создать группу узлов: тип ВМ, количество (минимум 2 для отказоустойчивости), автомасштабирование.
5. Установить Yandex Cloud CLI и kubectl, настроить доступ: yc managed-kubernetes cluster get-credentials --id ... --external.
6. Проверить: kubectl get nodes — увидишь свои ноды.

Стоимость стартовая — от 5–7 тысяч рублей в месяц за рабочий кластер с двумя нодами. Документация — yandex.cloud/ru/docs/managed-kubernetes.

VK Cloud Kubernetes

Альтернатива Яндекса от VK Group. Логика похожая: создаёшь кластер через панель, добавляешь группы нод, получаешь kubeconfig.

1. Зарегистрироваться в VK Cloud, создать проект.
2. В разделе Kubernetes → «Создать кластер», выбрать предустановленные плагины (Ingress Controller, мониторинг).
3. Настроить группу нод: тип флейвора, диск, сеть.
4. Скачать kubeconfig из панели и положить в ~/.kube/config.

VK Cloud сильнее завязан на другие сервисы VK, что удобно, если уже используешь VK Cloud Storage или Cloud Logs. Документация — cloud.vk.com/docs/kubernetes/k8s.

Selectel Managed Kubernetes

Старая школа российского хостинга. Selectel предлагает managed K8s с упором на гибкость: можно прицепить bare-metal-серверы как ноды, что даёт серьёзный прирост производительности по сравнению с виртуалками.

1. В личном кабинете Selectel: «Облачные сервисы» → «Managed Kubernetes» → «Создать».
2. Выбрать регион (Москва, Санкт-Петербург), версию K8s.
3. Добавить группу нод: виртуальные или выделенные серверы.
4. Получить kubeconfig, использовать kubectl как обычно.

Ценник стартует от 4 тысяч рублей в месяц.

Совет по выбору. Если уже сидишь в облаке Яндекса (Object Storage, базы) — бери Yandex MK8s. Если нужна максимальная производительность под HPC и тяжёлые нагрузки — Selectel с bare-metal. VK Cloud — рабочий третий вариант, особенно если уже есть проекты в их облаке.

Если интересно, как вырастает специалист, который умеет ставить и сопровождать такие кластеры — почитай пошаговый roadmap «Как стать DevOps-инженером с нуля»: там разобраны 12 месяцев обучения и реальные вакансии.

Альтернативы Kubernetes — Docker Swarm, Nomad, serverlessСкопировано

Kubernetes — стандарт, но не единственный вариант. Иногда более простые инструменты решают задачу за вечер вместо двух недель настройки. Вот честное сравнение.

На практике переходить на K8s стоит, когда более простые варианты упёрлись в потолок: Docker Compose не вытягивает по объёму, Swarm не справляется с масштабом, serverless не подходит из-за stateful-нагрузок.

Главные ошибки новичков при запуске первого кластераСкопировано

Эти грабли встречаются у всех, кто заходит в K8s в первый раз. Если знать их заранее — сэкономишь себе и команде десятки часов.

• Сразу лезть в продакшен. Самая частая. Поставил managed K8s в Yandex Cloud, накатил приложение — и в проде. Через две недели первая авария показывает, что ты не знаешь, как читать логи, как работают liveness-probes и что такое resource limits. Сначала Minikube, kind или k3s локально две недели, потом продакшен.
• Не задавать requests и limits. Без них поды могут забрать всю память ноды и положить соседей. Лимиты должны стоять на каждом контейнере.
• Игнорировать liveness и readiness probes. Если K8s не знает, как проверить здоровье твоего пода — он не поймёт, что под завис, и не перезапустит его. Трафик при этом будет идти в зомби.
• Хранить пароли в ConfigMap или прямо в YAML. Для секретов есть Secret, и в идеале — внешний менеджер вроде HashiCorp Vault или Yandex Lockbox.
• Не настраивать резервное копирование etcd. Если ты на self-hosted кластере и потерял etcd — потерял весь кластер. Бэкап раз в сутки минимум.
• Делать один гигантский namespace. Все приложения в default — рецепт хаоса. Минимум — отдельные неймспейсы под dev, staging, prod.
• Не следить за метриками. Без Prometheus + Grafana или managed-аналога ты узнаешь о проблемах от пользователей. Мониторинг — не опция, а обязательный шаг сразу после первого деплоя.
• Тащить всё в один кластер. Production и dev в одном кластере на одном control plane — гарантированный простой обоих окружений в момент аварии. Минимум два кластера.
• Пытаться выучить весь K8s сразу. Pod, Deployment, Service, Ingress — четыре объекта, которые покрывают 80% задач. Helm, Istio, Operators, CRD — позже.
• Игнорировать обновления версий. K8s выпускает релизы каждые 4 месяца, поддержка версии — около года. Кластер на версии трёхлетней давности — мина замедленного действия.

Чек-лист готовности к продакшен-кластеруСкопировано

Перед тем как тащить K8s в боевой контур — пробегись по этому списку. Каждый пункт — это потенциальная авария, если не закрыт заранее.

1. Минимум 3 ноды control plane для отказоустойчивости (или managed-кластер у провайдера).
2. Минимум 3 worker-ноды, разнесённые по разным зонам доступности.
3. Resource requests и limits заданы на каждом контейнере.
4. Liveness и readiness probes настроены для всех приложений.
5. Автомасштабирование включено (HPA для подов, Cluster Autoscaler для нод).
6. Логи централизованы — Loki, ELK, Yandex Cloud Logging или эквивалент.
7. Метрики и алерты — Prometheus + Grafana или managed-аналог. Настроены оповещения на падение подов и ноды.
8. Бэкапы etcd (для self-hosted) или managed-провайдер делает их за тебя.
9. Секреты не лежат в YAML и в репозитории — только Secret + менеджер секретов.
10. RBAC настроен: у каждого инженера свои права, у CI/CD — свой service account с минимально необходимыми правами.
11. Network Policies ограничивают трафик между неймспейсами и подами.
12. План обновления версии K8s на ближайшие 12 месяцев.

Если хотя бы 9 пунктов из 12 — зелёные, кластер можно запускать в прод. Меньше — возвращайся к доработке.

Где научиться Kubernetes и DevOps в 2026 годуСкопировано

Самостоятельно собрать знания по K8s можно: официальная документация на kubernetes.io, бесплатный интерактивный туториал Kubernetes Basics, KodeKloud Labs, Killercoda. Но это путь на год минимум, без структуры и без практики на реальных кейсах.

Курсы по Kubernetes ускоряют процесс в разы — ты получаешь чёткую программу, разбираешь типовые ошибки с ментором, делаешь пет-проект, который потом несёшь на собес. Для тех, кто хочет освоить K8s целенаправленно — собрали актуальную подборку:

Больше программ — в полном каталоге курсов по Kubernetes

А если ты только заходишь в DevOps-инженеры с нуля и K8s — пока далёкая цель — стартуй с обзора зарплат DevOps-инженеров и пошагового roadmap «Как стать DevOps-инженером». Там разобрано, в каком порядке ставить навыки и где K8s в этом списке появится.

Что почитать и посмотреть дальшеСкопировано

Когда первый кластер у тебя уже работает, а Pod, Deployment и Service не вызывают ужаса — двигайся дальше по этим источникам:

• Книги: «Kubernetes in Action» Марко Лукши (классика, есть русский перевод), «Kubernetes: Up and Running» от O’Reilly, «Programming Kubernetes» для тех, кто хочет писать operators.
• Документация: kubernetes.io/docs — лучшая официальная документация в open source. Прочитать раздел Concepts от и до — обязательная программа.
• Helm: helm.sh — пакетный менеджер для K8s. Без него катить большие приложения — мучение.
• CNCF Landscape: landscape.cncf.io — карта всего стека инструментов вокруг K8s: ingress-контроллеры, service mesh, CI/CD, мониторинг.
• YouTube-каналы: TechWorld with Nana (на английском, лучший вход), DevOps Toolbox, Cloud Native Computing Foundation.
• Telegram-каналы: @kubernetes_ru, @devops_chatik, @ru_devops — живое сообщество и обсуждение свежих кейсов.
• Практика: Killercoda и KodeKloud — браузерные песочницы с готовыми сценариями. Часовая практика в неделю даёт больше, чем час чтения.

Важная штука — сертификации CNCF. CKA (Certified Kubernetes Administrator) и CKAD (Certified Kubernetes Application Developer) реально котируются на рынке. Стоят около 300–400 долларов, но при сдаче дают +20–30% к зарплатной планке. На SDLC и жизненном цикле разработки разобрано, где K8s встраивается в общий процесс — пригодится для понимания контекста.

Kubernetes — это не магия и не заклинание из мира Google SRE. Это просто инструмент, который решает конкретную задачу: управлять десятками контейнеров на десятках серверов так, чтобы оно работало само. Месяц фокусированной практики — и ты уже свободно гоняешь поды и катишь релизы. Ещё через полгода — собираешь свой первый продакшен-кластер. Главное — начинать с малого: Minikube, один Deployment, одно приложение.