Kubernetes Manifest Linter

Kubernetes-manifester blir som oftest gjennomgått manuelt i en pull request, noe som gjør at de samme herdingsfeilene stadig havner i produksjon: et Deployment uten minnegrense som til slutt blir OOM-drept og tar med seg en node, en container som gladelig kjører som root fordi ingen satte runAsNonRoot, eller en Pod låst til en imagetagg som `:latest` som endres i det stille under en utrulling. Denne linteren fanger opp slike problemer i det øyeblikket du limer inn et manifest, uten å trenge en kjørende klynge, kubectl-kontekst eller noen form for legitimasjon.

Under panseret har den en liten, håndskrevet YAML-parser skrevet spesifikt for den realistiske delmengden av YAML som Kubernetes-manifester faktisk bruker: `---`-separerte dokumenter, innrykksbasert nesting, `key: value` og nestede blokkmappinger, `- ` sekvenselementer inkludert lister med maps, quotede og uquotede skalarer, kommentarer og `|`/`>`-blokkskalarer for ting som flerlinjers ConfigMap-verdier eller annoteringer. Det er ikke involvert noe eksternt YAML-bibliotek – både parseren og regelmotoren er innebygd i verktøyet og kjører fullstendig i nettleseren din.

Regeltabellen er basert på velkjent veiledning for klyngeherding – CIS Kubernetes Benchmark, kube-score og Pod Security Standards sin «Restricted»-profil – og sjekker hver container for manglende ressursforespørsler/grenser, containere som kan kjøre som root eller i privilegert modus, manglende liveness- og readiness-prober på langvarige arbeidslaster (Deployments, StatefulSets, DaemonSets), hostPath-volummonteringer som eksponerer vertsfilsystemet, bruk av hostNetwork og ikke-reproduserbare `:latest`- eller utaggede containerimages. Funn grupperes etter dokument og container, med en tydelig alvorlighetsgrad (feil/advarsel) på hvert enkelt, slik at du kan skille det som faktisk er risikabelt fra det som bare er et vennlig dytt mot beste praksis.

Den fungerer på enkeltmanifester eller hele flerdokumentfiler limt inn rett fra en Helm-template-rendring eller et `kustomize build`-resultat, og forstår Pod-, Deployment-, StatefulSet-, DaemonSet-, Job-, ReplicaSet- og CronJob-ressurser. Fordi alt kjøres lokalt, er det trygt å lime inn manifester som inneholder interne tjenestenavn, reell ressursdimensjonering eller annet du ikke ville sendt til et tredjeparts-API – nyttig for en rask pre-commit-sanitysjekk, som hjelp i en code review, eller bare for å lære hvordan «herdet» faktisk ser ut i praksis.