Jak zachować spokój, gdy Twój klaster Kubernetes pada, czyli dlaczego potrzebujesz Velero

Wyobraź sobie taką sytuację: piątkowy wieczór, planujesz odpoczynek, gdy nagle pojawia się powiadomienie na Slacku — jeden z twoich produkcyjnych klastrów Kubernetes padł. Błąd konfiguracji, awaria dostawcy chmury lub po prostu zwykły błąd ludzki — przyczyna nie ma już znaczenia. Liczy się to, jak szybko możesz przywrócić wszystko do działania. Jeśli masz tylko pliki YAML w Git, możesz mieć problem z odzyskaniem stanowych aplikacji i ich danych.

Tutaj z pomocą przychodzi Velero. To projekt VMware (pierwotnie stworzony przez Heptio), który stał się de facto standardem tworzenia kopii zapasowych w świecie K8s.

Czym jest i dlaczego samo GitOps to za mało

Wielu programistów uważa, że jeśli cała ich infrastruktura jest zdefiniowana w kodzie (IaC) i wdrażana przez ArgoCD lub Flux, kopie zapasowe są zbędne. To niebezpieczne założenie. Git przechowuje manifesty, ale nic nie wie o stanie Twoich Persistent Volumes (PV), dynamicznie wystawianych certyfikatów czy sekretów, które nigdy nie trafiły do repozytorium.

Velero robi dwie rzeczy: zapisuje obiekty API Kubernetes (deployments, configmapy, sekrety) i wykonuje migawki dysków z danymi. Działa w chmurach publicznych (AWS, GCP, Azure) oraz w lokalnych centrach danych na serwerach bare metal.

Trzy scenariusze, w których Velero ratuje życie

często widzę, że Velero jest używany nie tylko do ochrony przed katastrofami. Oto główne przypadki użycia:

1. Klasyczne odzyskiwanie po awarii. Tutaj wszystko jest proste: klaster padł, uruchamiasz nowy i przywracasz wszystko z magazynu S3 jednym poleceniem.
2. Migracja między chmurami. Przeniesienie z AWS do Google Cloud lub z jednego regionu do drugiego staje się trywialnym zadaniem. Velero pakuje zasoby i wdraża je w nowej lokalizacji.
3. Klonowanie środowisk. Potrzebujesz szybko stworzyć dokładną kopię produkcji do testów? Tworzysz kopię zapasową prod, przywracasz ją do przestrzeni nazw staging. Dane z bazy będą aktualne, a nie sprzed miesięcznego zrzutu.

Jak to działa pod maską

Architektura projektu jest dość przejrzysta. Istnieje komponent serwera, który działa wewnątrz klastra jako operator, oraz klient CLI do zarządzania procesem.

Gdy uruchamiasz kopię zapasową, dzieje się następujące:

1. Klient wysyła żądanie do API Velero.
2. Kontroler Backup znajduje wszystkie obiekty, które określiłeś (możesz filtrować według etykiet lub przestrzeni nazw).
3. Velero wykonuje żądania do API Kubernetes, aby zebrać opisy zasobów w formacie JSON.
4. Równolegle wywoływane są wtyczki do zarządzania dyskami (np. EBS w AWS lub sterowniki CSI), aby utworzyć migawki danych.
5. Wszystko to jest archiwizowane i wysyłane do magazynu obiektowego (zgodnego z S3).

Przy okazji, Velero obsługuje Restic i Kopia. Oznacza to, że możesz wykonywać przyrostowe kopie zapasowe systemu plików nawet tam, gdzie migawki chmurowe nie są dostępne.

Praktyczny przykład

Powiedzmy, że musimy wykonać kopię zapasową całej aplikacji w przestrzeni nazw app-production. Polecenie w terminalu wyglądałoby mniej więcej tak:

velero backup create production-backup --include-namespaces app-production

A jeśli ktoś przypadkowo usunie tę przestrzeń nazw za tydzień, odzyskanie zajmie zaledwie kilka minut:

velero restore create --from-backup production-backup

Ciekawe jest to, że Velero może modyfikować parametry zasobów w locie podczas przywracania. Możesz na przykład zmienić StorageClass dla dysków, jeśli stara klasa nie jest dostępna w nowym klastrze.

Niuansy kompatybilności

Twórcy Velero utrzymują dość rygorystyczną macierz kompatybilności. Obecnie wersja 1.18 jest testowana pod kątem najnowszych wydań Kubernetes (do 1.35). To ważne, ponieważ API Kubernetes zmienia się szybko, a starsze narzędzia często przestają działać po uaktualnieniu klastra.

Projekt działa pod auspicjami Cloud Native Computing Foundation (CNCF), co zapewnia pewne gwarancje: nie zniknie jutro, a jego bezpieczeństwo jest monitorowane.

Czy warto wdrożyć

Jeśli używasz Kubernetes w produkcji i masz jakiekolwiek dane na dyskach (bazy danych, kolejki, magazyny konfiguracji), Velero jest niezbędny.

Kto zdecydowanie skorzysta:

• Inżynierowie SRE, którzy chcą spać spokojnie w nocy.
• Zespoły, które często migrują między klastrami.
• Programiści, którzy potrzebują świeżych danych produkcyjnych do debugowania złożonych błędów.

Zacznij od oficjalnej dokumentacji na velero.io. Jest dość szczegółowa, choć czasami może przytłaczać. Najważniejsze, co musisz zapamiętać, to że kopia zapasowa istnieje dopiero wtedy, gdy przynajmniej raz pomyślnie ją przywrócisz. Spróbuj zrobić to w klastrze testowym, zanim powierzysz temu narzędziu prawdziwe dane.