#kubernetes

Kubernetes to system zarządzający kontenerami na grupie maszyn. Przyjmuje opis oczekiwanego układu aplikacji i sam go realizuje: uruchamia kontenery, przenosi je z maszyny, która przestała odpowiadać, i kieruje do nich ruch.

Zamówienie zamiast rozkazu

Najważniejsza rzecz w tym systemie nie dotyczy kontenerów, tylko sposobu wydawania poleceń.

Kubernetesowi nie wydaje się rozkazów. Składa się u niego zamówienie: mają pracować trzy kopie tej aplikacji, w tej wersji, z takim limitem pamięci. Klaster porównuje to zamówienie z rzeczywistością i w kółko likwiduje różnicę. Kiedy jedna kopia padnie, uruchamia nową. Kiedy padnie cała maszyna, przenosi jej kopie na pozostałe.

Ta pętla jest całą wartością systemu i jednocześnie źródłem jego najbardziej mylącego zachowania. Zamówienie z literówką albo z warunkiem nie do spełnienia nie zostaje odrzucone. Klaster przyjmuje je i czeka, dokładnie jak kelner, który zapisał danie i nigdy go nie przyniesie, a gość siedzi przy stole i nie wie, czy kuchnia pracuje. Usługa wygląda w panelu na uruchomioną i nie odpowiada nikomu, a szukanie powodu zaczyna się w dziennikach zdarzeń, nie w komunikacie o błędzie.

Czym różni się od uruchamiania kontenerów ręcznie

Sam kontener można uruchomić na serwerze jednym poleceniem i dla jednej aplikacji na jednej maszynie to wystarcza.

Kubernetes zaczyna mieć sens przy dwóch warunkach naraz: maszyn jest więcej niż jedna i aplikacja ma przeżyć utratę którejkolwiek z nich. Wtedy pojawiają się problemy, których pojedynczy serwer nie ma: na której maszynie uruchomić kontener, jak skierować do niego ruch, gdy zmienił adres, jak podmienić wersję bez przerwy w działaniu i jak nie uruchomić wszystkich kopii na tym samym sprzęcie.

Co dochodzi do utrzymania

Klaster nie jest warstwą doklejoną do serwerów, tylko kolejnym systemem z własnym cyklem życia.

Kubernetes wydaje nową wersję mniej więcej trzy razy w roku, a poprawki do konkretnego wydania kończą się po czternastu miesiącach: przez pierwszych dwanaście idą normalnie, przez ostatnie dwa wychodzą już tylko poprawki krytyczne. Klaster postawiony i zostawiony samemu sobie mija termin ważności przed drugimi urodzinami, co zwykle wychodzi dopiero przy audycie.

Aktualizacja nie jest przy tym kliknięciem, bo razem z wersją zmieniają się wersje interfejsów sterujących klastrem, a plik konfiguracji napisany dwa lata temu potrafi po niej przestać się wczytywać.

Do serwerów, systemu i aplikacji dochodzą przy tym sieć klastra, magazyn trwały, kontroler ruchu przychodzącego, certyfikaty i rejestr obrazów. Każda z tych warstw ma własne wydania i własne niezgodności.

Na co uważać

Pierwsze pytanie dotyczy danych. Kontener jest z założenia jednorazowy i to jest zaleta do chwili, w której trzyma w sobie bazę danych. Trwałe dane wymagają magazynu podpiętego do klastra, a ten magazyn jest osobnym systemem z własną awaryjnością. Bazę danych częściej zostawia się poza klastrem.

Drugie dotyczy limitów pamięci. Gdy zabraknie pamięci, klaster zabija kontener, który przekroczył limit, i uruchamia go ponownie. Bez ustawionych limitów zabija ten, który akurat był największy, czyli często nie ten, który zawinił. Ustawianie limitów jest robotą na godziny i nikt nie robi jej chętnie.

Trzecie dotyczy dostępu. Interfejs sterujący klastrem, jeśli odpowiada wprost z internetu i wystarcza mu samo hasło, działa idealnie do dnia, w którym ktoś go znajdzie. Konta służbowe z nadmiarowymi uprawnieniami są tu regułą, nie wyjątkiem, więc ich przegląd wypada powtórzyć po wdrożeniu, a nie tylko przed nim.

Czwarte dotyczy sieci wewnątrz klastra. Domyślnie każdy kontener widzi każdy inny, więc oddzielenie środowiska testowego od produkcyjnego wymaga osobnych reguł ruchu. Bez nich pomyłka w jednym miejscu sięga wszędzie, a klaster wygląda przy tym na poprawnie skonfigurowany.

Kiedy Kubernetes nie jest odpowiedzią

W małej firmie z jedną aplikacją na jednym serwerze klaster zamienia ryzyko techniczne na ryzyko kadrowe, zwykle mniej wygodne: aplikacja odporna na awarię maszyny staje się zależna od wiedzy jednej osoby. Sensowniejszym krokiem bywa wtedy uruchomienie kontenerów na zwykłym serwerze albo skorzystanie z usługi, w której dostawca prowadzi klaster za klienta. Kubernetes zaczyna się bronić tam, gdzie usług jest wiele, zmieniają się często, a przerwa w ich działaniu ma policzalną cenę.