Docker Compose czy Kubernetes? Wysoka dostępność ma koszt operacyjny

Dla małej aplikacji produkcyjnej działającej na pojedynczym serwerze zwykle wystarczy Docker Compose. Kubernetes warto rozważyć, gdy usługa ma pozostać dostępna po awarii hosta albo wymaga częstych aktualizacji bez przerwy w obsłudze ruchu. Taki wybór oznacza jednak utrzymanie całego klastra, nie tylko zmianę sposobu uruchamiania kontenerów.

Decyzję wyznacza dopuszczalny czas odtworzenia usługi, rodzaj awarii, który ma ona przetrwać, oraz możliwości zespołu. Jeśli po utracie serwera można poczekać na przywrócenie aplikacji i danych, pojedynczy host jest świadomym kompromisem. Jeśli ruch ma nadal trafiać do działającej instancji, potrzebne są zapasowe zasoby poza uszkodzoną maszyną.

Od jakiej awarii aplikacja ma być odporna?

Najpierw trzeba odróżnić awarię procesu od utraty hosta. Polityka restartu może ponownie uruchomić kontener na sprawnej maszynie, ale nie przywróci usługi na serwerze, który stracił zasilanie lub łączność. Odporność na taki przypadek wymaga innego miejsca uruchomienia aplikacji oraz sposobu skierowania do niego ruchu.

Dwa użyteczne wymagania to maksymalny czas przywrócenia działania i dopuszczalna utrata danych. Pierwsze określa, czy wystarczy odtworzenie z kopii, czy potrzebna jest gotowa instancja na innym hoście. Drugie dotyczy bazy danych i plików: uruchomienie nowego kontenera samo nie odtworzy zapisów, których nie ma w dostępnym magazynie ani kopii zapasowej.

Planowana aktualizacja to jeszcze inny scenariusz. Krótkie okno serwisowe może być akceptowalne, nawet jeśli awaria w godzinach pracy wymaga szybkiej reakcji. Warto oceniać te sytuacje osobno, bo częstotliwość wdrożeń i tolerancja na nieplanowaną przerwę prowadzą do różnych kosztów operacyjnych.

Kiedy wystarczy Docker Compose?

Compose pasuje do wdrożenia, którego usługi mieszczą się na jednym hoście, a wymagany czas odtworzenia pozwala odbudować serwer i przywrócić dane. Dokumentacja Docker dotycząca produkcji opisuje taki sposób uruchomienia, osobny plik ustawień produkcyjnych, politykę restartu i usługę zbierającą logi. Produkcyjne użycie Compose jest więc udokumentowane; jego przydatność zależy od wymaganego poziomu dostępności.

Na pojedynczym hoście zespół ma mniej elementów infrastruktury do aktualizowania i diagnozowania. Nadal musi zadbać o stan maszyny, dostęp do niej, monitoring, kopie danych i procedurę odtworzenia. Polityka restartu pomaga przy problemie kontenera, lecz po utracie hosta liczy się to, czy aplikację można uruchomić gdzie indziej wraz z aktualnymi danymi.

Compose pozostaje rozsądnym wyborem także przy okresowych wdrożeniach, jeśli dopuszczalne jest krótkie okno serwisowe. Wówczas powtarzalne uruchamianie usług i przećwiczone odtwarzanie mogą mieć większą wartość niż stała obsługa klastra. Sama niewielka skala aplikacji nie rozstrzyga jednak sprawy: mała usługa również może mieć wymaganie ciągłości pracy.

Kiedy uzasadniony jest klaster Kubernetes?

Kubernetes ma sens, gdy aplikacja potrzebuje replik na różnych węzłach, a utrata jednego hosta nie może oznaczać oczekiwania na ręczne odtworzenie usługi. Wytyczne produkcyjne Kubernetes wskazują, że środowisko na jednej maszynie ma pojedynczy punkt awarii; wysoka dostępność wymaga zaplanowania węzłów roboczych, replikacji płaszczyzny sterowania i równoważenia ruchu do API klastra.

To właśnie jest koszt operacyjny wyboru. Przy samodzielnym klastrze trzeba utrzymywać łączność między węzłami, uprawnienia, certyfikaty, aktualizacje i kopie danych konfiguracyjnych klastra. Usługa zarządzana może przejąć część prac związanych z płaszczyzną sterowania, lecz nie przejmuje automatycznie odpowiedzialności za poprawne działanie aplikacji i dostępność jej danych.

