Kubernetes Manifest Linter

Kubernetes манифестите обикновено се преглеждат на око в pull request, което значи, че едни и същи чести грешки продължават да стигат до production: Deployment без memory limit, който в крайна сметка бива OOM-kill-нат и повлича node със себе си, контейнер, който спокойно се изпълнява като root, защото никой не е задал runAsNonRoot, или Pod, закачен за image таг като `:latest`, който тихомълком се променя по време на rollout. Този linter улавя този клас проблеми в момента, в който поставите манифест, без да се нуждае от работещ клъстер, kubectl контекст или каквито и да било идентификационни данни.

Под капака включва малък собствен YAML парсер, написан специално за реалистичната част от YAML, която Kubernetes манифестите реално използват: разделени с `---` документи, влагане чрез отстъпи, `key: value` и вложени block mappings, елементи на списъци с `- `, включително списъци от асоциативни масиви, quoted и unquoted скалари, коментари, както и `|`/`>` block scalars за неща от сорта на многоредови стойности в ConfigMap или анотации. Не се използва външна YAML библиотека — и парсерът, и машината за правила са вградени в инструмента и работят изцяло в браузъра ви.

Таблицата с правила е моделирана по утвърдени насоки за укрепване на клъстери — CIS Kubernetes Benchmark, kube-score и „Restricted“ профила на Pod Security Standards — и проверява всеки контейнер за липсващи resource requests/limits, контейнери, които могат да се изпълняват като root или в privileged режим, липсващи liveness и readiness probes при дълготрайни натоварвания (Deployments, StatefulSets, DaemonSets), hostPath volume монтирания, които излагат файловата система на хоста, използване на hostNetwork, както и невъзпроизводими `:latest` или нетагирани container images. Находките са групирани по документ и по контейнер, като всяка има ясна степен на сериозност — грешка или предупреждение — така че да можете да различите действително рисковите неща от обикновени подсещания за добра практика.

Работи с единични манифести или с цели multi-document файлове, поставени директно от изхода на `helm template` или `kustomize build`, като разпознава ресурси от тип Pod, Deployment, StatefulSet, DaemonSet, Job, ReplicaSet и CronJob. Тъй като всичко се изпълнява локално, е безопасно да поставяте манифести, съдържащи вътрешни имена на услуги, реални ресурсни стойности или каквото и да е друго, което не бихте искали да изпратите към външно API — удобно за бърза проверка преди commit, за помощ при code review или просто за да научите как на практика изглежда един укрепен манифест.