Masz klaster Kubernetes, aplikacje potrzebują trwałych wolumenów, a lokalne dyski czekają na wykorzystanie? Rook z Ceph może zapewnić im blokowy lub współdzielony storage, pod warunkiem że zaplanujesz rozmieszczenie danych i pojemność pod awarie, a nie tylko pod zwykły dzień pracy.
Rook zarządza Ceph przez Kubernetes, ale odporność zależy od projektu klastra
- Rook wdraża i nadzoruje Ceph przez zasoby Kubernetes, a dane obsługują demony Ceph.
- RBD pasuje do wolumenów blokowych, a CephFS do współdzielonego systemu plików.
- Przy trzech replikach i trzech równych węzłach nominalna pojemność użytkowa wynosi około jednej pojemności węzła.
- Awaria operatora nie zatrzymuje sama w sobie operacji odczytu i zapisu, ale utrudnia zarządzanie klastrem.
- Przed aktualizacją sprawdź stan Ceph, działanie aplikacji korzystających z wolumenów i plan wycofania zmian.
Rook steruje Ceph, lecz nie przenosi przez siebie danych aplikacji
Gdy pod zapisuje plik na wolumenie, łatwo założyć, że ruch przechodzi przez operatora Rook. Tak nie działa ten podział: Rook wdraża i konfiguruje komponenty, natomiast aplikacje komunikują się z Ceph za pośrednictwem odpowiednich interfejsów.
To rozróżnienie przydaje się podczas diagnozowania awarii. Zgodnie z FAQ projektu Rook, zatrzymanie operatora nie odcina automatycznie działającego ruchu danych. Aplikacje mogą nadal czytać i zapisywać, choć operator nie wykona w tym czasie zadań zarządzających, takich jak zmiana konfiguracji czy obsługa aktualizacji.
Ceph udostępnia kilka rodzajów storage. RBD daje wolumen blokowy, najczęściej montowany jako PersistentVolume, a CephFS udostępnia system plików, z którego mogą korzystać równocześnie różne pody. Do przechowywania obiektów w modelu zgodnym z S3 służy brama RGW. Wybór interfejsu powinien wynikać z potrzeb aplikacji, nie z tego, który przykład YAML najłatwiej skopiować.
Trzy węzły i trzy repliki dają tylko pojemność jednego węzła
Trzy dyski po 4 TB wyglądają jak 12 TB storage. Przy trzech replikach Ceph zarezerwuje jednak miejsce na trzy kopie danych, więc w uproszczonym, równomiernym układzie zostanie około 4 TB pojemności nominalnej, jeszcze przed narzutem systemu i bezpiecznym zapasem operacyjnym.
Ten przykład zakłada po jednej równej puli dyskowej na każdym z trzech hostów oraz regułę rozmieszczania kopii między hostami. Ceph używa algorytmu CRUSH, który rozkłada dane według mapy urządzeń i domen awarii. Dokumentacja architektury Ceph opisuje hierarchię takich domen, od urządzenia i hosta po szafę rack.
W praktyce trzy hosty nie oznaczają odporności na każdą awarię. Jeśli wszystkie stoją w jednej szafie z jednym zasilaniem i jednym przełącznikiem, awaria tej infrastruktury może wyłączyć całą domenę naraz. Granica odporności wynika z rzeczywistego rozmieszczenia hostów, a nie z liczby replik wpisanej w konfiguracji.
Przed wdrożeniem przyjmij więc zasadę: jeśli klaster ma przeżyć utratę hosta bez zatrzymania aplikacji, sprawdź, czy CRUSH rozkłada kopie właśnie na poziomie hosta, a zaplanowana pojemność uwzględnia odbudowę danych. Przy trzech hostach awaria jednego pozostawia klaster zdegradowany; na odtworzenie pełnej liczby kopii może zabraknąć miejsca, dopóki host nie wróci albo nie dołączysz kolejnego.
Dobierz interfejs storage do sposobu pracy aplikacji
Problemy z wolumenem często zaczynają się przed pierwszym zapisem: od wyboru niewłaściwego modelu dostępu. RBD i CephFS rozwiązują inne zadania, dlatego ich zamiana nie sprowadza się do zmiany nazwy StorageClass.
| Potrzeba | Typowy wybór | Co sprawdzić |
|---|---|---|
| Wolumen blokowy dla pojedynczej instancji aplikacji | RBD | Tryb dostępu PVC i zachowanie aplikacji przy odłączeniu oraz ponownym podłączeniu wolumenu. |
| Współdzielone pliki widoczne dla wielu podów | CephFS | Wymagany tryb dostępu i obsługę klienta CephFS przez węzły Kubernetes. |
| Obiekty dostępne przez API zgodne z S3 | RGW | Polityki dostępu, sposób przechowywania sekretów oraz niezależny plan kopii zapasowej. |
Nie traktuj replikacji Ceph jako pełnej kopii zapasowej. Repliki pomagają przetrwać awarię urządzenia lub hosta, ale mogą powielić także niepożądane usunięcie albo uszkodzenie danych. Odzyskiwanie po błędzie użytkownika wymaga osobnej strategii, na przykład kopii poza klastrem i sprawdzonych testów odtworzenia.
Jeśli dopiero projektujesz usługę, zacznij od jej kontraktu: czy potrzebuje urządzenia blokowego, wspólnego katalogu, czy API obiektowego? Dopiero potem wybierz pulę, StorageClass i politykę retencji. Ja uznałbym taki porządek za bezpieczniejszy niż budowanie konfiguracji wokół domyślnego przykładu, bo ogranicza późniejsze migracje wolumenów.
Objaw w Kubernetes często wskazuje na problem niżej w warstwie storage
Pod w stanie oczekiwania nie zawsze oznacza problem z samym Kubernetes. Przyczyną może być brakujący OSD, niezdrowa pula albo niedostępny komponent CSI, więc diagnozę najlepiej zacząć od objawu i zawężać ją warstwa po warstwie.
| Sytuacja | Możliwa przyczyna | Co zrobić |
|---|---|---|
| PVC długo pozostaje w stanie Pending | Nieprawidłowa StorageClass, brak puli lub błąd provisionera CSI. | Sprawdź zdarzenia PVC, nazwę StorageClass i logi odpowiedniego provisionera. |
| Pod nie montuje już utworzonego wolumenu | Problem z węzłem, pluginem CSI, dostępem do urządzenia albo stanem klastra Ceph. | Porównaj zdarzenia poda z logami pluginu CSI na jego węźle; sprawdź też stan Ceph. |
| Po restarcie węzła OSD nie wraca | Brak wymaganych narzędzi lub usług hosta, problem z dyskiem albo wykryciem urządzenia. | Sprawdź logi OSD i stan urządzenia na hoście. Dokumentacja wymaga pakietu LVM w określonych konfiguracjach. |
| Rebalansowanie postępuje wolno po awarii | Ograniczona przepustowość sieci lub dysków, niedobór wolnego miejsca albo przeciążenie klastra. | Przed usuwaniem OSD sprawdź stan puli, wolne miejsce i postęp odbudowy; unikaj kolejnych zmian naraz. |
Lista wymagań w dokumentacji Rook dotyczącej prerekwizytów zwraca uwagę na pakiet LVM w konkretnych przypadkach, między innymi przy szyfrowaniu urządzeń, użyciu urządzenia metadanych lub wielu OSD na jednym urządzeniu. Brak zależności może ujawnić się dopiero po restarcie hosta, więc test instalacji nie powinien kończyć się na stanie „wszystkie pody działają”.
Sprawdzaj równocześnie stan Kubernetes i Ceph. `kubectl get pods` pokaże, czy komponenty działają, ale nie zastąpi kontroli kondycji klastra Ceph oraz puli. Z drugiej strony zielony stan Ceph nie dowodzi jeszcze, że CSI prawidłowo podłącza wolumeny do podów.
Aktualizację zacznij od zdrowego klastra i planu wycofania
Aktualizacja operatora może pociągnąć za sobą zmianę wersji Ceph, dlatego traktowanie jej jak zwykłego odświeżenia obrazu kontenera bywa ryzykowne. Stan wyjściowy powinien być zdrowy, a aplikacje korzystające ze storage powinny działać stabilnie.
Przed zmianą sprawdź kondycję Ceph, dostępność podów, zajętość puli i zgodność wersji z dokumentacją danej ścieżki aktualizacji. W instrukcji aktualizacji Rook wymagane są między innymi prawidłowy stan klastra i stabilna praca podów korzystających z Rook storage. Nie pomijaj też szczegółów konkretnego wydania, bo wymagania mogą się różnić między wersjami.
Węzeł z OSD nie powinien znikać z klastra tak, jak zwykły worker bez danych. Najpierw oceń wpływ jego wyłączenia na domenę awarii i replikację, a potem wykonaj konserwację zgodnie z procedurą dla swojej wersji Rook i Ceph. Przerwij aktualizację, jeśli klaster traci zdrowie; równoległe zmiany w Kubernetes, Ceph i sieci utrudniają ustalenie, co wywołało problem.
Najpierw sprawdź, czy klaster pasuje do obciążenia
Rook Ceph ma sens, gdy potrzebujesz storage zarządzanego razem z Kubernetes i masz zasoby oraz kompetencje do obsługi rozproszonego systemu. Jeśli potrzebujesz jednego prostego wolumenu w małym klastrze, narzut operacyjny może przewyższyć korzyści. Decyzję oprzyj na wymaganej odporności, pojemności po awarii i kosztach utrzymania, nie na samej dostępności manifestu.
Przed uruchomieniem obciążenia produkcyjnego przeprowadź test utraty hosta, odtworzenia kopii zapasowej i ponownego podłączenia wolumenu po restarcie węzła. Wtedy odpowiedź na pytanie „czy storage działa?” będzie oparta na zachowaniu aplikacji w awarii, a nie wyłącznie na zielonym statusie operatora.
