Миграция приложений и аварийное восстановление с помощью Red Hat Advanced Cluster Management (ACM)

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.
Всем привет! В предыдущем посте мы рассказали, как применять ACM для сине-зеленого развертывания, миграции приложений между кластерами и аварийного восстановления.



Сегодня покажем, как с помощью ACM провести бесшовную миграцию приложения reversewords между нашими кластерами и рассмотрим, как с помощью PlacementRules реализовать базовый сценарий аварийного восстановления.

Миграция приложений с помощью Red Hat ACM


Создаем новые PlacementRules и Subscription


Мы создадим два новых PlacementRule, одно для кластеров в регионе EU, другое – для US. Кроме того, для развертывания нашего приложения в том регионе, где оно должно выполняться, задействуем новую Subscription.

1. Создаем новый Namespace для хранения необходимых манифестов.

oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-region/00_namespace.yaml

2. Создаем PlacementRules, необходимые для таргетирования кластеров в регионах EU и US.

# PlacementRule targeting EU region clusters
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-region/01_placement_rule_EU.yaml
# PlacementRule targeting US region clusters
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-region/02_placement_rule_US.yaml

3. Создаем Subscription и Application.

ПРИМЕЧАНИЕ. Здесь Subscription сконфигурирована для развертывания приложения с помощью PlacementRule, отбирающего кластеры в регионе EU.

oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-region/03_subscription-region.yaml
oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-region/04_application-region.yaml

4. Теперь убедимся, что наше приложение работает на кластере в регионе EU (это наш Development-кластер).

oc --context dev -n reverse-words-region get deployments,services,pods
NAME                                  READY   UP-TO-DATE   AVAILABLE   AGE
deployment.extensions/reverse-words   1/1     1            1           4m39s

NAME                    TYPE           CLUSTER-IP      EXTERNAL-IP                                                                  PORT(S)          AGE
service/reverse-words   LoadBalancer   172.30.79.111   a3115b78bce924ddc885d2b7dab766a6-1199935412.eu-central-1.elb.amazonaws.com   8080:30254/TCP   4m39s

NAME                                 READY   STATUS    RESTARTS   AGE
pod/reverse-words-68795d69ff-xmwc6   1/1     Running   0          4m39s

5. Теперь выполним этот же запрос на кластере в регионе US (это наш Production-кластер) и убедимся, что там нет ни одного запущенного pod’а.

oc --context pro -n reverse-words-region get deployments,services,pods
No resources found in reverse-words-region namespace.

Выполняем миграцию приложения


Теперь предположим, что по каким-то юридическим причинам наше приложение больше не может выполняться на серверах в регионе EU, и поэтому его надо перенести на американские серверы. Не вопрос, это делается всего одной командой.

Как помните, у нас есть два PlacementRules, одно для серверов EU s, одно для серверов US. Поэтому мы просто пропатчим нашу Subscription, чтобы она прекратила использовать PlacementRule для серверов в EU и начала использовать PlacementRule для серверов в US.

Таким образом, заменив PlacementRule, который используется в нашей Subscription, мы автоматически перенесем приложение из одного региона в другой.

1. Патчим Subscription.

Патч ниже правит PlacementRule, которое используется Subscription, на кластеры в регионе us.

oc --context hub -n reverse-words-region patch subscription.apps.open-cluster-management.io/reversewords-region-app-subscription -p '{"spec":{"placement":{"placementRef":{"name":"us-region-clusters"}}}}' --type=merge

2. В результате, наше приложение автоматически перенесется с EU-кластеров на US-кластеры, что можно отследить по выводу команд ниже.

Приложение больше не выполняется в регионе EU (это кластер development).

oc --context dev -n reverse-words-region get deployments,services,pods
No resources found in reverse-words-region namespace.

Теперь оно выполняется в регионе US (это кластер production).

