Ответ
Cluster Networking в Kubernetes — это набор моделей, правил и реализаций, которые обеспечивают связь между всеми компонентами кластера. Основная модель предъявляет четыре фундаментальных требования:
- Все поды могут общаться друг с другом без NAT, независимо от ноды, на которой они находятся.
- Все ноды могут общаться со всеми подами без NAT.
- IP-адрес, который под видит сам себя, — это тот же IP, который видят другие поды.
На практике я работал с несколькими CNI (Container Network Interface) плагинами, которые реализуют эту модель:
- Calico: Использовал в продакшене за его производительность и мощные NetworkPolicies. Он использует BGP для маршрутизации или может работать в режиме overlay (IP-in-IP).
- Cilium: Внедрял в новых кластерах из-за eBPF, что дает глубокую видимость трафика (L7) и высокую производительность. Отлично подходит для security-аудита.
- Flannel: Простой и надежный вариант для менее сложных окружений, использует VXLAN.
Пример решения типовой задачи — изоляция трафика с помощью NetworkPolicy (используя Calico/Cilium или стандартный K8s NetworkPolicy):
# Эта политика разрешает только frontend-подам обращаться к backend-подам на порту 8080.
# Весь остальной входящий трафик к backend-подам блокируется.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: backend-allow-from-frontend
spec:
podSelector:
matchLabels:
app: backend
policyTypes:
- Ingress
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
ports:
- protocol: TCP
port: 8080
Ключевые компоненты сети, которые важно понимать:
- Pod Network: Каждый под получает IP из большого пула (например,
/16). Плагин CNI отвечает за назначение этих IP и маршрутизацию между нодами. - Service Network: Виртуальная сеть (например,
10.96.0.0/12). Сервисам типа ClusterIP выдаются IP из этого диапазона.kube-proxyотвечает за трансляцию виртуального IP сервиса в реальные IP подов. - DNS: CoreDNS предоставляет внутренний DNS для разрешения имен сервисов (
<service>.<namespace>.svc.cluster.local).