Мой вопрос (к MS и всем остальным): почему возникает эта проблема, и какие обходные пути могут быть реализованы самими пользователями/клиентами, а не службой поддержки Microsoft?
Очевидно, было несколько других вопросов по этому вопросу:
- Ошибка управляемого Azure Kubernetes
- Не удается связаться с нашим Azure-AKS kube - тайм-аут рукопожатия TLS
- Azure Kubernetes: Тайм-аут рукопожатия TLS (этот отзыв имеет некоторые отзывы Microsoft)
В репозитории AKS опубликовано несколько выпусков GitHub:
- https://github.com/Azure/AKS/issues/112
- https://github.com/Azure/AKS/issues/124
- https://github.com/Azure/AKS/issues/164
- https://github.com/Azure/AKS/issues/177
- https://github.com/Azure/AKS/issues/324
Плюс несколько тем в твиттере:
TL; DR
В настоящее время лучшим решением является отправка запроса о помощи - и подождите - или воссоздание кластера AKS (возможно, несколько раз, скрестите пальцы, см. ниже...), но должно быть что-то лучшее. По крайней мере, предоставьте возможность пользователям AKS для предварительного просмотра, независимо от уровня поддержки, обновить уровень серьезности запросов на поддержку для ЭТОЙ конкретной проблемы.
Вы также можете попробовать масштабировать свой кластер (при условии, что это не сломает ваше приложение).
А как насчет GitHub?
Многие из указанных выше проблем GitHub были закрыты как решенные, но проблема сохраняется. Ранее существовал документ с объявлениями о проблеме, но в настоящее время такие обновления статуса недоступны, хотя проблема продолжает появляться:
Я публикую это, поскольку у меня есть несколько новых лакомых кусочков, которых я не видел в других местах, и мне интересно, есть ли у кого-нибудь идеи относительно других возможных вариантов решения этой проблемы.
Затрагиваемое использование ресурсов виртуальных машин и узлов
Первая часть, которую я не видел, упоминавшаяся где-то в другом месте, - это использование ресурсов на узлах /vms/instance, на которые влияет вышеуказанная проблема Kubectl "Невозможно подключиться к серверу: net/http: TLS handshake timeout".
Использование производственного узла
Узлы на моем затронутом кластере выглядят так:
Падение загрузки и сети io сильно коррелирует как с увеличением использования диска, так и с периодом времени, когда мы начали испытывать проблему.
Общее использование узлов/виртуальных машин, как правило, остается неизменным до появления этой диаграммы в течение предыдущих 30 дней, за исключением нескольких проблем, связанных с трафиком на рабочих сайтах/обновлениями и т.д.
Метрики после устранения проблем (добавлено вскрытие)
К вышеупомянутому пункту, вот метрики того же узла после масштабирования вверх, а затем обратно вниз (что, как оказалось, облегчает нашу проблему, но не всегда работает - см. ответы внизу):
Обратите внимание на "провал" в процессоре и сети? Это когда проблема Net/http: TLS повлияла на нас - и когда сервер AKS был недоступен для Kubectl. Похоже, он не общался с VM/Node, а также не отвечал на наши запросы.
Как только мы вернулись (масштабировали # узлы вверх на один, а затем вернулись вниз - см. ответы об обходном пути), показатели (ЦП и т.д.) Вернулись в нормальное состояние - и мы смогли подключиться из Kubectl. Это означает, что мы, вероятно, можем создать сигнал тревоги для этого поведения (и у меня есть проблема, спрашивая об этом на стороне DevOps Azure: https://github.com/Azure/AKS/issues/416)
Размер узла потенциально влияет на частоту выпуска
Циммергрен на GitHub указывает, что у него меньше проблем с большими экземплярами, чем с пустыми узлами меньших узлов. Это имеет смысл для меня и может указывать на то, что серверы AKS распределяют рабочую нагрузку (см. следующий раздел) в зависимости от размера экземпляров.
"Размер узлов (например, D2, A4 и т.д.) :) Я сталкивался с тем, что при работе на А4 и выше мой кластер более здоров, чем, например, на А2. (К сожалению, у меня более десятка подобных опытов с комбинациями размеров и сбоями кластеров). "(https://github.com/Azure/AKS/issues/268#issuecomment-375715435)
Другие ссылки на размер кластера:
Может ли сервер AKS, отвечающий за более мелкие кластеры, попадать чаще?
Наличие нескольких "серверов" управления AKS в одном регионе Az
Следующее, что я не видел, упомянутое в другом месте, это тот факт, что вы можете иметь несколько кластеров, работающих бок о бок в одном и том же регионе, где один кластер (производство для нас в этом случае) получает "net/http: TLS handshake timeout" а другой работает нормально и может нормально подключаться через Kubectl (для нас это наша идентичная промежуточная среда).
Тот факт, что пользователи (Zimmergren и т.д. Выше), кажется, считают, что размер узла влияет на вероятность того, что эта проблема повлияет, вы также указываете на то, что размер узла может относиться к тому, как обязанности субрегиона назначаются субрегиональному AKS. серверы управления.
Это может означать, что повторное создание кластера с другим размером кластера с большей вероятностью поместит вас на другой сервер управления, что облегчит проблему и уменьшит вероятность того, что потребуется многократное повторное создание.
Использование промежуточного кластера
Оба наших кластера AKS находятся на востоке США. В качестве ссылки на приведенные выше метрики "производственного" кластера использование ресурсов "промежуточного" кластера (также восток США) не приводит к значительному падению ввода-вывода ЦП/сети - И не имеет увеличения дискового и т.д. За тот же период:
На идентичные среды влияют по-разному
Оба наших кластера работают с одинаковыми входами, службами, модулями и контейнерами, поэтому маловероятно, что что-то, что делает пользователь, вызывает эту проблему.
Повторное создание успешное ИНОГДА.
Вышеупомянутое существование нескольких субрегиональных обязанностей сервера управления AKS имеет смысл с поведением, описанным другими пользователями на github (https://github.com/Azure/AKS/issues/112), где некоторые пользователи могут воссоздать кластер (с которым можно связаться), в то время как другие повторно создать и все еще иметь проблемы.
Чрезвычайная ситуация может = многократное воссоздание
В чрезвычайной ситуации (т.е. ваш производственный сайт... как наш... необходимо управлять) вы можете НАДЕЖНО просто заново создать, пока не получите работающий кластер, который оказывается на другом сервере управления AKS экземпляр (тот, который не затронут), но имейте в виду, что это может не произойти с первой попытки - воссоздание кластера AKS происходит не совсем мгновенно.
Это сказал...
Ресурсы на затронутых узлах продолжают функционировать
Кажется, что все контейнеры/входы/ресурсы на нашей затронутой виртуальной машине работают хорошо, и у меня нет никаких сигналов тревоги для мониторинга времени безотказной работы/ресурсов (кроме странности использования, указанной выше на графиках)
Я хочу знать, почему возникает эта проблема, и какие обходные пути могут быть реализованы самими пользователями, а не службой поддержки Microsoft (в настоящее время есть билет). Если у вас есть идея, дайте мне знать.
Потенциальные намеки на причину
- https://github.com/Azure/AKS/issues/164#issuecomment-363613110
- https://github.com/Azure/AKS/issues/164#issuecomment-365389154
Почему нет ГКЕ?
Я понимаю, что Azure AKS находится в предварительном просмотре и что многие люди перешли в GKE из-за этой проблемы(). Тем не менее, мой опыт работы с Azure до сих пор был только положительным, и я предпочел бы предложить решение, если это вообще возможно.
А также... GKE иногда сталкивается с чем-то похожим:
Мне было бы интересно посмотреть, решило ли проблему масштабирование узлов в GKE.
