Kubernetes natív CI/CD Tekton alapokon

HUP

A Tekton egy nyílt forráskódú cloud native CI/CD eszköz, amely 2018-ban jelent meg a CNCF landscapen. Előnye, hogy a CI/CD folyamatokat Kubernetes környezetben tudjuk implementálni, K8s objektumonként. Natívan használhatjuk a cluster erőforrásait, amit a Kubernetesen futó alkalmazások is tudnak használni.

Milyen lehetőséget nyújt nekünk? Miért érdemes kubernetes nativ CI/CD környezeteket használni, építeni? Milyen problémára adhat nekünk segítséget, mire nem?

(Vigh Zoltán (Code Factory) előadása a HWSW free! meetup-sorozat 2022. május 25-i CI/CD tematikájú állomásán hangzott el.)

( asm v | 2022. 06. 16., cs – 19:31 )

Technikailag erdekes, de a hasznossagat nem igazan latom.

Szerintem elonyosebb a CI/CD automatizaciot a git repohoz kozel tartani (github, gitlab, etc.) mintsem eltolni a managelt kornyezetek iranyaba. Szerintem mindenkinek kulon EKS/AKS/GKE clustere van dev/staging/prod celokra. Akkor melyiken fusson a Tekton? Devbol deployoljunk a Prodra? Vagy minden kornyezetnek legyen sajat Tektonja? Overkill...

( dotnetlinux | 2022. 06. 16., cs – 23:28 )

Nekem is kicsit furcsa hogy a k8s-ben van leirva a sajat toolja. Jobban tetszik a kivulrol epitkezes. Ez olyan mintha az auto diagnosztikai eszkozok nem a szervizben lennenek hanem a kocsiban magaban. Van elonye, de egy oreg szaki mast mond. 

Az autos peldat azert nem erzem jonak, mert egy haztartasban tobbnyire csak 1-2 auto van es nincs cserelgetve havonta, ezert torodni kell veluk, karban kell tartani, hogy sokaig fussanak. Ellenben a managelt K8s kornyezetek (Terraformnak hala) egyre inkabb a konnyen eldobhato/cserelheto eszkozze valnak. Namarmost ha a teljes CI/CD automatizaciot a K8s-re toljuk, akkor minden K8s deploy utan meg a CI/CD infrastrukturat is ra kell masszirozni. Na ezt mar inkabb ne.

Ertem en, lehet egy dedikalt K8s cluster is a Tekton szamara, csak azzal pont nem egyszerusitunk semmit se.

( PTZool | 2022. 06. 18., szo – 15:31 )

Koszonom az eszreveteleket. Nehany dologra reagalnek. :)

A tektonnak azon a clusteren kell futni ahol szeretnenk hasznalni termeszetesen. Alapvetoen ez semmiben nem kulonbozik egy gitlab megoldastol. Ha a gitlabot szeretned integralni a k8s clusterrel, ott is futni kell egy agentnek a clusteren. (Persze fapados modon is megoldhatod ezeket a dolgokat, hogy k8s api-n keresztul deployolod az alkalmazasokat, ha CD rol beszelunk. De pl. ha a runnereket a k8sen inditod, kell neki kulon deployment)

Szerintem erdemes kette bontani a CI/CD feladatokat. Alapvetoen szo volt a dev/staging/prod clusterekrol. En itt meg a felsorolasba oda dobnam a build clustert is, mert ugy van ertelme. Build clusteren vegezzuk a build feladatokat, ez se nagyon kulonbozik a gitlab es egyeb CI megoldastol, ott runnereket futtatunk, itt annyiban van kulonbseg, hogy a build folyamat egy namespace-ben fut escalalva egy kulon clusteren es nem egy kulon gepen egy runner segitsegevel. Persze ez overkill egy bizonyos build szam alatt.

CD feladatok lenyegeben a dev/staging/prod kornyezetekben vannak, ott mar a lebuildet kesz alkalmazast kell kitenni, amihez nem feltetlenul kell a tekton neked.

