Compare languages | Модуль deckhouse: примеры конфигурации

Настройка режима обновления

Setting up the update mode

Управлять обновлением DKP можно следующими способами:

  • С помощью параметра settings.update ModuleConfig deckhouse;
  • С помощью секции параметров disruptions NodeGroup.

You can manage DKP updates in the following ways:

Конфигурация окон обновлений

Update windows configuration

Управлять временными окнами, когда Deckhouse будет устанавливать обновления автоматически, можно следующими способами:

You can configure the time windows when Deckhouse will automatically install updates in the following ways:

Пример настройки двух ежедневных окон обновлений: с 8:00 до 10:00 и c 20:00 до 22:00 (UTC):

An example of setting up two daily update windows — from 8 a.m. to 10 a.m. and from 8 p.m. to 10 p.m. (UTC):

yaml apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: deckhouse spec: version: 1 settings: releaseChannel: EarlyAccess update: windows:

  • from: “8:00” to: “10:00”
  • from: “20:00” to: “22:00”

yaml apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: deckhouse spec: version: 1 settings: releaseChannel: EarlyAccess update: windows:

  • from: “8:00” to: “10:00”
  • from: “20:00” to: “22:00”

Также можно настроить обновления в определенные дни, например по вторникам и субботам с 18:00 до 19:30 (UTC):

You can also set up updates on certain days, for example, on Tuesdays and Saturdays from 6 p.m. to 7:30 p.m. (UTC):

yaml apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: deckhouse spec: version: 1 settings: releaseChannel: Stable update: windows:

  • from: “18:00” to: “19:30” days:
  • Tue
  • Sat

yaml apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: deckhouse spec: version: 1 settings: releaseChannel: Stable update: windows:

  • from: “18:00” to: “19:30” days:
  • Tue
  • Sat

Ручное подтверждение обновлений

Manual update confirmation

Ручное подтверждение обновления версии Deckhouse предусмотрено в следующих случаях:

  • Включен режим подтверждения обновлений Deckhouse.

Manual confirmation of Deckhouse version updates is provided in the following cases:

  • The Deckhouse update confirmation mode is enabled.

Это значит, что параметр settings.update.mode ModuleConfig deckhouse установлен в Manual (подтверждение как patch-версии, так и минорной версии Deckhouse) или в AutoPatch (подтверждение минорной версии Deckhouse). Для подтверждения обновления необходимо выполнить следующую команду, указав необходимую версию Deckhouse:

This means that the parameter settings.update.mode in the ModuleConfig deckhouse is set to Manual (confirmation for both patch and minor versions of Deckhouse) or AutoPatch (confirmation for the minor version of Deckhouse). To confirm the update, it is necessary to execute the following command, specifying the required version of Deckhouse:

shell kubectl patch DeckhouseRelease v1.66.2 –type=merge -p=’{“approved”: true}’

shell kubectl patch DeckhouseRelease v1.66.2 –type=merge -p=’{“approved”: true}’

  • Включено подтверждение потенциально опасных обновлений (disruptive-обновлений).
  • Disruptive updates confirmation is enabled.

Это значит, что параметр update.disruptionApprovalMode ModuleConfig deckhouse установлен в Manual. Вы можете использовать следующую команду, чтобы установить его в Manual: shell kubectl patch mc deckhouse –type=merge -p=’{“spec”:{“update”:{“disruptionApprovalMode”:”Manual”}}}’

This means that the parameter update.disruptionApprovalMode in the deckhouse ModuleConfig is set to Manual. You can use the following command to set it to Manual: shell kubectl patch mc deckhouse –type=merge -p=’{“spec”:{“update”:{“disruptionApprovalMode”:”Manual”}}}’

Для подтверждения потенциального опасного обновления необходимо установить аннотацию release.deckhouse.io/disruption-approved=true на соответствующем ресурсе DeckhouseRelease. Пример:

To confirm a disruptive update, you need to set the annotation release.deckhouse.io/disruption-approved=true on the corresponding DeckhouseRelease resource. Example:

shell kubectl annotate DeckhouseRelease v1.66.2 release.deckhouse.io/disruption-approved=true

  • Если для какой-либо группы узлов отключено автоматическое применение потенциально опасных обновлений.

shell kubectl annotate DeckhouseRelease v1.66.2 release.deckhouse.io/disruption-approved=true

Это значит, что у NodeGroup, соответствующего группе узлов, установлен параметр spec.disruptions.approvalMode в Manual.

  • If automatic application of potentially dangerous updates is disabled for a node group.

Для обновления каждого узла в такой группе на узел нужно установить аннотацию update.node.deckhouse.io/disruption-approved=. Пример:

This means that the corresponding NodeGroup has the parameter spec.disruptions.approvalMode set to Manual.

shell kubectl annotate node ${NODE_1} update.node.deckhouse.io/disruption-approved=

For updating each node in such a group, the node must have update.node.deckhouse.io/disruption-approved= annotation. Example:

Оповещение об обновлении Deckhouse

shell kubectl annotate node ${NODE_1} update.node.deckhouse.io/disruption-approved=

В режиме обновлений Auto можно настроить вызов webhook’а для получения оповещения о предстоящем обновлении минорной версии Deckhouse.

Deckhouse update notification

Пример настройки оповещения:

In the Auto update mode, you can set up a webhook call, to be notified of an upcoming Deckhouse minor version update.

yaml apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: deckhouse spec: version: 1 settings: update: releaseChannel: Stable mode: Auto notification: webhook: https://release-webhook.mydomain.com

An example:

После появления новой минорной версии Deckhouse на используемом канале обновлений, но до момента применения ее в кластере на адрес webhook’а будет выполнен POST-запрос.

yaml apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: deckhouse spec: version: 1 settings: update: releaseChannel: Stable mode: Auto notification: webhook: https://release-webhook.mydomain.com

Чтобы всегда иметь достаточно времени для реакции на оповещение об обновлении Deckhouse, достаточно настроить параметр minimalNotificationTime. В этом случае обновление случится по прошествии указанного времени с учетом окон обновлений.

After a new Deckhouse minor version appears on the update channel, a POST request will be executed to the webhook’s URL before it is applied in the cluster.

Пример:

Set the minimalNotificationTime parameter to have enough time to react to a Deckhouse update notification. In this case, the update will happen after the specified time, considering the update windows.

yaml apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: deckhouse spec: version: 1 settings: update: releaseChannel: Stable mode: Auto notification: webhook: https://release-webhook.mydomain.com minimalNotificationTime: 8h

An example:

Если не указать адрес в параметре update.notification.webhook, но указать время в параметре update.notification.minimalNotificationTime, применение новой версии все равно будет отложено как минимум на указанное в параметре minimalNotificationTime время. В этом случае оповещением о появлении новой версии можно считать появление в кластере ресурса DeckhouseRelease, имя которого соответствует новой версии.

yaml apiVersion: deckhouse.io/v1alpha1 kind: ModuleConfig metadata: name: deckhouse spec: version: 1 settings: update: releaseChannel: Stable mode: Auto notification: webhook: https://release-webhook.mydomain.com minimalNotificationTime: 8h

Сбор информации для отладки

If you do not specify the address in the update.notification.webhook parameter, but specify the time in the update.notification.minimalNotificationTime parameter, then the release will still be postponed for at least the time specified in the minimalNotificationTime parameter. In this case, the notification of the appearance of a new version can be considered the appearance of a DeckhouseRelease resource with a name corresponding to the new version.

О сборе отладочной информации читайте в FAQ.

Collect debug info

 

Read the FAQ to learn more about collecting debug information.