Устранение неполадок плагина Istio CNI#

#Лог

Лог плагина Istio CNI предоставляет информацию о том, как плагин настраивает перенаправление трафика приложения в поде на основе PodSpec.

Плагин работает в пространстве процесса контейнерного рантайма, поэтому записи лога CNI можно увидеть в логе kubelet. Для упрощения отладки плагин CNI также отправляет свой лог в DaemonSet istio-cni-node.

Уровень логирования по умолчанию для плагина CNI — info. Чтобы получить более подробный вывод лога, можно изменить уровень, отредактировав cni.values.logLevel в конфигурации компонента ServiceMesh для istioCNI.

Лог пода DaemonSet Istio CNI также содержит информацию об установке плагина CNI и устранении гонок.

#Готовность DaemonSet

Готовность DaemonSet CNI указывает на то, что плагин Istio CNI правильно установлен и настроен. Если DaemonSet Istio CNI не готов, это свидетельствует о проблемах. Для диагностики смотрите логи DaemonSet istio-cni-node.

#Устранение гонок

По умолчанию в DaemonSet Istio CNI включено устранение гонок, которое эвакуирует под, запущенный до того, как плагин CNI стал готов. Чтобы понять, какие поды были эвакуированы, ищите в логах строки вида:

2021-07-21T08:32:17.362512Z     info   Deleting broken pod: service-graph00/svc00-0v1-95b5885bf-zhbzm

#Диагностика ошибки запуска пода

Распространённая проблема с плагином CNI — под не запускается из-за ошибки настройки сетевого окружения контейнера. Обычно причина ошибки записывается в события пода и видна через описание пода:

$ kubectl describe pod POD_NAME -n POD_NAMESPACE

Если под постоянно получает ошибку инициализации, проверьте лог init-контейнера istio-validation на наличие ошибок «connection refused», например:

$ kubectl logs POD_NAME -n POD_NAMESPACE -c istio-validation
...
2021-07-20T05:30:17.111930Z     error   Error connecting to 127.0.0.6:15002: dial tcp 127.0.0.1:0->127.0.0.6:15002: connect: connection refused
2021-07-20T05:30:18.112503Z     error   Error connecting to 127.0.0.6:15002: dial tcp 127.0.0.1:0->127.0.0.6:15002: connect: connection refused
...
2021-07-20T05:30:22.111676Z     error   validation timeout

Init-контейнер istio-validation настраивает локальный dummy-сервер, который слушает порты перенаправления трафика inbound/outbound и проверяет, может ли тестовый трафик быть перенаправлен на dummy-сервер. Если перенаправление трафика пода не настроено корректно плагином CNI, init-контейнер istio-validation блокирует запуск пода, чтобы предотвратить обход трафика. Чтобы проверить наличие ошибок или неожиданных сетевых настроек, ищите ID пода в логе istio-cni-node.

Другой признак неисправности плагина CNI — приложение в поде постоянно эвакуируется при запуске. Это обычно происходит из-за неправильной установки плагина, из-за чего перенаправление трафика пода не может быть настроено. Логика CNI устранения гонок считает под повреждённым из-за гонки и постоянно эвакуирует его. При возникновении такой ситуации проверьте логи DaemonSet CNI, чтобы узнать, почему плагин не удалось корректно установить.

При использовании Multus для объединения нескольких провайдеров CNI, например Kube-OVN, это может привести к тому, что плагин Istio CNI установит конфигурацию несколько раз (как в Multus, так и в Kube-OVN), что вызовет циклическую цепочку CNI и невозможность настройки сети для пода. Чтобы смягчить эту проблему, можно явно указать cni.values.cniConfFileName в имени конфигурационного файла Multus. Также рекомендуется вручную проверить все конфигурации CNI, чтобы убедиться в отсутствии дублирующих настроек.