Njësia 5 / 11

Kubernetes: Manifest, Helm dhe Orkestrimi i Fuqizuar nga AI

Fitimet:

  • Aftësia për të kuptuar objektet bazë (Pod, Deployment, Service, ConfigMap, Secret, Namespace) dhe filozofinë deklarative të Kubernetes dhe për të prodhuar manifeste solide për inteligjencën artificiale
  • Aftësia për të bërë manifeste të gatshme për prodhim dhe të sigurt me kufizime burimesh, kontrolle shëndetësore (sonda), etiketa fikse të imazhit dhe RBAC të ngushtë
  • Aftësia për të verifikuar kontekstin e saktë përpara ekzekutimit dhe për të aplikuar disiplinën e vrapimit të thatë me drejtim të thatë/ndryshim

Është e lehtë për të drejtuar një enë. Por krijimi i një sistemi që shpërndan qindra kontejnerë në dhjetëra serverë, rinis automatikisht kur njëri prej tyre rrëzohet, e përsërit atë kur rritet ngarkesa dhe e përditëson me zero ndërprerje? Ky është orkestrimi dhe mjeti standard i industrisë është Kubernetes (shkurt K8s) – platforma që vendos automatikisht, shkallëzon dhe menaxhon kontejnerët nëpër një grup. Kubernetes është i fuqishëm, por kompleks: gjithçka përcaktohet nga skedarë YAML të gjatë dhe të ndjeshëm ndaj dhëmbëzimit - të quajtur manifeste. Këtu AI jep një frymë të freskët; Me kontekstin e duhur, ai shpejt prodhon këto manifestime dhe deshifron gabimet e tyre misterioze.

Por në Kubernetes, një manifestim i gabuar do të thotë të dështosh në ngritjen e një shërbimi të tërë, të shkallëzosh gabimisht ose të lërë një cenueshmëri. Është përgjegjësia juaj të kuptoni dhe verifikoni çdo manifestim që prodhon AI – veçanërisht përpara se të aplikohet kubectl.

Objektet kryesore të Kubernetes

Për të audituar Kubernetes, duhet të dini konceptet kryesore:

  • Pod: Njësia më e vogël e punës; Ai përmban një ose disa kontejnerë. Në përgjithësi, Pod nuk përdoret drejtpërdrejt, por përdoren objektet mëmë që e menaxhojnë atë.
  • Deployment: Përcakton sa kopje të një aplikacioni do të ekzekutohet, cilin imazh do të përdorë dhe si do të përditësohet. Nëse një Pod rrëzohet, ai automatikisht do ta rikrijojë atë.
  • Shërbimi: Ofron një adresë rrjeti fikse dhe balancim të ngarkesës në pods; Edhe pse pods vijnë dhe shkojnë, adresa e aksesit nuk ndryshon.
  • ConfigMap dhe Secret: Mban vlerat e konfigurimit dhe informacionin sekret të ndarë nga Pods. ConfigMap është për cilësime të qarta, Sekreti është për vlera të ndjeshme.
  • Hapësira e emrave: Zona që ndan dhe izolon logjikisht burimet (p.sh. dev, prod).
  • Hyrja: Grupi i rregullave që drejton trafikun HTTP nga bota e jashtme te shërbimet në grup.

Helm është "menaxheri i paketave" i Kubernetes: ju lejon të modeloni manifeste të përsëritura (grafikë) dhe t'i instaloni ato me vlera të ndryshme në mjedise të ndryshme me një komandë të vetme. AI prodhon si manifestin e papërpunuar ashtu edhe diagramin Helm.

Pse ka kaq shumë objekte? Sepse filozofia thelbësore e Kubernetes është deklarative: ju përcaktoni "si dëshironi që sistemi të duket përfundimisht" (p.sh. "të ketë gjithmonë 3 kopje të këtij aplikacioni në funksion"), ndërsa Kubernetes vazhdimisht e lëviz gjendjen aktuale më afër gjendjes së dëshiruar. Nëse një Pod vdes, ai krijon një të ri; nëse një nyje zbret, ajo zhvendos ngarkesën e punës në një nyje tjetër. Kjo është arsyeja pse manifestet nuk janë komanda "bëj", por receta "le të jetë kështu". Kuptimi i këtij dallimi është kritik kur lexoni manifestimet që prodhon AI: çdo fushë përshkruan një pjesë të gjendjes së dëshiruar të sistemit. Një domen i gabuar do të thotë që Kubernetes po punon drejt një qëllimi të gabuar – dhe ai synim zbatohet në heshtje dhe me këmbëngulje.

Këshillë: Në Kubernetes, mjeti më i rëndësishëm i testimit të sigurt është kubectl application --dry-run=server -f file.yaml: tregon nëse serveri do të pranojë dhe çfarë të bëjë pa aplikuar në të vërtetë manifestin. Sigurohuni që të ekzekutoni "dry-run" dhe kubectl diff përpara se të aplikoni një manifest në prod.

