Mam aplikację w Javie w Springu, która nie jest mikroserwisami (monolit, tylko część aplikacji wydzielona do osobnego serwisu). Mam to na Dockerze (+ baza i kilka innych rzeczy), razem to wszystko spięte w Docker Compose.
Czy jest mi do czegoś przydatny Kubernetes?
Bo nie znam go i nie wiem po co mi on, ale niektórzy się uparli, żeby robić to na Kubernetesie. Bo niby tak wszyscy robią, bo modne, bo jest w ofertach pracy, bo niby wygodniej, bo Docker Compose to g*wno itd.
Ja mam rację, że powinienem sobie darować Kubernetesa czy oni mają rację, że ja jestem staroświecki i powinienem się dokształcić?
@badAttitude: dwa Javowe, baza i jeszcze ze dwa narzędzia. Razem wyjdzie z 5 kontenerów. Może za jakiś czas będę skalował jeden serwis to będzie może +2 kontenery.
@mk321: do tego raczej nie, kubernetes jest ciężki do nauki i zużywa trochę zasobów. Porównanie Docker Compose i Kubernetesa mija się z celem, to tak jakbyś porównał rower do samochodu. Poza odpalaniem wielu aplikacji na raz masz też takie ficzery jak skalowanie, wielu hostów, networking
@mk321: kubernetes służy do zarządzania klastrem z kontenerami. Przypadek z klastrem, który ma tylko jeden node, raczej sensu innego niż development nie ma (minikube).
Produkcyjnie nie chciałbyś korzystać z docker-compose, uwierz mi.
@mk321 to nie potrzebny Ci kubernetes, super narzędzie ale jak masz dziesiątki czy setki microservicow. Powiedz kolegom że armata na muchę ich rozwiązanie, więcej czasu zejdzie z konfiguracją tego wszystkiego niż pożytku. I ogólnie pamiętaj że baza na docker to złe rozwiązanie produkcyjne.
@mk321: Jeżeli starcza Ci to co masz i znasz, używaj tego co masz i znasz :) Kubernetes jest dobry, jeżeli potrzebujesz na produkcji elastycznie skalować swoją aplikację, możesz dynamicznie zwiększać/zmniejszać ilość podów, czyli kontenerów zawierających Twój program, bazę, redisa itd. bez wyłączania aplikacji.
Generalnie i upraszczając:
- docker-compose dobry dla developmentu, łatwo się korzysta i łatwo nauczyć - kubernetes dobry na produkcje, nieco trudniejszy do nauczenia i skonfigurowania, umożliwia elastyczne
@Saly: @globalbus: to jak produkcyjnie powinienem wdrażać tą aplikację? Obecnie wdrażana jest bez Dockera. Tzn. ręcznie odpalane jary, stawiana baza itd. Ale developersko, żeby było jednym skryptem to mamy Dockera i każdy sobie odpala wszystko naraz Docker Compose. Chciałem, żeby tak samo z Docker Compose było odpalane na produkcji. To złe podejście? Powinien być postawiony Kubernetes?
Czy developerom coś to zmienia? Jak mieliśmy aplikację bez Dockera i chcieliśmy
@badAttitude: @jeffery: jedni mówią, powinno być wszystko na Dockerze, inni mówią, że baza poza Dockerem, a jeszcze inni, że baza na Dockerze ale z podpiętym folderem na dane. Jak z tą bazą się powinno robić? Jak wszystkim zarządza Kubernetes (lub Docker Compose) to serio baza powinna być oddzielona i zarządzanie ręczne? Baza to jest prawie 1/3 całości mojej aplikacji. Czyli 1/3 byłaby poza Kubernetesem. To już w ogóle
@jeffery: dynamicznego skalowania na pewno nie będę miał. Przy wdrożeniu liczymy ile nodeów potrzeba i tyle uruchamiamy. Czyli jak Docker Compose to tylko do developmentu, a nie nadaje się na produkcję, a Kubernetes to armata na muchę, to na czym wdrażać na produkcję prostą aplikację na Dockerze składającą się z 4-5 kontenerów?
@mk321 baza na docker developersko czy testowo jest ok, ale docker ma też swoje narzuty dlatego produkcyjne baza powinna być na metalu ze względu na preformance.
@mk321: obowiązują podobne przykazania jak pod dockerem. Np. aplikacja nie powinna w--------ć więcej RAMu niż jej przydzielisz (inaczej będzie OOM). I że proces ma działać z PID 1, jak chcesz, aby był poprawnie zamykany. Itd, itd.
Kubernetes ma funkcjonalność rolling development, możliwość rollbacku do poprzedniej wersji itd. Jak potrzebujesz HA, to jest to fajne i wygodne. Jak jeden node padnie, to aplikacje wstaną na innym itd.
@yggdrasil: no właśnie pchany jest wszędzie ten Kubernetes na siłę. I wszyscy chcą go używać bo inni używają.
Mi się wydaje to całkowicie zbędne. Chyba że rzeczywiście bym miał prawdziwe mikroserwisy po kilkadziesiąt kontenerów, to rzeczywiście widzę problem z zarządzaniem tym. Ale ci widzę, że mówią chcą Kubernetes to nie mają tylu kontenerów.
Ale ciężko mi mówić na ten temat bo tak naprawdę nie wiem co to ten Kubernetes i po
@globalbus: Bo? Od wielu lat trzymam bazy w kontenerach produkcyjne. Dockera używam od praktycznie pierwszego release, tak samo Kubernetesa i zero problemów, a mam naprawdę duży ruch na bazach.
@yggdrasil: Jakakolwiek awaria node'a/sieci bardzo komplikuje sytuację z aplikacjami stateful. Brak dostępu do dysku, który jest sieciową abstrakcją pod Kubernetesem, to problemy. Dopóki wszystko działa, to może ci się wydawać, że to bardzo spoko opcja.
@globalbus: Kubernetes ma statefulset i przeżywa awarie sieci bez problemu. Poza tym awaria sieci to tez problem z dostępem do bazy jak jest ona poza klastrem. Ja używam produkcyjnie od lat, przeżyłem wiele awarii i sobie chwale. Zreszta jak masz ec2 to tez storage pod spodem jest abstrakcja i jakoś ludzie nie maja takich problemów jak z k8s.
@globalbus: Mam albo pojedyncza bazę i jak mi padnie node to podnosi się na innym, wtedy oczywiście tracisz połączenie na chwile. Druga metoda to klasyczny klaster, wtedy nawet lepiej, bo masz totalnie wylane na nody, jak sobie jeden zrestartujesz to nic się nie dzieje z baza.
Mam aplikację w Javie w Springu, która nie jest mikroserwisami (monolit, tylko część aplikacji wydzielona do osobnego serwisu). Mam to na Dockerze (+ baza i kilka innych rzeczy), razem to wszystko spięte w Docker Compose.
Czy jest mi do czegoś przydatny Kubernetes?
Bo nie znam go i nie wiem po co mi on, ale niektórzy się uparli, żeby robić to na Kubernetesie. Bo niby tak wszyscy robią, bo modne, bo jest w ofertach pracy, bo niby wygodniej, bo Docker Compose to g*wno itd.
Ja mam rację, że powinienem sobie darować Kubernetesa czy oni mają rację, że ja jestem staroświecki i powinienem się dokształcić?
Produkcyjnie nie chciałbyś korzystać z docker-compose, uwierz mi.
Generalnie i upraszczając:
- docker-compose dobry dla developmentu, łatwo się korzysta i łatwo nauczyć
- kubernetes dobry na produkcje, nieco trudniejszy do nauczenia i skonfigurowania, umożliwia elastyczne
Ale czy Ty potrzebujesz to nie wiem.
Obecnie wdrażana jest bez Dockera. Tzn. ręcznie odpalane jary, stawiana baza itd. Ale developersko, żeby było jednym skryptem to mamy Dockera i każdy sobie odpala wszystko naraz Docker Compose.
Chciałem, żeby tak samo z Docker Compose było odpalane na produkcji. To złe podejście? Powinien być postawiony Kubernetes?
Czy developerom coś to zmienia? Jak mieliśmy aplikację bez Dockera i chcieliśmy
Jak wszystkim zarządza Kubernetes (lub Docker Compose) to serio baza powinna być oddzielona i zarządzanie ręczne? Baza to jest prawie 1/3 całości mojej aplikacji. Czyli 1/3 byłaby poza Kubernetesem. To już w ogóle
Czyli jak Docker Compose to tylko do developmentu, a nie nadaje się na produkcję, a Kubernetes to armata na muchę, to na czym wdrażać na produkcję prostą aplikację na Dockerze składającą się z 4-5 kontenerów?
Kubernetes ma funkcjonalność rolling development, możliwość rollbacku do poprzedniej wersji itd. Jak potrzebujesz HA, to jest to fajne i wygodne. Jak jeden node padnie, to aplikacje wstaną na innym itd.
Baza na dockerze, dowolnym,
Mi się wydaje to całkowicie zbędne. Chyba że rzeczywiście bym miał prawdziwe mikroserwisy po kilkadziesiąt kontenerów, to rzeczywiście widzę problem z zarządzaniem tym. Ale ci widzę, że mówią chcą Kubernetes to nie mają tylu kontenerów.
Ale ciężko mi mówić na ten temat bo tak naprawdę nie wiem co to ten Kubernetes i po
@badAttitude: Robiles testy? Teraz to mało kto używa bare metal.
@yggdrasil: Jakakolwiek awaria node'a/sieci bardzo komplikuje sytuację z aplikacjami stateful. Brak dostępu do dysku, który jest sieciową abstrakcją pod Kubernetesem, to problemy. Dopóki wszystko działa, to może ci się wydawać, że to bardzo spoko opcja.