Argument „nie potrzebujemy kopii klastra, bo wszystko jest w Gicie” jest w połowie prawdziwy. Manifesty, konfiguracja, wersje obrazów: tak, są w repozytorium i klaster da się odtworzyć przez ponowną synchronizację. Druga połowa to wszystko, co powstaje w trakcie działania i czego w repozytorium nie ma. To właśnie ta połowa boli po awarii.
Co jest w repozytorium
Definicje wdrożeń, usług, polityk sieciowych, konfiguracje operatorów, wartości wykresów Helm, wersje obrazów. Jeśli klaster jest prowadzony deklaratywnie, nowy klaster po podłączeniu do repozytorium dochodzi do tego samego stanu bez ręcznych kroków. Repozytorium samo w sobie potrzebuje kopii: lustrzanej kopii w innym miejscu niż serwer Git, który może stać w tym samym klastrze lub na tym samym hoście.
Czego w repozytorium nie ma
Dane na wolumenach trwałych. Bazy danych, pliki użytkowników, indeksy, kolejki. Klaster odtworzony z repozytorium ma puste wolumeny.
Sekrety. Hasła, klucze, certyfikaty. Nie powinny być w repozytorium w postaci jawnej, więc albo są w zewnętrznym menedżerze sekretów, albo zaszyfrowane w repozytorium z kluczem trzymanym gdzie indziej, albo wpisane ręcznie i nieudokumentowane. Trzeci przypadek jest częstszy, niż ktokolwiek przyznaje.
Certyfikaty i urząd certyfikacji. Wewnętrzny urząd wydający certyfikaty usługom klastra. Jego utrata oznacza wymianę certyfikatów wszędzie, gdzie są zaufane, także poza klastrem.
Stan bazy klastra. Zasoby utworzone dynamicznie przez operatory, adnotacje, stany kontrolerów, obiekty utworzone ręcznie „na chwilę”. W klastrze prowadzonym rygorystycznie przez GitOps tego jest mało; w praktyce zawsze coś jest.
Obrazy w rejestrze. Jeśli rejestr działa w klastrze i nie ma kopii, odtworzony klaster nie ma czego uruchamiać, dopóki obrazy nie zostaną zbudowane ponownie, co wymaga działającego CI, które też może stać w klastrze.
Strategia
Wolumeny: dwa poziomy. Migawki wolumenów przez interfejs sterownika pamięci, zaplanowane i replikowane do innej lokalizacji, dla szybkiego przywrócenia. Osobno kopie spójne aplikacyjnie dla baz danych: operator bazy wykonujący zrzut lub archiwizację dziennika transakcji do magazynu obiektowego poza klastrem. Migawka wolumenu działającej bazy nie gwarantuje spójności; zrzut przez operator tak.
Sekrety: jedno źródło. Zewnętrzny menedżer sekretów z własną kopią zapasową albo szyfrowanie w repozytorium z kluczem przechowywanym w dwóch niezależnych miejscach poza klastrem. Klucz do sekretów przechowywany wyłącznie w klastrze jest kopią, której nie da się odczytać po awarii.
Urząd certyfikacji. Kopia klucza urzędu w sejfie na hasła lub na nośniku poza klastrem, z procedurą odtworzenia.
Stan klastra. Migawka bazy klastra z węzłów sterujących, codziennie, do magazynu poza klastrem. Dodatkowo eksport zasobów przez narzędzie do kopii klastra, który wychwytuje to, co powstało poza repozytorium, i pokazuje, co powinno do niego trafić.
Rejestr. Replikacja do drugiego rejestru poza klastrem albo procedura odbudowy obrazów z CI działającego poza klastrem. Jedno z dwóch, świadomie wybrane.
Test odtworzenia
Nowy, pusty klaster w odizolowanym środowisku. Podłączenie do repozytorium i synchronizacja. Przywrócenie sekretów. Przywrócenie wolumenów lub baz z kopii. Weryfikacja, że aplikacje uruchamiają się i widzą swoje dane. Pomiar czasu od zera do działającej aplikacji.
Ten test wykonany raz na kwartał odpowiada na pytanie, czy „wszystko jest w Gicie” jest prawdą. Zwykle za pierwszym razem nie jest, a lista braków staje się listą zadań.
Podsumowanie
Klaster prowadzony przez GitOps odtwarza się z repozytorium, ale aplikacje odtwarzają się z danych, sekretów i certyfikatów, których tam nie ma. Kopie migawek i zrzutów baz poza klastrem, sekrety z kluczem poza klastrem, kopia urzędu certyfikacji, migawka bazy klastra, plan dla rejestru i test odtworzenia od zera co kwartał. Repozytorium jest planem budynku; kopie zapasowe są tym, co w nim mieszka.