Enhet 5 / 11

Kubernetes: Manifest, Helm och AI-driven orkestrering

Vinster:

  • Förmåga att förstå de grundläggande objekten (Pod, Deployment, Service, ConfigMap, Secret, Namespace) och deklarativa filosofin för Kubernetes och producera solida manifest för artificiell intelligens
  • Möjlighet att göra manifest färdiga för produktion och säkra med resursbegränsningar, hälsokontroller (sonder), fasta bildtaggar och smala RBAC
  • Förmåga att verifiera korrekt sammanhang innan utförande och tillämpa torrkörningsdisciplin med torrkörning/diff

Det är lätt att köra en container. Men att etablera ett system som sprider hundratals behållare över dussintals servrar, startar om automatiskt när en av dem kraschar, replikerar det när belastningen ökar och uppdaterar det med noll driftstopp? Det är orkestrering, och industristandardverktyget är Kubernetes (K8s för kort) – plattformen som automatiskt distribuerar, skalar och hanterar behållare över ett kluster. Kubernetes är kraftfullt men komplext: allt definieras av långa, indragskänsliga YAML-filer – så kallade manifests. Det är här AI ger en frisk fläkt; Med rätt sammanhang producerar den snabbt dessa manifest och avkodar deras mystiska fel.

Men i Kubernetes innebär ett felaktigt manifest att man misslyckas med att stå upp en hel tjänst, skala felaktigt eller lämna en sårbarhet. Det är ditt ansvar att förstå och verifiera varje manifest som AI producerar - speciellt innan kubectl tillämpas.

Kubernetes kärnobjekt

För att granska Kubernetes bör du känna till huvudkoncepten:

  • Pod: Minsta arbetsenhet; Den innehåller en eller flera behållare. Generellt används inte podden direkt, men de överordnade objekten som hanterar den används.
  • Distribution: Definierar hur många kopior av ett program som ska köras, vilken bild den ska använda och hur den ska uppdateras. Om en Pod kraschar kommer den automatiskt att återskapa den.
  • Service: Ger en fast nätverksadress och belastningsbalansering till poddarna; Även om poddar kommer och går ändras inte åtkomstadressen.
  • ConfigMap och Secret: Håller konfigurationsvärden och hemlig information åtskilda från Pods. ConfigMap är för explicita inställningar, Secret är för känsliga värden.
  • Namnområde: Området som logiskt delar och isolerar resurser (t.ex. dev, prod).
  • Ingress: Regeluppsättningen som dirigerar HTTP-trafik från omvärlden till tjänster i klustret.

Helm är "pakethanteraren" för Kubernetes: den låter dig malla återkommande manifest (diagram) och installera dem med olika värden i olika miljöer med ett enda kommando. AI producerar både råmanifest och Helm-diagram.

Varför finns det så många föremål? Eftersom kärnfilosofin för Kubernetes är deklarativ: du definierar "hur du vill att systemet i slutändan ska se ut" (t.ex. "har alltid 3 kopior av denna applikation igång"), medan Kubernetes kontinuerligt flyttar det aktuella tillståndet närmare det önskade tillståndet. Om en Pod dör skapar den en ny; om en nod går ner, flyttar den arbetsbelastningen till en annan nod. Det är därför manifest inte är "gör"-kommandon, utan "låt det vara så här"-recept. Att förstå denna distinktion är avgörande när man läser manifesten som AI producerar: varje domän beskriver en del av det önskade tillståndet i systemet. En fel domän betyder att Kubernetes arbetar mot ett fel mål – och det målet upprätthålls tyst, ihärdigt.

Tips: I Kubernetes är det viktigaste säkra testverktyget kubectl apply --dry-run=server -f file.yaml: det visar om servern kommer att acceptera och vad man ska göra utan att faktiskt tillämpa manifestet. Se till att köra torrkörning och kubectl diff innan du applicerar ett manifest på prod.

