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

Платформа контейнеризации Kubernetes является сложной системой, состоящей из множества различных компонентов и внутренних API-объектов, которых насчитывается более 50. При возникновении различных проблем с кластером необходимо четко знать порядок действий для устранения сбоев. Существует множество различных проверок кластера Kubernetes и его компонентов — сегодня мы их разберем.

Подключение к кластеру Kubernetes при помощи утилиты kubectl

Чтобы подключиться к кластеру Kubernetes при помощи консольной утилиты kubectl, необходим специальный конфигурационный файл kubeconfig, в котором указаны настройки для подключения к кластеру. По умолчанию файл находится в скрытой директории .kube, которая расположена в домашней директории пользователя. Сам конфигурационный файл находится на мастер-ноде по пути /etc/kubernetes/admin.conf. 

Чтобы скопировать конфигурационный файл в домашний каталог пользователя, необходимо выполнить команду:

sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config

При использовании облачных кластеров Kubernetes файл можно скачать из панели управления кластером. 

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

export KUBECONFIG=$HOME/.kube/config

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

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

export KUBECONFIG=/home/dmitriy/Загрузки/config.yaml

где /home/dmitriy/Загрузки/ — полный путь до файла config.yaml.

Проверка клиентской и серверной версии Kubernetes

Несмотря на то, что данная проверка может показаться достаточно неочевидной, она играет фундаментальную роль для старта поиска проблем. Дело в том, что для стабильного функционирования Kubernetes необходимо, чтобы клиентская и серверная версии Kubernetes были одинаковыми во избежание непредвиденных проблем. Об этом в частности упоминается в официальной документации по установке утилиты kubectl.

Чтобы проверить клиентскую и серверную версию вашего кластера Kubernetes, необходимо выполнить команду:

kubectl version

В выводе команды обратите внимание на строки Client Version и Server Version. Если версии клиента и сервера будут отличаться (как на скриншоте выше), то в выводе команды будет выведено следующее предупреждение:

WARNING: version difference between client (1.31) and server (1.29) exceeds the supported minor version skew of +/-1.

Получение основной информации о кластере

Во время проверки работоспособности кластера может быть полезно узнать IP-адрес или доменное имя компонента кластера control plane, а также адрес встроенного в Kubernetes DNS-сервера — CoreDNS. Для этого используется команда:

kubectl cluster-info

Для получения самой подробной информации о кластере можно получить дамп кластера, воспользовавшись командой:

kubectl cluster-info dump

Учтите, что команда выводит огромный поток данных. Для их дальнейшего использования и анализа имеет смысл записать их в отдельный файл. Для этого достаточно перенаправить поток данных в отдельный файл:

kubectl cluster-info dump > cluster_dump.txt

Получение всех доступных API-объектов кластера

Если необходимо получить список всех API-объектов, которые доступны в кластере, достаточно выполнить команду:

kubectl api-resources

Зная имена объектов кластера, можно производить с ними различные действия — от получения списка присутствующих объектов до их редактирования и удаления. Вместо использования имени объекта можно использовать его сокращение (указываются в столбце SHORTNAMES), однако сокращенное имя поддерживается не у всех объектов.

Проверка работоспособности кластера

Рассмотрим, как проверить работоспосбность различных элементов кластера Kubernetes.

Ноды

Проверка статуса нод кластера

Начать стоит с проверки статуса нод кластера. Для этого используется команда:

kubectl get nodes

В выводе команды необходимо обратить внимание на столбец STATUS. Напротив каждой ноды должен отображаться статус Ready.

Вывод подробной информации

Если напротив какой-либо ноды отображается статус NotReady, то для выяснения более подробной причины можно отобразить полную информацию о ноде. Для этого используется команда:

kubectl describe node <имя_ноды>

В частности необходимо обратить внимание на разделы Conditions и Events, где отображаются все события, которые происходили на ноде. Благодаря данным сообщениям можно установить причину недоступности ноды.

Также в разделе Conditions отображается статусы таких компонентов узла, как:

• NetworkUnavailable — отображает статус корректности настройки сетевого взаимодействия. Если проблем с сетью нет, то отображается статус False. Если есть — будет отображен статус True.

