Kubernetes Manifest Linter

Kubernetes-manifester bliver sædvanligvis gennemgået med øjet i en pull-anmodning, hvilket betyder, at den samme håndfuld hærdningsfejl bliver ved med at komme til produktion: en implementering uden hukommelsesbegrænsning, der til sidst bliver OOM-dræbt og tager en node med sig, en beholder, der gladeligt kører som root, fordi ingen sætter runAsNonRoot, eller en Pod, der er fastgjort til et image-tag, som "sidst ud" ændres som "sidst." Denne linter fanger den problemklasse i det øjeblik, du indsætter et manifest, uden at have brug for en kørende klynge, kubectl-kontekst eller nogen legitimationsoplysninger overhovedet.

Under hætten indeholder den en lille håndrullet YAML-parser, der er skrevet specifikt til den realistiske undergruppe af YAML, som Kubernetes-manifester faktisk bruger: `---`-separerede dokumenter, indrykningsbaseret indlejring, `nøgle: værdi` og indlejrede bloktilknytninger, `-` sekvenselementer inklusive lister over kort, citerede og ikke-citerede bloker,>``-blokke,>`` skalarer for ting som multi-line ConfigMap værdier eller annoteringer. Der er ikke noget eksternt YAML-bibliotek involveret - parseren og regelmotoren er begge bundtet med værktøjet og kører udelukkende i din browser.

Regeltabellen er modelleret efter velkendt klyngehærdende vejledning - CIS Kubernetes Benchmark, kube-score og Pod Security Standards "Restricted"-profilen - og kontrollerer hver container for manglende ressourceanmodninger/-grænser, containere, der kan køre som root eller i privilegeret tilstand, manglende liveness og parathed-arbejdsbelastningsprober på lang-runs, Damonsets (installationer, installationer), hostPath-volumen mounts, der afslører værtsfilsystemet, værtsnetværksbrug og ikke-reproducerbare `:nyeste` eller umærkede containerbilleder. Resultater er grupperet efter dokument og efter beholder, med en klar fejl/advarselsgrad på hver enkelt, så du kan se, hvad der faktisk er risikabelt, ud fra hvad der blot er et skub i bedste praksis.

Det virker på enkelte manifester eller hele multi-dokument-filer indsat direkte fra en Helm-skabelon-gengivelse eller et "kustomize build"-output, der forstår Pod-, Deployment-, StatefulSet-, DaemonSet-, Job-, ReplicaSet- og CronJob-ressourcer. Fordi alt kører lokalt, er det sikkert at indsætte manifester, der indeholder interne tjenestenavne, reelle ressourcestørrelser eller andet, du ikke ønsker at sende til en tredjeparts API - nyttigt til en hurtig forudgående sundhedskontrol, en kodegennemgang eller bare at lære, hvordan "hærdet" faktisk ser ud i praksis.