Нашите ръце не са за скука: възстановяване на клъстера Rook в K8s

Ние вече разказахме, как\/поради какво ни харесва Rook: значително улеснява работата с хранилища в Kubernetes клъстери. Но с тази леснота идват и определени трудности. Надяваме се, новият материал да помогне да разбрахме по-добре тези трудности, преди да се проявят.

А за да бъде четенето по-интересно, ще започнем с последствията от хипотетичен проблем в клъстера.

„Всичко е загубено!“

Представете си, че един ден сте настроили и пуснали Rook в своя K8s клъстер. Той ви радва с работата си, но в един „прекрасен“ момент се случва следното:

• Новите pod’ове не могат да монтират RBD изображения от Ceph.
• Команди като lsblk и df не работят на възлите на Kubernetes. Това автоматично означава: „нещо не е наред“ с монтираните на възлите RBD изображения. Не може да се прочетат, което указва на недостъпност на мониторите…
• Да, в клъстера няма работещи монитори. Освен това – няма дори pod’ове с OSD, нито pod на MGR.

Кога беше стартиран pod : сред значимите промени в релиза Rook 1.0.0, свързани с Ceph, мога да отбележа поддръжка на Ceph Nautilus и възможността да се използва NFS за CephFS или RGW контейнери. От останалите се откроява "узряването" на поддръжката на EdgeFS до бета ниво.? Не так давно, как его деплоили. Почему? Rook-operator решил сделать новый кластер… Как же нам теперь восстановить работу кластера и данные в нём?

Първо ще тръгнем по по-дългия интересен път, извършвайки задълбочено разследване по „вътрешностите“ на Rook и стъпка по стъпка възстановяване на компонентите му. Разбира се, има и по-кратък правилен път: използване на резервни копия. Както е известно, администраторите се делят на два типа: на тези, които не правят резервни копия, и на тези, които вече правят… Но за това – след разследването.

Малко практика, или Дългият път

Нека се огледаме и възстановим мониторите

И така, нека разгледаме списъка с ConfigMap’ове: там има необходимите за резервиране rook-ceph-config и rook-config-override. Те се появяват при успешен деплой на клъстера.

NB: В новите версии, след приемането на този PR, ConfigMap’ите престават да бъдат показател за успешност на деплоя на клъстера.

За извършване на по-нататъшни действия ни е необходима остри ребут на всички сървъри, на които присъстват монтирани RBD изображения (ls \/dev\/rbd*). Трябва да се направи чрез sysrq (или „пешком“ в ЦОД). Това изискване произлиза от необходимостта да се откачат монтираните RBD, за което обикновеният ребут не е подходящ (ще бъде безуспешно да се опитват да се отмонтират нормално).

Театърът започва с закачалката, а Ceph клъстерът – с мониторите. Нека да ги разгледаме.

Rook монтира в pod на монитора следните единици:

Томове:
 rook-ceph-config:
   Тип:      ConfigMap (том, заполняемый с помощью ConfigMap)
   Имя:      rook-ceph-config
 rook-ceph-mons-keyring:
   Тип:        Secret (том, заполняемый с помощью секрета)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Тип:          HostPath (оболочка с директориями хоста)
   Путь:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Тип:          HostPath (оболочка с директориями хоста)
   Путь:          /var/lib/rook/mon-a/data
Монтаж:
  /etc/ceph от rook-ceph-config (ro)
  /etc/ceph/keyring-store/ от rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a от ceph-daemon-data (rw)
  /var/log/ceph от rook-ceph-log (rw)

Да видим, что в секрете rook-ceph-mons-keyring:

вид: Secret
data:
 keyring: LongBase64EncodedString=

Декодируем и получаем обычный keyring с правами для администратора и мониторов:

[mon.]
       key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
       caps mon = "allow *"