oc --context pro -n reverse-words-region get deployments,services,pods
NAME                                  READY   UP-TO-DATE   AVAILABLE   AGE
deployment.extensions/reverse-words   1/1     1            1           92s

NAME                    TYPE           CLUSTER-IP       EXTERNAL-IP                                                              PORT(S)          AGE
service/reverse-words   LoadBalancer   172.30.177.196   a90273a7fa3ea4015989fac522b6b36e-709976322.us-west-2.elb.amazonaws.com   8080:30375/TCP   2m33s

NAME                                 READY   STATUS    RESTARTS   AGE
pod/reverse-words-68795d69ff-jlktw   1/1     Running   0          92s

Как видите, PlacementRules позволяют легко и непринужденно переносить приложения между кластерами. В качестве критерия мы использовали регион, но в PlacementRule можно использовать и любые другие метки, которые сконфигурированы на кластерах.

Аварийное восстановление с помощью Red Hat ACM


Теперь покажем, как с помощью PlacementRules реализовать базовый сценарий аварийного восстановления.

Конфигурируем необходимые манифесты ACM


Мы воспользуемся манифестами ACM из предыдущего раздела, иначе говоря, будем использовать Namespace под названием reverse-words-region и Subscription, которая называется reversewords-region-app-subscription.

Нам надо создать новое PlacementRule с новыми свойствами, вот такими:

apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: us-eu-region-clusters
  namespace: reverse-words-region
spec:
  clusterConditions:
    - type: "ManagedClusterConditionAvailable"
      status: "True"
  clusterSelector:
    matchExpressions:
    - key: region
      operator: In
      values:
      - EU
      - US
    matchLabels: {}
  clusterReplicas: 1

  1. Свойство matchExpressions используется для отбора всех кластеров, у которых в метке region прописано значение EU или US.
  2. Свойство clusterReplicas нужно для того, чтобы выбрать из отобранных в предыдущем пункте кластеров только один.
  3. Кроме того, мы отбираем только кластеры в исправном состоянии (healthy).

Это новое PlacementRule гарантирует, что если один из кластеров перейдет в состояние non-healthy, то кластер, возвращаемый PlacementRule, изменится на один из кластеров в состоянии healthy.

Настраиваем Subscription, чтобы использовать это новое PlacementRule


1. Теперь создадим PlacementRule, про который только что говорили.

oc --context hub create -f https://raw.githubusercontent.com/RHsyseng/acm-app-lifecycle-blog/master/acm-manifests/reversewords-region/05_placement_rule_DR.yaml

Если посмотреть список кластеров, возвращаемый этим PlacementRule, то там будет только один кластер (в нашем случае – Production).

oc --context hub -n reverse-words-region get placementrule us-eu-region-clusters -o yaml
<OMITTED_OUTPUT>
status:
  decisions:
  - clusterName: managed-cluster1-dev
    clusterNamespace: managed-cluster1-dev

2. Идем дальше и обновим Subscription, которой мы пользовались в предыдущем разделе про миграцию. Мы пропатчим ее, чтобы использовать PlacementRule, которое мы только что создали.

oc --context hub -n reverse-words-region patch subscription.apps.open-cluster-management.io/reversewords-region-app-subscription -p '{"spec":{"placement":{"placementRef":{"name":"us-eu-region-clusters"}}}}' --type=merge

3. Приложение запустится в кластере EU (это Development), что можно отследить по выводу команд ниже:

oc --context dev -n reverse-words-region get deployments,services,pods
NAME                                  READY   UP-TO-DATE   AVAILABLE   AGE
deployment.extensions/reverse-words   1/1     1            1           42s

NAME                    TYPE           CLUSTER-IP      EXTERNAL-IP                                                                PORT(S)          AGE
service/reverse-words   LoadBalancer   172.30.185.94   a520ed21ff982452abeacf63b0b58cc5-31012041.eu-central-1.elb.amazonaws.com   8080:32283/TCP   42s