Steg för steg: Skapa manifest med AI

  1. Beskriv ansökan och behov. Bildnamn, port, hur många repliker, resursgränser (CPU/minne).
  2. Begär distribution + tjänst. Vanligtvis krävs båda tillsammans.
  3. Separat konfiguration och hemlighet. Inställningar till ConfigMap, känsliga värden till Secret.
  4. Lägg till hälsokontroller. livenessProbe (är den live) och readinessProbe (är den redo för trafik) är kritiska.
  5. Ställ in en resursgräns. Utan förfrågningar/begränsningar kan en Pod konsumera hela noden.
  6. Verifiera med `--dry-run` och `diff` och tillämpa sedan. Först i testnamnutrymmet.

Säkerhet: Kubernetes-specifika risker

  1. Hemlighet är inte riktigt hemligt – det är bara base64. Kubernetes Secret-objektbasen64 kodar värden; Detta är inte kryptering, det är lätt att dekryptera. För sann integritet krävs etcd-kryptering och externt valv (Vault, Cloud Secret Manager). Begå aldrig hemliga manifest direkt till Git (det finns lösningar för detta som förseglade hemligheter/externa hemligheter).
  2. Ställ in en resursgräns. En Pod utan gränser kan krascha hela noden med en minnesläcka.
  3. Minimibehörighet (RBAC). Med rollbaserad åtkomstkontroll har varje tjänst/användare bara de behörigheter den behöver. AI ger ibland stora kluster-admin; begränsa detta.
  4. Använd inte den "senaste" bildtaggen. Du vet inte vilken version som körs och du kan inte återställa den.
Varning: kubectl borttagning eller en felaktig tillämpning kan förstöra en live-distribution. Se till att verifiera vilket namnområde du befinner dig i (kubectl config aktuell-kontext) innan du kör kommandona; Oavsiktligt arbete är en vanlig katastrof i produktionssammanhang.

Rått manifest vs. Helm-tabell

kriterium

Rå YAML-manifest

Rordiagram

Installation

kubectl tillämpa -f

rodret installera

Multimedia (dev/prod)

Copy-paste, felbenägen

Enkelt diagram, olika värden.yaml

Version/återställning

för hand

lätt med tillbakarullning av rodret

Inlärningskurva

låg

medium

när

Liten enkel miljö

Multimedia, repetitiv service

tre minifodral

Fall 1 — hemligheten med den kraschade tjänsten. En Pod startade hela tiden om (CrashLoopBackOff). Teamet gav loggarna och manifestet till AI:n; AI:n visade att Pod aldrig ansågs vara "klar" eftersom beredskapsproben tittade på fel port. De fixade hamnen, tjänsten blev stabil på 10 minuter. Att upprätta denna relation manuellt kan ta timmar.

Fall 2 — att inte sätta gränser bröt knuten. Det fanns inga begränsningar i en distribution; En minnesläcka svällde Poden och kraschade hela noden, vilket också slog ner närliggande tjänster. Efter incidenten fick de AI att säga "lägg till rimliga CPU/minnesförfrågningar och gränser för alla implementeringar" och gjorde det till standard. En saknad linje kostar timmar av driftstopp.

Fall 3 — stor RBAC fångade. Under en undersökning visade det sig att ett ServiceAccount-manifest som genererats av AI var kopplat till kluster-admin-rollen – vilket innebär att tjänsten kunde hantera hela klustret. Teamet begränsade tillståndet till att bara läsa Pods i deras namnutrymme. Principen om minsta privilegium stängde en säkerhetsrisk.

Fyra kopierbara mallar

1) Implementering + tjänsteproduktion:

Skriv ett distributions- och servicemanifest för Kubernetes. Applikation: [AD], bild: [bild: fast version], port: [X], replika: [N]. Regler:- Lägg till CPU/minnesförfrågningar och begränsningar.- Definiera livenessProbe och readinessProbe.- Läs konfiguration från ConfigMap, hemlig från Secret object; Bädda inte in värden i manifestet, använd platshållare. - ANVÄND INTE bildtaggen ":senaste". Ge med beskrivning.

