Проблеми, пов’язані з кластерами та вузлами Kubernetes

1. Node

1.1 Node NotReady

Стан NotReady вузла в кластері Kubernetes може бути спричинений різними проблемами. Ось деякі реалістичні та поширені причини:

1. Проблеми з ресурсами вузла

• Недостатньо пам’яті або процесорних ресурсів: Якщо вузол вичерпує пам’ять або ресурси CPU, kubelet може позначити вузол як NotReady.
• Тиск на диск: Якщо використання диска на вузлі надто велике, kubelet може позначити його як NotReady.
• Приклад: команда kubectl describe node покаже DiskPressure у розділі умов.
• Тиск на мережу: Висока латентність мережі або втрачені пакети можуть призвести до проблем з готовністю вузла.

2. Проблеми з kubelet

• kubelet не працює: Сервіс kubelet на вузлі не працює або зазнав збою.
• Проблеми з сертифікатами: Сертифікат kubelet може бути прострочений, що спричиняє невдачу автентифікації з kube-apiserver.
• Помилки в конфігурації: Неправильно налаштовані прапорці kubelet (наприклад, неправильні значення для --cluster-dns, --api-servers) можуть призвести до проблем з підключенням.

3. Проблеми з мережею

• Мережа вузла недоступна: Вузол не може зв’язатися з контрольним планом або іншими вузлами.
• Збій плагіна CNI: Проблеми з плагіном Container Network Interface (CNI) (наприклад, Calico, Flannel, Weave) можуть порушити зв’язок між подами чи вузлами.
• Правила фаєрволу: Фаєрвол або групи безпеки, що блокують трафік Kubernetes (наприклад, порти 6443, 10250), можуть призвести до того, що вузол стане NotReady.

4. Проблеми з підключенням до контрольного плану

• Неможливість досягти kube-apiserver: Вузол не може підключитися до API-сервера через розбиті мережі або проблеми з DNS-розв’язуванням.
• Проблеми з etcd: Якщо база даних etcd контрольного плану не працює або має проблеми, API-сервер може не відповідати на серцебиття вузлів.

5. Проблеми з компонентами

• Збій контейнерного оточення: Контейнерне оточення (наприклад, Docker, containerd, CRI-O) не працює або неправильно налаштоване.
• Збій kube-proxy: Компонент kube-proxy на вузлі не працює належним чином, порушуючи зв’язок між вузлами.

6. Інші причини

Є ще багато можливих причин, таких як апаратні збої, відсутність деяких конфігураційних файлів, або інколи невідповідність версії kubelet може спричиняти збій вузла.

1.1.1 Як відлагодити вузол у стані NotReady

1. Перевірте умови вузла та статус kubelet:

kubectl describe node   
systemctl status kubelet  
# якщо він не працює/неактивний, перезапустіть його  
systemctl restart kubelet

1. Перевірте журнали:

• Журнали kubelet:
• Також можна перевірити журнали контейнерного оточення (наприклад, Docker):

journalctl -u kubelet  
journalctl -u docker

1. Перевірте підключення до мережі:

• Пінгувати API-сервер контрольного плану:
• Перевірте журнали плагіна CNI.

journalctl -u kubelet

1. Перевірте використання ресурсів:

top  
df -h  
# або безпосередньо використовуйте kubectl top  
kubectl top node --sort-by='cpu' | awk 'NR==2 {print $1}'

У цій статті ми завжди будемо використовувати команди systemd, та систему ubuntu .

1.2 Cordon та Drain вузли

kubectl cordon NODENAME  
kubectl drain NODENAME  
kubectl uncordon NODENAME

1.2.1 kubectl cordon NODENAME

• Призначення: Позначає вузол як неспланований.
  Це запобігає розміщенню нових подів на цьому вузлі.
• Вплив на існуючі поди: Існуючі поди продовжують працювати на вузлі.
• Використання: тимчасово запобігти розміщенню нових навантажень на вузлі, наприклад, для розслідування або невеликого технічного обслуговування, без порушення роботи існуючих додатків.

УВАГА: якщо ви вказали nodeName:, то можна все одно запланувати под на цей вузол, тому що:

• Cordon вузла: це вказує планувальнику “не розміщувати нові поди на цьому вузлі якщо тільки немає дуже вагомої причини.”
• nodeName у специфікації пода: це буде пряма інструкція для Kubernetes: “Я хочу, щоб цей под працював спеціально на цьому вузлі.”

1.2.2 kubectl drain NODENAME

• Призначення: Видаляє всі поди з вузла та позначає його як неспланований.
• Вплив на існуючі поди: Коректно завершує роботу подів, що працюють на вузлі.
• Використання: виконати більш серйозне технічне обслуговування на вузлі, наприклад, оновлення ядра, заміну апаратного забезпечення.

2. Cluster

2.1 Оновлення

Слідуючи офіційним документам тут

0. Перевірка доступної версії

sudo apt update  
sudo apt-cache madison kubeadm

1. Оновлення kubeadm

# змініть версію, як вам потрібно  
sudo apt-mark unhold kubeadm && \  
sudo apt-get update && sudo apt-get install -y kubeadm='1.32.x-*' && \  
sudo apt-mark hold kubeadm  
kubeadm version

1.1 на контрольному вузлі

sudo kubeadm upgrade apply

1.2 на інших вузлах

sudo kubeadm upgrade node

2. Drain вузол

kubectl drain  --ignore-daemonsets

Якщо на інших вузлах, спочатку підключіться до контрольного вузла через SSH, потім зробіть drain на вузлі, потім знову підключіться до оновлюваного вузла

3. Оновлення kubelet та kubectl

# змініть версію, як вам потрібно  
sudo apt-mark unhold kubelet kubectl && \  
sudo apt-get update && sudo apt-get install -y kubelet='1.32.x-*' kubectl='1.32.x-*' && \  
sudo apt-mark hold kubelet kubectl

Потім перезапустіть kubelet

sudo systemctl daemon-reload  
sudo systemctl restart kubelet

4. Uncordon вузол

kubectl uncordon 

Аналогічно, якщо ви на іншому вузлі, спочатку підключіться до контрольного вузла через SSH, потім виконайте uncordon.

Оригінал був опублікований на https://dev.to 8 січня 2025 року.

Перекладено з: Kubenetes Cluster & Nodes related issues