Обновление и откат Workload

1. Войдите в CCE console и нажмите имя кластера, чтобы открыть консоль кластера.
2. В панели навигации выберите Workloads. В правом верхнем углу отображаемой страницы нажмите Create Workload.
3. В области Upgrade под Advanced Settings выберите режим обновления. Подробности см. в Table 1. Общие параметры для поочередных обновлений и заменяющих обновлений служат схожим целям, хотя их реализации различаются.

   Table 1 режимы обновления Workload

   Параметр	Описание	Ограничение
   Максимальное количество недоступных Pods (maxUnavailable)	Максимальное количество или процент Pods, которые могут быть недоступны во время поочередного обновления. Это также задаёт предел для количества работающих Pods, которое может быть ниже ожидаемого. Значение по умолчанию — 25%. Во время обновления процент преобразуется в абсолютное число и округляется вниз. Например, если spec.replicas установлено в 2, недоступными не может быть ни один Pod (2 × 0.25 = 0.5, округлено вниз до 0). Следовательно, во время обновления всегда будет работать как минимум два Pod'а (2 запрошено – 0 недоступно). Каждый старый Pod удаляется только после создания нового, что гарантирует, что как минимум два Pod'а всегда работают до завершения обновления всех Pod'ов.	Этот параметр доступен только для Deployments и DaemonSets.
   Max. Surge (maxSurge)	Максимальное количество или процент pod‑ов, которые могут существовать сверх желаемого количества pod‑ов во время скользящего обновления. Этот параметр определяет максимальное количество новых pod‑ов, которые могут быть созданы одновременно для замены старых pod‑ов. Значение по умолчанию — 25%. При обновлении процент преобразуется в абсолютное число и округляется вверх. Например, если spec.replicas установлено в 2, по умолчанию одновременно может быть создано не более одного pod‑а (2 × 0.25 = 0.5, округляется вверх до 1). Следовательно, во время обновления может существовать до 3 pod‑ов (2 желаемых + 1 surge).	Этот параметр доступен только для Deployments и DaemonSets.
   Min. Ready Seconds (minReadySeconds)	Минимальная продолжительность, в течение которой новый pod должен оставаться в состоянии ready, прежде чем будет отмечен как доступный. Это обеспечивает стабильный период наблюдения, предотвращая преждевременное подключение нестабильных pod‑ов к сервису и тем самым повышая стабильность и надёжность развертывания.	None
   Revision History Limit (revisionHistoryLimit)	Максимальное количество старых ReplicaSet‑ов, сохраняемых для отката. Они потребляют ресурсы etcd и отображаются в выводе kubectl get rs. Исторические конфигурации каждого Deployment хранятся в соответствующем ReplicaSet. Удаление старого ReplicaSet делает невозможным откат Deployment к этой версии. По умолчанию CCE сохраняет последние 10 старых ReplicaSet.	None
   Max. Upgrade Duration (progressDeadlineSeconds)	Максимальное время в секундах, за которое Deployment может выполнить прогресс, прежде чем будет считаться неудачным. При указании этого параметра убедитесь, что его значение больше, чем minReadySeconds. Во время поэтапного обновления, если Deployment не делает прогресс в течение времени, указанного в progressDeadlineSeconds, он помечается следующими условиями: Type=Progressing, Status=False и Reason=ProgressDeadlineExceeded. Указанная информация свидетельствует о том, что обновление Deployment завершилось неудачей. CCE фиксирует событие сбоя, но не откатывает Deployment автоматически до предыдущей версии. Откат необходимо выполнить вручную или инициировать внешним механизмом.	Этот параметр доступен только для Deployment.
   Временное окно масштабирования (terminationGracePeriodSeconds)	Максимальное время, которое kubelet ожидает, пока контейнеры в pod завершатся корректно при удалении pod. Значение по умолчанию — 30 секунд. Контейнеры должны завершиться в течение этого периода. В противном случае они будут принудительно завершены с помощью SIGKILL.	None

