Kubernetes, Docker Compose czy Nginx – kiedy używać?

Podstawowa sprawa to taka, że k8s Ci ogarnia na kilku maszynach jednocześnie, gdzie Compose i nginx na jednej.

K8s używasz jak masz kawał ruchu i chcesz się skalować elegancko, mieć 0 downtime update i inne różne chmurowe dobrodziejstwo-przeklenstwa.

Compose + nginx świetna sprawa jak jesteś w stanie obsłużyć ruch jedną maszynką.

W k8s tworzysz klaster nodeów i cała magia polega na tym, że x maszyn może ogarniać co trzeba.

Btw k8s jest straszną krową z potężnym overheadem i not for rookies - ja sam rozumiem mniej więcej założenia ale ogarnięcie tego produkcyjnie to trzeba być OP.

Kiedy zacząć stosować k8s?
Jak mikroserwisow jest tyle, że manualne zarządzanie wszystkim prysparza bolu glowy i nieprzespanych nocy.

Kubernetes jest platformą która ogarnia w kij więcej rzeczy niż Compose czy ręczne "trzymanie kilku instancji" (choć tutaj ciężko porównać bo nie wiadomo o co konkretnie chodzi). Podstawowe rzeczy typu skalowanie, loadbalancing, service discovery, potem poziom wyżej mamy zarządzanie sekretami, montowanie wolumenów, dalej idąc mamy cały stack bezpieczeństwa, role based access control, network policies, konfiguracja sieci, no i pewnie dalej jest już totalna magia, czyli operatory, integracje z chmurami, custom resource definitions i pewnie sporo więcej.

Więc jeśli nie potrzebujesz tych rzeczy, to oczywiście nie używaj k8s.

Aczkolwiek dodałbym niuans, że faktycznie "Kubernetes to straszna krowa" cytując @rjakubowski - zgadzam się - ale też nie trzeba wszystkiego używać i kupować hype cloudowego. Kubernetes fantastycznie działa na pojedynczej maszynie z 2 giga ramu, jest do postawienia na Ubuntu w 10 minut jak się wie co się robi (głównie kopiowanie z dokumentacji), bez integracji z cloudem, bez wolumenów, bez ingressa - ale działa :)

rjakubowski napisał(a):

Podstawowa sprawa to taka, że k8s Ci ogarnia na kilku maszynach jednocześnie, gdzie Compose i nginx na jednej.

K8s używasz jak masz kawał ruchu i chcesz się skalować elegancko, mieć 0 downtime update i inne różne chmurowe dobrodziejstwo-przeklenstwa.

Compose + nginx świetna sprawa jak jesteś w stanie obsłużyć ruch jedną maszynką.

W k8s tworzysz klaster nodeów i cała magia polega na tym, że x maszyn może ogarniać co trzeba.

Btw k8s jest straszną krową z potężnym overheadem i not for rookies - ja sam rozumiem mniej więcej założenia ale ogarnięcie tego produkcyjnie to trzeba być OP.

Kiedy zacząć stosować k8s?
Jak mikroserwisow jest tyle, że manualne zarządzanie wszystkim prysparza bolu glowy i nieprzespanych nocy.

Czekaj, jak ngnix na jednej? Możesz mieć np 2 instancje ngnix (z taką samą konfiguracją loadbalancingu, 2 instancje żeby była redundancja) które loadbalancują na pulę instancji aplikacji. Chyba że czegoś fundamentalnie nie zrozumiałem.

@marian pazdzioch

Chodziło mi o to że compose nie jest w stanie utworzyć sieci ktora ogarnie kilka maszyn. Możesz mieć jedną maszynkę z nginx ktora będzie routowac na x instancji na których masz odpalone serwisy poprzez Compose. W k8s się tym nie przejmujesz bo masz Ingressa ktory to ogarnia i rozprowadza ruch na cały klaster.

Hola hola, k8s tak, to krowa, ale jest pełno innych dystrybucji: k0s, k3s, minikube - jeśli nie zleży nam na wodotryskach, to są jak najbardziej ok IMO

Próbuję zrozumieć kiedy należy używać kubernetes, kiedy można zrobić to (imho prościej dla początkujących) za pomocą docker compose a kiedy po prostu trzymać kilka instancji i loadbalancować do nich za pomocą nginx.

