Názory k článku Rychlé testy webu v plné palbě díky Gitlab CI a Kubernetes Ingressu

Pokud se nejedna o serial, clanek imho opomiji jednu dulezitou vec. Je nutne mit rozjety funkcni ingress controller, na ktery bude povesena bud svc typu loadbalancer (externi cloud prociser nebo treba metallb), pripadne obycejna clusterip s externi ip adresou, kterou ale musite nejak nahodit (rucne, keepalived apod).

Dale mi prijde ponekud neefektivni mit api mimo k8s cluster a resit to uvnitr k8s, protoze traffic jde do kubernetes, a odtamtud zase ven, musite mit prostupy na Vase k8s nody (pripadne naky hezky cni plugin) a vubec cele se to zeslozituje. Bud bych umistil api taktez do k8s a nebo bych routovani api resil jeste pred ingresem na urovni treba servername a externiho loadbalanceru (pokud ho mate),

Jinak ingress controler je v podstate takovy sofistikovanejsi templetator, ktery na zaklade ingress objektu vytvori nginx komfiguraci a reloadne nginx uvnitr podu.

Máte pravdu bez ingress controlleru si ingress neužijete. Myslím ale že veřejně dostupné cloudy ho běžně poskytují, minimálně v GKE k dispozici je. Konfigurace vlastního Kubernetes clusteru je obávám se mimo záběr článku, a osobně z ní seriál asi spíš tvořit nebudu, protože nerad píšu o věcech kterým skoro nerozumím.

Jinak API samozřejmě uvnitř Kubernetes clusteru mít můžete a dává to i smysl, prostě deploymentu s proxy podstrčíte adresu ClusterIP na které máte API vystrčené.

Dělal jsem obdobné řešení. Požadavky na úklid jsme měli jiné, mazání deploymentů nám pomocí nastaveného TTL hlídal Kubernetes Janitor. Některé gitové větve byly totiž u ledu opravdu dlouho :-) Na víkend vše ještě vypínal Kubernetes Downscaler, abychom ušetřili pár $$$.

kolem roku 2000 jsme doufali, ze operacni system bude reprezentovat ruzne uzivatelske systemy a ze budeme mit jedno jadro hurd, jedno linuxove jadro, jedno unixove jadro a nad tim pojede nekolik lehkych user-spaces s ruznymi tvaremi co budou vypadat jako operacni system.

dneska se to presunulo bud do vmware, ktery spousti cely system nebo na vyssi user level s dockerem a kubernetes. skoda, ze se nerozsirily jmenne prostory procesu a filesystemu, tohle by se nam hodilo (ctete o plan9).

Jmenne prostory (namespaces) se samozrejme rozsirily a prosadily, protoze kontejnery (docker, podman apod) jsou na nich defacto postavene :). Konfejner neni nic jineho nez proces obalen namespaces, cgroupama, pripadne treba selinux kontextem. Docker “jen” takovy proces vytvori, stara se o image a vubec dela vsechnu ty hezke kudrlinky kolem.

Me spis chybi informace, jak resite databaze. Aplikace vetsinou neni jen stateless a musi k sobe mit i nejakou (i vice) databazi, ktere zase nemuzou byt prazdne, ale je vhodne, aby obsahovaly nejaka testovaci data.

Clovek si rekne ok, udelam pro kazdou vetev cistou DB, k tomu nahraju nejake uvodni data / fixtures... Ale kdyz nekdo zmeni strukturu databaze, situace se zacina znacne komplikovat.

Zrovna tahle komponenta je bezestavový front-end, všecha data dostává z dalších komponent. Celé Zboží má nižší stovky komponent, několik databází a fulltextový index roztažený přes desítky serverů, a to celé kopírovat nám nedává úplně smysl. Úpravy dat většinou vyústí ve zpětně kompatibilní změny API, které se dostanou na test, a odtamtud si na něj už můžou sahat větve front-endu které je potřebují.