Для чего нужна команда describe в Kubernetes?

Команда kubectl describe в Kubernetes: Назначение и применение

Команда kubectl describe — это один из ключевых инструментов для диагностики и получения детализированной информации о ресурсах в кластере Kubernetes. В отличие от kubectl get, который показывает обобщённый список ресурсов, describe предоставляет всесторонний объединённый отчёт, включающий:

• Конфигурацию ресурса (желаемое состояние).
• Текущее состояние (актуальное состояние).
• Связанные события (Events).
• Другие релевантные объекты, связанные с запрашиваемым ресурсом.

Основные цели использования команды describe

1. Диагностика проблем — это основное назначение. Когда Pod находится в состоянии Pending, CrashLoopBackOff или Error, kubectl describe pod <pod-name> покажет:

    *   **События (Events)**: Хронологию ключевых изменений и ошибок (например, "Failed to pull image", "Insufficient memory", "Failed to mount volume").
    *   **Состояния контейнеров (Container State)**: Причины завершения работы (Last State), коды выхода, сообщения об ошибках.
    *   **Условия (Conditions)**: Подробный статус различных аспектов Pod (PodScheduled, Ready, Initialized, ContainersReady).

1. Просмотр детальной конфигурации объекта — команда агрегирует информацию из спецификации (spec), статуса (status) и метаданных. Например, для Deployment можно увидеть стратегию обновления, количество реплик, условия готовности, историю ревизий (если используется RollingUpdate).

2. Понимание связей между объектами — describe показывает владельцев ресурса (Owner References). Это критически важно для понимания иерархии. Например, описывая Pod, созданный Deployment, вы увидите ссылку на контролирующий его ReplicaSet.

Практические примеры использования

Пример 1: Диагностика проблемного Pod

kubectl describe pod/my-app-pod-xyz123 -n production

Вывод команды будет структурирован и может содержать критически важные для диагностики секции:

...
Events:
  Type     Reason          Age                From               Message
  ----     ------          ----               ----               -------
  Warning  FailedScheduling 2m (x5 over 4m)  default-scheduler  0/3 nodes are available: 3 Insufficient cpu.
  Normal   Scheduled       2m                default-scheduler  Successfully assigned prod/my-app-pod-xyz123 to node-02
  Warning  FailedMount     1m                kubelet            Unable to attach or mount volumes: unmounted volumes=[config-secret], unattached volumes=[config-secret kube-api-access-xyz]: timed out waiting for the condition
  Normal   Pulling         1m                kubelet            Pulling image "my-registry/app:v1.2"
  Warning  Failed          30s               kubelet            Failed to pull image "my-registry/app:v1.2": rpc error: code = Unknown desc = failed to pull and unpack image "my-registry/app:v1.2": failed to resolve reference "my-registry/app:v1.2": pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

Здесь сразу видна последовательность проблем: сначала нехватка CPU на узлах, затем проблема с монтированием тома и, наконец, ошибка доступа к образу в registry.

Пример 2: Анализ конфигурации Service

kubectl describe service/my-web-service

В выводе будет ключевая информация:

• Селекторы (Selectors): По каким label'ам Service находит Podы (app: my-web).
• Тип (Type): ClusterIP, NodePort, LoadBalancer.
• Порты (Port): Маппинг портов (targetPort, port, nodePort).
• Эндпоинты (Endpoints): Список IP-адресов и портов Podов, на которые фактически направляет трафик данный Service. Если этот список пуст — это явный признак проблемы с селекторами или готовностью Podов.

Name:              my-web-service
Namespace:         default
Selector:          app=my-web,tier=frontend
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.96.105.78
Port:              http  80/TCP
TargetPort:        8080/TCP
Endpoints:         10.244.1.15:8080,10.244.2.10:8080

Сравнение с другими командами

• kubectl get (с флагом -o yaml/json): Показывает полную сырую конфигурацию объекта в YAML или JSON формате. Идеален для инспекции или сохранения манифеста. describe же форматирует и интерпретирует эти данные, делая их более удобочитаемыми для человека.
• kubectl logs: Показывает вывод (stdout/stderr) конкретного контейнера. describe не показывает логи приложений, но дает контекст, в котором эти логи создавались (почему контейнер перезапускался, например).

Заключение

Команда kubectl describe — это швейцарский нож инженера DevOps при работе с Kubernetes. Она является первым и часто самым важным шагом при исследовании инцидента, предоставляя консолидированную картину состояния ресурса, его конфигурации и истории событий в кластере. Умение быстро находить и интерпретировать информацию в её выводе — базовый и необходимый навык для эффективного управления Kubernetes и оперативного решения проблем.