A kovetkezo kerdesedet nem tudom ertelmezni @asm:  Devbol deployoljunk a Prodra?

Vegyunk egy peldat, van egy alkalmazasod, amit fejlesztenek. Egy commit hatasara elindul a build folyamat. A build folyamat soran kiesik a vegtermek (build clusteren). Lesz mondjuk egy microservice imaged es egy hozza tartozo helm chartod, amit a megfelelo repoba megtalalsz. (Ez volt a build folyamat)

Dev clusterre ki szeretned tenni ezt a microservicet, neked nincs masra szukseged mint a helm chart verziora. Erre irsz egy taskot, amit sok fele keppen triggerelhetsz. Szoval te a tasknak a kovetkezo parametereket adod. Helm chart neve, verzioja, meg mondjuk hogy melyik ns-be telepuljon ki a az alkalmazasod, itt a pipeline tartalmazhat egyeb dolgokat, de most csak foglalkozzunk a deploy feladattal.

Ezt a taskot a tobbi clusterre is kiteszed es ha prodra akarod kitenni a megfelelo verziot megirod ra a megfelelo triggert. Most hogy ez egy commit, vagy egy api post vagy akar egy piros gomb megnyomasa az mar mindegy.

Es termeszetesen a triggerek lehetnek push vagy pull iranyuak. Itt mar csak az a kerdes a security mit enged meg.

Egyebkent abban egyet ertek hogy mondjuk a gitlabbal is ugyan ezt meg lehet oldani, es ez se egy mindenre jo megoldas.

 

Mi ahol hasznaljuk, a cluster kozeli folyamatokat automatizaljuk ezzel az eszkozzel. Gondolok itt, ns letrehozas es a hozza tartozo integraciok beallitasa, ami 30-40 lepesbol all. Az elodje a folyamatnak gitlab volt, viszont sok cluster kozeli dolog kezeleset egyszerubb volt megoldani tektonnal.

Koszi a hosszu valaszt, bar meg tovabbra se tiszta, hogy pontosan milyen esetekben elonyos a Tekton hasznalata.

> Devbol deployoljunk a Prodra?

Ezt meg azelott irtam, hogy tudtam volna, hogy minden K8s-be kell Tektont telepiteni.

Kifejtened kerlek, hogy mit ertesz "cluster kozeli folyamatok/integracio" alatt? Custom CNI/CSI telepites es hasonlo dolgok?

En arra torekszem, hogy _mindent_ helm chartokba pakolok bele, ne legyenek csak ugy `kubectl apply`-ozott objektumok. NS letrehozast a helm `--create-namespace` opcioja megoldja.

Amire mi hasznaljuk "namespace" letrehozas. :) Alapvetoen, ahol mi segitunk CI/CD-t megvalositani tobb 100 fejleszto dolgozik egyszerre es tobb projekten. A namespace egy stacket jelent, igy nem csak annyi a feladat, hogy letrehozzunk egy namespacet. A stack lehet 5 de akar 50 microservice 1 ns-en belul.

Mit is ertek azon, hogy cluster kozeli folyamatok/integracio:

  • namespace letrehozas (specialis nsx-t overlay network, ingresss/egress cim beallitas)
  • namespace metadata beallitasok (annotaciok fokent)
  • namespacehez tartozo networkpolicyk letrehozasa (tobb 100 ns-rol beszelunk, minden nshez kulon networkpolicy tartozik)
  • namespace jogosultsagok letrehozasa (rolebindingok, specialis roleok (nem feltetlenul elegendo a k8s adta default roleok)), itt fokent arra gondolj, hogy a fejlesztoknek /ns jogosultsagok (ldap)
  • namespace ingress kitelepites (security elvaras)
  • nehany specialis eszkoz, amit egyebkent erdemes hasznalni, ns-be kitelepituk, igy peldaul blackbox exporter kulso tuzfalak ellenorzesere (k8s probe objektum - tcp/dns/http checkeket lehet vele ellenorizni)
  • namespace quotak beallitasa
  • specialis serviceaccount letrehozasa (deploy folyamathoz)
  • default secretek (CA, kozponti URL-ek, stb) kitetele
  • automatikus DNS letrehozas a namespace ingresshez a kozponti zonafajlban, nem a k8sen belul
  • gitlab integracio a projecthez (agent, cert, es ldap mappeles, eleg komplex, minden ldapbol vezerelve)
  • artifactory letrehozas a nshez, jogosultsagok letrehozasa, szinten ldap mappeles
  • etc.