4. Настройте другие параметры и нажмите Create Workload. Статус workload изменится на Running позже.

Ниже используется Deployment в качестве примера для описания того, как настроить политику обновления workload с помощью kubectl.

1. Используйте kubectl для доступа к кластеру. Подробности см. в Accessing a Cluster Using kubectl.
2. Создайте файл с именем nginx-deployment.yaml. Это имя лишь пример. При необходимости вы можете переименовать его.

   vi nginx-deployment.yaml
   
   

   Ниже приведён пример файла. Подробности о конфигурации Deployment см. в Kubernetes official documentation.

   apiVersion: apps/v1
   kind: Deployment  
   metadata:
     name: nginx   
     namespace: default  
   spec:
     replicas: 2   
     selector:
       matchLabels:   
         app: nginx
     template:  
       metadata:
         labels:  
           app: nginx
       spec:
         containers:
         - image: nginx:latest    
           imagePullPolicy: Always  
           name: nginx  
           resources:  
             requests:  
               cpu: 250m
               memory: 512Mi
             limits:  
               cpu: 250m
               memory: 512Mi
         imagePullSecrets:  
         - name: default-secret  
          terminationGracePeriodSeconds: 30 
      strategy: 
        type: RollingUpdate  # A rolling upgrade.  Recreate  indicates a replacement upgrade.
        rollingUpdate:  # Configure rolling upgrade parameters.
          maxUnavailable: 25% 
          maxSurge: 25% 
      minReadySeconds: 0 
      revisionHistoryLimit: 10 
      progressDeadlineSeconds: 600 
   
   

   Table 2 Режимы обновления workload

   Параметр	Описание	Ограничение
   maxUnavailable	Максимальное количество или процент pods, которые могут быть недоступны во время скользящего обновления. Это также задаёт предел для количества работающих pods, которые могут быть ниже ожидаемого числа. Значение по умолчанию — 25%. Во время обновления процент преобразуется в абсолютное число и округляется вниз. Например, если spec.replicas установлен в 2, то pods недоступными быть не могут (2 × 0.25 = 0.5, округляется вниз до 0). Следовательно, во время обновления всегда будет работать как минимум два pod‑а (2 desired – 0 unavailable). Каждый старый pod удаляется только после создания нового, обеспечивая, что как минимум два pod‑а всегда работают до завершения обновления всех pod‑ов.	Этот параметр доступен только для скользящих обновлений.
   maxSurge	Максимальное количество или процент pods, которые могут существовать сверх желаемого количества pods во время скользящего обновления. Этот параметр определяет максимальное количество новых pods, которые могут быть созданы одновременно для замены старых pods. Значение по умолчанию — 25%. Во время обновления процент преобразуется в абсолютное число и округляется вверх. Например, если spec.replicas установлен в 2, по умолчанию одновременно может быть создано не более одного pod‑а (2 × 0.25 = 0.5, округляется вверх до 1). Следовательно, во время обновления может существовать до 3 pod‑ов (2 desired + 1 surge).	Этот параметр доступен только для скользящих обновлений.
   minReadySeconds	Минимальная продолжительность, в течение которой новый pod должен оставаться в состоянии ready, прежде чем будет помечен как доступный. Это обеспечивает стабильный период наблюдения, предотвращая преждевременное подключение нестабильных pod‑ов к сервису, тем самым повышая стабильность и надёжность развертывания.	None
   revisionHistoryLimit	Максимальное количество старых ReplicaSet, сохраняемых для отката. Они потребляют ресурсы etcd и отображаются в выводе kubectl get rs. Исторические конфигурации каждого Deployment хранятся в соответствующем ReplicaSet. Удаление старого ReplicaSet делает невозможным откат Deployment к этой версии. По умолчанию CCE сохраняет последние 10 старых ReplicaSet.	None
   progressDeadlineSeconds	Максимальное время в секундах, которое Deployment может занимать для прогресса, прежде чем считается неудачным. При указании этого параметра убедитесь, что его значение больше minReadySeconds. Во время постепенного обновления, если Deployment не делает прогресс в течение времени, указанного в progressDeadlineSeconds, он помечается следующими условиями: Type=Progressing, Status=False и Reason=ProgressDeadlineExceeded. Указанная информация свидетельствует о том, что обновление Deployment завершилось неудачей. CCE фиксирует событие сбоя, но не откатывает Deployment автоматически до предыдущей версии. Откат необходимо выполнить вручную или инициировать внешним механизмом.	None
   terminationGracePeriodSeconds	Максимальное время, которое kubelet ожидает завершения контейнеров в pod корректно при удалении pod. По умолчанию — 30 секунд. Контейнеры должны завершиться в течение этого периода. В противном случае они будут принудительно завершены сигналом SIGKILL.	None