Sprowadza się to do "jaki jest koszt sprzętu i ile kosztuje utrzymanie sprzętu oraz softu, który na tym sprzęcie działa, tak by mógł tam działać inny soft". Chcesz mieć tanio robisz sam. Chcesz mieć wygodniej, płacisz.

Od strony technicznej, najprościej zrozumieć problemy jakie rozwiązuje k8s. Z perspektywy CNCF k8s jest narzędziem służącym do orkiestracji i planowania uruchamiania aplikacji opartych o konteneryzację w ramach klastra (rozumianego jako zbiór zasobów (fizycznych, bądź wirtualnych) obliczeniowych, połączonych siecią).

• nie używasz kontenerów -> k8s nie jest Ci potrzebny
• nie masz klastra -> nie jest Ci potrzebny
• masz klaster -> mały -> k8s nie jest Ci potrzebny (np. dla takiego OKD zalecają produkcyjnie: 3 master nodes, >= 2 worker nodes -> >=5 maszyn; możesz uznać, "a co tam, będę kolokował worker workload na master nodach" -> 3 maszyny -" a ja mam tylko 2! -> nie potrzebujesz k8s").

Nie chcesz oprócz problemów aplikacji zajmować się problemami klastra k8s? Nie potrzebujesz k8s. No chyba, że nie masz wyboru, bo masz 100 worker nodes -> ale wtedy byś nie pytał czy nie lepiej używać docker-compose ;-)

K8S rozwiązuje Ci problemy wynikające ze skali konteneryzacji. Realizuje to w ramach orkiestracji (automatyzacja zarządzanie kontenerami) i planowania (efektywne wykorzystanie zasobów klastra). Do tego dostarcza abstrakcji na infrastrukturę (via interefejsy: CNI - sieć, CSI - storage, CRI - runtime kontenerów, CPI - cloud providers, ingress, runtime class....) Czy potrzebujesz takiej abstrakcji?
np. czy masz aplikacje, które muszą być odizolowane na poziomie kernela hosta (worker node'a) ze względów bezpieczeństwa, bądź wydajnościowych? Albo czy interesuje Cię to jak skonfigurowany jest storage i w jaki sposób podłączony do worker'a? Może wolałbyś potraktować to jako szczegół implementacyjny i operować na innym poziomie abstrakcji "potrzebuję 50TB storage z gwarancją 3 IOPS per TB i ma być replikowany do innego data center").

marian pazdzioch napisał(a):

Pisze jako adept spraw backendowych.

Chyba bardziej opsowych. Sam mikroserwis raczej powinien być niezależny od tego czy będzie na K8S działał czy na dockerze.

Próbuję zrozumieć kiedy należy używać kubernetes, kiedy można zrobić to (imho prościej dla początkujących) za pomocą docker compose a kiedy po prostu trzymać kilka instancji i loadbalancować do nich za pomocą nginx.

Kwestia skali tego co robisz i opłacalności utrzymania.
W większych chmurach masz klastry częściowo zarządzane przez dostawcę jak AKS w Azure, w dodatku łatwo konfigurowalne z innymi usługami, co też jest wygodne. Ale nadal - po pierwsze musi mieć to ekonomiczne uzasadnienie. Rachunki za chmurę mogą być wysokie.
Z drugiej strony na upartego to i na pojedynczej VMce K8S postawisz. Tylko pytanie czy jest sens.

PaulGilbert napisał(a):

Sam mikroserwis raczej powinien być niezależny od tego czy będzie na K8S działał czy na dockerze.

Niby tak, ale ja potrzebuję zrozumieć jak to działa pod spodem (nie w szczegółach tylko koncepty).

Tzn. ile ja tych mikroserwisów mam, jak one ze sobą gadają, skąd wchadza, gdzie wychadza, kto komu co, itp.

I chcę zacząć od czegoś mikro, potem większego co ma szansę działać na PROD a potem coś zaawansowanego.

I tak mi wyszło że mikro to kilka (w szczególności: 1 słownie jedna) instancji mikroserwisu, potem jakbym chciał to rozbudowywać to bym użył docker compose, a potem zrobił to w kubernetes.

