Введение
В курсе «Kubernetes для начинающих» вы использовали kubectl get, describe и метки, чтобы проверить работоспособность приложения. В реальных кластерах содержится множество объектов, поэтому следующий важный навык — задавать более точные вопросы и извлекать только необходимые сведения.
В этой лабораторной работе вы развернёте небольшое приложение витрины и изучите его с нескольких сторон: пространство имён, метки, структурированные поля, владение со стороны контроллеров и события. В конце вы составите компактную команду, связывающую Deployment с управляемыми им Pod.
Вам не нужно запоминать все форматы вывода. Вместо этого потренируйтесь переводить вопрос в точный запрос: «Какие объекты существуют?», «Какие Pod соответствуют этому Service?», «Кому принадлежит этот Pod?» или «Что произошло последним?». Каждый шаг добавляет один инструмент в этот рабочий процесс проверки.
Создание отдельного рабочего пространства
На этом шаге вы создадите пространство имён и развернёте в нём подготовленные ресурсы. Пространство имён ограничивает область последующих запросов и не позволяет перепутать объекты с одинаковыми именами.
Перейдите в рабочий каталог лабораторной работы, а затем проверьте текущий контекст перед изменением состояния кластера. Команда cd изменяет текущий рабочий каталог оболочки, поэтому последующие относительные имена файлов, например storefront.yaml, будут указывать на подготовленное рабочее пространство.
cd /home/labex/project/resource-inspection
kubectl config current-context
В выводе должно быть значение labex-v135. Создайте пространство имён и примените подготовленный манифест из нескольких документов:
kubectl create namespace practice-observe
kubectl apply -f storefront.yaml
kubectl rollout status deployment/storefront -n practice-observe --timeout=60s
Последние строки должны выглядеть примерно так. Пока два Pod запускаются, могут появляться промежуточные сообщения о процессе развёртывания:
namespace/practice-observe created
deployment.apps/storefront created
service/storefront created
deployment "storefront" successfully rolled out
Параметр -n practice-observe ограничивает выполнение команды этим пространством имён. Команда проверки развёртывания ожидает доступности обеих реплик Deployment, вместо того чтобы полагаться на произвольную задержку.
Параметр -n practice-observe понадобится вам неоднократно. В противном случае команды Kubernetes используют пространство имён, настроенное в текущем контексте, — обычно default. Из-за этого исправный объект может показаться «отсутствующим», если запрос был выполнен не в той области.
Обнаружение ресурсов и определение их области
На этом шаге вы воспользуетесь механизмом обнаружения API перед запросом объектов. kubectl api-resources выводит имена ресурсов, поддерживаемых текущим API-сервером, их сокращённые имена и признак принадлежности к пространству имён. Конвейер с head ограничивает широкий список первыми десятью строками, чтобы не перегружать терминал.
kubectl api-resources | head
kubectl api-resources --namespaced=true | grep -E 'pods|deployments|services'
Конвейер передаёт список ресурсов команде grep. Параметр -E включает альтернативы, разделённые символом |, поэтому одна команда может находить несколько имён ресурсов. Обратите внимание, что Pod, Deployment и Service относятся к ресурсам пространства имён.
Сначала выведите объекты приложения, используя полные имена ресурсов, а затем повторите запрос с распространёнными сокращениями:
kubectl get pods,deployments,services -n practice-observe
kubectl get po,deploy,svc -n practice-observe
Обе команды обращаются к одним и тем же ресурсам API. Сокращённые имена позволяют экономить время при вводе, но полные имена понятнее в скриптах и документации.
В выводе должны присутствовать один Deployment, два сгенерированных Pod и один Service. Список ресурсов через запятую — лишь удобный способ выполнить запрос; сами объекты по-прежнему имеют разные роли и схемы API.
Префиксы типов делают общий вывод более понятным. Сгенерированные суффиксы, адреса и значения возраста будут отличаться:
NAME READY STATUS RESTARTS AGE
pod/storefront-... 1/1 Running 0 ...
pod/storefront-... 1/1 Running 0 ...
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/storefront 2/2 2 2 ...
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/storefront ClusterIP ... <none> 80/TCP ...
Фильтрация с помощью меток и селекторов
На этом шаге вы будете использовать метки как метаданные, по которым можно выполнять запросы. Параметр --show-labels отображает все метки, а -l выбирает только объекты, чьи метки соответствуют заданному выражению.
kubectl get pods -n practice-observe --show-labels
kubectl get pods -n practice-observe -l app=storefront
kubectl get pods -n practice-observe -l 'app=storefront,tier=web'
Запятая между требованиями селектора означает логическое И. Поэтому последний запрос возвращает Pod, содержащие обе метки.
Сравните селектор Service с метками выбранных Pod:
kubectl get service storefront -n practice-observe -o jsonpath='Service selector: {.spec.selector.app}{"\n"}'
kubectl get pods -n practice-observe -l app=storefront -o custom-columns='NAME:.metadata.name,TIER:.metadata.labels.tier,IP:.status.podIP,READY:.status.containerStatuses[0].ready'
kubectl get endpointslices -n practice-observe -l kubernetes.io/service-name=storefront
JSONPath извлекает одно поле из Service. Параметр -o custom-columns формирует компактную таблицу из нескольких полей Pod. Такой способ надёжнее визуального поиска в большом YAML-документе.
Последняя команда запрашивает EndpointSlice, у которых автоматически управляемая метка kubernetes.io/service-name имеет значение storefront. EndpointSlice содержит сетевые конечные точки, выбранные для Service. Непустой столбец ENDPOINTS подтверждает, что соответствующие метки сформировали доступные сетевые бэкенды.
Селектор Service должен вывести storefront, а в обеих строках таблицы Pod должна присутствовать метка tier=web. Совпадающая метка app и является связующим звеном: Service обнаруживает Pod по меткам, а не через владение со стороны Deployment.
Service selector: storefront
NAME TIER IP READY
storefront-... web 10.244... true
storefront-... web 10.244... true
NAME ADDRESSTYPE PORTS ENDPOINTS AGE
storefront-... IPv4 80 10.244...,10.244... ...
Отслеживание владения со стороны контроллеров
На этом шаге вы проследите цепочку владения Kubernetes от Deployment к ReplicaSet и Pod. Контроллеры добавляют ссылки ownerReferences, чтобы Kubernetes знал, какой объект более высокого уровня управляет зависимым объектом.
kubectl get replicasets -n practice-observe -l app=storefront
kubectl get replicasets -n practice-observe -l app=storefront -o custom-columns='REPLICASET:.metadata.name,OWNER_KIND:.metadata.ownerReferences[0].kind,OWNER_NAME:.metadata.ownerReferences[0].name'
kubectl get pods -n practice-observe -l app=storefront -o custom-columns='POD:.metadata.name,OWNER_KIND:.metadata.ownerReferences[0].kind,OWNER_NAME:.metadata.ownerReferences[0].name'
Владельцем ReplicaSet должен быть Deployment storefront. Владельцем каждого Pod является сгенерированный ReplicaSet, а не Deployment напрямую:
Deployment/storefront -> ReplicaSet/storefront-... -> Pod/storefront-...
Используйте kubectl describe, когда необходимо увидеть эту связь вместе с условиями и последними событиями:
kubectl describe deployment storefront -n practice-observe
Не нужно каждый раз читать вывод describe от начала до конца. В рамках текущего вопроса сосредоточьтесь на разделах Selector, количестве реплик, условиях и событиях. Лучшая команда проверки — та, которая отвечает на конкретный вопрос с минимальным количеством лишней информации.
Чтение событий как временной шкалы
На этом шаге вы изучите события как свидетельства, упорядоченные по времени. События описывают планирование, работу с образами, контейнерами и действия контроллеров, но представляют собой временную диагностическую информацию, а не постоянные записи аудита.
kubectl get events -n practice-observe --sort-by=.metadata.creationTimestamp
Параметр --sort-by упорядочивает объекты по указанному пути к полю. Сначала ограничьте временную шкалу событиями Deployment, а затем — одного выбранного Pod:
kubectl events -n practice-observe --for deployment/storefront
POD_NAME=$(kubectl get pods -n practice-observe -l app=storefront -o jsonpath='{.items[0].metadata.name}')
echo "$POD_NAME"
kubectl events -n practice-observe --for "pod/${POD_NAME}"
Конструкция $(...) выполняет подстановку команды: оболочка запускает внутреннюю команду и сохраняет её вывод в POD_NAME. Теперь у вас есть воспроизводимый путь проверки: сузить область до пространства имён, выбрать объекты по меткам, извлечь нужные поля, проследить цепочку владельцев и завершить анализ соответствующей временной шкалой событий.
Имена Pod, сгенерированные контроллерами, меняются при замене объектов, поэтому безопаснее получать текущее имя по метке, чем копировать устаревшее значение. Этот приём будет использоваться и в последующих лабораторных работах по устранению неисправностей.
Обычно успешный жизненный цикл включает события Scheduled, Pulled, Created и Started. В недавно запущенном локальном кластере также может сохраниться более раннее предупреждение, например FailedCreatePodSandBox, пока Calico переходит в состояние готовности. Не делайте вывод, что приложение всё ещё неисправно, основываясь только на старом предупреждении: сравните его временную отметку с последующими штатными событиями, а затем проверьте текущее состояние READY у Pod. Временные метки и сгенерированные имена Pod намеренно опущены, поскольку при каждом запуске они меняются.
Итоги
Вы проверили приложение Kubernetes, не просматривая посторонние объекты. Вы объединили пространства имён, метки, JSONPath, настраиваемые столбцы, ссылки на владельцев и события, перейдя от общего перечня к точным эксплуатационным сведениям. В следующей лабораторной работе этот процесс проверки будет применён к неисправным Pod и контейнерам.
