В чем отличие ноды, пода и сервиса в Kubernetes

Что проверяют

Понимаете ли вы модель Kubernetes на уровне, нужном для работы с тестовыми стендами: где крутится приложение, почему меняется его адрес и через что к нему ходить. Следом тестировщику задают практику: как посмотреть логи упавшего пода или почему тесты после деплоя бьют в старую версию.

Как отвечать

• нода: виртуальная или физическая машина кластера. На ней работают kubelet, среда выполнения контейнеров вроде containerd и kube-proxy. API-сервер, etcd и планировщик живут на узлах control plane, термин «мастер» устарел;
• под: минимальная единица запуска. Один или несколько контейнеров с общей сетью и томами, всегда целиком на одной ноде. Под смертен: после пересоздания у него новый IP. Руками поды обычно не создают, ими управляет Deployment через ReplicaSet;
• сервис: стабильное имя и адрес перед группой подов, которые выбираются по меткам (selector). Типы: ClusterIP (по умолчанию, только внутри кластера), NodePort, LoadBalancer, ExternalName. HTTP снаружи обычно заводят через Ingress или Gateway API.

Связь одной фразой: сервис находит поды по меткам, планировщик раскладывает поды по нодам.

Полезные для QA команды: kubectl get pods -o wide покажет ноду, kubectl logs <pod> --previous даст логи до перезапуска, kubectl describe pod покажет события вроде CrashLoopBackOff и OOMKilled, kubectl port-forward svc/<name> 8080:80 откроет сервис на вашей машине. Под, не прошедший readinessProbe, сервис трафиком обходит.

Где спотыкаются

Приводят пример пода с веб-сервером и базой внутри. Так не делают: у них разный жизненный цикл и масштабирование. В один под кладут тесно связанные контейнеры, например приложение и sidecar с прокси.

Обращаются в тестах к поду по IP. После пересоздания адрес другой, стабильная точка входа есть только у сервиса.

Считают, что сервис сам поднимает поды. Он только маршрутизирует трафик, за число реплик отвечает Deployment.