Проверка состояния кластера kubernetes28.12.2021 12:02

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

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

Не только посмотрим в зубы нашему дареному коню, но и проверим температуру. Не только посмотрим в зубы нашему дареному коню, но и проверим температуру.

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

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

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

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

Оценим состояние наших нод и подов, их статус. Выполним команды:
```
kubectl get nodes -A -owide
kubectl get pods -owide
```
Здесь обращаем внимание на время жизни и количество рестартов подов: частые рестарты могут свидетельствовать о проблемах в кластере.
Посмотрим на события в кластере за последний час:
```
kubectl get events -owide
```
В выводе этой команды обращаем внимание на то:
- какие поды разворачивались и когда,
- были ли проблемы с хелсчеками,
- не заходил ли oom-киллер и т. п.
При установленном metrics-server также можно посмотреть на его нагрузку в кластере:
```
kubectl top nodes
kubectl top pods -A
```

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

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

Посмотрим на работу сердца нашего кластера — etcd. Для этого обратимся к логам пода (или юнита):
```
kubectl logs -n kube-system etcd-cluster-m1 --follow --tail 1000
```
Нас интересует:
- не отваливаются ли реплики,
- нет ли троттлинга,
- время сжатия данных.
Здесь уже могут вскрыться признаки проблем с производительностью дисков и сети.
Если компоненты k8s стоят на машинах, можно посмотреть логи юнитов:
```
journalctl -u etcd -n 1000 --follow
```
То же самое делаем и с компонентами kubernetes. Cмотрим:
- логи kube-apiserver,
- kube-scheduler,
- kube-controller-manager.
Не забываем заглянуть и в логи kubelet на самих воркерах.
Скорее всего, на этих этапах уже встретятся ошибки. Тут могут вскрыться и признаки проблем с сетью, средой запуска контейнеров, валидностью сертификатов, частой сменой лидеров шедулера и контроллера k8s и т. п. На этом этапе необходимо оценить их критичность и частоту.
Изучение работы компонентов может занять какое-то время, но в итоге это поможет лучше понять общее состояние кластера.
Не упускаем из виду и функционирование сети в самом кластере. У нас в кластерах в качестве 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.

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

Важно: определяемся с версией, которая поддерживает релиз нашего кластера. В данном случае скачаем последнюю версию программы
https://github.com/vmware-tanzu/sonobuoy/releases.
Запустим проверку нашего кластера стандартными тестами:
```
sonobuoy run
```
Если хотим ожидать завершения, можно использовать ключ --wait. Проверка кластера занимает около полутора часов.
Смотреть прогресс тестирования можно командой:
```
sonobuoy status
```

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

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 на сторадже. Главное — четко понимать, что вы хотите получить в итоге.