Проверка состояния кластера kubernetes

Итак, вы наконец-то стали счастливым обладателем k8s-кластера: получили его в наследство, в подарок на Новый год, заказали в DataLine) и т. п. У новых клиентов и даже у опытных пользователей часто возникает вопрос, как оценить кластер и проверить его работоспособность?

В ответ мы написали этот мануал: при выполнении всех пунктов можно закрыть 95% вопросов о состоянии здоровья кластера. Поскольку проверка такой многокомпонентной системы может стать нетривиальной задачей, подойдем к процессу как можно проще.

Оцениваем общее состояние

1. Проверяем, насколько совпадает версия клиента и сервера, чтобы не получить несовместимость функционала при дальнейшей работе:

kubectl get version

2. Дальше смотрим основные ресурсы нашего кластера:

kubectl cluster-info (обращаем внимание на ip-адрес, порт, состояние корднс в кластере)
kubectl get cs -A (получаем статус основых компонентов k8s)

3. Оценим состояние наших нод и подов, их статус. Выполним команды:

kubectl get nodes -A -owide
kubectl get pods -owide

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

4. Посмотрим на события в кластере за последний час:

kubectl get events -owide

В выводе этой команды обращаем внимание на то:

• какие поды разворачивались и когда,
• были ли проблемы с хелсчеками,
• не заходил ли oom-киллер и т. п.

5. При установленном metrics-server также можно посмотреть на его нагрузку в кластере:

kubectl top nodes
kubectl top pods -A

Оценив общее состояние кластера, перейдем к просмотру состояния всех компонентов: здесь может вскрыться очень-очень много интересного.

Оцениваем состояние компонентов k8s

1. Посмотрим на работу сердца нашего кластера – etcd. Для этого обратимся к логам пода (или юнита):

kubectl logs -n kube-system etcd-cluster-m1 --follow --tail 1000

Нас интересует:

• Не теряется ли связь между членами кластера etcd. Обращаем внимание на ошибки с хелсчеками, невозможностью получить версию мембера.
• Предупреждения, что исполнение запроса заняло много времени
• Время сжатия данных.

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

Если etcd установлен на машинах, то посмотрим логи юнитов командой:

journalctl -u etcd -n 1000 --follow

2. То же самое делаем и с компонентами kubernetes. Cмотрим логи:

• kube-apiserver,
• kube-scheduler,
• kube-controller-manager.

Не забываем заглянуть и в логи kubelet на самих воркерах.

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

Изучение работы компонентов может занять какое-то время, но в итоге это поможет лучше понять общее состояние кластера.

3. Не упускаем из виду и функционирование сети в самом кластере. У нас в кластерах в качестве CNI используется calico, так что покажу на его примере.

Смотрим логи с подов calico. Обращаем внимание на частое изменение маршрутов и пересечения имен.

kubectl logs -n kube-system calico-kube-controllers-755d84984b-qq9t2 --follow --tail 100
kubectl logs -n kube-system calico-node-pf6sv --follow --tail 1000

Также можно поставить утилиту calicoctl и быстренько посмотреть состояние с ее помощью. Запустить ее можно через под или исполняемый файл. Главное – обеспечить аналогичную установленной версию calicoctl.

Устанавливаем выбранную версию в кластере:

kubectl apply -f https://docs.projectcalico.org/archive/v3.19/manifests/calicoctl.yaml

kubectl exec -ti -n kube-system calicoctl -- calicoctl get nodes -o wide
kubectl exec -ti -n kube-system calicoctl -- calicoctl get bgpPeer -o wide

Или можем использовать ту же утилиту со своей машины:

calicoctl get nodes
calicoctl get BGPpers

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

Тестирование кластера на соответствие требованиям CNCF

Стандарт CNCF позволяет обеспечить ожидаемое поведение от кластера.

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

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

1. Важно: определяемся с версией, которая поддерживает релиз нашего кластера. В данном случае скачаем последнюю версию программы

https://github.com/vmware-tanzu/sonobuoy/releases.

2. Запустим проверку кластера стандартными тестами:

sonobuoy run

Если хотим  ожидать завершения, можно использовать ключ --wait. Проверка кластера занимает около полутора часов.

Смотреть прогресс тестирования можно командой:

sonobuoy status

3. По завершении скачиваем архив с отчетом и смотрим ошибки:

results=$(sonobuoy retrieve)
sonobuoy results $results

Вот один из примеров того, с чем столкнулись мы:

[sig-api-machinery] AdmissionWebhook [Privileged:ClusterAdmin] should be able to deny attaching pod [Conformance]
[sig-api-machinery] AdmissionWebhook [Privileged:ClusterAdmin] should deny crd creation [Conformance]
[sig-api-machinery] CustomResourcePublishOpenAPI [Privileged:ClusterAdmin] works for CRD with validation schema [Conformance]
[sig-api-machinery] CustomResourcePublishOpenAPI [Privileged:ClusterAdmin] works for CRD without validation schema [Conformance]
[sig-cli] Kubectl client Guestbook application should create and stop a working application  [Conformance]
[sig-network] DNS should provide DNS for pods for Subdomain [Conformance]
[sig-network] Ingress API should support creating Ingress API operations [Conformance]

Следующей командой можно более подробно посмотреть на проблемы:

sonobuoy results $results --mode detailed | jq '. | select(.status == "failed") | .details'

Для соответствия рекомендациям нам пришлось поправить параметры запуска компонентов k8s, внести изменения в настройку ingress и API кластера.

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

sonobuoy run --e2e-focus "Ingress API should support creating Ingress API operations" --e2e-skip "" --wait

***

Теперь у нас на руках есть базовое представление о состоянии нашего кластера. Дальше при желании можно углубиться в работу самих компонентов, обратиться к метрикам из prometheus-operator, устроить тест etcd, балансировщика и проверить iops на сторадже. Главное – четко понимать, что вы хотите получить в итоге.