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