Jeśli posłuchać Patoarchitektów, to niby Kubernetesa już wszyscy znają, a mimo to nadal raczej to głównie większe firmy z niego korzystają, a w mniejszych różnie bywa.
I z jednej strony wszystko można zrobić prościej, ale z pewnymi ograniczeniami, albo można rozbudować, zdejmując ograniczenia, ale kosztem stopnia skomplikowania i zasobów.

Marian, żeby odpowiedzieć na Twoje pytanie, po prostu postaram się wytłumaczyć do czego są te narzędzia.

Nginx to webserver, który jest używany jako

• reverse proxy czyli serwer pośredniczący. Za Nginx może stać np. osobny serwer na frontend i osobny na backend. Nginx otrzymując żądanie od klienta będzie wiedział do którego serwera je przepuścić, a klient będzie miał wrażenie, że łączy się z jednym serwerem.
• load balancer czyli serwer rozkładający ruch pomiędzy inne serwery np. masz dziesięć serwerów backendowych, a Nginx zadba żeby każdy z nich był obciążony tak samo.
• cache czyli serwer, który "pamięta" dane statyczne, ale również dynamiczne i zamiast puszczać ruch do serwera backend lub frontend odpowiada klientowi jeżeli "pamięta" dane o które klient pyta, odciążając serwery za nim.

Docker compose to z kolei narzędzie do uruchamiania aplikacji wielokontenerowych czyli masz np. kontener z backendem, kontener z frontendem, kontener z bazą danych, kontener z nginxem, kontener z certbotem itd. i chcesz sobie uprościć proces tworzenia infrastruktury. Zamiast odpalać wszystkie kontenery pojedynczo, ustawiać zmienne środowiskowe, konfigurować network itd itp, co może być czasochłonne opisujesz wszystko w jednym pliku docker-compose.yml i odpalasz to jednym poleceniem i tak samo możesz zatrzymać jednym poleceniem.

W końcu Kubernetes to cała platforma do zarządzania aplikacji kontenerowymi czyli:

• startowanie i zatrzymywanie kontenerów
• skalowanie kontenerów czyli np. masz duży ruch na kontenerze z mikroserwisem odpowiedzialnym za koszyk w sklepie internetowym, to Kubernetes uruchomi ci więcej kontenerów żeby obsłużyć ruch, a jak ruch się zmniejszy, to je pozabija.
• self healing czyli np. kontener padnie, to Kubernetes go spróbuje automatycznie podnieść
• load balancing czyli rozkłada równomiernie ruch podobnie jak Nginx czyli jak masz wiele kontenerów z mikroserwisem odpowiedzialnym za koszyk to kieruje ruch tak żeby każdy kontener był tak samo obciążony
• zarządzanie konfigurącją czyli zamiast wpisywać z ręki zmienne środowiskowe czy wpisywać je w docker file możesz skorzystać z Config Map i Secrets, do trzymania zmiennych konfiguracyjnych i kluczy.
• rollouts i rollbacks czyli automatyzacja wdrożeń np. możesz sobie skonfigurować, że jak wychodzi nowa wersja mikroserwisu z koszykiem i akurat jest Black Friday i masz tysiąc kontenerów z koszykiem zakupowym, to zamist zabić ten 1000 kontenerów na raz, i postawić 1000 na raz powodując awarię sklepu, Kubernetes może je zabijać i stawiać np. pojedynczo albo partiami co sprawia, że klienci nawet nie zauważą, że wyszła nowa wersja mikroserwisu.
• zarządzanie storage czyli masz dyski i automatycznie przydzielasz jakąś pamięć dyskową do kontenera gdy wstaje nowy i zabierasz gdy zabijasz stary.
• monitoring i logowanie
• rozszerzalność za pomocą np. operatorów które możesz sobie napisać w celu realizacji customowych potrzeb biznesowych
• bezpieczeństwo czyli możesz sobie deklarować polityki bezpieczeństwa, kontrolować dostęp, autoryzację i uwierzytelnienie

rjakubowski napisał(a):

Podstawowa sprawa to taka, że k8s Ci ogarnia na kilku maszynach jednocześnie, gdzie Compose i nginx na jednej.

