Первый Pod в Kubernetes для Nginx

Схема Kubernetes: Pod и Node

В этой инструкции шаг за шагом показано, как создать и удалить простой Pod с Nginx в Kubernetes. Приведены полезные команды, критерии приёмки, варианты отказа от этого подхода и чек-листы для разработчика и SRE.

Что такое Pod?

Pod — базовая единица выполнения приложения в Kubernetes. Это набор контейнеров, которые запускаются вместе на одном Node и разделяют сеть и тома. В большинстве случаев рекомендуется запускать в Pod один контейнер: это упрощает управление и масштабирование.

Коротко: Pod = «оболочка» для одного или нескольких тесно связанных контейнеров.

Жизненный цикл Pod

Pending — Pod принят системой, но образы контейнеров ещё не загружены или Pod не назначен на Node.
Running — Pod назначен на Node, и хотя бы один контейнер запущен или в процессе запуска.
Succeeded — Все контейнеры успешно завершили работу и не будут перезапущены.
Failed — По крайней мере один контейнер завершился с ошибкой или был принудительно остановлен.
Unknown — Статус Pod недоступен, обычно из‑за проблем связи с Node.

Важно: Pod считается временным и немодифицируемым. Обновления обычно выполняются через высшие объекты, такие как Deployment.

Требования

Аккаунт AWS (если вы используете EC2) или доступные виртуальные машины.
Рабочий Kubernetes-кластер (kubeadm, managed Kubernetes, kind, minikube и т.д.).
Установленный kubectl и доступ к kubeconfig.

Примечание: Вы можете использовать локальные VM (например, minikube или kind) вместо AWS EC2.

Что мы сделаем

Создадим Pod с образом nginx.
Проверим статус и логи.
Удалим Pod.

Подготовка директории и проверка кластера

Выполните на машине, откуда вы управляете кластером:

mkdir my-first-pod
cd my-first-pod/

Проверьте доступные Node и версию kubectl:

sudo kubectl get nodes
sudo kubectl version --client

Список Pod в неймспейсе по умолчанию:

sudo kubectl get pods

Если Node видны, можно создавать Pod.

Манифест Pod для Nginx

Создайте файл my-first-pod.yml и вставьте следующий манифест:

---
apiVersion: v1
kind: Pod
metadata:
  name: myfirstpod
  labels:
    app: web
spec:
  containers:
    - name: myfirstcontainer
      image: nginx
      ports:
        - containerPort: 80

Краткие пояснения к полям:

apiVersion — версия API объекта.
kind — тип объекта (Pod).
metadata.name — уникальное имя в неймспейсе.
labels — метки для группировки и селекторов.
spec — описание желаемого состояния Pod.

Развертывание и проверка

Создайте Pod командой:

sudo kubectl apply -f my-first-pod.yml

Проверьте список Pod и их статус:

sudo kubectl get pods

Посмотреть подробности конкретного Pod:

sudo kubectl describe pod myfirstpod

Проверить, что Nginx действительно работает (выполнение команды внутри Pod):

sudo kubectl exec myfirstpod -- curl -sS http://127.0.0.1:80

Если нужно получить интерактивную shell в контейнере:

sudo kubectl exec -it myfirstpod -- /bin/sh

Важно: в исходном тексте использовался символ длинного дефиса; в kubectl нужно два дефиса “–“ перед командой.

Удаление Pod

Если Pod больше не нужен:

sudo kubectl delete pod myfirstpod

Проверьте, что Pod удалён:

sudo kubectl get pods

Когда этот подход не подходит

Для продакшн‑приложений, где требуется автоматическое восстановление и масштабирование, вместо одиночного Pod используйте Deployment или ReplicaSet.
Для приложений с состоянием (БД) — StatefulSet.
Для задач с одиночным запуском и завершением используйте Job или CronJob.

Альтернативные подходы

kubectl run — быстро создать временный Pod для теста.
Deployment — управляемое развертывание с возможностью обновлений и авто‑восстановления.
Helm — шаблоны для сложных приложений и зависимостей.

Эвристики и ментальные модели

Один Pod = один логический процесс/сервис. Если контейнеры тесно связаны (sidecar, proxy), их можно объединить в Pod.
Подход «immutable infrastructure»: не редактируйте текущий Pod — создавайте новый манифест и применяйте.
Labels = главный инструмент поиска и селекции объектов.

Чек-листы по ролям

Разработчик:

