🥇Nasze ręce nie są do nudzenia: przywracanie klastra Rook w K8s

My już wspomnieliśmy, jak/why podoba nam się Rook: w znacznym stopniu upraszcza on pracę z magazynami w klastrach Kubernetes. Jednak z tą prostotą przychodzą również pewne trudności. Mamy nadzieję, że nowy materiał pomoże lepiej zrozumieć te trudności jeszcze przed ich pojawieniem się.

Aby było ciekawiej, zacznijmy od następstw hipotetycznego problemu w klastrze.

„Wszystko stracone!”

Wyobraź sobie, że pewnego dnia zainstalowałeś i uruchomiłeś Rook w swoim klastrze K8s, działał on bez zarzutu, ale w pewnym ‘cudownym’ momencie wydarza się coś takiego:

Nowe pod’y nie mogą zamontować obrazów RBD z Ceph.
Polecenia takie jak lsblk i df nie działają na węzłach Kubernetes. To automatycznie oznacza: „coś jest nie tak” z zamontowanymi na węzłach obrazami RBD. Nie można ich odczytać, co wskazuje na niedostępność monitorów…
Tak, w klastrze nie ma działających monitorów. Co więcej — nie ma nawet żadnych pod’ów z OSD ani pod’a MGR.

Kiedy uruchomiono pod rook-ceph-operator? Не так давно, как его деплоили. Почему? Rook-operator решил сделать новый кластер… Как же нам теперь восстановить работу кластера и данные в нём?

Na początek pójdziemy dłuższą, interesującą drogą, przeprowadzając dogłębną analizę ‘wnętrzności’ Rook i krok po kroku przywracając jego komponenty. Oczywiście istnieje również krótsza, prawidłowa droga: korzystanie z kopii zapasowych. Jak wiadomo, administratorzy dzielą się na dwa typy: tych, którzy nie robią kopii zapasowych, i tych, którzy już to robią… Ale o tym — po dochodzeniu.

Trochę praktyki, czyli Długa droga

Rozejrzyjmy się i przywróćmy monitory

Zobaczmy więc na listę ConfigMap’ów: są tam potrzebne do rezerwy rook-ceph-config i rook-config-override. Pojawiają się przy udanej instalacji klastra.

NB: W nowych wersjach, po zaakceptowaniu tego PR, ConfigMap’y przestały być wskaźnikiem pomyślnie przeprowadzonej instalacji klastra.

Aby przeprowadzić dalsze działania, potrzebny jest twardy reboot wszystkich serwerów, na których znajdują się zamontowane obrazy RBD (ls /dev/rbd*). Należy go przeprowadzić przez sysrq (lub ‘pieszo’ do centrum danych). Wymaganie to wynika z potrzeby odłączenia zamontowanych RBD, dla czego standardowy reboot się nie nada (będzie bezskutecznie próbować je odmontować normalnie).

Teatr zaczyna się od wieszaka, a klaster Ceph — od monitorów. Zobaczmy na nie.

Rook zamontowuje w pod monitorów takie encje:

Wolumeny:
 rook-ceph-config:
   Typ:      ConfigMap (wolumen zasilany przez ConfigMap)
   Nazwa:      rook-ceph-config
 rook-ceph-mons-keyring:
   Typ:        Secret (wolumen zasilany przez Secret)
   SecretName:  rook-ceph-mons-keyring
 rook-ceph-log:
   Typ:          HostPath (wolumen z barem hosta)
   Ścieżka:          /var/lib/rook/kube-rook/log
 ceph-daemon-data:
   Typ:          HostPath (wolumen z barem hosta)
   Ścieżka:          /var/lib/rook/mon-a/data
Montaże:
  /etc/ceph z rook-ceph-config (ro)
  /etc/ceph/keyring-store/ z rook-ceph-mons-keyring (ro)
  /var/lib/ceph/mon/ceph-a z ceph-daemon-data (rw)
  /var/log/ceph z rook-ceph-log (rw)

Sprawdźmy, co jest w sekrecie rook-ceph-mons-keyring:

typ: Secret
dane:
 keyring: LongBase64EncodedString=

Dekodujemy i uzyskujemy zwykły keyring z uprawnieniami do admina i monitorów:

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

Zapamiętajmy. A teraz spójrzmy na keyring w sekrecie rook-ceph-admin-keyring:

typ: Secret
dane:
 keyring: anotherBase64EncodedString=

Co jest w nim?

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

Ten sam. Zobaczmy jeszcze… Oto, na przykład, sekret rook-ceph-mgr-a-keyring:

[mgr.a]
       klucz = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew==
       uprawnienia mon = "allow *"
       uprawnienia mds = "allow *"
       uprawnienia osd = "allow *"

Ostatecznie znajdujemy jeszcze kilka sekretów w ConfigMapie rook-ceph-mon:

typ: Secret
dane:
 admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp==
 cluster-name: a3ViZS1yb29r
 fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg==
 mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==

I to jest początkowa lista keyringów, z których pochodzą wszystkie opisane wyżej sekrety.

Jak wiadomo (patrz dataDirHostPath do dokumentacji), Rook przechowuje takie dane w dwóch miejscach. Dlatego przejdźmy do węzłów, aby zobaczyć keyringi znajdujące się w katalogach, które są zamontowane w podach z monitorami i OSD. W tym celu znajdźmy na węzłach /var/lib/rook/mon-a/data/keyring i zobaczymy:

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