Muszę się niezgodzić. Nginx to narzędzie właśnie umożliwiające stawianie aplikacji na wielu serwerach. Nginx po pierwsze może robić za load balancer rozkładając ruch na wiele serwerów np. backendowych. Może działać jako reverse proxy czyli jak masz np. osobny serwer na backend i osobny na frontend, to Nginx będzie ogarniał gdzie kierować ruch w zależności od żądania. Nginx ma również możliwość odpalenia z pomocą keepalived na wielu redundantych serwerach zapewniając HA czyli jak jedna instancja Nginxa padnie, to zastępują ją pozostałe. Nginx tak naprawdę nie odróżnia czy dany host to osobny serwer czy tylko kontener czyli równie dobrze możesz nginxa odpalić sobie za pomocą docker compose i zrobić reverse proxy do kontenera z backendem i kontenera z frontendem. Z kolei plik docker compose upraszcza stawianie stosu kontenerów i nie jest prawdą, że jego użycie jest ograniczone tylko do jednego hosta. W przypadku jak chesz odpalić sobie stos na wielu serwerach to uruchamiasz docker swarma, dodajesz węzły do klastra, a później po prostu:

docker stack deploy --compose-file docker-compose.yml nazwa_deploymentu

Tak jak napisał kolega Golang K8S to więcej możliwości ale i większy stopień skomplikowania.
Więcej technologii, to więcej tasków, to więcej ludzi. Czym więcej technologii tym ludzie muszą być teź mocniej ogarnięci albo lepiej porozdzielane funkcje. W większych firmach trzeba ogarniać często na raz naprawdę sporo rzeczy: wybrana chmura czyli zwykle Azure, AWS lub Google, a nierzadko jeszcze i tak część rzeczy musi być na samo hostownych, jakieś narzędzia CICD, Groovy, automatyzacji jak Ansible, K8S, często Helm, jakiś service mesh - najczęściej Istio chyba, Kafka, Elastic Stack, Grafana/Prometheus, Linux/Bash, Terraform. A każda z tych technologii to kobyła. A to tylko standardowe rzeczy. Do tego dochodzi masa niestandardowtmych rozwiązań zwykle. Ze wzrostem stacku rośnie prawdopodobieństwo, że coś może nawalić, ilość miejsc w których coś się może posypać. Rośnie też ilość zasobów potrzebnych żeby tą całą infrastrukturę utrzymać. Jak masz rozbudowane obserwability to też zwykle jakiś osobny zespół który nad tym czuwa jest potrzebny.

A trzeba pamiętać, że to wszystko w cholerę kosztuje, więc pierwsze pytanie, czy biznesowo jest to uzasadnione wszystko. Bo aplikacja przede wszystkim musi generować zyski. Taki jest jej cel. Stąd też wybór technologii powinien się zaczynać od analizy budżetu bilansu.

marian pazdzioch napisał(a):

Pisze jako adept spraw backendowych.

Próbuję zrozumieć kiedy należy używać kubernetes, kiedy można zrobić to (imho prościej dla początkujących) za pomocą docker compose a kiedy po prostu trzymać kilka instancji i loadbalancować do nich za pomocą nginx.

Kubernetes jest trudny (relatywnie) do postawienia, w każdym razie w sposób który nie będzie kopał developerów utrzymujących aplikacje na klastrze K8s. Dla pojedynczej aplikacji nie warto, nawet jeśli ma wiele instancji, jak zaczyna pojawiać się ich kilka, potem kilkanaście itd. to już lepiej mieć dowolny orkiestrator. Taki dajmy na to Nomad, ma mniejsze możliwości ale jest też prostszy. Choć prawdę mówiąc łatwiej mi odnaleźć się w świecie K8s, może z przyzwyczajenia.

Oprócz uproszczenia samego deploymentu, orkiestracja odpowiada m.in. za service discovery i rozkładanie obciążenia (działających kontenerów) na worker node'ach. To nawet ważniejsze, niż robienie deploymentu przez YAMLa zamiast SSH.

Dla porównania, w docker-compose właściwie nie ma czego stawiać, ale i możliwości zarządzania czymkolwiek są ograniczone. Compose używam właściwie wyłącznie do zdefiniowania sobie prostego, lokalnego środowiska do testów i developmentu, nigdy jako narzędzie do deploymentu - choć w przypadkach za prostych na Kubernetesa pewnie by się sprawdził

