‏مانیتورینگ پالیسی‌های Kubernetes با Kyverno و VictoriaMetrics

به گفتهٔ نویسنده‌ها، تو پلتفرم‌های cloud-native فقط نوشتن پالیسی کافی نیست؛ باید ببینی که واقعاً دارن رعایت می‌شن یا نه. مشکل اینه که وقتی یه admission controller — یعنی همون لایه‌ای که موقع دیپلوی درخواست‌ها رو چک می‌کنه — یه workload رو رد می‌کنه، معمولاً هیچ داشبوردی نیست که بگه چرا و چند بار این اتفاق افتاده. اینجوری پالیسی می‌شه یه جعبهٔ سیاه.

ایدهٔ اصلی مقاله اینه که خروجی همین admission webhookها رو به‌جای لاگ‌های متنی، مستقیم تبدیل کنی به متریک بلادرنگ. برای این کار Kyverno — یه policy engine مخصوص Kubernetes که پالیسی‌ها رو با YAML و CEL معمولی می‌نویسه — رو با VictoriaMetrics — یه دیتابیس سری‌زمانی سبک — ترکیب می‌کنن. نتیجه اینه که compliance رو با همون ابزاری می‌بینی که CPU و لتنسی رو باهاش مانیتور می‌کنی.

نویسنده‌ها یه فریم‌ورک پنج‌مرحله‌ای دور چرخهٔ عمر یه workload می‌سازن: پالیسی validating که نبودِ لیبل‌های اجباری رو موقع admission بلاک می‌کنه، mutating که خودش لیبل‌های جامونده رو تزریق می‌کنه، generating که موقع ساخت namespace منابع پیش‌فرض مثل ConfigMap می‌سازه، image validation که فقط اجازهٔ ایمیج‌های مورد اعتماد رو می‌ده، و delete که جلوی حذف منابع حساس رو می‌گیره.

بعد از اینکه متریک‌ها راه افتادن، هر رویداد enforcement با کوئری‌های استاندارد PromQL می‌ره رو داشبورد Grafana. مثلاً با متریک kyverno_admission_requests_total می‌شه دید چند درخواست allow و چندتا block شده. نویسنده‌ها تأکید می‌کنن که تو کلاسترهای بزرگ این متریک‌ها cardinality بالایی دارن و ابزار Cardinality Explorer کمک می‌کنه بفهمی کدوم لیبل‌ها بیشترین فضا رو می‌خورن، تا هزینهٔ ذخیره‌سازی بالا نره.

نکات کلیدی:

• Kyverno پالیسی‌ها رو با YAML و CEL استاندارد می‌نویسه، پس لازم نیست زبون تخصصی جدید یاد بگیری.
• فریم‌ورک پنج‌تا نوع پالیسی داره: validate، mutate، generate، image validation و delete.
• خروجی admission webhookها به متریک تبدیل می‌شه و با PromQL رو Grafana میاد.
• متریک kyverno_admission_requests_total تعداد درخواست‌های allow و block رو نشون می‌ده.
• VictoriaMetrics سبکه و Cardinality Explorer جلوی انفجار متریک‌های پرکاردینالیتی رو می‌گیره.