Lenyeg, amikor mi egy ns-t letrehozunk a fejlesztok szamra minden letre van hozva nev konvencio alapjan. O nekik lenyegeben egy ldap jogot kell megkerni es megkapjak a megfelelo jogokat. Artifactory, harbor, gitlab, k8s, stb. Ezt a folyamatot vegzi a tekton. Osszesen nem is tudom de a ns letrehozas nem csak egy create ns-t jelent nalunk, hanem olyan 40-50 feladatot, mind ezt ugy hogy idempotens. Van egy tekton leiro/ns es abban vannak a parameterek, amit gitben tarolunk es ez alapjan jonnek letre a nsek es ha valtozas van ez alapjan modosul.

Remelem megvalaszoltam a kerdesed.

A helm chartos hozzallas tok jo, bar mi kezdjuk elengedni es inkabb operatorokat hasznalunk es kezdjuk elengedni a helmes telepitest. Termeszetesen nalunk is, a stackek kitelepitese helm chartal tortenik, ott egyebkent egy altalunk fejlesztett open source helm libraryt hasznalunk.

https://artifacthub.io/packages/helm/cf-common/helm-common

Sajnos a helmnek vannak hibai, ezeket probaltuk orvosolni egy library segitsegevel. Ha sok helm chart van es api verzio valtas van, akkor sajnos ezeket is modositani kell. Ez a problema 5-10 helm chartnal nem gaz, de nalunk tobb ezer van, igy egy API verzio valtas nagyon macera volt ennelkul. :) Ez a reklam helye volt. :P

Koszonom a reszleteket.

Ez azert egy meglehetosen komplex, specialis eset, amihez kellett egy automatizacio. Leirasod alapjan ez nem is igazan a tradicionalis CI/CD-rol szol, hanem az ns letrehozas koruli automatizaciorol. A K8s objektumok kezelese alapvetoen idempotens hasznalatot tesznek lehetove (yaml akarhanyszor applyozhato, csak a kulonbseg hajtodik vegre, stb.), a helm segitsegevel pedig ossze tudjuk ezeket fogni chartokba verziozva. Nyilvan ns-enkent eltero a konfiguracio (mar csak a neve miatt is), ezert template-elni kell a yaml-oket (direktben vagy helm values-on keresztul). Es itt nem tiszta, hogy ebben a Tekton miben segit. Miben mas egy ansible playbook vagy akar egy egyszeru shell scripthez (ha nehany helm chartba van a teljes konfig beletuszkolva, akkor lenyegeben `helm upgrade`-ek sorozata, ami szinten idempotens) kepest?

Node mindegy is, az mar ebbol kiderult szamomra, hogy nem egy szeleskorben hasznos eszkozrol beszelunk, ezert nem latom ertelmet, hogy jobban megismerjem. Pl. egy ArgoCD-t hasznosabb eszkoznek gondolok eteren. De azert koszi megegyszer.

Szerk.: Utolag meg annyit hozzatennek, hogy a fo kulonbseg az, hogy nalatok a K8s cluster az allando es ns-ekkel oldjatok meg a projektek kozotti szeparaciot. Mi inkabb egy uj EKS-t deployolunk, ha uj projektnek kell K8s, ebbol fakadoan az automatizaciot inkabb Terraformmal valositjuk meg.