Перейти к основному содержимому

Первые шаги с Docker и Kubernetes

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ
Разработчику Архитектору Инженеру

Установка Docker Desktop​

Docker Desktop — это графическое приложение, которое объединяет движок Docker, клиент командной строки и инструменты виртуализации. Для работы на Windows требуется активировать функции виртуализации в BIOS/UEFI материнской платы.

Системные требования​

  • Операционная система: Windows 10 или Windows 11 (версии 20H2 и выше).
  • Архитектура процессора: x64 с поддержкой виртуализации (Intel VT-x / AMD-V).
  • Память: минимум 4 ГБ ОЗУ (рекомендуется 8 ГБ и более).
  • Диск: свободное место не менее 5 ГБ.

Пошаговая установка​

  1. Скачивание установщика. Перейдите на официальный сайт проекта Docker и скачайте файл Docker Desktop Installer.exe.
Docker Desktop Installer.exe

Разбор:

  • Это имя файла установщика, а не команда для терминала; запускают двойным щелчком или из PowerShell: .\Docker Desktop Installer.exe install.
  • Установщик подтягивает Docker Engine, CLI, Compose и (по выбору) компонент Kubernetes.
  • На Windows 10/11 рекомендуется бэкенд WSL 2: Linux-ядро в WSL выполняет контейнеры быстрее, чем старый режим только на Hyper-V.
  1. Запуск установки. Запустите скачанный файл от имени администратора.
  2. Настройка компонентов. В мастере установки отметьте галочками следующие опции:
    • Использование гипервизора Hyper-V.
    • Использование WSL 2 (Windows Subsystem for Linux) версии 2. Это критически важно для производительности и совместимости с Kubernetes.
  3. Завершение. Дождитесь окончания процесса и перезагрузите компьютер при необходимости.
  4. Первый запуск. Откройте приложение Docker Desktop. Иконка в трее должна стать зеленой, что свидетельствует о готовности движка.

Если WSL 2 ещё не включён, в PowerShell от имени администратора (Windows 10 2004+ / Windows 11) обычно достаточно:

wsl --install

Разбор:

  • wsl --install ставит подсистему WSL, ядро WSL 2 и дистрибутив по умолчанию (часто Ubuntu); после перезагрузки выполните wsl --set-default-version 2.
  • На старых сборках или при ручной настройке включают компоненты через DISM/Optional Features, в PowerShell это Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux -All и Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -All (нужна перезагрузка).
  • VirtualMachinePlatform даёт лёгкую виртуализацию для WSL 2; без неё Docker Desktop на WSL 2 не стартует.
  • Hyper-V в мастере Docker Desktop — отдельный путь (Windows Pro/Enterprise); с WSL 2 Hyper-V для самих контейнеров обычно не обязателен, но опции могут пересекаться на одной машине.

Проверка работоспособности​

В PowerShell или командной строке:

docker --version

Разбор:

  • Вызывает клиент Docker CLI из PATH; версия клиента должна совпасть с тем, что ставит Docker Desktop.
  • Если команда не найдена — Docker Desktop не запущен или каталог CLI не добавлен в PATH (перезапуск терминала после установки).
  • На Windows CLI общается с демоном через named pipe //./pipe/docker_engine (WSL 2 или Hyper-V бэкенд — в Settings → General).

Система выведет номер версии, например: Docker version 24.0.7, build afdd53b.

Docker version 24.0.7, build afdd53b

Разбор:

  • Пример ожидаемого вывода: номер релиза клиента и короткий идентификатор сборки (build …).
  • Строка подтверждает, что бинарник docker доступен; для полной проверки движка нужен docker run (ниже).
  • Версии клиента и сервера (docker version без флагов) могут отличаться по полям — для диагностики смотрите и Client, и Server.

Выполните тестовый запуск образа для проверки изоляции процессов:

docker run hello-world

Разбор:

  • docker run создаёт контейнер из образа; если образа нет локально, CLI выполняет неявный docker pull с Docker Hub.
  • hello-world — минимальный образ, который печатает приветствие и завершается; успех означает, что демон Docker и сеть до реестра работают.
  • На WSL 2 бэкенде контейнер выполняется внутри Linux VM в WSL, а не как нативный процесс Windows.

Play ITЗагрузка интерактивного демо…

Работа с образами и запуск контейнеров​

Образ (Image) — это неизменяемый шаблон, содержащий код приложения, библиотеки и зависимости. Контейнер — это запущенный экземпляр образа.