Repliki aplikacji też nie wystarczą, jeśli wszystkie zależą od jednej niedostępnej bazy, wspólnego magazynu plików albo jednego punktu wejścia ruchu. Dlatego wymaganie odporności trzeba odnieść do całej ścieżki żądania. Dopiero wtedy wiadomo, które elementy należy powielić, a które można odtwarzać po awarii.

Co zmienia sposób aktualizacji?

Przy częstych publikacjach nowej wersji znaczenie ma sposób wymiany działających instancji. Opisane przez Docker odtworzenie usługi w Compose zatrzymuje i tworzy na nowo jej kontener; przy pojedynczej instancji może to przerwać obsługę żądań. Bardziej rozbudowane przełączanie ruchu da się zorganizować wokół takiego wdrożenia, ale jego przygotowanie i utrzymanie spoczywa wtedy na zespole.

W Kubernetes mechanizm Deployment może stopniowo zastępować repliki. Ustawienia maxUnavailable i maxSurge określają, ile instancji może być niedostępnych oraz ile dodatkowych może działać podczas aktualizacji. Korzyść wymaga jednak miejsca na nowe repliki i poprawnego określania, kiedy są gotowe do przyjmowania ruchu.

Bezprzerwowe wdrożenie nie wynika z samego użycia Kubernetes: zależy również od zachowania aplikacji, jej zależności i konfiguracji ruchu. Jeśli aktualizacje są rzadkie, a okno serwisowe jest dopuszczalne, utrzymywanie klastra wyłącznie dla tego mechanizmu może być nieproporcjonalne. Przy częstych wdrożeniach bez zgody na przerwę warto porównać pracę potrzebną do własnego procesu przełączania z pracą przy klastrze.

Co mówią badania wydajności?

Benchmark nie zastąpi wymagania dostępności, ale pokazuje, jak silnie wynik zależy od środowiska. Badanie dystrybucji Kubernetes porównywało Kubeadm, K3s, MicroK8s i K0s z usługą OpenFaaS, uwzględniając tryb wirtualizacji i środowisko uruchomieniowe kontenerów. Mierzyło między innymi tempo obsługi żądań i wykorzystanie procesora w tych konfiguracjach, a nie uniwersalną przewagę Kubernetes nad Compose.

W badaniu startu kontenerów Docker wykonano po 50 powtórzeń testu w środowiskach obejmujących dyski SSD i HDD w chmurze oraz Docker Desktop na macOS. Autor mierzył czas uruchomienia kontenera w różnych warunkach infrastruktury; ten wynik nie określa czasu przywrócenia całej aplikacji po awarii hosta. O wyborze orkiestracji więcej mówi zatem własny wymagany czas odtworzenia niż najszybszy start kontenera w cudzym środowisku.

Drzewo decyzji dla małej aplikacji

• Pojedynczy host, akceptowana przerwa po jego utracie: wybierz Compose, jeśli procedura odbudowy maszyny, uruchomienia usług i przywrócenia danych mieści się w wymaganym czasie.
• Pojedynczy host, brak zgody na taką przerwę: zapewnij dodatkową maszynę, dostępne dane i przełączenie ruchu. Sama instalacja Kubernetes na dotychczasowym serwerze nie usuwa punktu awarii.
• Wiele węzłów, wymagane utrzymywanie replik i aktualizacje bez przerwy: rozważ Kubernetes, uwzględniając również obsługę sieci, płaszczyzny sterowania, uprawnień i aktualizacji klastra.
• Wymagana odporność, ograniczone zasoby zespołu: porównaj samodzielne utrzymanie klastra z usługą zarządzaną. Zakres prac może się zmniejszyć, ale aplikacja, jej zależności i dane nadal wymagają opieki.

Przeczytaj także:

• PostgreSQL czy MySQL? Benchmark zmienia zwycięzcę wraz z operacją
• Klucz dostępu chroni przed phishingiem, ale nie twórz go na wspólnym sprzęcie
• Zoom czy Google Meet na słabym łączu? Benchmark nie daje jednego zwycięzcy