Отладка проблем с сетью Kubernetes: основные методы

Проблемы с сетью Kubernetes обычно проявляются как тайм-ауты, Connection refused, ошибки DNS, пустые конечные точки сервисов или некорректные ответы Ingress. Чтобы быстро их исправить, проследите путь: исходный под, целевой под, сервис, DNS, NetworkPolicy, а затем Ingress или балансировщик нагрузки.

Это руководство предоставляет практическую последовательность проверок и команды kubectl, которые показывают, где трафик останавливается.

Основы сетевого взаимодействия в Kubernetes

Прежде чем приступить к отладке, важно понять основные концепции сети в Kubernetes:

Сеть подов: Каждый под получает свой собственный уникальный IP-адрес. Поды в одном узле могут общаться напрямую. Поды на разных узлах общаются через виртуальную сеть (плагин CNI).
Сервисы: Сервисы предоставляют стабильный IP-адрес и DNS-имя для набора подов. Они действуют как уровень абстракции, позволяя другим подам или внешним клиентам получать доступ к серверным частям приложений, не зная IP-адресов отдельных подов.
DNS: DNS Kubernetes (обычно CoreDNS) преобразует имена сервисов в IP-адреса кластера, обеспечивая обнаружение сервисов.
Сетевые политики: Эти ресурсы контролируют трафик подов, когда ваш плагин CNI их применяет. Кластер без поддержки NetworkPolicy будет принимать объекты, но может не применять правила.
Ingress: Контроллеры Ingress управляют внешним доступом к сервисам внутри кластера, обычно HTTP и HTTPS. Они обеспечивают маршрутизацию, балансировку нагрузки и завершение SSL.

Распространенные проблемы с сетью и стратегии отладки

1. Сбои связи между подами

Когда поды не могут общаться друг с другом, даже в одном пространстве имен, это основной признак проблемы с сетью.

Симптомы:

Ошибки приложения, указывающие на тайм-ауты соединения или отказы.
Команды curl или ping из одного пода в другой не работают.

Шаги по отладке:

Проверьте IP-адреса подов: Убедитесь, что исходный и целевой поды имеют действительные IP-адреса. Используйте kubectl exec <pod-name> -- ip addr.
Проверьте сетевое подключение (внутри пода): Из исходного пода попробуйте выполнить ping на IP-адрес целевого пода. Если это не удается, проблема может быть в плагине CNI или сетевом взаимодействии узлов.
```
kubectl exec <source-pod-name> -- ping <destination-pod-ip>
```
Проверьте сетевые политики: Сетевые политики являются частой причиной. Проверьте, не блокируют ли какие-либо политики трафик между подами.
```
kubectl get networkpolicies -n <namespace>
```
Изучите правила podSelector и ingress/egress, чтобы понять, какой трафик разрешен или запрещен. Как только под выбран политикой входящего трафика, разрешается только явно разрешенный входящий трафик.
Состояние плагина CNI: Убедитесь, что ваш плагин интерфейса контейнерной сети (CNI) (например, Calico, Flannel, Cilium) правильно работает на всех узлах. Проверьте журналы подов демонсета CNI.
```
kubectl get pods -n kube-system -l k8s-app=<cni-plugin-label>
kubectl logs <cni-plugin-pod-name> -n kube-system
```

2. Проблемы с обнаружением сервисов

Когда поды не могут получить доступ к другим сервисам по их DNS-именам или IP-адресам кластера, это указывает на проблему с DNS Kubernetes или конфигурацией объекта сервиса.

Симптомы:

Ошибки приложения, такие как Name or service not known.
Команды nslookup или dig внутри пода не могут разрешить имена сервисов.

Шаги по отладке:

Проверьте разрешение DNS: Из пода проверьте разрешение DNS для известного сервиса.
```
kubectl exec <pod-name> -- nslookup <service-name>.<namespace>.svc.cluster.local
```
Если это не удается, проверьте журналы подов CoreDNS на наличие ошибок.
```
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs <coredns-pod-name> -n kube-system
```
Проверьте объект сервиса: Убедитесь, что объект сервиса правильно настроен и имеет конечные точки, указывающие на работоспособные поды.
```
kubectl get service <service-name> -n <namespace> -o yaml
kubectl get endpoints <service-name> -n <namespace>
```
Вывод endpoints должен содержать IP-адреса подов, поддерживающих сервис.
Зонды готовности подов: Если поды не проходят свои зонды готовности, они не будут добавлены в конечные точки сервиса. Проверьте конфигурации зондов готовности и журналы подов на наличие проблем.