Получение образов из реестра​

Реестр Docker Hub — основное хранилище публичных образов. Загрузка образа (pull), пример Nginx:

docker pull nginx:1.27-alpine

Разбор:

  • pull скачивает слои образа в локальное хранилище Docker Desktop (на диске Windows, каталог WSL-дистрибутива docker-desktop-data при бэкенде WSL 2).
  • nginx — имя репозитория на Docker Hub; 1.27-alpine — тег (версия + базовый образ Alpine Linux).
  • Указывайте конкретный тег, а не latest, чтобы повторные деплои не подтягивали неожиданную версию.

Указывайте конкретный тег (1.27-alpine), а не latest: иначе повторный деплой может подтянуть другую версию без изменения манифеста.

Просмотр доступных образов​

Список локальных образов:

docker images

Разбор:

  • Показывает образы в локальном store движка (аналог docker image ls).
  • Колонки REPOSITORY, TAG, IMAGE ID, CREATED, SIZE помогают убедиться, что pull завершился и какой тег закэширован.
  • Один IMAGE ID может соответствовать нескольким тегам, если они указывают на один и тот же манифест.

Вывод содержит таблицу с колонками:

  • REPOSITORY: имя образа.
  • TAG: версия образа.
  • IMAGE ID: уникальный идентификатор слоя.
  • CREATED: дата создания.
  • SIZE: размер на диске.

Запуск контейнера​

Команда docker run создает и запускает контейнер из указанного образа.

Базовый пример запуска Nginx:

docker run -d --name my-web-server nginx:1.27-alpine

Разбор:

  • -d (detached) — контейнер в фоне, терминал не привязан к stdout процесса в контейнере.
  • --name my-web-server — стабильное имя для docker stop, docker logs, docker rm вместо автогенерируемого.
  • nginx:1.27-alpine — образ из локального кэша или с Hub; без -p порты на хост Windows не публикуются.

Проверка состояния контейнера​

Список активных контейнеров отображается командой:

docker ps

Разбор:

  • По умолчанию только работающие контейнеры на текущем контексте Docker Desktop.
  • Колонки PORTS, NAMES, STATUS показывают проброс портов и имя, заданное через --name.
  • Если список пуст после docker run -d, смотрите docker ps -a — контейнер мог сразу завершиться с ошибкой.

Чтобы увидеть все контейнеры (включая остановленные), добавьте флаг -a:

docker ps -a

Разбор:

  • -a / --all добавляет контейнеры в состоянии Exited, Created и т.д.
  • Полезно после сбоя entrypoint: контейнер есть, но не в Up.
  • STATUS вида Exited (1) намекает на код возврата процесса PID 1 в контейнере.

Доступ к приложению внутри контейнера​

По умолчанию контейнеры изолированы от сети хоста. Чтобы открыть приложение по IP-адресу компьютера, необходимо пробросить порт.

Пример запуска с пробросом порта 80:

docker run -d -p 8080:80 --name my-web-server nginx:1.27-alpine

Разбор:

  • -p 8080:80 — публикация порта: 8080 на хосте Windows → 80 внутри контейнера (Nginx слушает 80).
  • На Docker Desktop с WSL 2 localhost:8080 на Windows перенаправляется в контейнер через сеть бэкенда.
  • Повторный docker run с тем же --name завершится ошибкой, пока старый контейнер не удалён (docker rm).

Откройте браузер и перейдите по адресу http://localhost:8080. Вы увидите приветственную страницу Nginx. Тот же сценарий через Compose (nginx + проброс порта) — стек №1.

Управление жизненным циклом​

Остановка и удаление контейнера выполняются отдельными командами:

docker stop my-web-server
docker rm my-web-server

Разбор:

  • docker stop посылает SIGTERM процессу PID 1, затем SIGKILL по таймауту; имя должно совпадать с --name или ID из docker ps.
  • docker rm удаляет остановленный контейнер; для работающего сначала stop или docker rm -f.
  • Данные в анонимных томах без -v при rm не всегда стираются — именованные тома переживают контейнер.

Для удаления всех контейнеров и очистки пространства можно использовать:

docker system prune

Разбор:

  • Удаляет остановленные контейнеры, неиспользуемые сети, "висячие" образы и кэш сборки (по подтверждению).
  • Не трогает работающие контейнеры и образы, на которые есть ссылки у запущенных контейнеров.
  • docker system prune -a агрессивнее — снимает неиспользуемые образы без тегов у running; в учебной среде осторожно.