[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Запомним. А теперь посмотрим на keyring в секрете rook-ceph-admin-keyring:

вид: Secret
data:
 keyring: anotherBase64EncodedString=

Что в нём?

[client.admin]
       key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Тот же. Посмотрим ещё… Вот, например, секрет rook-ceph-mgr-a-keyring:

[mgr.a]
       key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       caps mon = "allow *"
       caps mds = "allow *"
       caps osd = "allow *"

В конечном итоге мы находим ещё несколько секретов в ConfigMap’е rook-ceph-mon:

вид: Secret
data:
 admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
 cluster-name: a3ViZS1yb29r
 fsid: ZmZiYjliYjMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==
 mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==

И это изначальный список с keyring’ами, откуда берутся все описанные выше секреты.

Как известно (см. dataDirHostPath в документацията), Rook хранит такие данные в двух местах. Поэтому давайте сходим на узлы, чтобы посмотреть на keyring’и, лежащие в каталогах, что примонтированы в pod’ы с мониторами и OSD. Для этого найдём на узлах /var/lib/rook/mon-a/data/keyring и увидим:

# cat /var/lib/rook/mon-a/data/keyring
[mon.]
       key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg==
       caps mon = "allow *"

Внезапно тут секрет оказался другим — не как в ConfigMap’ах.

А что насчет админского keyring’а? Он тоже у нас есть:

# cat /var/lib/rook/kube-rook/client.admin.keyring
[client.admin]
       key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx= 
       caps mds = "allow *"
       caps mon = "allow *"
       caps osd = "allow *"
       caps mgr = "allow *"

Вот тут и проблема. Произошел некий сбой: кластер пересоздался… но в действительности нет.

Становится понятно, что в секретах хранятся заново сгенерированные keyring’и, и они не от нашего старого кластера. Поэтому:

• берём keyring от монитора из файла /var/lib/rook/mon-a/data/keyring (либо из бекапа);
• изменяем keyring в секрете rook-ceph-mons-keyring;
• прописываем keyring от админа и монитора в ConfigMap’е rook-ceph-mon;
• удаляем контроллеры pod’ов с мониторами.

Чудо не заставит себя долго ждать: мониторы появятся и запустятся. Ура, начало положено!

Восстановим OSD

Заходим в pod rook-operator: вызов ceph mon dump показывает, что все мониторы на месте, а ceph -s — на това, че са в кворума. Въпреки това, ако погледнем на дървото на OSD (ceph osd tree), ще видим нещо странно: OSD-те започнаха да се появяват, но са празни. Значи, трябва да ги възстановим по някакъв начин. Но как?

Междувременно, в ConfigMap-ите се появиха толкова нужните ни rook-ceph-config и rook-config-override, както и множество други ConfigMap-ове с имена вида rook-ceph-osd-$nodename-config. Нека да ги разгледаме:

kind: ConfigMap
data:
 osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'

Всичко е грешно, всичко е объркано!

Нека да скалираме pod-а на оператора до нулата, да изтрием генерираните Deployment-и на pod-овете с OSD и да поправим тези ConfigMap-ове. Но откъде да вземем правилната карта на OSD по възлите?

• Нека отново да копаем в директориите /mnt/osd[1-2] на възлите — с надеждата, че можем да се закачим за нещо.
• В каталога /mnt/osd1 има 2 подкаталога: osd0 и osd16. Последният — това е точно онзи ID, който е посочен в ConfigMap (16)?
• Нека да проверим по размерите и да видим, че osd0 е значително по-голямо osd16.

Стигаме до извода, че osd0 — това е нужният OSD, който е бил посочен като /mnt/osd1 в ConfigMap (все пак използваме directory based osd.)

Стъпка по стъпка проверяваме всички възли и поправяме ConfigMap-ите. След всички указания можем да стартираме pod на Rook-оператора и да прочетем логовете му. А в тях всичко е прекрасно:

• Аз съм оператор на кластера;
• Намерих дисковете на възлите;
• Намерих мониторите;
• мониторите се свързаха, т.е. образуваха кворум;
• стартирам деплойментите на OSD…

Отново ще влезем в pod на оператора Rook и ще проверим живота на кластера… да, малко се объркахме с изводите за имената на OSD на някои възли! Няма проблем: отново поправихме ConfigMap-ите, изтрихме излишните каталози от новите OSD и стигнахме до дългоочакваното състояние HEALTH_OK!

Нека да проверим образите в пула:

# rbd ls -p kube
pvc-9cfa2a98-b878-437e-8d57-acb26c7118fb
pvc-9fcc4308-0343-434c-a65f-9fd181ab103e
pvc-a6466fea-bded-4ac7-8935-7c347cff0d43
pvc-b284d098-f0fc-420c-8ef1-7d60e330af67
pvc-b6d02124-143d-4ce3-810f-3326cfa180ae
pvc-c0800871-0749-40ab-8545-b900b83eeee9
pvc-c274dbe9-1566-4a33-bada-aabeb4c76c32
…

Всичко е на мястото си — кластерът е спасен!

Аз съм мързелив и правя резервни копия, или Бързият начин

Ако резервните копия за Rook са правени, процедурата за възстановяване става значително по-проста и се свежда до следното:

1. Скалираме deployment на Rook-оператора до нула;
2. Изтриваме всички деплойменти, с изключение на Rook-оператора;
3. Възстановяваме всички секрети и ConfigMap-ове от резервното копие;
4. Възстановяваме съдържанието на директориите /var/lib/rook/mon-* на възлите;
5. Възстановяваме (ако случайно сме загубили) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
6. Обратно скалираме deployment на Rook-оператора на 1.

Полезни съвети

Правете резервни копия!

А за да избегнем ситуации, в които ще се наложи възстановяване от тях:

1. Преди мащабни операции с кластера, включващи рестартиране на сървърите, скалирайте Rook-оператора до нула, за да не прави излишни действия.
2. На мониторите предварително добавяйте nodeAffinity.
3. Обърнете внимание на предварителната настройка на таймаутите ROOK_MON_HEALTHCHECK_INTERVAL и ROOK_MON_OUT_TIMEOUT.

Вместо заключение

Няма смисъл да спорим, че Rook, като допълнителен „слой“ (в общата схема на организация на хранилищата в Kubernetes), както много опростява, така и добавя нови трудности и потенциални проблеми в инфраструктурата. Остава само да се направи обоснован избор между тези рискове от една страна и ползата, която решението носи в конкретния ви случай, от друга.

Между другото, наскоро в документацията на Rook беше добавен раздел „Adopt an existing Rook Ceph cluster into a new Kubernetes cluster“. В него се описва по-подробно какво е необходимо да се направи, за да се премести с наличните данни в нов Kubernetes клъстер или да се възстанови работата на клъстера, който е бил разрушен по някаква причина.

P.S.

Прочетете също в нашия блог:

• «Rook или не Rook — вот в чём въпрос»;
• «Rook — „самообслужващо“ хранилище за данни за Kubernetes»;
• «Longhorn, разпределено хранилище за K8s от Rancher, е предадено на CNCF».
• «Създаваме постоянно хранилище с provisioning в Kubernetes, базирано на Ceph».

Източник: habr.com