Налагодження вузлів Kubernetes за допомогою kubectl
Ця сторінка показує, як налагоджувати вузол на кластері Kubernetes за допомогою команди kubectl debug
.
Перш ніж ви розпочнете
Вам треба мати кластер Kubernetes, а також інструмент командного рядка kubectl має бути налаштований для роботи з вашим кластером. Рекомендується виконувати ці настанови у кластері, що має щонайменше два вузли, які не виконують роль вузлів управління. Якщо у вас немає кластера, ви можете створити його, за допомогою minikube або використовувати одну з цих пісочниць:
Версія вашого Kubernetes сервера має бути не старішою ніж 1.2. Для перевірки версії введітьkubectl version
.Вам потрібно мати дозвіл на створення Podʼів та призначення їх новим Вузлам. Також вам потрібно мати дозвіл на створення Podʼів, які мають доступ до файлових систем з хосту.
Налагодження вузла за допомогою kubectl debug node
Використовуйте команду kubectl debug node
, щоб розмістити Pod на Вузлі, який ви хочете налагодити. Ця команда корисна в сценаріях, коли ви не можете отримати доступ до свого Вузла за допомогою зʼєднання SSH. Після створення Podʼа, відкривається інтерактивний інтерфейс оболонки на Вузлі. Щоб створити інтерактивну оболонку на Вузлі з назвою “mynode”, виконайте:
kubectl debug node/mynode -it --image=ubuntu
Creating debugging pod node-debugger-mynode-pdx84 with container debugger on node mynode.
If you don't see a command prompt, try pressing enter.
root@mynode:/#
Команда налагоджування допомагає збирати інформацію та розвʼязувати проблеми. Команди, які ви можете використовувати, включають ip
, ifconfig
, nc
, ping
, ps
тощо. Ви також можете встановити інші інструменти, такі як mtr
, tcpdump
та curl
, з відповідного менеджера пакунків.
Примітка:
Команди для налагодження можуть відрізнятися залежно від образу, який використовує Pod налагодження, і ці команди можуть потребувати встановлення.Pod налагодження може отримувати доступ до кореневої файлової системи Вузла, підключеної за адресою /host
в Podʼі. Якщо ви використовуєте kubelet у просторі імен файлової системи, Pod налагодження бачить корінь для цього простору імен, а не всього Вузла. Для типового вузла Linux ви можете переглянути наступні шляхи для пошуку відповідних логів:
/host/var/log/kubelet.log
- Логи
kubelet
, який відповідає за запуск контейнерів на вузлі. /host/var/log/kube-proxy.log
- Логи
kube-proxy
, який відповідає за направлення трафіку на точки доступу Service. /host/var/log/containerd.log
- Логи процесу
containerd
, який працює на вузлі. /host/var/log/syslog
- Показує загальні повідомлення та інформацію щодо системи.
/host/var/log/kern.log
- Показує логи ядра.
При створенні сеансу налагодження на Вузлі майте на увазі, що:
kubectl debug
автоматично генерує імʼя нового контейнера на основі імені вузла.- Коренева файлова система Вузла буде змонтована за адресою
/host
. - Хоча контейнер працює у просторі імен IPC, мережі та PID хосту, Pod не є привілейованим. Це означає, що читання деякої інформації про процес може бути неможливим, оскільки доступ до цієї інформації мають тільки суперкористувачі. Наприклад,
chroot /host
буде невдалим. Якщо вам потрібен привілейований контейнер, створіть його вручну або використовуйте прапорець--profile=sysadmin
. - Застосовуючи профілі налагодження, ви можете встановити конкретні властивості, такі як securityContext до Podʼу налагодження.
Очищення
Коли ви закінчите використання Podʼа налагодження, видаліть його:
kubectl get pods
NAME READY STATUS RESTARTS AGE
node-debugger-mynode-pdx84 0/1 Completed 0 8m1s
# Змініть імʼя контейнера відповідно
kubectl delete pod node-debugger-mynode-pdx84 --now
pod "node-debugger-mynode-pdx84" deleted
Примітка:
Командаkubectl debug node
не працюватиме, якщо Вузол відключений (відʼєднаний від мережі, або kubelet вимкнено і він не перезапускається тощо). Перевірте налагодження вимкненого/недоступного вузла в цьому випадку.