Aplikacja działa. Potem pojawia się aktualizacja, awaria serwera albo kilka działów potrzebuje jednocześnie większej mocy. Kubernetes organizuje rozmieszczenie kontenerów i przywracanie uzgodnionego stanu działania. To, czy aplikacja staje się dzięki temu bardziej niezawodna, zależy od całej architektury.
Weźmy wewnętrzny portal zamówień: pracownicy wprowadzają zamówienia, interfejs przekazuje je do systemu gospodarki magazynowej, a proces w tle tworzy dokumenty. Te zadania mogą wykonywać osobne kontenery. Kto uruchamia je pojedynczo, musi też koordynować aktualizacje, ponowne uruchomienia i rozmieszczenie na maszynach. Tu zaczyna się orkiestracja.
Stan docelowy staje się podstawą utrzymania
W Kubernetes można na przykład określić, że mają działać dwie instancje aplikacji internetowej w konkretnej wersji oprogramowania. Platforma stale porównuje ten stan docelowy ze stanem rzeczywistym. Deployment opisuje wdrożenie aplikacji i za pomocą kontrolera ReplicaSet zarządza jej Podami. Gdy brakuje instancji, mechanizm sterowania próbuje uruchomić zastępczą.
Pomaga to również przy aktualizacjach: nową wersję można wdrażać stopniowo. Zasoby, sposób uruchamiania i wybrana strategia aktualizacji muszą to umożliwiać. Technicznie udane wdrożenie nie dowodzi, że zamówienie zostało poprawnie przetworzone. Ta kontrola pozostaje zadaniem aplikacji i jej testów.
Najważniejsze pojęcia na przykładzie portalu zamówień
- Obraz kontenera
- Spakowana podstawa aplikacji wraz z potrzebnymi plikami i składnikami środowiska wykonawczego. Z tego obrazu uruchamiane są kontenery.
- Pod
- Najmniejsza jednostka wdrażania w Kubernetes. Zwykle zawiera jeden kontener aplikacji; ściśle powiązane kontenery mogą współdzielić Pod i między innymi jego przestrzeń sieciową. Dwie kopie aplikacji internetowej oznaczają zazwyczaj dwa Pody.
- Węzeł
- Maszyna uruchamiająca Pody. Węzeł może być maszyną wirtualną lub fizycznym serwerem. Kubernetes może więc uzupełniać warstwę wirtualizacji, nie musi jej zastępować.
- Klaster i warstwa sterowania
- Klaster łączy mechanizm sterowania z węzłami wykonującymi obciążenia. Warstwa sterowania obejmuje serwer API, bazę stanu, harmonogram i kontrolery. Na węzłach za wykonanie odpowiadają kubelet oraz środowisko uruchomieniowe kontenerów.
- Service
- Stały logiczny punkt dostępu do grupy Podów. Przy wymianie ich adresy mogą się zmieniać. Service oddziela dostęp od pojedynczych, krótkotrwałych instancji.
Co faktycznie dzieje się podczas awarii
Jeśli węzeł ulegnie awarii, zarządzane Pody mogą zostać ponownie uruchomione na innych odpowiednich węzłach. Wymaga to wykrycia awarii, wystarczającej rezerwy mocy i dostępu do potrzebnych danych. Druga instancja na tym samym fizycznym hoście nie chroni przed awarią tego hosta. Kilka serwerów w tej samej domenie zasilania lub sieci również może mieć wspólny punkt awarii.
Dla naszego portalu oznacza to, że interfejs WWW można szybko zastąpić. Rozpoczęte zadanie tworzenia dokumentu musi jednak być tak zaprojektowane, aby powtórzenie nie utworzyło podwójnej faktury lub zamówienia. Wymiana instancji nie może powodować niekontrolowanej utraty sesji. Te właściwości zależą od architektury oprogramowania i połączonych systemów.
Trzy serwery same w sobie nie są więc planem dostępności. Sterowanie, aplikacje, sieć, pamięć masową i moc pozostałą po awarii trzeba rozpatrywać łącznie. Dotyczy to również chmury i zarządzanej usługi Kubernetes: rzeczywisty zakres usługi określa obowiązki dostawcy oraz te pozostające po stronie firmy.
Dane trwałe wymagają osobnego planu
Pody są wymienne. Dane firmowe nie mogą więc istnieć wyłącznie w zapisywalnym systemie plików kontenera. Kubernetes może podłączać trwałą pamięć masową przez Persistent Volumes i powiązane żądania nazywane Persistent Volume Claims. StorageClass opisuje sposób udostępniania odpowiedniej pamięci masowej.
Te obiekty nie zapewniają automatycznie odporności samej pamięci masowej. Lokalny dysk pozostaje związany ze swoją infrastrukturą; zewnętrzna usługa przechowywania ma własną wydajność i zachowanie przy awarii. Właściwym rozwiązaniem może być też baza danych poza klastrem. Decydują wsparcie aplikacji, spójność danych, ścieżki dostępu i uzgodniony proces odtwarzania.
Dla portalu osobno określamy więc dopuszczalny czas niedostępności, akceptowalną utratę danych i sposób testowania odtwarzania. Klaster, który niezawodnie rozpropaguje przypadkowe usunięcie na wszystkie instancje, nie zastępuje kopii zapasowej. Więcej o kopiach zapasowych i odtwarzaniu.
Kiedy dodatkowa infrastruktura się opłaca
Kubernetes staje się interesujący, gdy kilka aplikacji jest regularnie aktualizowanych, potrzebne są powtarzalne wdrożenia lub świadomy podział obciążeń między dostępne maszyny. Powstają przy tym zadania związane z aktualizacją platformy, zarządzaniem dostępem, siecią, pamięcią masową i monitorowaniem.
Dla jednej stabilnej aplikacji lepszym ekonomicznie wyborem może być odpowiednio utrzymywany serwer z Docker Compose lub klasyczna maszyna wirtualna. Decyzję należy zacząć od wymaganego sposobu działania: jakie przerwy są akceptowalne? Jak często występują zmiany? Kto rozumie środowisko i potrafi je odtworzyć w razie problemów?
Użyteczny pilotaż ma sprawdzalne cele
- Przetestować reprezentatywny proces biznesowy z realistyczną ilością danych, bez produkcyjnych danych klientów.
- Przećwiczyć aktualizację wraz z planowanym powrotem. Zmiany schematu bazy danych ocenić osobno.
- W kontrolowanych warunkach przetestować awarię jednej instancji i jednego zaplanowanego składnika infrastruktury.
- Odtworzyć kopię zapasową w osobnym środowisku testowym i otworzyć ją, aby potwierdzić użyteczność danych biznesowych.
- Imiennie przypisać odpowiedzialność za alarmy, utrzymanie platformy i aplikację.
DAXS pomaga ocenić aplikację i wybrać odpowiednią infrastrukturę oraz przeprowadzić wdrożenie i uzgodnione utrzymanie. Praktycznym pierwszym krokiem jest wstępna ocena z konkretnym przypadkiem użycia i jasnymi kryteriami odbioru.
Źródła: Kubernetes: rola i granice platformy · Składniki klastra · Pody i ich cykl życia · Deploymenty i aktualizacje · Services · Trwała pamięć masowa · Planowanie środowisk produkcyjnych
