Итак, вы наконец-то стали счастливым обладателем k8s-кластера: получили его в наследство, в подарок на Новый год, заказали в DataLine) и т. п. У новых клиентов и даже у опытных пользователей часто возникает вопрос, как оценить кластер и проверить его работоспособность?  В ответ мы написали этот мануал: при выполнении всех пунктов можно закрыть 95% вопросов о состоянии здоровья кластера. Поскольку проверка такой многокомпонентной системы может стать нетривиальной задачей, подойдем к процессу как можно проще. Проверяем, насколько совпадает версия клиента и сервера, чтобы не получить несовместимость функционала при дальнейшей работе: Дальше смотрим основные ресурсы нашего кластера:   Оценим состояние наших нод и подов, их статус. Выполним команды:   Здесь обращаем внимание на время жизни и количество рестартов подов: частые рестарты могут свидетельствовать о проблемах в кластере.   Посмотрим на события в кластере за последний час:   В выводе этой команды обращаем внимание на то: какие поды разворачивались и когда,  были ли проблемы с хелсчеками,  не заходил ли oom-киллер и т. п. При установленном metrics-server также можно посмотреть на его нагрузку в кластере:   Оценив общее состояние кластера, перейдем к просмотру состояния всех компонентов: здесь может вскрыться очень-очень много интересного. Посмотрим на работу сердца нашего кластера – etcd. Для этого обратимся к логам пода (или юнита):  Нас интересует: не отваливаются ли реплики,  нет ли троттлинга,  время сжатия данных.  Здесь уже могут вскрыться признаки проблем с производительностью дисков и сети.   Если компоненты k8s стоят на машинах, можно посмотреть логи юнитов:    То же самое делаем и с компонентами kubernetes. Cмотрим:   логи kube-apiserver,  kube-scheduler,  kube-controller-manager.   Не забываем заглянуть и в логи kubelet на самих воркерах.   Скорее всего, на этих этапах уже встретятся ошибки. Тут могут вскрыться и признаки проблем с сетью, средой запуска контейнеров, валидностью сертификатов, частой сменой лидеров шедулера и контроллера k8s и т. п. На этом этапе необходимо оценить их критичность и частоту.  Изучение работы компонентов может занять какое-то время, но в итоге это поможет лучше понять общее состояние кластера. Не упускаем из виду и функционирование сети в самом кластере. У нас в кластерах в качестве CNI используется calico, так что покажу на его примере.     Смотрим логи с подов calico. Обращаем внимание на частое изменение маршрутов и пересечения имен.     Также можно поставить утилиту calicoctl и быстренько посмотреть состояние с ее помощью. Запустить ее можно через под или исполняемый файл. Главное – обеспечить аналогичную установленной версию calicoctl.  Устанавливаем нашу версию в кластере: Или можем использовать ту же утилиту со своей машины:   Где-нибудь здесь при желании можно измерить скорость сети между самими подами, к примеру, утилитой iperf. В том числе это касается подов, расположенных на разных машинах.   Стандарт CNCF позволяет обеспечить ожидаемое поведение от кластера.  Определим, имеет ли наш кластер стандартные настройки. Для этого обратимся к утилите Sonobuoy: мы используем ее для тестирования своих сборок k8s. На данном этапе могут выясниться недостающие параметры запуска компонентов, функциональные проблемы кластера или невозможность обработать действия в самом кластере. Важно: определяемся с версией, которая поддерживает релиз нашего кластера. В данном случае скачаем последнюю версию программыhttps://github.com/vmware-tanzu/sonobuoy/releases. Запустим проверку нашего кластера стандартными тестами:   Если хотим  ожидать завершения, можно использовать ключ --wait. Проверка кластера занимает около полутора часов.   Смотреть прогресс тестирования можно командой:   По завершении скачиваем архив с отчетом и смотрим ошибки:   Вот один из примеров того, с чем столкнулись мы:   Следующей командой можно более подробно посмотреть на проблемы:   Для соответствия рекомендациям нам пришлось поправить параметры запуска компонентов k8s, внести изменения в настройку ingress и API кластера. После устранения неисправности, чтобы не ждать прохождения полного теста, можно запустить только конкретный: Теперь у нас на руках есть базовое представление о состоянии нашего кластера. Дальше при желании можно углубиться в работу самих компонентов, обратиться к метрикам из prometheus-operator, устроить тест etcd, балансировщика и проверить iops на сторадже. Главное – четко понимать, что вы хотите получить в итоге.