3. Создайте Deployment.

   kubectl create -f nginx-deployment.yaml
   
   

   Если отображается информация, аналогичная следующей, Deployment создаётся:

   deployment.apps/nginx created
   
   

4. Проверьте статус Deployment.

   kubectl get deployment
   
   

   Если отображается информация, аналогичная следующей, Deployment создан:

   NAME           READY     UP-TO-DATE   AVAILABLE   AGE 
   nginx          2/2       2            2           4m5s
   
   

5. Измените образ, используемый Deployment, на nginx:alpine.

   kubectl edit deploy nginx
   
   

   Измените образ в spec.containers.image, сохраните изменения и выйдите.

6. Проверьте ReplicaSets Deployment.

   kubectl get rs
   
   

   Отображается информация, аналогичная следующей:

   NAME               DESIRED   CURRENT   READY     AGE 
   nginx-6f9f58dffd   2         2         2         1m    # New-version ReplicaSet (activated)
   nginx-7f98958cdf   0         0         0         48m   # Old-version ReplicaSet (deactivated)
   
   

   Во время обновления, при установленном spec.replicas в значение 2 и при значениях maxSurge и maxUnavailable, равных 25%, количество pods меняется следующим образом:

   • maxSurge = 1 (2 x 25% = 0.5, округление вверх) -> Можно добавить не более одного дополнительного pod.
   • maxUnavailable = 0 (2 x 25% = 0.5, округление вниз) -> Недоступный pod не допускается.

   Во время обновления в общей сложности может существовать до трёх pods, при этом два всегда доступны для сервисов. CCE создает новые pods, проверяет их готовность и удаляет старые pods по одному, пока все не будут обновлены.

7. После завершения обновления проверьте статусы pod'ов:

   kubectl get pods
   
   

   В выводе команды, если все pods находятся в состоянии Running, Deployment был обновлён.

   NAME                     READY     STATUS    RESTARTS   AGE
   nginx-6f9f58dffd-tdmqk   1/1       Running   0          1m
   nginx-6f9f58dffd-tesqr   1/1       Running   0          1m
   
   

Если во время обновления происходит ошибка, вы можете откатить Deployment к предыдущей версии. Это возможно, потому что ReplicaSet‑ы старой версии сохраняются после каждого обновления. Откат по сути заменяет обновлённый ReplicaSet старым. Вы можете использовать revisionHistoryLimit для управления максимальным количеством сохраняемых исторических версий (по умолчанию: 10).

• Using the console
  1. Войдите в CCE console и нажмите название кластера, чтобы открыть консоль кластера.
  2. В панели навигации выберите Workloads. В столбце Operation целевой нагрузки выберите More > Roll Back.

• Using kubectl

  Выполните следующую команду для отката целевого Deployment:

  kubectl rollout undo deployment nginx
  
  

  Если отображается информация, аналогичная следующей, откат выполнен успешно:

  deployment.apps/nginx rolled back