Kubernetes Manifest Linter

Kubernetes-manifest granskas vanligtvis med ögat i en pull-begäran, vilket innebär att samma handfull härdningsmisstag fortsätter att komma till produktion: en distribution utan minnesgräns som så småningom blir OOM-dödad och tar en nod med sig, en behållare som glatt körs som root eftersom ingen ställer in runAsNonRoot, eller en Pod som fästs till en bildtagg som "senast ut" ändras. Denna linter fångar den klassen av problem i det ögonblick du klistrar in ett manifest, utan att behöva ett körande kluster, kubectl-kontext eller några referenser alls.

Under huven innehåller den en liten handrullad YAML-parser skriven speciellt för den realistiska delmängden av YAML som Kubernetes-manifesterna faktiskt använder: `---`-separerade dokument, indragningsbaserad kapsling, `key: value` och kapslade blockmappningar, `- `sekvensobjekt inklusive listor med kartor, citerade och "ociterade" block,>`` skalärer för saker som multi-line ConfigMap-värden eller anteckningar. Det finns inget externt YAML-bibliotek inblandat – parsern och regelmotorn är båda buntade med verktyget och körs helt i din webbläsare.

Regeltabellen är utformad efter välkänd vägledning för klusterhärdning – CIS Kubernetes Benchmark, kube-score och Pod Security Standards "Restricted"-profilen – och kontrollerar varje behållare för saknade resursbegäranden/begränsningar, behållare som kan köras som root eller i privilegierat läge, saknade liveness- och beredskaps-arbetsbelastningssonder på långa driftsättningar, Damonsets, Damonsets. hostPath-volymmonteringar som exponerar värdfilsystemet, värdnätverksanvändning och icke-reproducerbara `:senaste` eller otaggade behållarbilder. Fynden är grupperade efter dokument och behållare, med en tydlig fel-/varningsgrad på var och en så att du kan se vad som faktiskt är riskabelt från vad som bara är en knuff med bästa praxis.

Det fungerar på enstaka manifest eller hela multidokumentfiler som klistrats in direkt från en Helm-mallrendering eller en "kustomize build"-utdata, och förstår Pod-, Deployment-, StatefulSet-, DaemonSet-, Job-, ReplicaSet- och CronJob-resurser. Eftersom allt körs lokalt är det säkert att klistra in manifest som innehåller interna tjänstnamn, verklig resursstorlek eller något annat som du inte skulle vilja skicka till ett tredjeparts-API – användbart för en snabb förutsättningskontroll, ett hjälpmedel för kodgranskning eller bara lära sig hur "härdad" faktiskt ser ut i praktiken.