Ответ
Я проверяю связность между сервисами комплексно, начиная с базовых сетевых проверок и заканчивая анализом политик.
1. Базовая проверка доступности:
# Проверка TCP-порта с помощью netcat
nc -zv <service-b-hostname-or-ip> <port>
# Проверка HTTP/HTTPS эндпоинта с помощью curl
curl -v http://<service-b>:<port>/health
curl -I http://<service-b>:<port> # Только заголовки
2. В контексте Kubernetes:
# Запуск диагностической команды изнутри пода сервиса A
kubectl exec -it <pod-a> -- sh -c "curl -m 5 http://<service-b>.<namespace>.svc.cluster.local:<port>"
# Проверка DNS-разрешения имён сервисов внутри кластера
kubectl exec -it <pod-a> -- nslookup <service-b>
kubectl exec -it <pod-a> -- cat /etc/resolv.conf
3. Анализ сетевой конфигурации:
- Сервисы и эндпоинты:
kubectl get svc,ep <service-b>— убедиться, что у сервиса есть активные эндпоинты (поды). - Network Policies:
kubectl get networkpolicy -A— проверить, не блокируют ли политики трафик между неймспейсами или подами. - Ingress/Service Mesh: Если используется Istio/Linkerd, проверяю VirtualServices, DestinationRules и Sidecar-конфигурации.
4. Проверка на уровне инфраструктуры:
- Группы безопасности (Security Groups) в облаке или правила файрвола на хостах.
- Таблицы маршрутизации и настройки VPC/подсетей, если сервисы в разных сетях.
5. Логи и метрики:
Смотрю логи пода-инициатора (kubectl logs <pod-a>) на наличие Connection refused, Timeout или No route to host. Также проверяю метрики сетевых ошибок в Prometheus/Grafana.
Такой подход позволяет локализовать проблему: DNS, уровень сети (L3/L4), политики безопасности (L7) или конфигурацию самого приложения.