Názory k článku MicroK8s: tři roky zkušeností s Kubernetes v Ubuntu

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. ;-)

Používám na produkci od doby, co přidali podporu HA, a nemohu si vynachválit. Nastavení jednoduché, upgrady řeším vždy novým clusterem, který mi vytváří terraform. Aspoň vždy ověřím DR scénář :)

9. 10. 2024, 16:48 editováno autorem komentáře

Pro pochopení a správné fungování Kubernetes, je důležitá příprava Vaší instance, aby jste měli naprostou kontrolu nad celým systémem. Bude k tomu zapotřebí funkce pro intel vt-d a vt-x a pro amd-v.
Doporučení:
1. Připravte si čistou Linuxovou distribuci nazvanou control-center, nejlépe formou virtualizace.
Pro virtualizaci na Windows můžete použít WSL, Hyper-V a nebo jiný hypervizor. Doporučuji použít vmware.
Pro virtualizaci na Linux doporučuji použít /dev/kvm s nástrojem virt.
Nedoporučuji pro virtualizaci linux používat docker obrazy.
2. V případě, že je Váš výchozí systém Windows a použili jste hypervizor vmware, tak ještě před vytvořením virtualizace deaktivujte features windows subsystem linux, hyper-v a machine virtualization. Tím docílíte toho, že můžete provádět vnořenou virtualizaci na linuxové distribuci.
3. Jakmile máte připravenou čistou distribuci, proveďte zálohu pro okamžité a rychlé obnovení v případě failu.
4. Po nasazení control-center, vytvořte vnořenou virtualizaci na linuxové distribuci pomocí KVM, tím docílíte izolace vrstvy kubernetes clusteru.
Toto řešení je vhodné pro izolaci síťového rozhraní Vašeho uzlu.
Pokud máte dostatek jader a ram pamětí, tak doporučuji vytvořit DEV,TEST,PROD. Tím získáte více uzlů a můžete testovat vývoj až do produkčního prostředí.
5. Nainstalujte nástroj ansible a vytvořte ansible playbooky pro instalaci kubernetes clusteru a pro nasazování projektů.

Na github existuje mnoho hotových playbooků a případnou úpravu nebo konfiguraci můžete přízpůsobit vlastním potřebám.

Proč doporučuji toto komplikované řešení pro vývoj v kubernetes ?
Lépe porozumíte fungování kubernetes a rovnou při nasazování Vašich projektů získáte přehled o tom, jak složitá je produkce.
Použít řešení docker, docker-compose je sice fajn a tisíckrát jednodušší, ale je to strašně na hony vzdálené od produkčního prostředí a pro produkci to nedoporučuji.
Pokud chcete, aby Váš produkt běžel v moderním produkčním prostředí, je nutné mít představu o detailním fungování kubernetes.

Pro nasazování nedoporučuji používat HELM.
Helm Vám to zjednoduší, ale zase Vám úplně zkreslí možnosti konfigurace kubernetes deploymentů.
V HELM jsem se setkal s nestabilitou a při častém nasazování nedokázal zničit běžící pody. Pak vyžadoval ruční zásah a ta automatizace pro mě ztratila potenciál. Raději čisté deployments aplikované pomocí kubectl 100% stabilita, funkčnost a možnost vlastní automatizace konfigurace.

Pokud máte případné dotazy, jsem Vám k dispozici.

Wow, dakujem. Prave sa ucim K8s a idem hladat lepsi job. Tvoj prispevok beriem ako navod :).

Co to ještě doplnit o Argo CD?

Aktuálně se zaměřuji hlavně na produkční nasazení infrastruktury do vnořené virtualizace.
Argo CD pro testování pravděpodobně nasadím na vrstvu 3.
Aktuálně testuji pro produkci toto vrstvení.

Vrstva 1 - Baremetal (Windows)
Fyzická infrastruktura s deaktivovanými features - WSL, Hyper-V a Virtual machine platform.

Vrstva 2 - Fyzická síťová infrastruktura a routování

Vrstva 3 - VMware - Hypervizor (Linux)

Vrstva 4 - Virtuální síťová infrastruktura a routování.

Vrstva 5 - Vnořená virtualizace libvirt a vSphere

Vrstva 6 - Vnořená virtuální síťová infrastruktura a routování.

Vrstva 7 - Kubernetes nad úrovní vnořené virtualizace.

Vrstva 8 - Izolovaná virtuální síťová infrastruktura kubernetes a routování.

Vrstva 9 - Aplikační vrstva

Ja som nasiel jednu dost otravnu chybu, ak som rozbehol HA klaster aj s windows nodami na verzii 1.28 a vyssie tak mi na podoch na windows nodach nefungovali logy cez lens lebo certifikat na windowsovej node neobsahuje subject alternative name pre IPcku nody.

Funkcny workaround co som nasiel bol vytvorit klaster na 1.27 a potom ho upgradnut vyssie. Sice to nepregeneruje certifikaty, ale aspon to potom nekontroluje tu IPcku.