Руководство по устранению неполадок сети Kubernetes

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

Когда дело доходит до сети Kubernetes, на самом деле это не что иное, как одна из следующих трех ситуаций.

Pod обращается к внешней сети контейнера
Доступ к сети pod из-за пределов контейнера
взаимный доступ между модулями

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

Устранение неполадок в сети в основном начинается с этих ситуаций, обнаруживает определенные сетевые аномалии, а затем находит решения. Есть много возможных причин сетевых аномалий, наиболее распространенными из них являются:

Конфигурация сетевого модуля CNI неверна, что приводит к сбою сети с несколькими хостами, например

sysctl net.ipv4.ip_forward
sysctl net.bridge.bridge-nf-call-iptables
Сегмент IP конфликтует с существующей сетью
Плагин использует протокол, не поддерживаемый базовой сетью.
Забыли включить переадресацию IP и т.д.

Маршрутизация сети POD теряется, например

kubenet требует маршрут от podCIDR до IP-адреса хоста в сети. Эти маршруты, если они не настроены должным образом, могут вызвать проблемы, такие как сетевое взаимодействие модуля.
На общедоступной облачной платформе kube-controller-manager автоматически настроит маршрутизацию для всех узлов, но если конфигурация неверна (например, сбой аутентификации и авторизации, превышение квоты и т. д.), это также может привести к сбою настройки маршрутизации.

Группы безопасности, брандмауэры или политики безопасности на хосте или облачной платформе блокируют сеть Pod, например

Сеть Pod запрещена правилами iptables, не управляемыми Kubernetes.
Группа безопасности общедоступной облачной платформы запрещает сеть Pod (обратите внимание, что сеть Pod может не находиться в том же сегменте сети, что и сеть Node).
ACL для выключателей или маршрутизаторов запрещает POD сети

Flannel Pod был в инициализации: Crashloopbackoff

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

Глядя в журнал найдете

Обычно это вызвано включением SELinux, и отключение SELinux может быть решено. Есть два способа:

Изменить метод файла /etc/selinux/config: SELINUX=disabled
Временно изменено командой (перезапуск будет потерян): setenforce 0

Не удалось разрешить DNS в Pod

Если версия Docker, установленная на узле, выше 1.12, то Docker изменит политику iptables FORWARD по умолчанию на DROP. Это может вызвать проблемы с доступом к сети модуля. Решение состоит в том, чтобы запустить iptables -P FORWARD ACCEPT на каждом узле, например.

Если вы используете сетевой плагин flannel/weave, обновление до последней версии также может решить эту проблему.

Неспособность разрешить DNS также может быть вызвана ненормальной службой kube-dns.Вы можете использовать следующую команду, чтобы проверить, нормально ли работает kube-dns

Если kube-dns находится в состоянии CrashLoopBackOff, вам необходимо просмотреть логи пода kube-dns и исправить службу DNS согласно логам.

Если модуль kube-dns работает нормально, вам необходимо дополнительно проверить правильность настройки службы kube-dns:

Если служба kube-dns не существует или список конечных точек пуст, служба kube-dns настроена неправильно и ее можно повторно развернуть.

ClusterIP не может получить доступ к сервису

При сбое доступа к сервисному кластеру вы можете сначала подтвердить, есть ли соответствующие конечные точки.

kubectl get endpoints <service-name>

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

Если конечные точки в норме, вы можете дополнительно проверить

Соответствует ли containerPort пода containerPort службы.
Нормально ли напрямую обращаться к podIP:containerPort?

Идя дальше, даже если приведенная выше конфигурация верна, существуют другие причины, по которым служба не может быть доступна, например:

Контейнеры в POD могут еще не запустить или не прослушать указанный контейнер
Аномалии маршрутизации сети CNI или хоста также могут вызывать аналогичные проблемы.
Возможно, не запущена служба kube-proxy или неправильно настроены соответствующие правила iptables.

Pod не может получить доступ к себе через Service

Обычно это вызвано неправильно настроенной шпилькой, которую можно настроить с помощью параметра Kubelet --hairpin-mode.Дополнительные параметры включают «promiscuous-bridge», «hairpin-veth» и «none» (по умолчанию — «promiscuous-bridge»). .

Для режима шпильки вы можете использовать следующую команду, чтобы подтвердить, вступает ли она в силу.

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

Невозможно получить доступ к API Kubernetes

Многим службам расширения требуется доступ к данным, требуемым запросом Kubernetes API (например, kube-dns, Operator и т. д.). Обычно, когда API Kubernetes недоступен, вы можете сначала убедиться, что API Kubernetes работает нормально, выполнив следующую команду:

Если вы получаете сообщение об ошибке тайм-аута, вам необходимо дополнительно подтвердить, что служба с именем kubernetes и список конечных точек работают нормально:

Затем вы можете напрямую получить доступ к конечным точкам, чтобы увидеть, можно ли нормально получить доступ к kube-apiserver. Недоступный обычно означает, что kube-apiserver не запустился нормально, или правила брандмауэра блокируют доступ.

Однако если возникает ошибка 403 — Forbidden, это означает, что в кластере Kubernetes включен контроль авторизации доступа (например, RBAC).В настоящее время необходимо создать роль и привязку роли для ServiceAccount, используемого модулем для авторизации. доступ к необходимым ресурсам.