--- metadata: - name: generator content: Diplodoc Platform v5.50.6 - property: og:title content: Стратегии обновления YTsaurus - property: og:description content: В документе описаны стратегии обновления кластера YTsaurus. - property: og:type content: article - property: og:url content: https://ytsaurus.tech/docs/ru/admin-guide/update/update_strategy - property: article:tag content: admin-guide/update/update_strategy - property: article:modified_time content: '2026-07-27T17:00:00+03:00' - property: article:author content: Захар Телух alternate: - https://ytsaurus.tech/docs/ru/admin-guide/update/update_strategy.md --- > **Documentation Index:** Fetch the complete configuration index at https://ytsaurus.tech/docs/ru/llms.txt # Стратегии обновления YTsaurus В этой статье описаны стратегии обновления компонентов кластера YTsaurus, их отличия и порядок настройки. Выбирайте стратегию в зависимости от требований к доступности кластера во время обновления. ## Обзор стратегий {#strategies} Стратегия обновления определяет, перезапускает ли оператор pod'ы компонента одновременно или последовательно по одному. От этого зависит, будет ли кластер доступен во время обновления. Чтобы выбрать стратегию, опишите правила обновления в поле `updatePlan`. В каждом правиле вы указываете, какие компоненты обновлять и по какой стратегии. Одно правило может охватывать весь кластер, отдельные компоненты или группы компонент. Подробнее — в разделе [Настройка поля updatePlan](https://ytsaurus.tech/docs/ru/admin-guide/update/update_strategy.md#updateplan). Оператор поддерживает три стратегии обновления: #| || **Стратегия** | **Описание** | **Доступность кластера** || || `BulkUpdate` | Оператор применяет эту стратегию по умолчанию, если вы не указали её явно. Оператор одновременно удаляет и пересоздаёт все pod'ы компонента. При обновлении мастер-серверов оператор включает safe mode и создаёт снапшоты. Планируйте такое обновление в период минимальной нагрузки. Подробнее — в разделе [Стратегия по умолчанию `BulkUpdate`](#default) | Кластер недоступен || || `RollingUpdate` | Доступна с версии оператора **0.31.0**. Оператор обновляет pod'ы по одному или группами и гарантирует минимальное количество доступных инстансов. Подходит не для всех компонентов: мастер-серверы можно обновить только через `BulkUpdate` или `OnDelete`. Для остальных компонентов требуется минимум 2 инстанса. Подробнее — в разделе [Стратегия `RollingUpdate`](#configure-rolling) | Кластер доступен, кроме обновления мастер-серверов || || `OnDelete` | Доступна с версии оператора **0.31.0**. Оператор обновляет спецификацию `StatefulSet`, но не перезапускает pod'ы автоматически — вы удаляете их вручную. Для мастер-серверов удаляйте pod'ы по одному, иначе кластер станет недоступен | Зависит от действий пользователя || |# ## Настройка поля updatePlan {#updateplan} Добавьте поле `updatePlan` в спецификацию кластера YTsaurus. В нём вы перечисляете правила: в каждом правиле выбираете компоненты по полю `class` или `component` и задаёте стратегию обновления в поле `strategy`. Оператор проверяет правила сверху вниз и применяет первое подходящее. Поэтому специфичные правила по полю `component` ставьте перед общими правилами по полю `class`. #### Описание полей {#fields} #| || **Поле** | **Описание** || || `class` | Выбор компонентов по классу. Доступные значения: - `Everything` — оператор обновляет все компоненты; - `Stateless` — оператор обновляет все [stateless-компоненты](*stateless), кроме мастер-серверов, Data-нод и Tablet-нод; - `Nothing` — оператор не обновляет ни один компонент. || || `component.type` | Выбор по типу компонента: `Master`, `HttpProxy`, `RpcProxy`, `DataNode`, `ExecNode`, `TabletNode`, `Scheduler`, `ControllerAgent`, `Discovery` и другие || || `component.name` | Выбор конкретной instance group по имени. Необязательное поле || || `concurrency` | Максимальное количество instance groups, которые оператор обновляет одновременно || || `strategy.rollingUpdate` | Стратегия `RollingUpdate`: оператор обновляет pod'ы по одному || || `strategy.onDelete` | Стратегия `OnDelete`: вы удаляете pod'ы вручную || || `strategy.runPreChecks` | Запускать ли pre-checks перед обновлением каждого pod'а || |# Примеры настройки поля `updatePlan` для стратегии `RollingUpdate` смотрите в разделе [Обновление без остановки кластера](https://ytsaurus.tech/docs/ru/admin-guide/update/update-ytsaurus.md#rolling-update-scenario). ## Предзагрузка образов {#image-heater} По умолчанию оператор скачивает новый образ во время обновления, когда pod уже остановлен. Из-за этого компонент дольше остаётся недоступным. Чтобы скачать образы заранее, включите предзагрузку — оператор скачает нужные образы до начала обновления, и переключение pod'ов пройдёт быстрее. Предзагрузку для всех компонентов включает флаг `enableImageHeater` в блоке `clusterFeatures`: ```yaml spec: clusterFeatures: enableImageHeater: true ``` Предзагрузка особенно полезна при стратегии `RollingUpdate`, когда важно минимальное время недоступности. Пример совместной настройки — в разделе [Обновление без остановки кластера](https://ytsaurus.tech/docs/ru/admin-guide/update/update-ytsaurus.md#rolling-update-scenario). Ход предзагрузки отражается в статусе `WaitingForImageHeater` поля `UPDATESTATE`. ## Переход с enableFullUpdate на updatePlan {#migration-from-enablefullupdate} Начиная с версии оператора **0.32.0**, поле `updatePlan` заменило флаг `enableFullUpdate`, поэтому этот флаг больше не действует. Информацию о релизах оператора смотрите на [странице релизов](https://ytsaurus.tech/docs/ru/admin-guide/releases.md#kubernetes-operator). Флаг `enableFullUpdate` только включал или отключал полное обновление. Поле `updatePlan` задаёт список правил: в каждом правиле вы выбираете компоненты и стратегию их обновления. Прямое соответствие старого флага и нового поля: #| || **Флаг `enableFullUpdate`** | **Поле `updatePlan`** | **Результат** || || `enableFullUpdate: true` | Правило с `class: Everything` | Обновить все серверные компоненты || || `enableFullUpdate: false` | Пустой `updatePlan` или правило с `class: Nothing` | Не обновлять ничего || |# {% cut "Пример: полное обновление" %} ```yaml # Оператор 0.31.0 и старше spec: enableFullUpdate: true ``` ```yaml # Оператор 0.32.0 и новее spec: updatePlan: - class: Everything ``` {% endcut %} Кроме прямого соответствия, `updatePlan` даёт возможности, которых не было у `enableFullUpdate`: - **Выбор набора компонентов.** Правило с `class: Stateless` обновляет все [stateless-компоненты](*stateless), кроме мастер-серверов, Data-нод и Tablet-нод. Также можно выбрать отдельный компонент по типу через поле `component`. - **Выбор стратегии обновления.** В поле `strategy` каждого правила вы задаёте стратегию `RollingUpdate` или `OnDelete`. Подробнее — в разделе [Настройка поля updatePlan](#updateplan). {% cut "Пример: обновить только HTTP-прокси" %} ```yaml # Оператор 0.32.0 и новее spec: updatePlan: - component: type: HttpProxy ``` Флаг `enableFullUpdate` не позволял выбрать отдельный компонент — он обновлял либо все серверные компоненты, либо ни одного. Обновить один компонент можно было только переопределением его образа в поле `image`. Этот способ работает и сейчас — подробнее в разделе [Обновление отдельных компонентов](https://ytsaurus.tech/docs/ru/admin-guide/update/update-ytsaurus.md#partial-update). {% endcut %} Оператор обновляет только те компоненты, которые явно перечислены в `updatePlan`. Остальные компоненты он не трогает, даже если их образ изменился: такой компонент переходит в состояние `UpdateBlocked` и ждёт, пока вы добавите его в план. Если `updatePlan` пуст или не задан, оператор не обновляет ничего. При изменении `coreImage` кластер перейдёт в состояние `UpdateBlocked` — обновление подготовлено, но заблокировано. ## Стратегия по умолчанию BulkUpdate {#default} Если вы не задали поле `updatePlan` или задали его без поля `strategy`, оператор применяет стратегию `BulkUpdate`. Обновление проходит в три фазы: Подготовка. : Оператор включает safe mode и запрещает запись в кластер, сохраняет и удаляет таблет-целлы — динамические таблицы становятся недоступны. Затем оператор создаёт снапшоты мастер-серверов и переводит их в режим `read-only`. Замена pod'ов. : Оператор одновременно удаляет pod'ы всех компонентов — на этом этапе кластер полностью недоступен. После этого оператор пересоздаёт pod'ы с новым образом. Восстановление. : Оператор дожидается выхода мастер-серверов из режима `read-only`, восстанавливает таблет-целлы и отключает safe mode. Кластер полностью недоступен от начала подготовки до конца восстановления. Длительность зависит от размера кластера — от нескольких минут до десятков минут. ## Стратегия RollingUpdate {#configure-rolling} При стратегии `RollingUpdate` оператор обновляет pod'ы по одному или группами и гарантирует минимальное количество доступных инстансов. ### Доступность компонентов при RollingUpdate {#component-availability} #| || **Компонент** | **Что делает оператор** | **Доступность** || || HTTP/RPC-прокси | Оператор обновляет pod'ы по одному. Kubernetes Service автоматически перенаправляет трафик на готовые pod'ы | Клиенты могут обращаться к кластеру || || Data-ноды | Оператор обновляет pod'ы по одному. Данные доступны через реплики на других нодах | Чтение и запись работают || || Exec-ноды | Перед обновлением pod'а оператор отключает scheduler jobs, после обновления — включает обратно | Оставшиеся ноды выполняют операции || || Tablet-ноды | Оператор обновляет pod'ы по одному | Динамические таблицы доступны через оставшиеся ноды || || Планировщик, Controller-агент | Оператор обновляет pod'ы по одному | Планирование операций работает || || Мастер-серверы | Для мастер-серверов `RollingUpdate` пока не реализован. Оператор обновляет их через `BulkUpdate` или `OnDelete` | При `BulkUpdate` кластер недоступен || |# {% note warning "Важно" %} Для корректной работы стратегии `RollingUpdate` у каждого компонента должно быть минимум 2 инстанса. Если инстанс один, при его обновлении компонент будет недоступен так же, как при `BulkUpdate`. {% endnote %} ### Рекомендуемое количество инстансов {#instance-count} #| || **Компонент** | **Минимум для доступности** | **Рекомендуется** || || HTTP/RPC-прокси | 2 | 3 и более || || Data-ноды | 3 — для репликации данных | 3 и более || || Exec-ноды | 2 | 2 и более || || Мастер-серверы | 3 — для кворума | 3 || || Tablet-ноды | 2 | 3 и более || |# Примеры настройки `RollingUpdate` для кластера — в разделе [Дополнительные сценарии](https://ytsaurus.tech/docs/ru/admin-guide/update/update-ytsaurus.md#rolling-update-scenario) инструкции по обновлению. ### Настройка доступности pod'ов {#budget} По умолчанию при стратегии `RollingUpdate` оператор обновляет по одному pod'у за раз. Чтобы задать другое количество, используйте поле `minReadyInstanceCount`: ```yaml 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`. {% cut "Примеры расчёта maxUnavailable" %} #| || **instanceCount** | **minReadyInstanceCount** | **maxUnavailable** | **Что происходит** || || 1 | не задано → 0 | 1 | Оператор обновляет единственный pod, компонент недоступен || || 3 | не задано → 2 | 1 | Оператор обновляет по 1 pod'у, 2 pod'а всегда доступны || || 5 | 3, задано явно | 2 | Оператор обновляет по 2 pod'а, 3 pod'а всегда доступны || || 5 | не задано → 4 | 1 | Оператор обновляет по 1 pod'у, 4 pod'а всегда доступны || |# {% endcut %} [*stateless]: Stateless-компоненты не хранят данные — это HTTP- и RPC-прокси, планировщик, Controller-агент и другие. Мастер-серверы, Data-ноды и Tablet-ноды относятся к stateful-компонентам: они отвечают за хранение данных, поэтому стратегия `Stateless` их не обновляет.