Эта команда удалит остановленные контейнеры, неиспользуемые сети и дубликаты образов.

18 команд Docker — карманный набор

Вы уже попробовали pull, run, ps, stop, rm и system prune.

Полный список с пояснениями — build, push, exec, logs, inspect, cp, save/load и другие — в универсальной шпаргалке.

Настройка Kubernetes на локальной машине​

Kubernetes (K8s) — это система автоматизированного развертывания, масштабирования и управления контейнеризированными приложениями. На Windows проще всего включить встроенный кластер в Docker Desktop (одноузловой control plane + worker). Альтернативы: Minikube или kind — отдельная установка, если Docker Desktop Kubernetes не используете. Ниже — сценарий с Docker Desktop.

Активация Kubernetes в Docker Desktop​

  1. Откройте настройки Docker Desktop (шестеренка в левом верхнем углу окна).
  2. Перейдите во вкладку Settings -> Kubernetes.
  3. Установите переключатель Enable Kubernetes в положение "Вкл".
  4. Нажмите кнопку Apply & Restart. Система перезапустит сервисы и создаст кластер.

Процесс может занять несколько минут. В трее появится индикатор статуса кластера.

Установка CLI клиента kubectl​

Инструмент kubectl позволяет взаимодействовать с API сервером Kubernetes. Он устанавливается автоматически вместе с Docker Desktop, но его наличие нужно проверить.

kubectl version --client

Разбор:

  • Печатает версию только клиента kubectl; флаг --client не требует работающего кластера.
  • Бинарник ставится Docker Desktop вместе с CLI; PATH обновляется после установки/перезапуска терминала.
  • Если ошибка "не найден" — скачайте kubectl.exe с сайта Kubernetes и добавьте каталог в переменную PATH пользователя Windows.

Если вывод показывает ошибку, скачайте бинарный файл kubectl.exe с официального сайта Kubernetes и поместите его в папку, добавленную в переменную окружения PATH.

Проверка состояния кластера​

Команда kubectl get nodes отображает узлы (ноды) кластера.

kubectl get nodes

Разбор:

  • Обращается к API встроенного кластера Docker Desktop; контекст по умолчанию обычно docker-desktop.
  • Узел docker-desktop — единственная нода control plane и worker на локальной машине.
  • NotReady чаще всего значит, что Kubernetes ещё поднимается после Apply & Restart или не хватает ресурсов WSL 2 (память в Settings → Resources).

Ожидаемый вывод:

NAME     STATUS   ROLES           AGE   VERSION
docker-desktop   Ready    control-plane          5m   v1.29.0

Разбор:

  • STATUS Ready — kubelet на ноде здоров и принимает поды.
  • ROLES control-plane — на этой ноде же работают компоненты управления (в учебном кластере всё на одной VM WSL).
  • VERSION — версия kubelet/kubernetes на ноде; номер может отличаться от версии клиента kubectl.

Статус Ready означает, что нода готова принимать рабочие нагрузки.

Play ITЗагрузка интерактивного демо…

Развёртывание приложения и оркестрация​

Оркестрация включает создание манифестов (описаний ресурсов), их применение к кластеру и мониторинг состояния.

Namespace (необязательно)​

По умолчанию ресурсы попадают в namespace default. Для изоляции учебного приложения:

kubectl create namespace dev

Разбор:

  • Создаёт логический изолятор имён; объекты в dev не видны в default без -n dev.
  • kubectl create namespace — императивная команда; в проде чаще namespace в YAML и kubectl apply.
  • Для учебных манифестов ниже можно оставить default или добавить metadata.namespace: dev.

В манифестах добавьте metadata.namespace: dev или применяйте с -n dev.

Создание манифеста Deployment​

Манифест описывает желаемое состояние приложения. Создайте файл deployment.yaml со следующим содержимым:

Код ITЗагрузка примера кода…

Разбор:

  • apiVersion: apps/v1 и kind: Deployment — версия API и тип ресурса для управляемого набора подов.
  • replicas: 2 — желаемое число идентичных подов; контроллер Deployment создаёт ReplicaSet.
  • selector.matchLabels и template.metadata.labels с app: my-app должны совпадать, иначе Deployment не привяжет поды.
  • image: nginx:1.27-alpine — образ из Docker Hub; kubelet на ноде docker-desktop скачивает его через runtime Docker Desktop.
  • containerPort: 80 — порт контейнера для Service и probe (сам по себе наружу не публикует).

