Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Всем привет! В предыдущем посте мы рассказали, как применять ACM для сине-зеленого развертывания, миграции приложений между кластерами и аварийного восстановления.
Сегодня покажем, как с помощью ACM провести бесшовную миграцию приложения reversewords между нашими кластерами и рассмотрим, как с помощью PlacementRules реализовать базовый сценарий аварийного восстановления.
Мы создадим два новых PlacementRule, одно для кластеров в регионе EU, другое – для US. Кроме того, для развертывания нашего приложения в том регионе, где оно должно выполняться, задействуем новую Subscription.
1. Создаем новый Namespace для хранения необходимых манифестов.
2. Создаем PlacementRules, необходимые для таргетирования кластеров в регионах EU и US.
3. Создаем Subscription и Application.
ПРИМЕЧАНИЕ. Здесь Subscription сконфигурирована для развертывания приложения с помощью PlacementRule, отбирающего кластеры в регионе EU.
4. Теперь убедимся, что наше приложение работает на кластере в регионе EU (это наш Development-кластер).
5. Теперь выполним этот же запрос на кластере в регионе US (это наш Production-кластер) и убедимся, что там нет ни одного запущенного pod’а.
Теперь предположим, что по каким-то юридическим причинам наше приложение больше не может выполняться на серверах в регионе EU, и поэтому его надо перенести на американские серверы. Не вопрос, это делается всего одной командой.
Как помните, у нас есть два PlacementRules, одно для серверов EU s, одно для серверов US. Поэтому мы просто пропатчим нашу Subscription, чтобы она прекратила использовать PlacementRule для серверов в EU и начала использовать PlacementRule для серверов в US.
Таким образом, заменив PlacementRule, который используется в нашей Subscription, мы автоматически перенесем приложение из одного региона в другой.
1. Патчим Subscription.
Патч ниже правит PlacementRule, которое используется Subscription, на кластеры в регионе us.
2. В результате, наше приложение автоматически перенесется с EU-кластеров на US-кластеры, что можно отследить по выводу команд ниже.
Приложение больше не выполняется в регионе EU (это кластер development).
Теперь оно выполняется в регионе US (это кластер production).
Как видите, PlacementRules позволяют легко и непринужденно переносить приложения между кластерами. В качестве критерия мы использовали регион, но в PlacementRule можно использовать и любые другие метки, которые сконфигурированы на кластерах.
Теперь покажем, как с помощью PlacementRules реализовать базовый сценарий аварийного восстановления.
Мы воспользуемся манифестами ACM из предыдущего раздела, иначе говоря, будем использовать Namespace под названием reverse-words-region и Subscription, которая называется reversewords-region-app-subscription.
Нам надо создать новое PlacementRule с новыми свойствами, вот такими:
Это новое PlacementRule гарантирует, что если один из кластеров перейдет в состояние non-healthy, то кластер, возвращаемый PlacementRule, изменится на один из кластеров в состоянии healthy.
1. Теперь создадим PlacementRule, про который только что говорили.
Если посмотреть список кластеров, возвращаемый этим PlacementRule, то там будет только один кластер (в нашем случае – Production).
2. Идем дальше и обновим Subscription, которой мы пользовались в предыдущем разделе про миграцию. Мы пропатчим ее, чтобы использовать PlacementRule, которое мы только что создали.
3. Приложение запустится в кластере EU (это Development), что можно отследить по выводу команд ниже:
4. Теперь убьем кластер EU, чтобы имитировать чрезвычайную ситуацию, и посмотрим, что произойдет.
ПРИМЕЧАНИЕ. Мы сейчас реально убьем наш кластер. Если не хотите убивать свой, то просто удалите из него метку region: EU.
5. Когда кластер EU снова появится в сети, он будет автоматически добавлен в PlacementRule.
Итак, в первой части мы рассмотрели базовые концепции жизненного цикла приложения в Red Hat ACM и показали, как их применять на примере развертывания приложения в двух кластерах. Во второй, как применять ACM для сине-зеленого развертывания, миграции приложений между кластерами и аварийного восстановления. А в заключительной части разобрали миграцию приложений и аварийное восстановление с помощью в Red Hat 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
- Свойство matchExpressions используется для отбора всех кластеров, у которых в метке region прописано значение EU или US.
- Свойство clusterReplicas нужно для того, чтобы выбрать из отобранных в предыдущем пункте кластеров только один.
- Кроме того, мы отбираем только кластеры в исправном состоянии (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.
- Как только 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
- Приложение автоматически переместилось в кластер 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
- Кластера EU больше нет.
5. Когда кластер EU снова появится в сети, он будет автоматически добавлен в PlacementRule.
Заключение
Итак, в первой части мы рассмотрели базовые концепции жизненного цикла приложения в Red Hat ACM и показали, как их применять на примере развертывания приложения в двух кластерах. Во второй, как применять ACM для сине-зеленого развертывания, миграции приложений между кластерами и аварийного восстановления. А в заключительной части разобрали миграцию приложений и аварийное восстановление с помощью в Red Hat ACM. До новых встреч!