Cześć,
Załóżmy, że mamy infrastrukturę na VMware on-premise. Aplikacje działają na gołym linuxie.
Robię konteneryzację aplikacji i uruchamiam ją w Kubernetes.
Zastanawiam się jak mamy wygląda podział takiej aplikacji. Mam np. 15 mikroservisów, 5 baz danych, 1 RabbitMQ, 2 Redisy, 1 Cassandra.
Jak ma się to do klastrów, node'ów i podów? Jak to podzielić?
0
5
Devopsem nie jestem (pomijam, że to metodyka a nie stanowisko, no ale korpo i tak wydzielają sobie devopsów i developerów), powiem co widziałem / kleciłem jako developer.
Generalnie "to zależy", ale jak masz te 15 mikroserwisów + trochę dodatkowych elementów i to jest jedna aplikacja, to raczej miałoby sens wrzucić do jednego klastra, niż dzielić na wiele mniejszych. Ewentualnie możesz myśleć o wydzielaniu namespace'ów, ale nadal zarządzasz jednym klastrem, który potencjalnie może mieć wiele VMek / serwerów pod spodem.
Czemu jeden klaster a nie więcej - k8s powinien spokojnie to ogarnąć o ile to wszystko nie funkcjonuje w ultra-turbo-dużej skali, więc trochę nie ma sensu mnożyć bytów ponad potrzebę. Poza tym - jeśli masz 1 klaster a pod nim 20 maszynek, to utrata jednej (np. w czasie restartu) robi 5% różnicy. Utrata jednej maszynki z dwóch, bo podzieliłeś całość między 10 klastrów to już utrata 50% ;)
Dotychczas z k8s miałem do czynienia w takim układzie, że klaster był dzielony między zespołami (a tym samym między mikroserwisami), każdy zespół miał swój namespace na pody, joby i inne rzeczy, natomiast osobne środowiska (deweloperskie, integracyjne etc.) były na osobnych klastrach. Ewentualnie jak zespół miał własny klaster na zupełnie inny produkt, to osobny był produkcyjny a osobny nie-produkcyjny, no i środowisko jako namespace. Tyle że infrastruktura to był EKS i/lub EC2 i/lub jakiś własny k8s postawiony na EC2, a nie VMWare on premise. No ale idea pozostaje podobna.
Co do node'ów - nie powinieneś musieć się tym martwić, to czym powinieneś się martwić to czy k8s ma dostępną odpowiednio dużą pulę odpowiednio mocnych node'ów, żeby uciągnąć to, co na nim chcesz uruchamiać i zapewnić żądane zasoby. Scheduler k8s powinien przydzielić odpowiednio zasoby (nody).
Natomiast w przypadku podów - raczej będziesz celował w deployowanie każdego komponentu w osobnym podzie, który może być skalowany (przez dorzucanie / odejmowanie replik) oddzielnie. Nie po to bawisz się w mikroserwisy, żeby wszystkie skalowały się razem i były razem deployowane jako jeden monolityczny twór, tylko rozbity na kontenerki ;) Idąc tym tokiem bazy, redisy i inne cassandry również będą raczej miały oddzielne pody.
Generalnie nie oznacza to, że nie możesz deployować wiele różnych kontenerów w jednym podzie - w zasadzie możesz, jeśli np. oprócz właściwych mikroserwisów masz dodatkowo jeszcze jakieś sidecary, workery etc. które powinny żyć blisko kontenera (ko-lokacja i te sprawy) to raczej polecą do jednego poda. W dużym uproszczeniu, jeśli coś żyje razem, releasujesz to razem, skaluje się razem i myślisz o tym jako o jednym bycie - to pewnie śmiało może być w jednym podzie. Jeśli nie - to trzymasz w osobnych.
0
@superdurszlak: uczę się dopiero i nie załapałem jeszcze dobrze koncepcji architektury rozwiązań korzystających z k8s.
Czyli jak mam 15 mikroserwisów, to powinienem stworzyć 15 podów i w te pody pakować tyle kontenerów ile mi się podoba?
3
Mniej więcej, generalnie myśl o podzie jako takiej podstawowej jednostce w k8s. Teraz pomyśl co jest Twoją jednostką - pewnie jeden mikroserwis, bo nie chcesz by były ze sobą zespawane.
Podobnie mikroserwis i jego baza - raczej nie robisz upgrade silnika bazy i mikroserwisu jednocześnie, najwyżej podbijasz wersję schematu bazy więc nie chcesz, by przy redeployu aplikacji baza też się przewracała - więc wrzucasz ją osobno (z tego co kojarzę StatefulSet z podmontowanym volume pod przechowywanie danych, żeby nie wyparowały wraz z kontenerem).