3.3.4 · блок 3
Сеть в кластере: Service и NetworkPolicy
Сеть в кластере: Service и NetworkPolicy
Зачем это нужно
Pod'ы ephemeral: IP меняется при restart. Клиенту и другим сервисам нужен стабильный адрес и балансировка между репликами. Service даёт DNS-имя и virtual IP внутри кластера. NetworkPolicy ограничивает, кто с кем может говорить — defense in depth для ML-сервиса с PII.
Без понимания Service вы не подключите inference к Istio (модуль 3.6); без NetworkPolicy любой compromised Pod сканирует весь кластер.
Основные идеи
ClusterIP (default). Внутренний IP + DNS: scorer.ml-prod.svc.cluster.local. Доступен только из кластера. Типичный фронт для inference между микросервисами.
NodePort / LoadBalancer. Внешний доступ: NodePort пробрасывает порт на каждой node; LoadBalancer создаёт облачный LB. В enterprise часто Ingress или Gateway API + mesh вместо голого LoadBalancer на каждый сервис.
Service selector. Service направляет трафик на Pod'ы с matching labels:
apiVersion: v1
kind: Service
metadata:
name: scorer
spec:
selector:
app: scorer
ports:
- port: 80
targetPort: 8080
Headless Service (clusterIP: None). Для StatefulSet — DNS на каждый Pod отдельно (scorer-0.scorer).
kube-proxy modes. Реализация балансировки (iptables, ipvs) — прозрачна для разработчика, но полезна SRE при отладке.
NetworkPolicy. Firewall на уровне Pod (если CNI поддерживает, например Calico, Cilium):
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: scorer-ingress
spec:
podSelector:
matchLabels:
app: scorer
policyTypes: [Ingress]
ingress:
- from:
- podSelector:
matchLabels:
app: gateway
ports:
- port: 8080
Только gateway Pod'ы могут бить в scorer:8080. Egress policies ограничивают исходящие (например, только к PostgreSQL и S3 endpoint).
DNS CoreDNS. nslookup scorer из debug Pod — проверка service discovery.
Как это выглядит на практике
Контур online ML:
1. Deployment scorer (3 replicas).
2. Service scorer ClusterIP :80 → :8080.
3. Ingress или Istio VirtualService (позже) — внешний HTTPS.
4. NetworkPolicy: ingress только от ingress-controller namespace; egress к minio:9000 и postgres:5432.
Отладка:
kubectl run curl --rm -it --image=curlimages/curl -- sh
curl http://scorer.ml-prod.svc.cluster.local/health
Connection refused — Pod не ready или targetPort неверный. Timeout — NetworkPolicy или Service selector не совпадает с labels Pod.
Для batch Job сеть проще: Job может не иметь Service, если никто не вызывает её по HTTP.
Практикум модуля: Deployment + Service — минимальная связка; NetworkPolicy — по возможности в учебном кластере.
Что сделать после занятия
- [ ] Создайте Service для своего Deployment и проверьте доступ из временного curl-Pod.
- [ ] Нарисуйте схему трафика: client → Ingress → Service → Pod.
- [ ] Напишите NetworkPolicy «deny all ingress к scorer, кроме gateway» (даже если кластер не применит — упражнение на YAML).