Hap pas hapi: Krijimi i manifesteve me AI

  1. Përshkruani kërkesën dhe nevojën. Emri i imazhit, porta, sa kopje, kufijtë e burimeve (CPU/memoria).
  2. Kërkoni vendosje + shërbim. Zakonisht të dyja kërkohen së bashku.
  3. Ndani konfigurimin dhe sekretin. Cilësimet në ConfigMap, vlerat e ndjeshme në Secret.
  4. Shtoni kontrolle shëndetësore. livenessProbe (a është drejtpërdrejt) dhe ReadinessProbe (a është gati për trafik) janë kritike.
  5. Vendosni një kufi burimi. Pa kërkesa/kufizime, një Pod mund të konsumojë të gjithë nyjen.
  6. Verifiko me "--dry-run" dhe "diff", më pas apliko. Së pari në hapësirën e emrave të testit.

Siguria: Rreziqe specifike të Kubernetes

  1. Sekreti nuk është vërtet sekret - është thjesht bazë64. Objekti Kubernetes Secret base64 kodon vlerat; Ky nuk është enkriptim, ai deshifrohet lehtësisht. Për privatësinë e vërtetë, kërkohet enkriptimi etjd dhe kasaforta e jashtme (Vault, menaxher sekret i resë kompjuterike). Asnjëherë mos bëni manifestime sekrete drejtpërdrejt në Git (ka zgjidhje për këtë, si p.sh. Sekretet e mbyllura/Sekretet e jashtme).
  2. Vendosni një kufi burimi. Një Pod pa kufij mund të prishë të gjithë nyjen me një rrjedhje memorie.
  3. Autoriteti minimal (RBAC). Me kontrollin e aksesit të bazuar në role, çdo shërbim/përdorues ka vetëm lejet që i nevojiten. AI ndonjëherë jep një grup të madh administrues; ngushtoje këtë.
  4. Mos përdorni etiketën e imazhit "të fundit". Ju nuk e dini se cili version po ekzekutohet dhe nuk mund ta ktheni përsëri.
Kujdes: fshirja e kubectl ose një aplikim i gabuar mund të shkatërrojë një vendosje të drejtpërdrejtë. Sigurohuni që të verifikoni se në cilën hapësirë ​​emri jeni (kubectl config aktual-context) përpara se të ekzekutoni komandat; Puna aksidentale është një fatkeqësi e zakonshme në kontekstin e prodhimit.

Tabela e manifestit të papërpunuar kundrejt Helm

kriteri

Manifesti i YAML i papërpunuar

Tabela e helmetit

Instalimi

kubectl zbatoj -f

instalimi i timonit

Multimedia (dev/prod)

Copy-paste, i prirur për gabime

Grafik i vetëm, vlera të ndryshme.yaml

Versioni/rikthehet

me dorë

lehtë me kthimin e timonit

Kurba e të mësuarit

të ulëta

e mesme

kur

Ambient i vogël, i vetëm

Shërbim multimedial, i përsëritur

tre mini kuti

Rasti 1 - sekreti i shërbimit të rrëzuar. Një Pod po rindizej vazhdimisht (CrashLoopBackOff). Ekipi i dha regjistrat dhe manifestin tek AI; Inteligjenca artificiale tregoi se Pod nuk u konsiderua kurrë "i gatshëm" sepse Probe gatishmërie po shikonte në portin e gabuar. E rregulluan portin, shërbimi u bë i qëndrueshëm në 10 minuta. Krijimi manual i kësaj marrëdhënieje mund të zgjasë disa orë.

Rasti 2 - mosvendosja e kufijve e theu nyjën. Nuk kishte kufizime në një vendosje; Një rrjedhje memorie fryu Pod-in dhe rrëzoi të gjithë nyjen, duke rrëzuar edhe shërbimet fqinje. Pas incidentit, ata e bënë AI të thoshte "shtoni kërkesat dhe kufijtë e arsyeshëm të CPU/memorjes për të gjitha vendosjet" dhe e bënë atë standard. Një linjë që mungon kushton orë joproduktive.

Rasti 3 - RBAC i madh i kapur. Gjatë një hetimi, një manifest i llogarisë së shërbimit të krijuar nga AI u zbulua se ishte i lidhur me rolin e administratorit të grupit - që do të thotë se shërbimi mund të menaxhonte të gjithë grupin. Ekipi ngushtoi lejen për të lexuar vetëm Pods në hapësirën e tyre të emrave. Parimi i privilegjit më të vogël mbylli një cenueshmëri sigurie.

Katër shabllone të kopjueshëm

1) Vendosja + prodhimi i shërbimit:

Shkruani një manifest të vendosjes dhe shërbimit për Kubernetes. Aplikimi: [AD], imazhi: [image: fixed-version], porta: [X], kopja: [N]. Rregullat:- Shtoni kërkesat dhe kufijtë e CPU/memorjes.- Përcaktoni livenessProbe dhe ReadinessProbe.- Lexoni konfigurimin nga ConfigMap, sekret nga objekti sekret; Mos i futni vlerat në manifest, përdorni mbajtëset e vendeve. - MOS përdorni etiketën e imazhit ": fundit". Jepni me përshkrim.

