Kubernetes dla małego zespołu: czy warto?

Kubernetes wygrał. To branżowy standard orkiestracji kontenerów, każda chmura oferuje zarządzaną wersję, a prelekcje konferencyjne sprawiają, że brzmi obowiązkowo. Więc mały zespół budujący aplikację Rails czuje pociąg: na pewno my też powinniśmy być na Kubernetes? Ten wpis to uczciwa próba odpowiedzi na to — co Kubernetes naprawdę daje, co naprawdę kosztuje i czy mały zespół faktycznie go potrzebuje. Krótka wersja, którą potem uzasadnię: prawdopodobnie jeszcze nie.

Co Kubernetes właściwie daje

Kubernetes to prawdziwa i imponująca inżynieria, a jego korzyści są realne. To deklaratywny orkiestrator kontenerów: opisujesz stan pożądany swojego systemu (uruchom 3 kopie tego kontenera, daj mu tyle pamięci, wystaw go tu, połącz go z tamtym), a Kubernetes pracuje nieustannie, by dopasować rzeczywistość — ta sama idea uzgadniania pożądane-vs-faktyczne z wpisu o EC2, podniesiona do całej platformy. Konkretnie:

Samonaprawianie. Kontener pada, Kubernetes go restartuje. Węzeł umiera, przeplanowuje pracę gdzie indziej. System nieustannie naprawia się ku zadeklarowanemu stanowi.
Deklaratywne skalowanie. Zmień „3 repliki” na „10”, a Kubernetes to czyni; autoskalowanie może to zrobić na podstawie obciążenia.
Rolling deploye i rollbacki są wbudowane, z health checkami bramkującymi rollout.
Spójna abstrakcja między chmurami. Twój deployment jest opisany tak samo, czy działa na AWS, GCP, czy na twoim własnym sprzęcie.

Dla organizacji uruchamiającej wiele usług przy realnej skali to transformujące. Pytaniem nie jest, czy Kubernetes jest dobry — to czy twoja sytuacja potrzebuje tego, co oferuje, za cenę, którą nalicza.

Co naprawdę kosztuje

Oto część, którą prelekcje konferencyjne niedoceniają. Kubernetes jest operacyjnie ciężki, a koszt jest płacony nieustannie, nie raz:

Stroma, szeroka krzywa uczenia. Pody, usługi, deploymenty, ingressy, configmapy, sekrety, wolumeny, namespace’y, RBAC — Kubernetes ma duże słownictwo i mnóstwo koncepcji, a musisz zrozumieć sporą ich część, zanim będziesz mógł bezpiecznie wdrożyć i operować aplikacją. To tygodnie nauki, które nie są budowaniem twojego produktu.
Efektywnie chce zespołu platformy. Dobre prowadzenie Kubernetes — sieć, ingress, zarządzanie sekretami, monitoring, upgrade’y samego klastra, debugowanie, gdy pod nie chce się zaplanować — jest bliskie pełnoetatowej specjalizacji. Dla małego zespołu ludzie utrzymujący Kubernetes to ci sami, którzy powinni budować funkcje, a Kubernetes może po cichu zjeść dużą część ich czasu.
Więcej ruchomych części, więcej trybów awarii. Dodałeś duży, złożony system rozproszony pod swoją aplikacją, a on ma własne tryby awarii, które teraz musisz rozumieć i debugować — na szczycie awarii twojej aplikacji. Gdy coś pęka, „czy to moja aplikacja, czy klaster?” to nowe i częste pytanie.
Zarządzany Kubernetes pomaga, ale tego nie wymazuje. Zarządzana płaszczyzna kontrolna (EKS, GKE) usuwa część ciężaru, ale wciąż posiadasz obciążenia, konfigurację sieci, YAML i wiedzę operacyjną. Obniża podłogę; nie czyni Kubernetes prostym.

Uczciwe podsumowanie: Kubernetes wymienia operacyjną prostotę na operacyjną moc. Ta wymiana jest znakomita, gdy potrzebujesz mocy i masz ludzi; to zła wymiana, gdy nie potrzebujesz żadnego.

Czy mały zespół go potrzebuje?

