Оновлення OpenShift до 4.12

Ця сторінка документації описує процес підготовки до оновлення та сам процесс оновлення кластерів продакшн та розробницьких до версії OKD 4.12. Основна стаття від RedHat

План оновлення

Для кожного кластер є нижче окремий розділ зі special steps if any

  1. Виконати та внести всі зміни в компоненти платформи вказані в таблиці 1. Зміни повинні бути backward compatible з 4.11 версією.

  2. Перевірити на чистому кластері 4.12 збірку інсталлера платформи після внесених змін.

  3. Встановити версію в пайплайні розгортання кластерів в 4.12.0-0.okd-2023-03-05-022504 для розгортання тестових кластерів з новою версією.

  4. Оновити Stage RPZM Gigacloud.

  5. Оновити кластер Envone та реєстри.

  6. Оновити Reestr1

  7. Production RPZM Gigacloud

  8. Підготувати інструкції по оновленню для інших Міністерств

Оновлення до останньої версії 4.11 не рекомендується через наявність дефекту у роботі з Ceph, який критично впливає на роботу Платформи та сповільнює роботу підсистеми розподіленого зберігання файлів. Вирішений тільки з версії 4.12.0-0.okd-2023-03-05-022504

Обовʼязкові зміни для компонентів реєстрів та Платформи перед початком оновлення до 4.12

Table 1. Обовʼязкові зміни в компонентах
# API Компонент\Репозиторій Ресурс Суть змін

1

machine.openshift.io/v1beta1

control-plane-gerrit, storage, logging

registry-machine-set

1. Оновити AMI воркерів до Fedora 37 (ami-094fe1584439e91dd)

2. Оновити версію API awsproviderconfig.openshift.io/v1beta1 → machine.openshift.io/v1beta1

2

operators.coreos.com/v1alpha1

storage

values.yaml

Додати версію ocs-operator для 4.12

3

noobaa.io/v1alpha1

storage, control-plane-gerrit

Noobaa BucketClass/BackingStore

Видалити весь компонент noobaa

4

install.istio.io/v1alpha1

service-mesh

Istio Operator

Оновити istio до версії 1.18 через багу

5

autoscaling/v2beta2 policy/v1beta1

keycloak

hpa, pod security policy

1. Оновити autoscaling/v2beta2 до autoscaling/v2

2. Мігрувати на pod security admission

6

batch/v1beta1

backup-management

CronJob

Migrate from batch/v1beta1 to batch/v1

7

-

Усюди, де використовується в docker images

-

Оновити oc та kubectl до відповідної okd 4.12 / 1.25 kubernetes

8

operator.openshift.io/v1

service-mesh / ip-restrictions

Service, IngressController

Мігрувати з service.beta.kubernetes.io/load-balancer-source-ranges анотації на специфікацію CR IngressController. Приклад:

endpointPublishingStrategy: loadBalancer: allowedSourceRanges:

- 174.128.55.224/29

- 174.128.60.0/24

Також перенести всю конфігурацію по обмеженню доступу з service-mesh репозиторію до ip-restrictions

Проблеми з версією 4.11 на 4.12

Проблема Чи наявна в 4.12

Kubelet CPU

Важко сказати не перевіривши власноруч, але судячи з комментаря в тікеті на Github, оригінальна проблема вирішена

OLM Оператор

Пофікшено

Noobaa

Буде видалена як компонент

Kong

З великою вірогідністю так

Gigacloud network performance issues

Важко сказати не перевіривши власноруч, але Fedora 36 була оновлена до 37 у OKD 4.12

Спеціальні кроки для оновлення кластерів

Перед оновленням обовʼязково зробити бекап etcd та бекап Платформи з реєстрами

  1. Оновити версію Платформи та реєстрів до останньої, яка пітримує 4.12 (див. розділ з обовʼязковими змінами)

  2. Резервна копія реєстрів

  3. Резервна копія Платформи

  4. Резервна копія Etcd

  5. Закрити доступ для користувачів та оновитись до версії кластера 4.11 (листопад) з якої починає бути до доступне оновлення до 4.12

    4.12 на vSphere доступна тільки з 13 версії заліза vSphere та ESXi 6.7U3

  6. Пропатчити конфігмапу зі згодою на оновлення 4.12 командою

    oc -n openshift-config patch cm admin-acks --patch '{"data":{"ack-4.11-kube-1.25-api-removals-in-4.12":"true"}}' --type=merge

  7. Запустити оновлення до 4.12.0-0.okd-2023-03-05-022504

  8. Дочекатись оновлення операторів та мастерів

  9. Перевірити чи стартувало перестворення воркерів (піштовхнути, якщо ні)

  10. Провести smoke тест та перевірити чи все працює