Как проверить состояние кластера Kubernetes

Ниже — набор практических проверок с командами и пояснениями, что именно они показывают и на что обратить внимание.

Быстрая сводка

kubectl cluster-info
kubectl get nodes -o wide
kubectl get pods -A
kubectl get pods -n kube-system -o wide
kubectl get events -A --sort-by=.metadata.creationTimestamp

cluster-info покажет эндпоинты API/DNS. get nodes — статус нод (Ready/NotReady). get pods -A — быстро увидеть проблемы в приложениях и системных подах.

Проверка нод

kubectl get nodes
kubectl describe node <node-name>
kubectl top nodes

Смотрите в kubectl get nodes колонку STATUS (Ready), в describe — условия (Conditions: Ready, MemoryPressure, DiskPressure, PIDPressure, NetworkUnavailable). kubectl top nodes показывает загрузку CPU/Memory (требует metrics-server).

Контрольная плоскость и системные компоненты

kubectl get pods -n kube-system
kubectl get ds,deploy -n kube-system
kubectl logs -n kube-system <kube-apiserver-pod> # если control plane виден как pod
kubectl get --raw='/healthz'
kubectl get --raw='/readyz'

Если control plane управляется облаком (не виден в kube-system), используйте облачные панели. get --raw '/healthz' обращается к API-серверу и вернёт ok при здоровье.

Проверка подов и приложений

kubectl get pods -A -o wide
kubectl get pods -A --field-selector=status.phase!=Running
kubectl get pods -A | grep -E 'CrashLoopBackOff|Error|ImagePullBackOff'
kubectl describe pod <pod> -n <ns>
kubectl logs <pod> -n <ns> \[-c <container>\]

Ищите CrashLoopBackOff, Pending (обычно нет ресурсов или PVC не привязан), ImagePullBackOff (проблемы с registry). describe и logs — первые инструменты для диагностики.

События кластера

kubectl get events -A --sort-by=.metadata.creationTimestamp

События часто содержат причину почему Pod перезапускается/не запускается, почему нода taint'ена и т.п.

Сеть и DNS

kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system <coredns-pod>
kubectl get daemonset -n kube-system # посмотреть CNI (calico, flannel, weave)

Проверьте, что CoreDNS/CNI-поды в Running. Для теста DNS/сети можно запустить временный pod и из него выполнить nslookup/curl/ping к сервисам и другим pod'ам.

Хранилище

kubectl get pv
kubectl get pvc -A
kubectl describe pvc <pvc> -n <ns>

Ищите Lost/Released/Pending состояния, ошибки привязки PV к PVC или 부족 ресурсов.

Агрегированные API и CRD

kubectl get apiservices
kubectl get crd

Проблемы с apiservices блокируют расширяемые API (операторы, сервисы через aggregation layer).

Метрики и автоскейлинг

kubectl top pods -A
kubectl top nodes
kubectl get hpa -A

HPA и kubectl top требуют установленного metrics-server или источника метрик.

Глубокая диагностика

kubectl cluster-info dump > cluster-dump.json
kubectl rollout status deployment/<name> -n <ns>

cluster-info dump создаёт большой дамп для анализа; useful при сложных инцидентах.

Полезные приёмы

• При Pending — kubectl describe pod покажет причину (нет ресурсов, PVC не готов, nodeSelector/taints).

• При частых рестартах — kubectl logs --previous для старой инстанции контейнера.

• Если control plane недоступен из kubectl — проверьте kubeconfig/context (kubectl config current-context) и сетевой доступ к API-серверу.

Сводка команд-«шпаргалок»:

kubectl cluster-info
kubectl get nodes -o wide
kubectl describe node <node>
kubectl get pods -A -o wide
kubectl get pods -A --field-selector=status.phase!=Running
kubectl describe pod <pod> -n <ns>
kubectl logs <pod> -n <ns> \[-c container\]
kubectl get events -A --sort-by=.metadata.creationTimestamp
kubectl get pv; kubectl get pvc -A
kubectl get apiservices
kubectl top nodes; kubectl top pods -A
kubectl cluster-info dump > dump.json