• MemoryPressure — отображает статус оперативной памяти на узле. Если оперативной памяти достаточно, то отображается статус False, в противном случае — статус True.

• DiskPressure — отображает статус достаточного количества места на жестком диске ноды. Если места на диске достаточно, то отображается статус False. Если же наблюдается нехватка свободного места на жестком диске, то будет отображен статус True.

• PIDPressure — отображает статус «переполненности» процессов. Если на ноде запущено минимальное количество процессов, то отображается статус False. Если же на узле запущено много процессов, то будет отображен статус True.

• Ready — отображает общий статус работоспособности ноды. Если нода работоспособна и готова к запуску подов, то будет отображаться статус True. Если же на ноде будут найдены какие-либо проблемы (см. предыдущий список возможных проблем), то будет отображаться статус False.

Мониторинг использования ресурсов

В Kubernetes можно отслеживать потребление ресурсов как самих нод кластера, так и объектов типа под (pod), а также контейнеров.

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

kubectl top node

Команда top node отображает, сколько ресурсов процессора (столбец CPU) и оперативной памяти (столбец MEMORY) потребляет каждая нода. Значения отображаются в миллиядрах (для процессора) и в байтах для оперативной памяти. Также значения дублируются в процентном соотношении. 

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

kubectl top pod -A

Если требуется отобразить поды, находящиеся в определенном пространстве имен (namespace), необходимо явно указать имя пространства имен используя ключ -n:

kubectl top pod -n kube-system

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

kubectl top pod --containers -A

Просмотр событий в кластере

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

kubectl get events

При использовании команды get events будут выводиться все события, вне зависимости от типа объектов в кластере. 

В качестве столбцов используются следующие:

• LAST SEEN — время, когда произошло событие. Указывается в секундах, минутах, часах, днях и месяцев.

• TYPE — указывает на статус события. Является аналогом степени критичности. В качестве статуса поддерживаются значения Normal, Warning, Error.

• REASON — означает причину возникновения события. Например, причина Starting означает, что объект в кластере был запущен, а Pulling — что был скачан образ для контейнера (выполнен pull).

• OBJECT — объект кластера, с которым произошло какое-либо событие включая ноды кластера (например их инициализация).

• MESSAGE — отображает подробное сообщение события. Может оказаться полезным при поиске проблем. 

Можно сократить список событий путем использования конкретного пространства имен:

kubectl get events -n kube-system

Для более детального отображения событий используется опция wide:

kubectl get events -o wide

Опция wide добавляет новые столбцы с информацией, среди которых:

• SUBOBJECT — отображает подобъект, с которым связано событие; это может быть контейнер, том, секрет и т.д.

• SOURCE — источник события. Это может быть, например, компонент kubelet, node-controller и т.д.

• FIRST SEEN — временная метка, когда событие было впервые зарегистрировано в кластере.

• COUNT — количество повторений события с момента его появления в кластере.

• NAME — имя объекта, например, пода или секрета, с которым произошло событие. 

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

kubectl get events -w

Команда get events также поддерживает фильтры при помощи опции --field-selector, в которой указывается поле из вывода команды get events. Например, выведем все события в кластере, тип которых указан как Warning:

kubectl get events --field-selector type=Warning -A

Дополнительно поддерживается фильтрация по временным меткам. Например, чтобы вывести все события, которые произошли самыми первыми, используется параметр .metadata.creationTimestamp:

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

kube

API-сервер Kubernetes

API-сервер является ключевым компонентом и «мозгом» Kubernetes, через который проходят обработку все запросы к кластеру. Важно, чтобы API мог постоянно отвечать на запросы. Для проверки API-сервера используются специальные API Endpoints — livez и readyz.

Для запуска livez используется команда:

kubectl get --raw  '/livez?verbose'

Для запуска readyz используется команда:

kubectl get --raw  '/readyz?verbose'

Если при вызове запросы livez и readyz вернули статус ok, то API-сервер запущен и готов принимать запросы.

Компоненты кластера Kubernetes

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

kubectl get componentstatuses

Если в столбцах STATUS и MESSAGE будут отображены статусы Healthy и ok, то компоненты успешно запущены и работают. Если у какого-либо компонента будет найдена ошибка или произойдет сбой, то в столбце STATUS будет отображен статус Unhealthy, а в столбце MESSAGE будет предоставлено сообщение с ошибкой.

