Просмотр подов и узлов

Узнайте, как диагностировать проблемы с Kubernetes-приложениями с помощью kubectl get, kubectl describe, kubectl logs и kubectl exec.

Цели

  • Узнать про поды Kubernetes
  • Узнать про узлы Kubernetes
  • Научиться диагностировать развёрнутые приложения

Поды Kubernetes

После того, как вы создали Deployment в модуле 2, Kubernetes создал под (Pod), в котором был размещён экземпляр вашего приложения. Под — это абстрактный объект Kubernetes, представляющий собой группу из одного или нескольких контейнеров приложения (например, Docker) и совместно используемых ресурсов для этих контейнеров. Ресурсами могут быть:

  • общее хранилище (тома);
  • сеть (уникальный IP-адрес кластера);
  • информация о том, как запускать каждый контейнер, например, версия образа контейнера или используемые номера портов.

Под представляет специфичный для приложения "логический хост" и может содержать разные контейнеры приложений, которые в общем и целом тесно связаны. Например, в поде может размещаться как контейнер с приложением на Node.js, так и другой контейнер, который получает некоторые данные для их дальнейшей публикации на веб-сервере Node.js. Все контейнеры в поде имеют одни и те же IP-адрес и пространство портов, всегда размещаются и планируются для выполнения на одном и том же узле.

Поды — неделимая единица в платформе Kubernetes. При создании деплоймента в Kubernetes создаются поды с контейнерами внутри (вместо того, чтобы непосредственно создавать контейнеры). Каждый объект Pod связан с узлом (Node), на котором он размещён, и остаётся там до окончания работы (согласно стратегии перезапуска) либо удаления. В случае неисправности узла такой же под будет запланирован для запуска на других доступных узлах кластера.

Краткое содержание:

  • Поды
  • Узлы
  • Основные команды kubectl

Под (Pod) — группа из одного или нескольких контейнеров приложений (например, Docker) и их общих хранилищ (томов), IP-адреса и информации о том, как их запускать.


Схема подов


Узлы

Под всегда работает в узле (Node). Узел — это рабочая машина в Kubernetes, которая в зависимости от кластера может быть либо виртуальной, либо физической. Каждый узел управляется компонентом под названием control plane. Узел может содержать несколько подов, которые control plane автоматически размещает ("планирует" для запуска) на разные узлы кластера. Автоматическое планирование (распределение подов по узлам) control plane учитывает доступные ресурсы на каждом узле.

В каждом узле Kubernetes как минимум работает:

  • Kubelet — процесс, отвечающий за взаимодействие между control plane и узлом; он управляет подами и запущенными контейнерами на рабочей машине.
  • Среда выполнения контейнера (вроде Docker), отвечающая за получение (загрузку) образа контейнера из реестра, распаковку контейнера и запуск приложения.

Контейнеры должны запускаться вместе в пределах одного пода только в случаях, когда они тесно связаны и должны совместно использовать ресурсы (например, диск).


Схема узла


Диагностика с помощью kubectl

В модуле 2 вы использовали инструмент командной строки kubectl. В этом (третьем) модуле вы продолжите его использовать, но для получения информации о развернутых приложениях и окружениях, в которых они работают. Наиболее распространенные операции выполняются с использованием следующих команд kubectl:

  • kubectl get — вывод списка ресурсов;
  • kubectl describe — вывод подробной информации о ресурсе;
  • kubectl logs — вывод логов контейнера в поде;
  • kubectl exec — выполнение команды в контейнере пода.

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

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

Узел — рабочая машина в Kubernetes, которая может быть как виртуальной, так и физической (в зависимости от используемого кластера). На одном узле могут быть запущены несколько подов.

Проверка конфигурации приложения

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

kubectl get pods

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

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

kubectl describe pods

Здесь можно увидеть подробности о контейнере пода: IP-адрес, используемые порты и список событий, относящихся к жизненному циклу пода.

У подкоманды describe подробный вывод. В частности, он затрагивает концепции, которые мы ещё не рассматривали, но не волнуйтесь — они станут понятнее в дальнейшем.

Примечание: подкоманду describe можно использовать для получения информации о многих примитивах Kubernetes, включая узлы (Nodes), поды (Pods) и деплойменты (Deployments). Вывод describe предназначен для чтения человеком, не для использования в скриптах.

Просмотр приложения в терминале

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

kubectl proxy

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

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
echo Name of the Pod: $POD_NAME

Чтобы увидеть вывод приложения, выполним запрос через curl:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

Здесь URL указывает на маршрут к API пода.

Просмотр логов контейнера

Всё, что обычное приложение отправляет в стандартный вывод (standard output), становится логами контейнера в поде. Получить эти логи можно с помощью команды kubectl logs:

kubectl logs "$POD_NAME"

Примечание: указывать название контейнера не требуется, потому что в данном поде у нас единственный контейнер.

Выполнение команд в контейнере

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

kubectl exec "$POD_NAME" -- env

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

Далее запустим Bash-сессию в контейнере пода:

kubectl exec -ti $POD_NAME -- bash

Откроется консоль в контейнере, в котором работает NodeJS-приложение. Исходный код приложения находится в файле server.js:

cat server.js

Также можно убедиться, что приложение запущено и работает, обратившись к нему через curl:

curl http://localhost:8080

Примечание: мы здесь использовали localhost, поскольку выполняли команду внутри пода NodeJS. Если у вас не получается подключиться к localhost:8080, проверьте, что запускали команду kubectl exec, а сейчас вызываете команду из пода.

Чтобы закрыть подключение к контейнеру, введите exit.

Когда всё готово, переходите к разделу Создание сервиса для открытия доступа к приложению.

Изменено October 15, 2024 at 3:18 AM PST: Merge pull request #48346 from windsonsea/metricy (50a9341)