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

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

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

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

   kubectl 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

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

   • не отваливаются ли реплики, 

   • нет ли троттлинга, 

   • время сжатия данных. 

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

2. Если компоненты k8s стоят на машинах, можно посмотреть логи юнитов:

   journalctl -u etcd -n 1000 --follow

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

   • логи kube-apiserver, 

   • kube-scheduler, 

   • kube-controller-manager. 

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

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

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

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