Vlákno názorů k článku MicroK8s: tři roky zkušeností s Kubernetes v Ubuntu od sarimak - Ahoj, dik moc za clanek! Taky jsem pred...

Ahoj, dik moc za clanek! Taky jsem pred casem zkousel si hrat s microk8s v nadeji, ze to bude jednoduchy zpusob jak si otestovat, ze pomoci YAML manifestu pujde nasadit par aplikacnich podu do k8s a to vse lokalne (je mi jedno, jestli mam v k8s ingress, staci kdyz moje service v podu najede a komunikuje s jinou moji service v jinem podu) -- a vzdal jsem to, protoze mi to prislo zbytecne slozite a hluboko zanorene do snap ekosystemu.

Nastesti jsem narazil na k3s (https://k3s.io) -- nebo spis na jeho variantu zabalenou dovnitr Docker containeru, k3d (https://k3d.io). Jelikoz Docker stejne provozuju (na nahozeni postgresu pres trivialni compose), prijde mi to jako jednodussi varianta.

GUI nepouzivam, na vsechno co v k8s potrebuju delat mi staci k9s TUI (logy, port forwarding, shell, kontrola env promennych) nebo kubectl (apply a delete nad YAML manifestama).

Druha vec ve ktere jsem se pri prvnich krocich v k8s svete ztracel bylo mnozstvi resources, ze kterych jsem si pro svoji microservice nedovedl vybrat. Pokud to nekdo budete resit, zacnete u `Service` (ten defaultni typ, co se mu v k8s svete rika `ClusterIP`) a `Deployment` -- pro obycejnou webovou sluzbu typu FastAPI v Pythonu to bohate staci. Maji pouzitelnou dokumentaci primo na webu k8s.

Treba se to nekomu bude hodit, az bude delat prvni krok od Docker/compose ke Kubernetes...

9. 10. 2024, 09:39 editováno autorem komentáře

Ano presne tak aj ja pouzivam k3s ale priamo nainstalovane pod wsl. Dovod bol ze rancher dekstop alternativa k docker desktop (licencia docker desktop a limit obratu do 10 mil) pri kubernetes clustery pre nieco vyuzivala o dost viac pamete ako spustenie priamo pod wsl2.

Po zkušenostech s WSL bych raději použil jiný hypervizor.
1. WSL má jeden sdílený síťový adaptér pro všechny distribuce včetně výchozího rozhraní eth0.
To znamená, když na jedné distribuci upravíte rozhraní, tak se automaticky sdílí okamžitě všem distribucím.
Což může být na jednu stranu výhodou, ale na druhou stranu to komplikuje nastavení sítě při provozů více uzlů.
Na WSL jsem zvolil variantu vytvoření virtuálního dummy rozhraní pro každý uzel a striktním povolením rozsahu ip adres.
Každá distribuce pak používala ven výchozí bránu eth0 , ale pokud se volal uzel dovnitř, tak tam byla definovaná specifická adresa pro uzel.
Tím pádem lze provozovat více uzlů na na více distribucích současně.
Stejně tak fungovala i komunikace mezi uzly(distribucemi) a každý měla svou unikátní adresu pro kubernetes cluster.
Určitě doporučuji namapovat na WSLku dns přes nějakou službu a nebo vlastní automatizaci, protože dhcp přiděluje nové ip adresy, tuším při každé reinstalaci.
Celkem hardcore SETUP, ale funguje to, mám na to hotovou automatizaci.

2. Všechny WSL distribuce sdílí resources a neumí je přidělovat jednotlivým distribucím specificky. Aktuálně umí pouze alokaci ram a cpu pro všechny distribuce současně.
Na github proběhla už před rokem diskuze na toto téma, ale zatím od Microsoftu žádný update.
Což svým způsobem nemusí vadit, ale přeci jen je lepší pro produkční prostředí, když daná distribuce nemůže vyčerpat zdroje jiným distribucím. Takže to beru jako velký fail. Jde to samozřejmě ošetřit nějakou službou na každé distribuci, ale to je už obcházení nedostatku.
Zajímavě tento nedostatek obešel například projekt Podman, který je opensource a není licencovaný. Běží na něm rancher. Popravdě jsem nezkoumal jak přesně mají ty zdroje udělané, ale jde to škálovat na machines, ale ty zdroje bude hlídat pravděpodobně nějaká služba na pozadí.

3. Pokud používáte WSL, automaticky přicházíte o možnost vnořené virtualizace na dané distribuci, protože WSL v současné době neumožňuje vnořenou virtualizaci. To samé na Windows neumožňuje ani Hyper-V. Pro vnořenou virtualizaci je nutný jiný Hypervizor jako je virtualbox a nebo vmware. Je nutné mít vypnuté na výchozí windows instanci features hyper-v,windows sub system linux, a virtal machine platform.

Vnořená virtualizace je super věc a díky ní můžete například používat kvm, xen na jednotlivých linuxových instancích a vložit kubernetes cluster do vyšší vrstvy.

“ale přeci jen je lepší pro produkční prostředí” - ja mel za to, ze wsl je apise pro vyvoj a ne pro produkci, tech omezeni vuci produkcnim hypervisorum je docela dost.

To máte pravdu. Je to více vývojářské prostředí, ale pro produkci ho lze použít také. Asi záleží, do jaké vrstvy a za jakým účelem by ho kdo chtěl použít. Co se testování WSL týče, tak je vysoce stabilní.

Nasazení nové distribuce formou importu je okamžité v řádu vteřin.
Je to specifická vrstva kontejnerizace a lze ji použít k nasazení specifických služeb, které jsou izolované.

Chci WSL otestovat ještě ve variantě:
baremetal(Windows) -> vmware -> (Linux) -> libvirt -> (Windows Server) -> WSL(Linux) -> Kubernetes

Chci otestovat chování různých kombinací vnořených virtualizací a jak to v závěru zatíží jednotlivé vrstvy a kolik bude v jednotlivých variantách ztrát na výkonu cpu, ram a jaké jsou možnosti přetížení a stability.

Hmm, zkušenosti z přechodu od 'docker compose' ke 'k8s' by se hodil. ;-)