Стратегии обновления YTsaurus

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

Обзор стратегий

Стратегия обновления определяет, перезапускает ли оператор pod'ы компонента одновременно или последовательно по одному. От этого зависит, будет ли кластер доступен во время обновления.

Чтобы выбрать стратегию, опишите правила обновления в поле updatePlan. В каждом правиле вы указываете, какие компоненты обновлять и по какой стратегии. Одно правило может охватывать весь кластер, отдельные компоненты или группы компонент. Подробнее — в разделе Настройка поля updatePlan.

Оператор поддерживает три стратегии обновления:

Настройка поля updatePlan

Добавьте поле updatePlan в спецификацию кластера YTsaurus. В нём вы перечисляете правила: в каждом правиле выбираете компоненты по полю class или component и задаёте стратегию обновления в поле strategy. Оператор проверяет правила сверху вниз и применяет первое подходящее. Поэтому специфичные правила по полю component ставьте перед общими правилами по полю class.

Описание полей

Примеры настройки поля updatePlan для стратегии RollingUpdate смотрите в разделе Обновление без остановки кластера.

Предзагрузка образов

По умолчанию оператор скачивает новый образ во время обновления, когда pod уже остановлен. Из-за этого компонент дольше остаётся недоступным. Чтобы скачать образы заранее, включите предзагрузку — оператор скачает нужные образы до начала обновления, и переключение pod'ов пройдёт быстрее.

Предзагрузку для всех компонентов включает флаг enableImageHeater в блоке clusterFeatures:

spec:
  clusterFeatures:
    enableImageHeater: true

Предзагрузка особенно полезна при стратегии RollingUpdate, когда важно минимальное время недоступности. Пример совместной настройки — в разделе Обновление без остановки кластера.

Ход предзагрузки отражается в статусе WaitingForImageHeater поля UPDATESTATE.

Переход с enableFullUpdate на updatePlan

Начиная с версии оператора 0.32.0, поле updatePlan заменило флаг enableFullUpdate, поэтому этот флаг больше не действует. Информацию о релизах оператора смотрите на странице релизов.

Флаг enableFullUpdate только включал или отключал полное обновление. Поле updatePlan задаёт список правил: в каждом правиле вы выбираете компоненты и стратегию их обновления.

Прямое соответствие старого флага и нового поля:

# Оператор 0.31.0 и старше
spec:
  enableFullUpdate: true

# Оператор 0.32.0 и новее
spec:
  updatePlan:
    - class: Everything

Кроме прямого соответствия, updatePlan даёт возможности, которых не было у enableFullUpdate:

• Выбор набора компонентов. Правило с class: Stateless обновляет все stateless-компоненты, кроме мастер-серверов, Data-нод и Tablet-нод. Также можно выбрать отдельный компонент по типу через поле component.
• Выбор стратегии обновления. В поле strategy каждого правила вы задаёте стратегию RollingUpdate или OnDelete. Подробнее — в разделе Настройка поля updatePlan.

# Оператор 0.32.0 и новее
spec:
  updatePlan:
    - component:
        type: HttpProxy

Оператор обновляет только те компоненты, которые явно перечислены в updatePlan. Остальные компоненты он не трогает, даже если их образ изменился: такой компонент переходит в состояние UpdateBlocked и ждёт, пока вы добавите его в план.

Если updatePlan пуст или не задан, оператор не обновляет ничего. При изменении coreImage кластер перейдёт в состояние UpdateBlocked — обновление подготовлено, но заблокировано.

Стратегия по умолчанию BulkUpdate

Если вы не задали поле updatePlan или задали его без поля strategy, оператор применяет стратегию BulkUpdate. Обновление проходит в три фазы:

Подготовка.

Оператор включает safe mode и запрещает запись в кластер, сохраняет и удаляет таблет-целлы — динамические таблицы становятся недоступны. Затем оператор создаёт снапшоты мастер-серверов и переводит их в режим read-only.

Замена pod'ов.

Оператор одновременно удаляет pod'ы всех компонентов — на этом этапе кластер полностью недоступен. После этого оператор пересоздаёт pod'ы с новым образом.

Восстановление.

Оператор дожидается выхода мастер-серверов из режима read-only, восстанавливает таблет-целлы и отключает safe mode.

Кластер полностью недоступен от начала подготовки до конца восстановления. Длительность зависит от размера кластера — от нескольких минут до десятков минут.

Стратегия RollingUpdate

При стратегии RollingUpdate оператор обновляет pod'ы по одному или группами и гарантирует минимальное количество доступных инстансов.

Доступность компонентов при RollingUpdate

Рекомендуемое количество инстансов

Примеры настройки RollingUpdate для кластера — в разделе Дополнительные сценарии инструкции по обновлению.

Настройка доступности pod'ов

По умолчанию при стратегии RollingUpdate оператор обновляет по одному pod'у за раз. Чтобы задать другое количество, используйте поле minReadyInstanceCount:

spec:
  httpProxies:
    - instanceCount: 5
      minReadyInstanceCount: 3  # всегда минимум 3 pods доступны
      role: default

Оператор вычисляет количество одновременно обновляемых pod'ов по формуле:

maxUnavailable = max(1, instanceCount - minReadyInstanceCount)

В примере выше оператор обновляет до 2 pod'ов одновременно, а 3 pod'а всегда обслуживают запросы: maxUnavailable = max(1, 5 - 3) = 2.