3. Проблемы с контроллером Ingress

Внешний доступ к вашим сервисам управляется ресурсами Ingress и контроллерами Ingress. Проблемы здесь могут сделать ваше приложение недоступным извне кластера.

Симптомы:

Ошибки 502 Bad Gateway, 404 Not Found или 503 Service Unavailable при доступе к приложениям через их внешний URL.
Журналы контроллера Ingress показывают ошибки, связанные с серверными сервисами.

Шаги по отладке:

Проверьте поды контроллера Ingress: Убедитесь, что поды контроллера Ingress (например, Nginx Ingress, Traefik) работают и исправны.

kubectl get pods -l app.kubernetes.io/component=controller # Отрегулируйте метку в соответствии с вашим контроллером Ingress
kubectl logs <ingress-controller-pod-name> -n <ingress-namespace>

Проверьте ресурс Ingress: Проверьте конфигурацию вашего ресурса Ingress.
```
kubectl get ingress <ingress-name> -n <namespace> -o yaml
```
Убедитесь, что раздел rules правильно сопоставляет имена хостов и пути с соответствующими service.name и service.port.
Проверьте сервис и конечные точки: Как и в случае с обнаружением сервисов, убедитесь, что серверный сервис, на который указывает Ingress, правильно настроен и имеет работоспособные конечные точки.
```
kubectl get service <backend-service-name> -n <namespace>
kubectl get endpoints <backend-service-name> -n <namespace>
```
Брандмауэр и балансировщик нагрузки: Если доступ осуществляется извне кластера, убедитесь, что любые внешние брандмауэры или балансировщики нагрузки облачного провайдера правильно настроены для перенаправления трафика на сервис контроллера Ingress (часто это сервис типа LoadBalancer).

4. Применение сетевых политик

Сетевые политики могут быть мощным инструментом, но также и источником проблем с подключением при неправильной настройке. Они работают по принципу наименьших привилегий; если политика явно не разрешает трафик, он запрещен.

Шаги по отладке:

Определите применяемые политики: Определите, какие сетевые политики влияют на рассматриваемые поды.
```
kubectl get networkpolicy -n <namespace>
```
Проверьте селекторы политик: Внимательно изучите podSelector в каждой соответствующей сетевой политике. Этот селектор определяет, к каким подам применяется политика. Если под выбран несколькими политиками, разрешенный трафик является объединением правил этих политик, а не самым строгим отдельным правилом.
Просмотрите правила входящего/исходящего трафика: Проанализируйте разделы ingress и egress сетевой политики. Если вы пытаетесь установить соединение из пода A в под B, вам необходимо убедиться, что:
- Сетевая политика, примененная к поду B, разрешает входящий трафик от пода A (или более широкий селектор меток, включающий под A).
- Сетевая политика, примененная к поду A, разрешает исходящий трафик к поду B (или более широкий селектор меток, включающий под B).
Проверьте с помощью широко открытой политики: В качестве временного шага по устранению неполадок вы можете создать сетевую политику, которая разрешает весь трафик к определенным подам или пространствам имен и от них, чтобы увидеть, восстановится ли подключение. Это помогает изолировать, действительно ли проблема связана с сетевыми политиками.
```
# Пример: Разрешить весь входящий и исходящий трафик для подов с меткой app=my-app
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-for-my-app
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  - Egress
  ingress:
    - {}
  egress:
    - {}
```
Предупреждение: Эта политика allow-all должна использоваться только для временной отладки. Удалите ее, как только закончите тест.

Основные инструменты и команды

kubectl exec: Выполнение команд внутри пода (например, ping, curl, nslookup).
kubectl logs: Просмотр журналов подов, особенно для компонентов плоскости управления и сетевых плагинов.
kubectl describe: Получение подробной информации о подах, сервисах, Ingress и сетевых политиках, что часто показывает статус и события.
kubectl get: Список ресурсов и их базовый статус.
tcpdump: Мощный анализатор пакетов командной строки. Вы можете запустить его внутри пода или на узле для захвата сетевого трафика.
```
# Пример: Захват трафика на интерфейсе eth0 внутри пода
kubectl exec <pod-name> -- tcpdump -i eth0 -nn port 80
```

Вывод

Отлаживайте сеть Kubernetes изнутри наружу. Сначала докажите IP-связность подов, затем конечные точки сервисов, затем DNS, затем NetworkPolicy и, наконец, поведение Ingress или внешнего балансировщика нагрузки. Такой порядок не позволит вам гоняться за симптомом Ingress, когда у сервиса нет готовых конечных точек.