Контейнерный движок

Как известно, Kubernetes самостоятельно не запускает поды с контейнерами. Для этого используется сторонний компонент под названием Container Runtime Interface или сокращенно CRI, он же контейнерный движок. Важно знать, правильно ли отрабатывает среда для запуска контейнеров. На момент написания статьи Kubernetes поддерживает следующие контейнерные движки:

• containerd

• CRI-O

Стоит упомянуть, что среда для запуска и управления контейнеров Docker не поддерживается начиная с версии Kubernetes 1.24.

CRI-O

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

systemctl status crio

В строке Active должен отображаться статус active (running). Если статус отображается как failed, то причину ошибки стоит искать в информационных сообщениях crio и в лог-файлах. Для вывода основной информации о crio, включая последние сообщения об ошибках, используется команда:

crictl info

Если при работе с crio возникнет ошибка, то в параметре message будет отображаться ее полное описание. Также crio записывает все данные о своей работе в лог-файлы. По умолчанию они находятся в директории /var/log/crio/pods.

Дополнительно можно использовать журналы journalctl. В частности, чтобы вывести все журналы юнита crio, необходимо выполнить команду:

journalctl -u crio

Containerd

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

systemctl status containerd

В строке Active должен отображаться статус active (running). Если статус отображается как failed, то для получения более подробной информации можно выполнить встроенную команду status, которая отобразит все события, включая ошибки:

containerd status

Другой вариант — воспользоваться журналами journalctl. Для отображения журналов юнита crio необходимо выполнить команду:

journalctl -u containerd

Дополнительно можно проверить параметры конфигурационного файла containerd. Для этого используются две команды (вывод команд, как правило, достаточно большой):

• containerd config default — отображает конфигурационный файл по умолчанию. Используется в том случае, если в сам файл не были внесены какие-либо изменения. При возникновении ошибок данный файл с настройками можно использовать для отката. 
• containerd config dump — отображает текущий использующийся конфигурационный файл, в который были внесены какие-либо изменения.

Проверка статуса подов

Kubernetes оперирует подами — наименьшими единицами программного обеспечения в кластере, в которых запускаются контейнеры с приложениями. Статус подов должен быть всегда READY. Чтобы отобразить список всех подов в кластере и их статусы, необходимо выполнить команду:

kubectl get po -A

Чтобы отобразить поды только в одном конкретном пространстве имен (namespace), используется ключ -n, в котором указывается имя необходимого пространства:

kubectl get po -n kube-system

Для отображения более подробной информации о поде, включая возможные ошибки, можно воспользоваться командой kubectl describe pod, которая отображает максимально подробную информацию о поде:

kubectl describe pod coredns-6997b8f8bd-b5dq6 -n kube-system

Все события, связанные с подом, включая ошибки, отображаются в разделе Events:

Получение информации об объектах с помощью kubectl describe

Команда kubectl describe является мощным инструментом, когда нужно найти подробную информацию об объекте включая поиск и просмотр всевозможных ошибок. Команду можно применять ко всем объектам кластера Kubernetes которые присутствуют в выводе команды kubectl api-resources. 

Файлы типа deployment массово используются при развертывании приложений в кластере Kubernetes. Благодаря им можно контролировать состояние развертывания сервисов, включая увеличение реплик приложений. Для того чтобы вывести статусы всех доступных deployment в кластере Kubernetes, используется команда:

kubectl get deployments -A

Важно, чтобы в столбцах READY, UP-TO-DATE, AVAILABLE было отображено, столько подов, сколько указано в файле deployment. Стоит отметить, что если в столбце READY будет показано 0 или меньшее количество подов, чем задано, то под с приложением не будет запущен вовсе. Чтобы узнать причину ошибки, используется команда describe с указанием типа объекта, в данном случае deployment:

kubectl describe deployment coredns -n kube-system

Так же, как и при использовании describe при работе с подами, все события, включая ошибки, отображаются в разделе Conditions:

По аналогии с файлами типа deployment, команду kubectl describe можно использовать, например, с файлами объектов replicaset и statefulset.

Заключение

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