Как определить причину сбоя кластера AKS kubernetes

У меня есть производственный кластер AKS kubernetes, размещенный на юге Великобритании, который стал нестабильным и не отвечает:

изображение 1

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

По таблице аналитических данных видно, что проблема началась около 21:50 прошлой ночью.

изображение 2

Я просмотрел журналы в самой службе AKS и журналы Kibana для приложений, работающих в кластере во время сбоя, но я изо всех сил пытаюсь найти что-нибудь, что могло бы вызвать это.

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

Мой вопрос: не хватает ли мне очевидных мест, где можно найти информацию о том, что вызвало проблему? какие-либо журналы событий, которые могут указывать на проблему?


azure kubernetes azure-aks
person Declan McNulty    schedule 18.01.2019    source источник
comment
как насчет уровня платформы? это могло быть проблемой на уровне платформы   -  person 4c74356b41    schedule 18.01.2019
comment
Журналы что-нибудь показывают? Вы пробовали просматривать журналы модуля / контейнера?   -  person Rico    schedule 18.01.2019
comment
Вы включили сбор журналов? Если у вас есть, журналы kubernetes-api-server записываются в большой двоичный объект хранилища или собираются в экземпляре loganalytics.   -  person Aditya Sundaramurthy    schedule 18.01.2019
comment
Кроме того, AKS недавно перешел из сообщества Docker на Moby. У нас проблемы с кластерами с тех пор, как они переключились. В частности, что касается процесса демона Docker, который перестает отвечать на запросы.   -  person Aditya Sundaramurthy    schedule 18.01.2019
comment
Судя по вашему описанию и фотографии, я думаю, что есть две возможные причины: 1. ресурсов недостаточно, 2. в вашем изображении, приложении или конфигурации есть какая-то ошибка. Вы можете проверить модуль или службу с помощью команды kubectl describe pod/service podName/serviceName.   -  person Charles Xu    schedule 19.01.2019
comment
@AdityaSundaramurthy Подали ли вы заявку в службу поддержки по проблеме, которую вы описываете? Надо посмотреть (я ведущий менеджер по AKS).   -  person Sean McKenna    schedule 19.01.2019

Ответы (2)


arrow_upward
1
arrow_downward

Я бы посоветовал изучить журнал событий K8s примерно в то время, когда ваши узлы были «не готовы».

Попробуйте открыть вкладку «Узлы» и выберите верхний период времени, когда что-то пошло не так. Посмотрите, какие статусы узлов. Любое давление? Вы можете увидеть это на панели свойств справа от списка узлов. Панель свойств также содержит ссылку на журналы событий за этот период времени ... Обратите внимание, что ссылка на журналы событий на панели свойств узла создает сложный запрос для отображения только событий, отмеченных этим узлом.

Вы можете получить эту информацию с помощью более простых запросов (а также выполнить более интересные запросы) в журналах. Откройте вкладку «Журналы» в левом меню кластера и выполните запрос, аналогичный этому (измените временной интервал на тот, который вам нужен):

let startDateTime = datetime('2019-01-01T13:45:00.000Z');
let endDateTime = datetime('2019-01-02T13:45:00.000Z');
KubeEvents_CL
| where TimeGenerated >= startDateTime and TimeGenerated < endDateTime
| order by TimeGenerated desc

Посмотрите, есть ли у вас события, указывающие на то, что пошло не так. Также интересно посмотреть инвентаризацию узлов в вашем кластере. Узлы сообщают о состоянии K8s. До возникновения проблемы он был "Готов" ... Затем что-то пошло не так - каков статус? Случайно закончился диск?

let startDateTime = datetime('2019-01-01T13:45:00.000Z');
let endDateTime = datetime('2019-01-02T13:45:00.000Z');
KubeNodeInventory
| where TimeGenerated >= startDateTime and TimeGenerated < endDateTime
| order by TimeGenerated desc
person Vitaly    schedule 18.01.2019

arrow_upward
0
arrow_downward

Просто догадка, но проверьте наличие https://github.com/Azure/AKS/issues/305 есть шаги, чтобы определить и исправить это.

person user10891134    schedule 25.01.2019