★ Pod и контейнер. Deployment создаёт поды — на практике в поде один контейнер приложения. Несколько реплик Deployment — это несколько подов с одинаковой меткой app: my-app.

★ ReplicaSet. Deployment управляет объектом ReplicaSet, тот поддерживает нужное число Pod'ов с меткой app: my-app. Отдельный манифест ReplicaSet вручную почти не пишут.

Служба Service​

Поды получают IP при создании, но при перезапуске IP меняется. Service даёт стабильное имя и балансирует запросы между подами с подходящими метками.

Создайте service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
    - port: 80
      targetPort: 80

Разбор:

  • type: ClusterIP — виртуальный IP только внутри кластера; с Windows-хоста напрямую не открыт без port-forward или Ingress.
  • selector.app: my-app должен совпадать с метками подов из Deployment.
  • port: 80 — порт Service; targetPort: 80 — порт контейнера nginx в поде.

Метка app: my-app в selector обязана совпадать с template.metadata.labels в Deployment. Service получает стабильный DNS: my-app-service (в namespace default — my-app-service.default.svc.cluster.local). Проверка Endpoints:

kubectl get endpoints my-app-service

Разбор:

  • Endpoints — список IP:port подов, прошедших selector Service.
  • Пустой список при "живых" подах — несовпадение меток или поды не в Ready.
  • Имя my-app-service совпадает с metadata.name в service.yaml.

Внешний HTTP-трафик с интернета обычно идёт через Ingress + Ingress Controller; для локальной проверки на Windows удобнее port-forward (ниже).

Применение конфигурации​

Для внедрения ресурса в кластер:

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

Разбор:

  • kubectl apply — декларативное создание/обновление; в PowerShell те же команды, если kubectl в PATH.
  • -f указывает файл манифеста; путь относительно текущей директории терминала.
  • Порядок Deployment → Service логичен, но Service можно применить и до появления подов (endpoints заполнятся позже).

Система сообщит о создании ресурсов:

deployment.apps/my-app-deployment created
service/my-app-service created

Разбор:

  • deployment.apps/... — группа API apps, ресурс Deployment зарегистрирован в кластере.
  • created — объект новый; при повторном apply с изменениями будет configured.
  • Ошибки валидации YAML или API версии выводятся до этой строки.

★ Цикл согласования (reconcile). Вы задаёте желаемое состояние (replicas: 2). Control plane сравнивает его с фактическим и через контроллеры создаёт или удаляет Pod'ы, пока расхождение не исчезнет. После apply достаточно проверить поды (см. блок "Проверка работы подов" ниже).

От манифеста до Running

После apply манифест попадает в API Server и etcd, Scheduler назначает Pod на ноду, kubelet скачивает образ, поднимает сеть и контейнеры.

Полная цепочка (фазы Pending → Running, завершение и SIGTERM) — в разделе жизненный цикл Pod.

Проверка работы подов​

Под (Pod) — минимальная единица развёртывания в Kubernetes. Статус созданных экземпляров:

kubectl get pods

Разбор:

  • В default namespace покажет поды с префиксом my-app-deployment-….
  • READY 1/1 — контейнер прошёл readiness (если probe не заданы, часто сразу после старта).
  • STATUS ContainerCreating / ImagePullBackOff — сигнал смотреть kubectl describe pod.

Пример вывода:

NAME                                READY   STATUS    RESTARTS   AGE
my-app-deployment-5d4f8b7c9-x2k4l   1/1     Running   0          10s
my-app-deployment-5d4f8b7c9-j9m3n   1/1     Running   0          10s

Разбор:

  • Два пода соответствуют replicas: 2; суффикс после hash — уникальный идентификатор ReplicaSet.
  • Running и 1/1 — процесс nginx в контейнере запущен.
  • RESTARTS 0 — контейнер не перезапускался из-за падений.

Статус Running и значение 1/1 означают, что контейнер успешно запустился.

Масштабирование приложения​

Kubernetes позволяет изменять количество реплик без остановки сервиса.

Увеличение количества копий до 5:

kubectl scale deployment my-app-deployment --replicas=5

Разбор:

  • Меняет поле spec.replicas Deployment без правки YAML на диске (до следующего apply -f файл и кластер могут разойтись).
  • Контроллер создаёт дополнительные поды на ноде docker-desktop, если хватает CPU/RAM WSL.
  • Имя my-app-deployment — metadata.name из манифеста.

Проверка результата:

kubectl get pods