Stawianie kilku instancji (ale jak, ręcznie?) i samodzielne spinanie z load balancerem to już jest poziom, na którym bym się zastanowił nad jakimkolwiek IaC, choćby najprostszym, i automatyzacją.

Jeśli to jedna aplikacja i nie opłaca się robić pod to klastra K8s, ani nawet babrać w docker-compose, rozważ jakiś prosty playbook Ansible, w którym zdefiniujesz sobie taki deployment w kodzie, i dorzucisz konfigurację z listą serwerów na których ma działać aplikacja, serwer dla load balancera, itd. itd. a Ansible przeprowadzi instalację według instrukcji, np. załaduje binarkę i dorzuci usługę do systemd. Kiedyś zrobiliśmy tak automatyzację w labie, gdzie na fizycznych serwerach chodziły Gitlab runnery, a ręczne zarządzanie rosnącą liczbą runnerów było nieefektywne. Ansible spodobał mi się o tyle, że na zarządzanych przez niego serwerach nie trzeba instalować nic, żadnych daemonów ani agentów - wystarczy dostęp po SSH.

Dla mnie taka ogólna zasada - jeżeli chmura, to kubernetes. Docker to konieczność odpalenia jakiejś VM, pilnowanie uaktualnień itd. Moim zdaniem masa energii psu w d... Bare metal dla mnie odpada właściwie z założenia. W dzisiejszych czasach nie widzę żadnych korzyści z posiadania jakiegoś serwera z systemem operacyjnym, który ma konflikty jakichś bibliotek, ktoś na nim coś tam grzebnął i nikt nie wie co, a aplikacja przestała działać i trzeba tydzień poświęcić, żeby znaleźć jakiś kwiatek typu dodana zmienna środowiskowa, która coś zrąbała. Docker compose właściwie jedynie lokalnie, bo można w moment odpalić środowisko lokalne, a k8s do uruchamiania na pojedynczej maszynie nadaje się tak 2/10.

Odnośnie złożoności Kubernetesa to fajny komentarz padł niedawno na Hacker News: https://news.ycombinator.com/item?id=41332979
"simple/complex" is not the right paradigm. The real SRE controversy is "unique/standard"

I wydaje mi się to w 100% zgodne z moim doświadczeniem. W jednym projekcie mam (między innymi ofc) statyczną stronę odpaloną na Kubernetesie, serwuje plik który zmienia się czasami. Ktoś powie - idiotyzm, można wrzucić index.html na wirtualkę przez scp i praktykant z technikum zrozumie o co biega, po co ta cała zabawa z deploymentem, podem, servicem, ingressem i pierdylionem kontrolerów naokoło? No właśnie - po to, żeby mieć standardowy sposób wdrażania czegokolwiek. Nawet kosztem skomplikowania, ostatecznie wychodzi się na plus.

kelog napisał(a):

Odnośnie złożoności Kubernetesa to fajny komentarz padł niedawno na Hacker News: https://news.ycombinator.com/item?id=41332979
"simple/complex" is not the right paradigm. The real SRE controversy is "unique/standard"
[...] No właśnie - po to, żeby mieć standardowy sposób wdrażania czegokolwiek. Nawet kosztem skomplikowania, ostatecznie wychodzi się na plus.

Jeśli już masz klaster K8s na którym uruchamiasz aplikacje, IMO absurdem byłoby wrzucanie jakichkolwiek aplikacji gdzie indziej niż na klaster (lub jeden z klastrów, jeśli masz więcej) - nawet, jeżeli to "tylko" statyczna strona. Właśnie z powodów, które wymieniłeś - nie chcemy mieć sytuacji, gdy zapytany o jakąś aplikację rzucasz kostką i wypada jedna z iluś metod wdrożenia:

1. Kubernetes
2. Systemd na bare metal w data center
3. Docker swarm
4. Uruchomione z palca, na pececie pod czyimś biurkiem
5. AWS ECS
6. AWS EC2 z systemd albo i bez
7. Azure AppService

Natomiast jeżeli nie ma zupełnie nic, a chcesz postawić coś prostego, rozpoczynanie od stawiania Kubernetesa wydaje mi się lekką przesadą. Lepiej już postawić w mniej czasochłonny sposób, a jeśli będzie widać, że potrzeba istnieje, to zacząć przygotowywać klastry i z czasem przenieść zasoby do klastra.