NAME                                 READY   STATUS    RESTARTS   AGE
pod/reverse-words-68795d69ff-crzqp   1/1     Running   0          42s

4. Теперь убьем кластер EU, чтобы имитировать чрезвычайную ситуацию, и посмотрим, что произойдет.

ПРИМЕЧАНИЕ. Мы сейчас реально убьем наш кластер. Если не хотите убивать свой, то просто удалите из него метку region: EU.

  1. Как только ACM увидит, что кластер EU исчез, вывод PlacementRule обновится и будет указывать на кластер US.

    oc --context hub -n reverse-words-region get placementrule us-eu-region-clusters -o yaml

    Теперь PlacementRule указывает на кластер US.

    <OMITTED_OUTPUT>
status:
  decisions:
  - clusterName: managed-cluster2-prod
    clusterNamespace: managed-cluster2-prod

  2. Приложение автоматически переместилось в кластер US.

    oc --context pro -n reverse-words-region get deployments,services,pods
NAME                                  READY   UP-TO-DATE   AVAILABLE   AGE
deployment.extensions/reverse-words   1/1     1            1           76s

NAME                    TYPE           CLUSTER-IP       EXTERNAL-IP                                                               PORT(S)          AGE
service/reverse-words   LoadBalancer   172.30.187.142   a1c7d218d901c40ac98375f4a9474084-1310645059.us-west-2.elb.amazonaws.com   8080:31095/TCP   78s

NAME                                 READY   STATUS    RESTARTS   AGE
pod/reverse-words-68795d69ff-ttzz5   1/1     Running   0          77s

  3. Кластера EU больше нет.



5. Когда кластер EU снова появится в сети, он будет автоматически добавлен в PlacementRule.

Заключение


Итак, в первой части мы рассмотрели базовые концепции жизненного цикла приложения в Red Hat ACM и показали, как их применять на примере развертывания приложения в двух кластерах. Во второй, как применять ACM для сине-зеленого развертывания, миграции приложений между кластерами и аварийного восстановления. А в заключительной части разобрали миграцию приложений и аварийное восстановление с помощью в Red Hat ACM. До новых встреч!
Источник: https://habr.com/ru/company/redhatrussia/blog/532192/

Вернуться к списку

Интересные статьи

Интересные статьи

NSX Advanced Load Balancer – умный автомасштабируемый балансировщик нагрузки. Часть 2: установка и настройка
NSX Advanced Load Balancer – умный автомасштабируемый балансировщик нагрузки. Часть 2: установка и настройка
В прошлый раз я рассказал о функциях балансировщика нагрузки NSX ALB, описал его архитектуру и схему работы. Мы посмотрели, как работает глобальная балансировка серверов (GSLB), которая о...
Рейт лимиты с помощью Python и Redis
Рейт лимиты с помощью Python и Redis
В этой статье мы рассмотрим некоторые алгоритмы рейт лимитов на основе Python и Redis, начиная с самой простой реализации и заканчивая продвинутым обобщённым алгоритмом контроля скорост...
Вывод внутриигровых сообщений с помощью Particle System
Вывод внутриигровых сообщений с помощью Particle System
Задача При разработке нашей игры The Unliving, мы поставили перед собой задачу по отображению различных сообщений, таких, как нанесенный урон, нехватка здоровья или энергии, величина награды...
Выведение Action type с помощью Typescript
Выведение Action type с помощью Typescript
Всем привет! Меня зовут Дмитрий Новиков, я javascript-разработчик в Альфа-Банке, и сегодня я расскажу вам про наш опыт выведения Action type при помощи Typescript, с каким проблемами мы столкнули...
Ускоряем работу нейросетей с помощью хеширования
Ускоряем работу нейросетей с помощью хеширования
Индустрия сконцентрировалась на ускорении перемножений матриц, однако улучшение алгоритма поиска может привести к более серьёзному повышению быстродействия В последние годы компьютерная инду...