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

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

Понимаете ли вы, где на самом деле работает ваше приложение и как до него доходит трафик. Python-разработчику вопрос задают, чтобы понять, сможет ли он сам выкатить сервис на FastAPI или Django и разобраться, почему запросы не доходят. Следом спрашивают про типы сервисов и пробы.

Как отвечать

• нода: машина кластера, виртуальная или физическая. На ней работают kubelet, среда выполнения контейнеров (обычно containerd) и kube-proxy. Управляющие компоненты (kube-apiserver, etcd, планировщик, контроллеры) называют control plane, термин «мастер» устарел;
• под: минимальная единица, которую планирует Kubernetes. Один или несколько контейнеров с общим сетевым пространством: у пода один IP, контейнеры видят друг друга через localhost и могут делить тома. Под целиком живёт на одной ноде и эфемерен: при пересоздании получает новый IP. Руками поды почти не создают, ими управляет Deployment через ReplicaSet;
• сервис: стабильная точка входа к набору подов. Выбирает поды по меткам, даёт постоянный виртуальный IP и DNS-имя вида api.default.svc.cluster.local. Типы: ClusterIP по умолчанию и только внутри кластера, NodePort, LoadBalancer, ExternalName.

На примере: приложение на FastAPI под uvicorn упаковано в образ, Deployment держит три реплики пода на разных нодах, Service раздаёт на них трафик. Трафик получают только поды с успешной readinessProbe, поэтому эндпоинт вроде /healthz делают честным и дешёвым. Снаружи к сервису обычно ведут через Ingress или Gateway API.

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

Говорят, что под это контейнер. Под это обёртка над одним или несколькими контейнерами с общей сетью, и sidecar рядом с приложением обычное дело.

Считают, что сервис балансирует каждый запрос. Обычный ClusterIP через kube-proxy работает на уровне соединений, поэтому долгое keep-alive соединение или gRPC прилипает к одному поду, и нагрузка ложится неравномерно.

Путают масштабирование пода и процессов в нём: запускают gunicorn с десятком воркеров в каждом поде, ставят много реплик и получают нехватку памяти на ноде. Решите, чем масштабируетесь, воркерами или репликами, и задайте resources у контейнера.