Разбор:

  • Должно отображаться пять подов в Running (при достаточных ресурсах).
  • Часть в Pending — нехватка ресурсов на локальном кластере; смотрите kubectl describe pod для событий scheduler.
  • Service продолжит балансировать между всеми подами с меткой app: my-app.

Теперь в списке будет пять работающих подов.

Предоставление доступа извне​

Внутри кластера приложение уже доступно по DNS имени my-app-service. Для доступа с хоста (браузер на Windows) удобнее всего port-forward; тип LoadBalancer в Docker Desktop часто долго остаётся в pending. Тип NodePort (порт 30000–32767 на узле) — альтернатива, если нужен доступ без port-forward.

Цепочка с Ingress в production: браузер → Ingress Controller → Service → Pod.

Получение информации о службе:

kubectl get svc my-app-service
kubectl port-forward svc/my-app-service 8080:80

Разбор:

  • kubectl get svc — ClusterIP и порты Service; EXTERNAL-IP для ClusterIP обычно <none>.
  • port-forward поднимает туннель с localhost Windows на порт Service: 8080 локально → 80 у Service (дальше на targetPort подов).
  • Процесс port-forward держит терминал занятым; остановка — Ctrl+C.

Теперь приложение доступно по адресу http://localhost:8080.

Мониторинг и управление​

Эффективное управление требует постоянного отслеживания логов и ресурсов.

Просмотр логов​

Для просмотра вывода приложения из конкретного пода:

kubectl logs my-app-deployment-5d4f8b7c9-x2k4l

Разбор:

  • Имя пода — из kubectl get pods (суффикс hash у каждого деплоя свой).
  • Логи — stdout/stderr контейнера nginx-container из манифеста.
  • Флаг -f добавляет потоковый просмотр (аналог tail -f).

Просмотр логов всех подов в рамках деплоймента:

kubectl logs -l app=my-app

Разбор:

  • -l app=my-app — селектор по метке; собирает логи со всех подов с этой меткой.
  • Удобно при нескольких репликах без перечисления имён подов.
  • Для Deployment с несколькими контейнерами указывают -c имя-контейнера.

Описание ресурса​

Команда kubectl describe предоставляет детальную информацию о состоянии объекта, включая события и ошибки:

kubectl describe pod my-app-deployment-5d4f8b7c9-x2k4l

Разбор:

  • Секция Events внизу — главный источник при ImagePullBackOff, CrashLoopBackOff, проблемах монтирования томов.
  • Показывает назначенную ноду, IP пода, условия Ready, лимиты и probe.
  • Подставьте актуальное имя из kubectl get pods вместо примера из статьи.

В разделе Events можно увидеть процессы создания, привязки к узлу и возможные сбои.

Удаление ресурсов​

Для полного удаления приложения из кластера:

kubectl delete -f deployment.yaml
kubectl delete -f service.yaml

Разбор:

  • Удаляет объекты, описанные в файлах (по kind + metadata.name).
  • Deployment удаляет ReplicaSet и поды; Service — endpoints и ClusterIP.
  • Порядок Service/Deployment не критичен при delete, но поды исчезнут с Deployment.

Или удаление одного ресурса по имени:

kubectl delete deployment my-app-deployment

Разбор:

  • Императивное удаление по типу и имени без файла.
  • Service my-app-service останется, пока не удалите отдельно — трафик в никуда.
  • Namespace dev удаляется командой kubectl delete namespace dev (осторожно — каскадно все объекты внутри).

Практический мини-сценарий для закрепления​

Ниже компактная лабораторка, которая даёт полный цикл "поднять, проверить, масштабировать, снять логи, удалить".

  1. Запустите Deployment и Service из манифестов.
  2. Проверьте поды и Endpoints.
  3. Откройте доступ через port-forward.
  4. Увеличьте число реплик до 5.
  5. Проверьте распределение нагрузки и статус.
  6. Удалите ресурсы и убедитесь, что namespace чист.

Набор команд:

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl get pods -o wide
kubectl get endpoints my-app-service
kubectl port-forward svc/my-app-service 8080:80
kubectl scale deployment my-app-deployment --replicas=5
kubectl get pods
kubectl delete -f deployment.yaml
kubectl delete -f service.yaml

Разбор:

  • apply — поднять Deployment и Service; get pods -o wide — поды с нодой и IP для отладки сети.
  • get endpoints — убедиться, что Service видит поды перед port-forward.
  • port-forward — проверка в браузере на Windows; в отдельном окне PowerShell выполняйте scale и get pods.
  • delete -f — убрать учебные ресурсы; при namespace dev добавляйте -n dev ко всем командам.

