Как избежать простоев во время планового обслуживания

Я сталкиваюсь с простоями всякий раз, когда кластер GKE обновляется во время периода обслуживания. Мои сервисы (API) становятся недоступными примерно через ~ 5 минут.

Тип расположения кластера установлен на «Зональный», и все мои модули имеют 2 реплики. Похоже, что затронуты только те модули, которые используют контроллер входа nginx.

Могу ли я что-нибудь сделать, чтобы предотвратить это? Я читал, что использование региональных кластеров должно предотвратить простои в плоскости управления, но я не уверен, что это связано с моим случаем. Любые подсказки будут оценены!

Вы можете использовать региональный кластер или использовать оператор входа не по умолчанию.

guillaume blaquiere 02.05.2022 22:23
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Kubernetes - это портативная, расширяемая платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и сервисами, которая...
0
1
60
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

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

Обновление GKE обновляет две части кластера: плоскость управления или главные узлы и рабочие узлы. Это два отдельных обновления, хотя они могут выполняться одновременно в зависимости от конфигурации кластера.

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

Возвращаясь к предыдущему пункту об обновлении плоскости управления и узла. Обновление уровня управления НЕ влияет на перспективу конечного пользователя/заказчика. Службы будут продолжать работать.

Обновление узла БУДЕТ влиять на клиента, поэтому вам следует рассмотреть различные методы, чтобы обеспечить высокую доступность и отказоустойчивость ваших служб.

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

В своем вопросе вы упоминаете контроллер входа nginx. Если вы используете Helm для установки этого в свой кластер, то по умолчанию он не настроен для использования антиаффинности, поэтому он может быть выведен из эксплуатации, если все его реплики будут запланированы на один и тот же узел, а затем этот узел помечается для обновления или чего-то подобного.

Спасибо Вам за подробный ответ! Говоря «время простоя», я имел в виду, что мои службы становятся недоступными, спасибо, что указали на это! Да, я использую Helm для входящего контроллера. На самом деле, я только что заметил, что он был развернут только с 1 репликой ... Я попытаюсь увеличить количество реплик и выяснить, как включить анти-аффинити pod, надеюсь, это решит мою проблему. Спасибо еще раз!

spiriteris 03.05.2022 15:18

Ссылка в ответе покажет несколько примеров антиаффинности, которые вы можете использовать. Аналогичный пример есть в stackoverflow.com/questions/71790088/… (это для Wordpress, но идея та же). Вы можете проверить, находятся ли ваши модули на разных узлах, выполнив kubectl get pods -n {namespace} -o wide и посмотрев, что отображается под заголовком «Узел».

Blender Fox 03.05.2022 15:26

Другие вопросы по теме