Устранение неполадок в Kubernetes: руководство для начинающих

Если вы работаете или работали с Kubernetes, скорее всего, вы столкнулись с некоторыми из проблем, описанных здесь.

Это случается с лучшими из нас: вы приходите в офис в понедельник, ваша NMS вся в минусе, узлы кластера Kubernetes не работают, а балансировщик нагрузки не работает.

Я здесь, чтобы сэкономить вам время на устранение неполадок, рассмотрев типичные проблемы, которые я видел в своих собственных развертываниях.

Я занимаюсь разработкой и передовым кодом, и мне всегда нравится экспериментировать с новыми способами развертывания узлов Kubernetes и различных оверлейных сетей. Именно в этих развертываниях возникает большинство моих проблем с Kubernetes.

Давайте приступим.

Нет ответа от удаленного Kubectl

The connection to the server localhost:8080 was refused — did you specify the right host or port?

Большинство администраторов Kubernetes когда-то сталкивались с этой ошибкой. Это происходит, когда либо API Kubernetes недоступен по указанному URL-адресу, либо есть проблема с API Kubernetes.

Обратите внимание, что проблема с разрешениями в Kubernetes API, скорее всего, приведет к другой ошибке.

Для начала убедимся, что kubectl установлен и имеет правильную версию:

kubectl version

Результат должен быть примерно таким, как показано ниже:

Client Version: version.Info{Major:”1", Minor:”12", GitVersion:”v1.12.1", GitCommit:”4ed3216f3ec431b140b1d899130a69fc671678f4", GitTreeState:”clean”, BuildDate:”2018–10–05T16:46:06Z”, GoVersion:”go1.10.4", Compiler:”gc”, Platform:”linux/amd64"}

Если есть другие ошибки (команда не найдена и т. Д.):

• Убедитесь, что вы запускаете kubectl от имени пользователя, у которого есть доступ для выполнения команд kubectl.
• Убедитесь, что пути kubectl настроены правильно.
• По умолчанию kubectl не работает с учетной записью «root».

Если сам kubectl работает должным образом, мы можем перейти к устранению неполадок кластера.

ssh к одному из ваших главных узлов:

ssh [email protected]

Одна из наиболее распространенных проблем - сбой службы etcd на одном или нескольких главных узлах.

Вы можете проверить статус услуги через:

service etcd status

Если служба сообщает о мертвой, значит, проблема здесь.

Одна из наиболее распространенных причин сбоя службы etcd (особенно после перезагрузки главного узла) заключается в том, что на узле включен свопинг. Это особенно актуально для кластеров под управлением kubeadm.

Как root, запустите:

swapoff -ased -i '/ swap / s/^/#/' /etc/fstab

Затем отключите запуск подкачки при загрузке:

nano /etc/fstab# Comment out the second line mentioning swap
# Save the file

Своп также может повлиять на службу kubelet.

Вы можете проверить статус услуги через:

service kubelet status

Вы также можете найти журналы обеих служб в /var/log для дальнейшего устранения неполадок.

Выполните эти проверки на всем etcd кластере (на всех главных узлах).

Теперь у вас должен быть исправный кластер, и kubectl должен работать.

Проблемы с постоянными объемами

Устранение неполадок постоянных томов состоит из двух частей:

• Устранение неполадок с претензиями на объем.
• Устранение неполадок с привязкой модуля тома.

Доступность тома

Первый шаг - проверить, видит ли кластер Kubernetes PV. Самый простой способ посмотреть PV в кластере - через панель управления Kubernetes.

Если у вас не установлена ​​панель управления, у вас есть несколько вариантов:

• Получите приложение для iOS или Android под названием Kuber и подключитесь к своему кластеру.
• Настройте приборную панель. (Вот подробное руководство).
• Используйте kubectl.

Чтобы просмотреть PV через kubectl, запустите:

lyokowarrior@kube-client:~$ kubectl get pv
NAME             CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                   STORAGECLASS   REASON   AGE
task-pv-volume   10Gi       RWO            Retain           Bound    default/task-pv-claim   manual                  20h

В приведенных выше выходных данных указан один исправный связанный том.

Общие шаги по устранению неполадок:

• Если вы используете NFS, убедитесь, что общие ресурсы NFS доступны для кластера.
• Убедитесь, что тома исправны и находятся в состоянии «привязка».
• Ознакомьтесь с примером руководства по PV здесь:

Служба недоступна

Распространенная проблема в любом кластере заключается в том, что развернутая служба недоступна при развертывании или становится недоступной по какой-либо причине.

Например, у нас есть развертывание HTTPD, работающее на порте 3182, который должен быть доступен в локальной сети через балансировщик нагрузки.

• Сценарий 1. Служба вообще недоступна. (Нет ответа от curl localhost: 3182).
• Сценарий 2: Услуга доступна только изнутри.

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

Еще раз, панель управления Kubernetes может помочь вам понять статус ваших сервисов. Если у вас нет панели инструментов, вы можете использовать kubectl.

Чтобы повторно развернуть службу:

kubectl delete service affected-service

(Замените имя службы своим собственным).

kubectl expose deployment affected-deployment -n=default --type=LoadBalancer --name=affected-service --external-ip=192.168.2.54 --port=3182

Воссоздайте выставленный сервис. (Замените имена, IP-адреса и пространства имен своими собственными).

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

Не могу войти в Личный кабинет

Панели мониторинга на автономных кластерах Kubernetes могут быть непростыми. Распространенная проблема - невозможность войти в панель управления.

Токен требуется для входа в большинство установок, и первый шаг - проверить, работает ли токен и был ли выбран правильный:

kubectl get secrets -n=kube-system | grep dashboard

Должен появиться список всего secrets, относящегося к приборной панели. Если ничего не отображается, возможно, что-то не так с развертыванием панели мониторинга.

Ознакомьтесь с моим руководством по развертыванию или по одной из приведенных ниже ссылок с инструкциями по развертыванию информационной панели.

Теперь давайте получим содержимое secret:

kubectl describe secret kubernetes-dashboard-token-xxx0x-n=kube-system

(Замените имя secret именем из списка из предыдущего шага).

Скопируйте и вставьте secret на страницу входа в панель управления. Теперь вы можете войти в систему.

Распространенной проблемой является ошибка аутентификации HTTP при попытке доступа к панели управления.

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

Примечание. Чтобы полностью удалить все компоненты приборной панели:

kubectl delete deployment kubernetes-dashboard --namespace=kube-system 
kubectl delete service kubernetes-dashboard  --namespace=kube-system 
kubectl delete role kubernetes-dashboard-minimal --namespace=kube-system 
kubectl delete rolebinding kubernetes-dashboard-minimal --namespace=kube-system
kubectl delete sa kubernetes-dashboard --namespace=kube-system 
kubectl delete secret kubernetes-dashboard-certs --namespace=kube-system
kubectl delete secret kubernetes-dashboard-key-holder --namespace=kube-system

Убедитесь, что все компоненты панели управления удалены:

kubectl get secret,sa,role,rolebinding,services,deployments --namespace=kube-system | grep dashboard

Как всегда, приветствую комментарии и вопросы.

Ресурсы

Чтобы ознакомиться с полными руководствами по приборной панели, посмотрите:

~ Павел