Wyjaśniającym pytaniem nie jest „czy Kubernetes jest dobry?”, lecz „jaki problem rozwiązuję i czy Kubernetes to najprostsza rzecz, która go rozwiązuje?” Dla małego zespołu z aplikacją Rails i skromną skalą uczciwą odpowiedzią jest zwykle nie, jeszcze nie, bo problemy, które Kubernetes rozwiązuje, to głównie problemy, których nie masz przy tym rozmiarze:

Prawdopodobnie uruchamiasz garść usług, nie setki — więc orkiestracja wielu usług to moc, której nie używasz.
Prawdopodobnie nie potrzebujesz autoskalować przez flotę węzłów — para odpowiednio dobranych serwerów obsługuje twoje obciążenie.
Twoje potrzeby deployu (atomowy release, łatwy rollback, health checki) są realne, ale osiągalne znacznie prościej.

Koszt tymczasem jest płacony w pełni bez względu na twój rozmiar — krzywa uczenia i ciężar operacyjny nie kurczą się, bo jesteś mały. Więc mały zespół przyjmujący Kubernetes często płaci pełny koszt za ułamek korzyści i spędza czas operując klastrem, który powinien był pójść w produkt.

Prostsze alternatywy

Po co mały zespół powinien zwykle sięgnąć zamiast tego, w przybliżonej kolejności rosnącej kontroli:

PaaS (Heroku i spółka). Dla wielu małych zespołów to właściwa odpowiedź przez lata: git push, by wdrożyć, platforma obsługuje serwery, skalowanie to suwak, a operujesz niemal niczym. Premia, którą płacisz w hostingu, jest znacznie mniejsza niż koszt pensji operowania Kubernetes samodzielnie.
Zarządzana usługa kontenerów prostsza niż pełny Kubernetes — uruchom kontenery bez ręcznego zarządzania orkiestratorem.
Para dobrze skonfigurowanych serwerów (podejście Ansible/Capistrano z wcześniejszych wpisów) z kontenerami, co w zupełności wystarcza wielu aplikacjom i które w pełni rozumiesz.

Każda z nich daje ci kontenery, deploye i rollbacki bez klastra, a możesz przejść na Kubernetes później, jeśli i kiedy naprawdę je przerośniesz.

Kiedy Kubernetes staje się wart

By być wobec niego sprawiedliwym: jest realny punkt, w którym Kubernetes staje się właściwym wyborem. Gdy uruchamiasz wiele usług (prawdziwą architekturę mikroserwisów), gdy masz prawdziwe wielkoskalowe potrzeby autoskalowania, gdy potrzebujesz przenośności multi-region albo hybrid-cloud i — co kluczowe — gdy masz ludzi, by go operować (zespół platformy/infra albo silną pojemność DevOps), Kubernetes zarabia na swoją złożoność i staje się prawdziwym aktywem. Sygnałem jest to, że czujesz ból, który Kubernetes rozwiązuje — a nie że przeczytałeś, że to czego używają poważne zespoły.

Werdykt

Kubernetes to znakomita inżynieria rozwiązująca realne problemy — orkiestrację wielu kontenerów przy skali, deklaratywnie i samonaprawiająco — ale rozwiązuje je przy stromym, ciągłym koszcie operacyjnym, który nie kurczy się dla małych zespołów. Dla małego zespołu budującego aplikację Rails przy skromnej skali przyjęcie Kubernetes zwykle oznacza płacenie pełnej ceny za korzyści, których jeszcze nie używasz, podczas gdy PaaS albo para dobrze prowadzonych serwerów dostarczyłaby deploye, rollbacki i niezawodność znacznie prościej. Wybieraj infrastrukturę według problemu, który faktycznie masz, nie tego, który branża mówi, że powinieneś aspirować mieć. Sięgaj po Kubernetes, gdy naprawdę czujesz ból, który rozwiązuje, i masz ludzi, by go prowadzić — a do tego czasu trzymaj infrastrukturę tak prostą, jak pozwala twoja skala, i wydaj zaoszczędzony czas na produkt. Najbardziej wyrafinowanym wyborem jest często najprostszy, który działa.