Проверяем, насколько совпадает версия клиента и сервера, чтобы не получить несовместимость функционала при дальнейшей работе:
kubectl version
Дальше смотрим основные ресурсы нашего кластера:
kubectl cluster-info (обращаем внимание на ip-адрес, порт, состояние корднс в кластере)
kubectl get cs -A (получаем статус основых компонентов k8s)
Оценим состояние наших нод и подов, их статус. Выполним команды:
kubectl get nodes -owide
kubectl get pods -A -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 позволяет обеспечить ожидаемое поведение от кластера. Определим, имеет ли наш кластер стандартные настройки. Для этого обратимся к утилите 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