Блог

У меня возникли некоторые проблемы с довольно новым кластером, где пара узлов (кажется, всегда происходит парами, но, возможно, это просто совпадение) станут неготовыми, и kubectl describe скажет, что Kubelet прекратил публикацию статуса узла для памяти, диска, PID и ready.

Все запущенные модули застряли в завершении (можно использовать k9s для подключения к кластеру и увидеть это), и единственное решение, которое я нашел, — это оцепить и слить узлы. Через несколько часов они, похоже, удаляются и создаются новые. В качестве альтернативы я могу удалить их с помощью kubectl.

Они полностью недоступны через ssh (тайм-аут), но AWS сообщает, что экземпляры EC2 не имеют проблем.

За последнюю неделю это произошло три раза. Все восстанавливается нормально, но явно есть какая-то проблема, и я хотел бы разобраться в ней.

Как бы я мог узнать, что произошло, если я вообще не могу получить доступ к ящикам? (На самом деле мне только что пришло в голову, возможно, сделать снимок тома и смонтировать его, поэтому я попробую, если это произойдет снова, но любые другие предложения приветствуются)

Запуск kubernetes версии v1.18.8

Здесь есть две наиболее распространенные возможности, обе, скорее всего, вызваны большой нагрузкой:

• Out of Memory ошибка на узле kubelet. Может быть решена путем добавления надлежащего --kubelet-extra-args в BootstrapArguments . Например: --kubelet-extra-args "--kube-reserved memory=0.3Gi,ephemeral-storage=1Gi --system-reserved memory=0.2Gi,ephemeral-storage=1Gi --eviction-hard memory.available<200Mi,nodefs.available<10%"

• Проблема, объясненная здесь:

иногда kubelet не может исправить статус своего узла, потому что на узле остается более 250 ресурсов, kubelet не может одновременно просматривать более 250 потоков с помощью kube-apiserver. Итак, я просто настраиваю kube-apiserver —http2-max-streams-per-connection на 1000, чтобы облегчить боль.

Вы можете либо скорректировать приведенные выше значения, либо попытаться найти причину высокой нагрузки / операций ввода-вывода и попытаться настроить ее.

У меня была такая же проблема, через 20-30 минут мои узлы перешли в NotRready статус, и все модули, связанные с этими узлами, застряли в Terminating статусе.
Я пытался подключиться к своим узлам через SSH, иногда я сталкивался с таймаутом, иногда я мог (с трудом) подключиться, и я выполнил top команду для проверки запущенных процессов.
Наиболее трудоемким процессом было kswapd0 .
Память моего экземпляра и процессор были заполнены (!), Потому что он пытался много поменять местами (из-за нехватки памяти), в результате чего kswapd0 процесс потреблял более 50% процессора!

Основная причина:
некоторые модули потребляли 400% своего запроса памяти (определенного при развертывании Kubernetes), поскольку они изначально были недостаточно подготовлены. Как следствие, когда мои узлы запустились, Kubernetes разместил их на узлах с запросом памяти всего 32 МБ на модуль (значение, которое я определил), но этого было недостаточно.

Решение:
решение заключалось в увеличении запросов на контейнеры:

 requests:
  memory: "32Mi"
    cpu: "20m"
    limits:
       memory: "256Mi"
       cpu: "100m"
  

С этими значениями (в моем случае):

 requests:
  memory: "256Mi"
    cpu: "20m"
    limits:
       memory: "512Mi"
       cpu: "200m"
  

Важно:
После этого я обработал текущее обновление (кордон> слив > удаление) моих узлов, чтобы гарантировать, что Kubernetes напрямую резервирует достаточно памяти для моих недавно запущенных модулей.

Вывод:
регулярно проверяйте потребление памяти вашими модулями и со временем корректируйте запросы на ресурсы.
Цель состоит в том, чтобы ваши узлы никогда не были удивлены насыщением памяти, потому что обмен может быть фатальным для ваших узлов.

Ответ оказался проблемой с iops в результате команд du, поступающих, как я думаю, из cadvisor. Я перешел на поля io1, и с тех пор у меня была стабильность, поэтому я отмечу это как закрытое, а перемещение типов экземпляров ec2 как разрешение

Спасибо за помощь!