Niespodziewanie tutaj sekret okazał się innym — nie takim jak w ConfigMapach.

A co z admin keyringiem? Mamy go również:

# 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 *"

I tu pojawia się problem. Nastąpiła pewnego rodzaju awaria: klaster został odbudowany… ale w rzeczywistości nie.

Staje się jasne, że w sekretach przechowywane są na nowo wygenerowane keyringi, a one nie są z naszego starego klastra. Dlatego:

weź keyring od monitora z pliku /var/lib/rook/mon-a/data/keyring (lub z kopii zapasowej);
zmień keyring w sekrecie rook-ceph-mons-keyring;
wpisz keyring od admina i monitora w ConfigMapie rook-ceph-mon;
usuń kontrolery podów z monitorami.

Cud nie każe na siebie długo czekać: monitory pojawią się i uruchomią. Hurra, początek został zrobiony!

Przywróćmy OSD

Wchodzimy w pod rook-operator: wywołanie ceph mon dump pokazuje, że wszystkie monitory są na miejscu, a ceph -s — na to, że są w kworum. Jednak jeśli spojrzymy na drzewo OSD (ceph osd tree), zobaczymy coś dziwnego: OSD zaczęły się pojawiać, ale są puste. Wygląda na to, że również je trzeba jakoś przywrócić. Ale jak?

Tymczasem w ConfigMapach pojawiły się tak potrzebne nam rook-ceph-config i rook-config-override, a także wiele innych ConfigMapów o nazwach w stylu rook-ceph-osd-$nodename-config. Spójrzmy na nie:

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

Wszystko nie tak, wszystko pomieszane!

Zresetujemy pod operatora, usuniemy wygenerowane Deploymenty podów z OSD i poprawimy te ConfigMapy. Ale skąd wziąć właściwą mapę OSD według węzłów?

Spróbujemy jeszcze raz poszukać w katalogach /mnt/osd[1-2] na węzłach — w nadziei, że uda się czegoś tam doszukać.
W katalogu /mnt/osd1 są 2 podkatalogi: osd0 i osd16. Ostatni to właśnie ten ID, który jest podany w ConfigMap (16)?
Sprawdźmy po rozmiarach i zobaczymy, że osd0 jest znacznie większy osd16.

Dochodzi do wniosku, że osd0 — to jest potrzebny OSD, który był wskazany jako /mnt/osd1 w ConfigMap (przecież używamy directory based osd.)

Sprawdzamy krok po kroku wszystkie węzły i poprawiamy ConfigMapy. Po wszystkich wskazówkach można uruchomić pod operatora Rook i przeczytać jego logi. A tam wszystko w porządku:

jestem operatorem klastra;
znalazłem dyski na węzłach;
znalazłem monitory;
monitory się zaprzyjaźniły, tzn. utworzyły kworum;
uruchamiam deploymenty OSD…

Ponownie wejdźmy do podu operatora Rook i sprawdźmy żywotność klastra… tak, pomyliliśmy się nieco co do nazw OSD na niektórych węzłach! Nie ma sprawy: poprawiliśmy znowu ConfigMapy, usunęliśmy zbędne katalogi nowych OSD i osiągnęliśmy długo oczekiwany stan HEALTH_OK!

Sprawdzimy obrazy w puli:

# 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
…

Wszystko na miejscu — klaster uratowany!

Jestem leniwy w robieniu kopii zapasowych, czyli Szybka droga

Jeśli kopie zapasowe dla Rook były robione, to procedura przywracania staje się znacznie prostsza i sprowadza się do następujących kroków:

Skalujemy do zera deployment operatora Rook;
Usuwamy wszystkie deploymenty, oprócz operatora Rook;
Przywracamy z kopii zapasowych wszystkie tajne dane i ConfigMapy;
Przywracamy zawartość katalogów /var/lib/rook/mon-* na węzłach;
Przywracamy (jeśli przypadkiem utracone) CRD CephCluster, CephFilesystem, CephBlockPool, CephNFS, CephObjectStore;
Z powrotem skalujemy deployment operatora Rook do 1.

Przydatne wskazówki

Twórz kopie zapasowe!

Aby unikać sytuacji, w których trzeba będzie ich przywracać:

Przed masowymi pracami z klastrem, które obejmują restart serwerów, zmniejszcie Rook-operatora do zera, aby nie robił nic niepotrzebnego.
Na monitory z wyprzedzeniem dodajcie nodeAffinity.
Zwróćcie uwagę na wstępne ustawienia czasów oczekiwania ROOK_MON_HEALTHCHECK_INTERVAL i ROOK_MON_OUT_TIMEOUT.

Zamiast zakończenia

Nie ma sensu dyskutować, że Rook, będąc dodatkową „warstwą” (w ogólnej strukturze organizacji magazynów w Kubernetes), zarówno upraszcza wiele rzeczy, jak i wprowadza nowe złożoności i potencjalne problemy w infrastrukturze. Kwestią pozostaje „małe”: dokonanie przemyślanego, uzasadnionego wyboru pomiędzy tymi ryzykami a korzyściami, które rozwiązanie przynosi w Twoim konkretnym przypadku.

Przy okazji, niedawno do dokumentacji Rook został dodany rozdział „Adopt an existing Rook Ceph cluster into a new Kubernetes cluster”. W nim dokładniej opisano, co należy zrobić, aby przenieść istniejące dane do nowego klastra Kubernetes lub przywrócić działanie klastra, który uległ awarii z jakiegoś powodu.