Ответ
Pod — это минимальная и неделимая единица развертывания в Kubernetes. Это абстракция над одним или несколькими контейнерами, которые разделяют сетевое пространство (один IP) и хранилище (volumes). Pods эфемерны: они создаются, умирают и никогда не восстанавливаются. Контроллеры (Deployments, StatefulSets) управляют жизненным циклом Pod'ов, поддерживая желаемое количество реплик.
Service — это абстракция, которая определяет логический набор Pod'ов (обычно выбираемых по селектору selector) и политику доступа к ним. Service предоставляет стабильную конечную точку: DNS-имя и виртуальный IP (ClusterIP), который не меняется, даже если Pod'ы, на которые он указывает, пересоздаются и меняют свои реальные IP-адреса. Service также обеспечивает базовую балансировку нагрузки между этими Pod'ами.
Простая аналогия: Pod — это конкретный рабочий процесс (контейнер), а Service — это стабильный номер отдела в компании, куда звонят клиенты. Сотрудники (Pods) могут меняться, но номер (Service) остается прежним, и вызов автоматически перенаправляется на свободного сотрудника.
Пример:
- Deployment создает 3 реплики Pod'ов с лейблом
app: my-api. - Каждый Pod получает свой внутренний IP (например,
10.244.1.5,10.244.2.3). - Service типа
ClusterIPс селекторомapp: my-apiсоздает виртуальный IP (например,10.96.123.45) и имяmy-api-svcв DNS кластера. - Другие приложения в кластере обращаются к
http://my-api-svc:80. Трафик с этого Service балансируется между тремя Pod'ами (10.244.1.5,10.244.2.3, ...).
Манифест Service:
apiVersion: v1
kind: Service
metadata:
name: my-api-service
spec:
selector:
app: my-api # Селектор, который находит Pod'ы
ports:
- protocol: TCP
port: 80 # Порт, на котором Service принимает запросы
targetPort: 8080 # Порт контейнера в Pod'е, куда перенаправлять трафик
type: ClusterIP # Тип Service (внутренний)
В своей работе я проектирую приложения так, чтобы они не зависели от IP конкретных Pod'ов, а всегда обращались к стабильным DNS-именам Services для межсервисного взаимодействия.