2) Manifest fellösning:

Den aktuella Poden är i tillståndet [CrashLoopBackOff / Pending / ImagePullBackOff]. Enligt följande manifest och 'kubectl describe'-utdata, lista de möjliga grundorsakerna i sannolikhetsordning och utfärda verifieringskommandot för var och en. Manifest: [YAML] Beskriv: [OUTPUT]

3) Säkerhets-/integritetskontroll:

Kontrollera detta Kubernetes-manifest: saknas resursgränsen, saknas den prob, finns det en :senaste tagg, finns det en alltför bred RBAC/behörighet, är hemligheten inbäddad i manifestet? Skriv resultaten i prioritetsordning och med korrigering. Manifest: [YAML]

4) Konvertering till styrdiagram:

Konvertera följande råmanifest till ett återanvändbart Helm-diagram: vilka värden ska gå ut till values.yaml (bild, replik, källa, miljö)? Visa diagramstruktur och exempelvärden.yaml.Manifests: [YAML]

Svag prompt / Stark prompt

Svag: "Skriv Kubernetes YAML för min ansökan."

Resultat: en no-probe, no-limit-distribution med :senaste taggen, inbäddning av den hemliga slätten; Osäker och ömtålig i prod.

Stark: "Skriv Kubernetes Deployment + Service. Bild minapp:1.4.2, 3 repliker, 8080 portar. CPU 100m-500m, minne 128Mi-512Mi lägg till förfrågningar/begränsningar. Sätt liveness probe för /healthz, readiness sonden för /readyed. Läs hemligheten från det hemliga objektet, skriv in den hemliga beskrivningen."

Skillnad: andra promptversionen ger skala, resursgränser, hälsokontroller och hemliga regler; Produktionen är nära produktion och säker.

Vanliga misstag

  • Anger inte resursgränser. En enda Pod kan konsumera hela noden.
  • Lägger inte till en hälsokontroll (sond). Kubernetes kan inte upptäcka en kraschad/inte klar Pod.
  • `:senaste`-taggen. Det blir oklart vilken version som körs, den kan inte rullas tillbaka.
  • Överlåter hemligheten direkt till Git. Base64 är inte kryptering; alla löser det.
  • Kör kommandon i fel kontext/namnutrymme. Det vanligaste sättet att krascha i prod.
  • hoppar över `--dry-run`/`diff`. Ser inte vad som kommer att hända innan implementering.

Sammanfattningsvis

Kubernetes är en kraftfull men komplex orkestrator som automatiskt distribuerar, skalar och optimerar behållare över ett kluster; Allt definieras av manifest YAML, som Helm mallar. AI producerar snabbt Deployment/Service-manifest och Helm-diagram, löser mystiska buggar - men du måste uttryckligen be om resursgräns, hälsokontroll, oföränderlig bildtagg, smal RBAC och hemliga säkerhetsregler. --dry-run, diff och korrekt kontextkontroll är vanor som förhindrar prod-krascher.

Applikationsuppgift

Låt AI generera ett manifest för en exempelapplikation med mallen "Deployment + Service generation". Sedan: (1) Låt den kontrolleras för resursgräns, probe, :senaste och hemlig med mallen "Säkerhets-/sanity check"; (2) kör kubectl apply --dry-run=server på ett testkluster/minikube om möjligt och läs utdata; (3) notera de två mest kritiska säkerhets-/robusthetsföremålen som du finner saknas.

checklista

  • [ ] Jag lade till bildversionen, antalet repliker, port- och resursgränser till min begäran.
  • [ ] Jag lade till livlighet och beredskapsundersökning till manifestet.
  • [ ] Bildtaggen fixerad; Jag använde inte :latest.
  • [ ] Hemlighet är inte inbäddad i manifestet; Jag använde hemligt objekt/externt valv.
  • [ ] Jag minskade RBAC/behörigheter till minimala behörigheter.
  • [ ] Innan jag ansökte verifierade jag att jag var i rätt sammanhang och att --dry-run/diff utmatar.