Проверил локально работу образа nginx.
Написал минимальный Pod-манифест.
Протестировал запросы через kubectl exec или Port‑forward.

SRE / DevOps:

Проверил доступность Node и ресурсов.
Добавил limits/requests и liveness/readiness (в Production).
Настроил мониторинг и логирование.

Security Engineer:

Запретил контейнеру права root, если возможно.
Проверил образ на уязвимости.
Применил NetworkPolicy для ограничения трафика.

Критерии приёмки

Pod успешно создан командой kubectl apply.
Статус Pod — Running в kubectl get pods.
Nginx отвечает на HTTP-запросы внутри Pod.
При удалении Pod ресурс корректно снимается.

Отладка и распространённые ошибки

Pod в состоянии Pending — скорее всего нет подходящих Node, или не хватает ресурсов, или проблемы с доступом к реестру образов. Используйте kubectl describe pod для событий.
CrashLoopBackOff — контейнер падает при старте; смотрите логи: kubectl logs myfirstpod.
ImagePullBackOff — проблема с загрузкой образа (ошибки аутентификации или имени образа).
Unknown — проверьте состояние Node и kubelet.

Команды для диагностики:

sudo kubectl describe pod myfirstpod
sudo kubectl logs myfirstpod
sudo kubectl get events --sort-by=.metadata.creationTimestamp
sudo kubectl get nodes

Безопасность и надёжность

Не запускайте контейнеры с правами root без необходимости.
Используйте образ с минимальной базой и следите за обновлениями.
Добавляйте resource requests и limits, liveness и readiness пробы для продакшн‑сценариев.
Для сетевой изоляции применяйте NetworkPolicy.

Мини‑чек‑шит команд

Создать Pod: kubectl apply -f my-first-pod.yml
Посмотреть Pod: kubectl get pods
Детали Pod: kubectl describe pod
Логи контейнера: kubectl logs
Выполнить команду внутри: kubectl exec –
Удалить Pod: kubectl delete pod

Кейс: когда нужен Pod вручную

Быстрая проверка образа в кластере.
Интеграционный тест одного контейнера.
Обучающие и демонстрационные сценарии.

Типичный план миграции с одиночного Pod в Production

Переход на Deployment.
Добавление реплик и стратегий обновления.
Настройка readiness и liveness.
Мониторинг и alerting.

Примеры тестов и критерии приёмки

Тест 1: Применить манифест и убедиться, что Pod статус Running в течение 60 секунд.
Тест 2: Выполнить HTTP запрос внутри Pod и получить 200.
Тест 3: Удалить Pod и убедиться, что ресурсы освободились.

Быстрый план действий при проблемах

kubectl describe pod — читаем события.
kubectl logs — смотрим логи контейнера.
kubectl get nodes — проверяем Node.
Если образ кривой — исправляем манифест и kubectl apply.
Для отката — kubectl delete pod или применяем предыдущий манифест.

Диаграмма принятия решения

flowchart TD
  A[Нужно развернуть один контейнер?] -->|Да| B[Использовать Pod для тестов]
  A -->|Нет| C[Использовать Deployment/StatefulSet]
  B --> D{Production?}
  D -->|Да| C
  D -->|Нет| E[Оставить Pod для тестовой среды]

Примеры манифестов и шаблонов

Шаблон для быстрого теста (nginx с resource limits и probe):

apiVersion: v1
kind: Pod
metadata:
  name: nginx-sample
spec:
  containers:
  - name: nginx
    image: nginx:stable
    ports:
    - containerPort: 80
    resources:
      requests:
        cpu: "100m"
        memory: "128Mi"
      limits:
        cpu: "250m"
        memory: "256Mi"
    livenessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 30
      periodSeconds: 10

Короткое резюме

Pod — минимальная единица Kubernetes для запуска контейнеров.
Для тестов и обучения можно использовать одиночный Pod с nginx.
Для продакшна предпочтительнее Deployment/ReplicaSet и дополнительные настройки безопасности, проб и ресурсов.

Часто задаваемые вопросы

Как быстро создать Pod без манифеста?

Для простого теста используйте kubectl run, но для повторяемости и версионирования манифесты YAML предпочтительнее.

Чем Pod отличается от Deployment?

Pod — экземпляр контейнера(ов). Deployment управляет набором Pod и обеспечивает обновления и восстановление.

Конец статьи. Следуйте чек-листам и рекомендациям по безопасности при переходе в продакшн.

Создание первого Pod в Kubernetes для Nginx