Устранение неполадок приложений Kubernetes — модули отладки

1. Модуль отладки

Первым шагом в отладке модуля является просмотр информации о модуле. Просмотрите текущий статус и последние события Pod с помощью следующей команды:

kubectl describe pods ${POD_NAME}

Взгляните на состояние контейнеров в поде. Одинаков ли статус этих контейнеров  Running ? Вы недавно перезагружались?

Последующая отладка зависит от состояния пода.

Под застрял в состоянии ожидания

Если модуль завис в  Pending состоянии, это означает, что модуль не запланирован на узле. Обычно это происходит из-за нехватки ресурсов какого-либо типа, препятствующих планированию. Глядя на вывод команды выше  kubectl describe ... , должно быть видно, почему она не была запланирована. Общие причины следующие:

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

• Используется hostPort : если модуль привязан к  hostPort, количество узлов, которые могут запускать модуль, ограничено. В большинстве случаев hostPort в этом нет необходимости, но для предоставления пода следует использовать объект службы. Если вам действительно нужно его использовать  hostPort, то количество нод в кластере — это верхний предел количества Pod’ов, которые можно создать.

Pod застрял в состоянии ожидания

Если модуль застрял в  Waiting состоянии, это означает, что модуль был запланирован для рабочего узла, но не может работать на этом узле. Также kubectl describe ... может быть полезен вывод команды. Waiting Наиболее распространенной причиной этого состояния является сбой извлечения образа. Есть три области для проверки:

• Убедитесь, что имя изображения написано правильно.
• Убедитесь, что образ был отправлен в реестр.
• Попробуйте посмотреть, сможете ли вы вытащить изображение вручную. Например, если вы используете Docker на своем ПК, запустите  docker pull <镜像>.

Pod дает сбой или иным образом неработоспособен

После того, как модуль запланирован, его можно отладить, как описано в разделе «Отладка работающего модуля».

Pod находится в рабочем состоянии, но не работает должным образом

Если Pod ведет себя не так, как ожидалось, вероятно, есть  mypod.yamlпроблема в описании Pod (например, на вашем локальном компьютере), и ошибка была проигнорирована, когда Pod был создан без сообщения об ошибке. Обычно отношения вложенности области раздела в определении Pod неверны, и неправильное написание имени поля приводит к игнорированию соответствующего содержимого. Например, если вы ошибочно  command напишете  commnd, под будет создан, но не выполнит ожидаемую командную строку.

Первое, что можно сделать, это удалить свой модуль и попытаться  --validate воссоздать его с помощью option. Например, запустить  kubectl apply --validate -f mypod.yaml. Если  command он написан с ошибкой  commnd, вы увидите следующее сообщение об ошибке:

I0805 10:43:25.129850   46757 schema.go:126] unknown field: commnd
I0805 10:43:25.129973   46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842
pods/mypod

Следующее, что нужно проверить, это то, что под на сервере API соответствует тому, что вы ожидаете создать (например, вы изначально использовали файл YAML на своем локальном компьютере для создания пода). Например, после запуска  kubectl get pods/mypod -o yaml > mypod-on-apiserver.yamlвручную сравните  mypod.yaml с описанием пода, полученным с сервера API. Обычно YAML, полученный с сервера API, содержит строки, которых нет в YAML, используемом для создания пода. Однако, если некоторые строки в исходном файле не существуют в версии сервера API, это означает, что спецификация пода проблематична.

Отладка контроллера реплики

Контроллер реплики относительно прост и понятен. Либо они могут создавать стручки, либо нет. Если модуль не может быть создан, см. приведенные выше инструкции по отладке модуля.

Вы также можете использовать  kubectl describe rc ${CONTROLLER_NAME} команды для просмотра событий, связанных с контроллером реплики.

Служба отладки

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

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

Ресурс конечных точек можно просмотреть с помощью следующей команды:

kubectl get endpoints ${SERVICE_NAME}

Убедитесь, что количество конечных точек соответствует количеству подов участников службы. Например, если ваша служба используется для запуска 3 реплик контейнеров nginx, вы должны увидеть 3 разных IP-адреса в конечных точках службы.

Отсутствуют конечные точки службы

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

...
spec:
  - selector:
     name: nginx
     type: frontend

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

kubectl get pods --selector=name=nginx,type=frontend

Убедитесь, что Pod   соответствует containerPort сервису  .targetPort