После выполнения вы руками пройдёте базовые операции SRE-разработчика в Kubernetes.

Типовые ошибки новичка и быстрая диагностика​

СимптомЧастая причинаЧто проверить
ImagePullBackOffНеверное имя образа или закрытый реестрkubectl describe pod <pod-name> и поле image
CrashLoopBackOffПриложение падает при стартеkubectl logs <pod-name> --previous
PendingНе хватает CPU/RAM на узле или Pod ещё не запланированkubectl describe pod <pod-name> и requests/limits; см. жизненный цикл Pod
Сервис не отвечаетМетки Service и Deployment не совпадаютkubectl get svc, kubectl get pods --show-labels
Нет доступа из браузераНет port-forward или неверный портПроверить kubectl port-forward и адрес http://localhost:8080

Базовая команда для расследования почти любого кейса:

kubectl describe pod <pod-name>

Разбор:

  • Замените <pod-name> на имя из kubectl get pods (угол скобок в команду не вводите).
  • События scheduler, kubelet, pull образа и failed probe — в Events.
  • Для упавшего контейнера дополните kubectl logs <pod-name> --previous.

Она показывает события планирования, сетевые ошибки, проблемы с образом и probe-проверками.

Что изучить следующим шагом​

После этой практики логично идти в более глубокие темы:

Так вы сохраняете плавный переход от "первого запуска" к реальной эксплуатации кластера.

Мини-практикум по диагностике ошибок​

Этот блок тренирует навык поиска причин, когда "что-то не работает".

Ситуация 1 — ошибка в имени образа​

Измените в deployment.yaml образ на несуществующий тег и примените манифест:

kubectl apply -f deployment.yaml
kubectl get pods
kubectl describe pod <pod-name>

Разбор:

  • После apply поды перейдут в ImagePullBackOff — kubelet не сможет скачать образ с Hub.
  • get pods — быстрый статус; точная причина в describe → Events (Failed to pull image).
  • Верните корректный тег в YAML и снова kubectl apply -f deployment.yaml.

Ожидаемый результат — статус ImagePullBackOff. После этого верните корректный тег образа и повторите apply.

Ситуация 2 — несовпадение меток Service и Deployment​

Смените selector.app в service.yaml на другое значение и примените:

kubectl apply -f service.yaml
kubectl get endpoints my-app-service

Разбор:

  • Service обновится, но endpoints опустеют, если ни один под не несёт новую метку selector.
  • kubectl get endpoints my-app-service покажет пустой список адресов — типичный симптом рассинхрона меток.
  • Верните app: my-app в selector и в labels Deployment, затем снова проверьте endpoints.

Вы увидите пустой endpoint-list. Верните совпадающую метку и снова проверьте endpoints.

Ситуация 3 — недостаток ресурсов​

Повысьте replicas до значения, которое превышает доступные ресурсы вашей машины, затем:

kubectl get pods
kubectl describe pod <pending-pod-name>

Разбор:

  • Лишние поды останутся в Pending — scheduler не найдёт ноду с свободными requests CPU/RAM.
  • В Events будет Insufficient cpu или Insufficient memory (зависит от лимитов WSL и Docker Desktop).
  • Показывает, зачем в проде задают requests/limits и мониторят ёмкость кластера.

Такой эксперимент показывает, как Kubernetes сообщает о проблемах планирования и почему важны корректные requests/limits.

Короткий чек-лист локальной готовности​

  • Docker Desktop запущен и Kubernetes в статусе Ready.
  • kubectl get nodes возвращает хотя бы одну ноду со статусом Ready.
  • Локальные манифесты проходят kubectl apply без ошибок.
  • Сервис имеет рабочие endpoints.
  • Доступ к приложению подтверждён через port-forward.

После этого можно переходить к более сложным сценариям из Реализация Kubernetes.

Основа по протоколу

Базовый разбор HTTP и HTTPS находится в отдельной статье — HTTP как основа веб-интеграций.

В подборках​

Статья входит в тематические подборки и блок "С чего начать?" на главной. Соседние шаги того же маршрута:

Первые шаги (маршрут подборки) — Первые шаги к микросервисам, Первые шаги с Memcached, Первые шаги с Cassandra, Первые шаги с Redis, Первые шаги с MongoDB, Первые шаги с SQL.

Содержание