Анализ работоспособности кластера после перезапуска

Для проверки работоспособности кластера после перезапуска проверьте состояние его плоскости управления. Плоскость управления включает следующие компоненты:

kube-apiserver — компонент, который представляет API Kubernetes;
etcd — хранилище конфигураций и состояний ресурсов кластера Kubernetes;
kube-scheduler — компонент, который отслеживает созданные поды без привязанного узла и выбирает узел, на котором они должны работать;
kube-controller-manager — диспетчер контроллеров.

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

Проверьте состояние компонентов плоскости управления с помощью команды:

kubectl get --raw='/readyz?verbose'

Все компоненты должны иметь состояние ok:

Вывод команды kubectl get --raw='/readyz?verbose', если кластер функционирует нормально

[+]ping ok
[+]log ok
[+]etcd ok
[+]etcd-readiness ok
[+]informer-sync ok
[+]poststarthook/start-kube-apiserver-admission-initializer ok
[+]poststarthook/generic-apiserver-start-informers ok
[+]poststarthook/priority-and-fairness-config-consumer ok
[+]poststarthook/priority-and-fairness-filter ok
[+]poststarthook/storage-object-count-tracker-hook ok
[+]poststarthook/start-apiextensions-informers ok
[+]poststarthook/start-apiextensions-controllers ok
[+]poststarthook/crd-informer-synced ok
[+]poststarthook/bootstrap-controller ok
[+]poststarthook/rbac/bootstrap-roles ok
[+]poststarthook/scheduling/bootstrap-system-priority-classes ok
[+]poststarthook/priority-and-fairness-config-producer ok
[+]poststarthook/start-cluster-authentication-info-controller ok
[+]poststarthook/start-kube-apiserver-identity-lease-controller ok
[+]poststarthook/start-kube-apiserver-identity-lease-garbage-collector ok
[+]poststarthook/start-legacy-token-tracking-controller ok
[+]poststarthook/aggregator-reload-proxy-client-cert ok
[+]poststarthook/start-kube-aggregator-informers ok
[+]poststarthook/apiservice-registration-controller ok
[+]poststarthook/apiservice-status-available-controller ok
[+]poststarthook/kube-apiserver-autoregistration ok
[+]autoregister-completion ok
[+]poststarthook/apiservice-openapi-controller ok
[+]poststarthook/apiservice-openapiv3-controller ok
[+]shutdown ok
readyz check passed

Если состояние компонента не соответствует значению ok, изучите сообщение об ошибке для этого компонента. Например, оно может быть следующим: [-]etcd failed: reason withheld.

Если по сообщению об ошибке не удалось установить ее причину, проверьте состояние подов компонентов, выполнив шаг 2.

Для проверки состояния подов компонентов выполните следующую команду:

kubectl get pods -n kube-system -o wide | grep <component>

Здесь:

<component> — имя компонента из списка выше.

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

Если команда kubectl get pods -n kube-system -o wide | grep etcd не возвращает результатов, это означает, что компонент etcd установлен как сервис. Для проверки его состояния используйте следующую команду:

systemctl status etcd.service

Пример вывода состояния компонента etcd

● etcd.service - etcd
     Loaded: loaded (/etc/systemd/system/etcd.service; enabled; vendor preset: disabled)
     Active: active (running) since Mon 2024-09-16 14:27:48 MSK; 2 months 13 days ago
   Main PID: 695 (etcd)
      Tasks: 12 (limit: 4652)
     Memory: 403.8M
        CPU: 1d 5h 58min 7.285s
     CGroup: /system.slice/etcd.service
             └─ 695 /usr/local/bin/etcd

Nov 29 14:07:35 master01-inst.test.coe.rvision.local etcd[695]: {"level":"info","ts":"2024-11-29T14:07:35.980+0300","caller":"mvcc/hash.go:137","msg":"storing new hash","hash":669749590,"revision":42723972,"compact-revision":42723201}
Nov 29 14:12:35 master01-inst.test.coe.rvision.local etcd[695]: {"level":"info","ts":"2024-11-29T14:12:35.935+0300","caller":"mvcc/index.go:214","msg":"compact tree index","revision":42724748}
...

Если сервис etcd работает корректно, его статус (Active) отображается как active (running). В противном случае обратитесь в службу поддержки, приложив вывод команды systemctl status etcd.service.

Если статус пода сервиса отличается от Running, выполните команду для получения его логов:

kubectl logs -n kube-system <pod_name> --all-containers=true

Здесь:

<pod_name> — имя пода, полученное на шаге 2.

При большом количестве событий в логе можно сузить вывод, перенаправив результаты команды kubectl logs в утилиты для обработки текста. Например, чтобы отобразить только последние несколько событий:

Пример 1. Пример вывода 20 последних событий в журнале с помощью команды tail

kubectl logs -n kube-system kube-scheduler-master.rvision.local --all-containers=true | tail -n 20

Если логи пода недоступны, можно просмотреть таблицу последних событий (Events), связанных с подом. Для этого выполните команду:

kubectl -n kube-system describe pod <pod_name>

Здесь:

<pod_name> — имя пода, полученное на шаге 2.

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