2) Zgjidhja e gabimit manifest:

Pod-i aktual është në gjendjen [CrashLoopBackOff / Në pritje / ImagePullBackOff]. Sipas manifestit të mëposhtëm dhe rezultatit 'kubectl describe', renditni shkaqet e mundshme rrënjësore sipas probabilitetit dhe lëshoni komandën e verifikimit për secilën. Manifesti: [YAML] Përshkruani: [OUTPUT]

3) Kontrolli i sigurisë/integritetit:

Kontrollo këtë manifest Kubernetes: a mungon kufiri i burimit, a mungon prob, a ka një etiketë :latest, a ka një RBAC/leje tepër të gjerë, a është sekreti i ngulitur në manifest? Shkruani gjetjet sipas rëndësisë dhe me korrigjim. Manifesti: [YAML]

4) Konvertimi në grafikun Helm:

Konvertoni manifestet e mëposhtme të papërpunuara në një tabelë Helm të ripërdorshme: cilat vlera duhet të dalin në vlerat.yaml (imazhi, kopja, burimi, mjedisi)? Shfaq strukturën e grafikut dhe vlerat e mostrës.yaml. Manifeston: [YAML]

Prompt i dobët / Prompt i fortë

I dobët: "Shkruaj Kubernetes YAML për aplikacionin tim."

Rezultati: një vendosje pa sondë, pa kufi me etiketën :last, duke futur rrafshin sekret; I pasigurt dhe i brishtë në prod.

I fortë: "Shkruaj Kubernetes Deployment + Service. Image myapp:1.4.2, 3 kopje, 8080 porte. CPU 100m-500m, memorie 128Mi-512Mi shto kërkesa/kufizime. Vendos hetimin e gjallërisë për /shëndetin. hetuesi i gatishmërisë Lexojeni objektin e fshehtë nga /re. manifestoni.

Dallimi: versioni i dytë i shpejtë jep shkallën, kufijtë e burimeve, kontrollet shëndetësore dhe rregullin sekret; Prodhimi është afër prodhimit dhe i sigurt.

Gabimet e zakonshme

  • Mos vendosja e kufijve të burimeve. Një Pod i vetëm mund të konsumojë të gjithë nyjen.
  • Mos shtimi i një kontrolli shëndetësor (sondë). Kubernetes nuk mund të zbulojë një Pod të rrëzuar/jo gati.
  • etiketa `: fundit`. Bëhet e paqartë se cili version po ekzekutohet, ai nuk mund të rikthehet.
  • Kryerja e sekretit direkt në Git. Base64 nuk është enkriptim; të gjithë e zgjidhin.
  • Ekzekutimi i komandave në kontekst/hapësirë ​​emri të gabuar. Mënyra më e zakonshme për të rrëzuar në prod.
  • duke anashkaluar `--dry-run`/`diff`. Duke mos parë se çfarë do të ndodhë përpara zbatimit.

Në përmbledhje

Kubernetes është një orkestrues i fuqishëm por kompleks që vendos automatikisht, shkallëzon dhe optimizon kontejnerët nëpër një grup; Gjithçka përcaktohet nga YAML të dukshme, të cilat Helm i shabllon. Inteligjenca artificiale prodhon shpejt manifestet e vendosjes/shërbimit dhe grafikët e Helm-it, zgjidh gabime misterioze – por duhet të kërkoni në mënyrë eksplicite kufirin e burimeve, kontrollin shëndetësor, etiketën e pandryshueshme të imazhit, RBAC të ngushtë dhe rregulla sekrete sigurie. --Dry-run, diff dhe kontrolli i saktë i kontekstit janë zakone që parandalojnë përplasjet prod.

Detyra e aplikimit

Bëni që AI të krijojë një manifest për një aplikacion mostër me shabllonin "Deployment + Service Generation". Më pas: (1) Kontrollojeni për kufirin e burimeve, hetimin, :latest dhe sekretin me shabllonin "Security/sanity check"; (2) ekzekutoni kubectl aplikoni --dry-run=server në një grup testimi/minikube nëse është e mundur dhe lexoni daljen; (3) vini re dy artikujt më kritikë të sigurisë/qëndrueshmërisë që ju mungojnë.

listë kontrolli

  • [ ] Kërkesës sime i shtova versionin e imazhit, numrin e kopjeve, portin dhe kufijtë e burimeve.
  • [ ] I shtova provë gjallërie dhe gatishmërie manifestit.
  • [ ] Etiketa e imazhit u rregullua; Nuk e kam përdorur :latest.
  • [ ] Sekreti nuk është i ngulitur në manifest; Kam përdorur objekt sekret/kasafortë të jashtëm.
  • [ ] I ngushtova RBAC/lejet në lejet minimale.
  • [ ] Përpara aplikimit, verifikova se isha në kontekstin e duhur dhe se rezultatet --dry-run/diff.