Kubernetes Manifest Linter

Kubernetes-manifest granskas oftast för hand i en pull request, vilket gör att samma handfull härdningsmisstag gång på gång når produktion: en Deployment utan minnesgräns som till slut blir OOM-dödad och drar med sig en nod, en container som glatt körs som root för att ingen satte runAsNonRoot, eller en Pod låst till en image-tagg som `:latest` som ändras i det tysta under en rollout. Den här lintern fångar den typen av problem så fort du klistrar in ett manifest, utan att behöva ett körande kluster, kubectl-kontext eller några som helst inloggningsuppgifter.

Under huven finns en liten egenutvecklad YAML-parser skriven specifikt för den realistiska delmängd av YAML som Kubernetes-manifest faktiskt använder: `---`-separerade dokument, indentationsbaserad nästling, `key: value` och nästlade blockmappningar, `- `-sekvenselement inklusive listor med mappningar, citerade och ociterade skalärer, kommentarer samt block-skalärer med `|`/`>` för saker som flerradiga ConfigMap-värden eller annoteringar. Inget externt YAML-bibliotek är inblandat – parsern och regelmotorn är båda inbyggda i verktyget och körs helt i din webbläsare.

Regeltabellen är baserad på välkänd vägledning för klusterhärdning – CIS Kubernetes Benchmark, kube-score och Pod Security Standards-profilen "Restricted" – och kontrollerar varje container för saknade resursförfrågningar/begränsningar, containrar som kan köras som root eller i privilegierat läge, saknade liveness- och readiness-probes på långkörande arbetslaster (Deployments, StatefulSets, DaemonSets), hostPath-volymmontningar som exponerar värdens filsystem, hostNetwork-användning samt icke-reproducerbara `:latest`- eller otaggade container-images. Fynden grupperas per dokument och container, med en tydlig fel-/varningsgrad på vart och ett så att du kan se vad som verkligen är riskabelt och vad som bara är en påminnelse om bästa praxis.

Det fungerar på enstaka manifest eller hela flerdokument-filer inklistrade direkt från en Helm template-rendering eller en `kustomize build`-utmatning, 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änstenamn, verklig resursdimensionering eller vad som helst annat du inte vill skicka till ett tredjeparts-API – användbart för en snabb sanity check före commit, som hjälp vid kodgranskning eller helt enkelt för att lära sig hur "härdat" faktiskt ser ut i praktiken.