Czym jest Kubernetes i czy naprawdę jest potrzebny?

Kubernetes ma opinię skomplikowanego i jest to opinia zasłużona – ale idea, która za nim stoi, jest prosta: to system do niezawodnego uruchamiania wielu kontenerów na grupie maszyn, który restartuje te, które ulegają awarii, i rozkłada obciążenie między te, które działają poprawnie – bez człowieka, który musiałby wpatrywać się w panel i interweniować ręcznie.

Jaki problem rozwiązuje

Pojedynczym kontenerem na pojedynczym serwerze łatwo zarządzać. Ale gdy tylko pojawia się prawdziwy ruch produkcyjny, zwykle potrzeba kilku instancji aplikacji (dla przepustowości i na wypadek awarii jednego serwera), a do tego bazy danych, cache, procesów działających w tle i jakiegoś sposobu kierowania ruchu do tych instancji, które w danej chwili rzeczywiście działają. Robienie tego ręcznie – logowanie się przez SSH na serwer, zauważenie, że kontener padł, restart, aktualizacja konfiguracji load balancera – nie skaluje się poza garstkę usług i gwarantuje, że ktoś zostanie postawiony na nogi o trzeciej w nocy przez coś, co maszyna powinna była już sama naprawić.

Kubernetes przejmuje to zadanie. Opisujecie pożądany stan – „uruchom trzy kopie tego kontenera, rozłożone na różne maszyny, i utrzymuj to tak” – a Kubernetes nieustannie dąży do tego, by rzeczywistość odpowiadała temu opisowi. Serwer pada? Kubernetes przenosi działające na nim kontenery gdzie indziej. Kontener ulega awarii? Zostaje automatycznie zrestartowany. Ruch rośnie? Można go skonfigurować tak, by sam dodawał kolejne kopie.

Najważniejsze elementy – bez nadmiaru żargonu

• Pod – najmniejsza jednostka wdrożeniowa, zwykle jeden kontener (czasem kilka ściśle ze sobą współpracujących).
• Deployment – określa, ile kopii poda ma działać i jak wdrażać ich aktualizacje bez przestojów.
• Service – stały adres sieciowy, który kieruje ruch do aktualnie istniejących, sprawnych podów, nawet gdy są one pod spodem wymieniane.
• Node – rzeczywista maszyna (fizyczna lub wirtualna), na której działają pody.
• Cluster – cały zestaw węzłów, którymi Kubernetes zarządza jako jednym systemem.

Pod spodem Kubernetes obsługuje wykrywanie usług, równoważenie obciążenia, wdrożenia stopniowe (rolling deployments), automatyczne wycofywanie zmian po nieudanych testach kondycji i zarządzanie sekretami – całą operacyjną „hydraulikę”, która kiedyś wymagała zestawu osobnych narzędzi połączonych ręcznie.

Uczciwa odpowiedź: czy go potrzebujecie?

Kubernetes rozwiązuje prawdziwe problemy, ale kosztem prawdziwej złożoności – krzywej uczenia się, narzutu operacyjnego i całego słownika, który wasz zespół musi teraz znać. Jeśli macie jedną czy dwie usługi z przewidywalnym, umiarkowanym ruchem, prostsze rozwiązanie – kilka serwerów za load balancerem albo zarządzana platforma, która całkowicie ukrywa orkiestrację – najprawdopodobniej sprawdzi się lepiej i będzie wymagać znacznie mniej czasu inżynierów na utrzymanie.

Kubernetes zaczyna być wart swojej złożoności, gdy macie wiele usług, które trzeba niezależnie skalować i wdrażać, gdy ruch jest na tyle zmienny, że automatyczne skalowanie naprawdę ma znaczenie, albo gdy jesteście już na tyle głęboko w infrastrukturze chmurowej, że jego ekosystem (i szeroka pula inżynierów, którzy już go znają) przeważa nad kosztem nauki. Sięganie po niego przed tym etapem to jeden z częstszych sposobów, w jaki zespoły kończą z pełnoetatową pracą polegającą wyłącznie na utrzymywaniu klastra w dobrej kondycji, zamiast na budowaniu produktu, który ten klaster ma obsługiwać.

Rozsądna ścieżka

Wiele odnoszących sukcesy produktów w ogóle nie korzysta z Kubernetesa, a wiele innych wdraża go po roku czy dwóch, gdy operacyjny ból, który rozwiązuje, faktycznie się pojawi. Zaczęcie od czegoś prostszego i migracja wtedy, gdy odczujecie ten konkretny problem, który Kubernetes rozwiązuje, to zwykle mniej ryzykowna kolejność niż wdrażanie go od razu tylko dlatego, że to znana nazwa.

Decyzja, czy Kubernetes to właściwy wybór – czy też prostsze rozwiązanie lepiej posłuży wam przez najbliższy rok – to dokładnie ten rodzaj decyzji infrastrukturalnych, w których pomagamy zespołom w Burncode, na podstawie ruchu i wielkości zespołu, które faktycznie mają, a nie tych, które może kiedyś będą mieć.