Я сталкиваюсь с простоями всякий раз, когда кластер GKE обновляется во время периода обслуживания. Мои сервисы (API) становятся недоступными примерно через ~ 5 минут.
Тип расположения кластера установлен на «Зональный», и все мои модули имеют 2 реплики. Похоже, что затронуты только те модули, которые используют контроллер входа nginx.
Могу ли я что-нибудь сделать, чтобы предотвратить это? Я читал, что использование региональных кластеров должно предотвратить простои в плоскости управления, но я не уверен, что это связано с моим случаем. Любые подсказки будут оценены!
Вы упоминаете «время простоя», но это время простоя для вас, использующего плоскость управления (т. е. kubectl
перестает работать), или это время простоя, когда конечный пользователь, использующий службы, перестает видеть, что служба работает.
Обновление GKE обновляет две части кластера: плоскость управления или главные узлы и рабочие узлы. Это два отдельных обновления, хотя они могут выполняться одновременно в зависимости от конфигурации кластера.
В этом могут помочь региональные кластеры, но они будут стоить дороже, поскольку у вас будет больше узлов, но плюс в том, что кластер более устойчив.
Возвращаясь к предыдущему пункту об обновлении плоскости управления и узла. Обновление уровня управления НЕ влияет на перспективу конечного пользователя/заказчика. Службы будут продолжать работать.
Обновление узла БУДЕТ влиять на клиента, поэтому вам следует рассмотреть различные методы, чтобы обеспечить высокую доступность и отказоустойчивость ваших служб.
Распространенным методом является увеличение числа реплик, а также включение модуля антиаффинность. Это гарантирует, что модули будут запланированы на разных узлах, поэтому, когда произойдет обновление узла, оно не отключит всю службу, поскольку кластер запланировал все реплики на одном узле.
В своем вопросе вы упоминаете контроллер входа nginx. Если вы используете Helm для установки этого в свой кластер, то по умолчанию он не настроен для использования антиаффинности, поэтому он может быть выведен из эксплуатации, если все его реплики будут запланированы на один и тот же узел, а затем этот узел помечается для обновления или чего-то подобного.
Спасибо Вам за подробный ответ! Говоря «время простоя», я имел в виду, что мои службы становятся недоступными, спасибо, что указали на это! Да, я использую Helm для входящего контроллера. На самом деле, я только что заметил, что он был развернут только с 1 репликой ... Я попытаюсь увеличить количество реплик и выяснить, как включить анти-аффинити pod, надеюсь, это решит мою проблему. Спасибо еще раз!
Ссылка в ответе покажет несколько примеров антиаффинности, которые вы можете использовать. Аналогичный пример есть в stackoverflow.com/questions/71790088/… (это для Wordpress, но идея та же). Вы можете проверить, находятся ли ваши модули на разных узлах, выполнив kubectl get pods -n {namespace} -o wide
и посмотрев, что отображается под заголовком «Узел».
Вы можете использовать региональный кластер или использовать оператор входа не по умолчанию.