Kubernetes Manifest Linter

Манифестите на Kubernetes обикновено се преглеждат на око в заявка за изтегляне, което означава, че една и съща шепа втвърдяващи грешки продължават да стигат до производство: внедряване без ограничение на паметта, което в крайна сметка се убива от OOM и взема възел със себе си, контейнер, който щастливо работи като root, защото никой не е задал runAsNonRoot, или Pod, прикрепен към етикет на изображение като `:latest`, който тихо се променя под a внедряване. Този линтер улавя този клас проблеми в момента, в който поставите манифест, без да се нуждаете от работещ клъстер, kubectl контекст или каквито и да било идентификационни данни.

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

Таблицата с правила е моделирана на добре познати насоки за укрепване на клъстерите — CIS Kubernetes Benchmark, kube-score и Pod Security Standards „Restricted“ профил — и проверява всеки контейнер за липсващи заявки/лимити за ресурси, контейнери, които могат да работят като root или в привилегирован режим, липсващи сонди за жизнеспособност и готовност при дълготрайни работни натоварвания (Внедрявания, StatefulSets, DaemonSets), монтирания на тома на hostPath, които разкриват файловата система на хоста, използването на мрежата на хоста и невъзпроизводими `:latest` или немаркирани изображения на контейнери. Констатациите са групирани по документ и по контейнер, с ясна грешка/сериозност на предупреждението за всеки от тях, така че можете да различите кое всъщност е рисковано от това, което е просто подтик към най-добрата практика.

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