قابل مشاهده‌سازی Policy as Code

به گزارش از وبسایت cncf

پروژه‌های CNCF در این مطلب که توسط Diana Todea (رئیس مهندسی روابط توسعه‌دهنده، VictoriaMetrics) و Cortney Nickerson (جامعه در Kyverno) تهیه شده است، مقایسه‌ای میان فرزندپروری و مدیریت رفتار برنامه‌ها در پلتفرم‌های ابری بومی ارائه می‌دهد. همان‌طور که کودکان برای رشد سالم به مرزها و قوانین نیاز دارند، برنامه‌ها نیز بدون چارچوب‌های مشخص نمی‌توانند به‌درستی عمل کنند. هیچ برنامه‌ای ذاتاً «خوب» یا «بد» نیست؛ آنچه تعیین‌کننده است، رفتارهایی است که توسط قواعد و محافظ‌ها شکل می‌گیرند.

در دنیای فناوری، مفهوم Policy as Code نقش همان نرده‌های حمایتی را ایفا می‌کند: تعیین می‌کند برنامه‌ها چگونه باید عمل کنند، به چه منابعی دسترسی داشته باشند و چگونه در مقیاس با حفظ سرعت نوآوری مطابق‌سازی شوند. تیم‌های مهندسی پلتفرم، همچون والدین، از سیاست‌ها برای هدایت رفتار برنامه‌ها و تشویق تصمیم‌گیری ایمن و مسئولانه استفاده می‌کنند.

اما تعریف قوانین کافی نیست؛ لازم است بتوانیم نظارت کنیم که آیا این قوانین اجرا می‌شوند، کجا شکست می‌خورند و آیا اثرات جانبی نامطلوب ایجاد می‌کنند یا خیر. بدون قابلیت مشاهده در زمان واقعی، اجرای سیاست‌ها ممکن است به یک جعبه سیاه تبدیل شود و شناسایی پیکربندی‌های نادرست، شکاف‌های انطباق یا موانع بهره‌وری توسعه‌دهنده پیش از تأثیرگذاری بر محیط تولید دشوار گردد.

اینجاست که Policy as Code با Observability ترکیب می‌شود. همان‌طور که والدین برای ارزیابی عملکرد قوانین به بازخورد نیاز دارند، تیم‌های پلتفرم نیز به بینش مداوم در مورد نتایج سیاست‌ها در سراسر خوشه‌ها احتیاج دارند. ادغام Kyverno (یک موتور خط‌مشی بومی Kubernetes) با VictoriaMetrics (یک راه‌حل نظارتی متن‌باز) می‌تواند نقاط کور سیاست را از بین ببرد و دید یکپارچه‌ای از انطباق و سلامت سیستم فراهم کند؛ بدین ترتیب حاکمیت در مقیاس افزایش می‌یابد بدون آنکه دید یا سرعت توسعه‌دهنده تضعیف شود. 📊

اهمیت این موضوع از منظر سازمانی: به طور تاریخی، امنیت خوشه و قابلیت مشاهده زیرساخت اغلب در سازمان‌ها به صورت دو سیلو جدا عمل کرده‌اند؛ تیم‌های امنیتی قوانین را تدوین می‌کرده‌اند و تیم‌های observability داشبوردها را می‌ساخته‌اند. این چارچوب با در نظر گرفتن اجرای سیاست به‌عنوان منبع تله‌متری، این پویایی را تغییر می‌دهد: به‌جای تکیه بر لاگ‌های غیرفعال و متن‌محور برای کشف علت شکست استقرار، وب‌قلاب‌های کنترل پذیرش مستقیماً به جریان‌های متریک بلادرنگ تبدیل می‌شوند و سیاست را به‌عنوان داده در دسترس ابزارهای نظارت قرار می‌دهند.

چطور این رویکرد اصطکاک را کاهش می‌دهد: توسعه‌دهندگان معمولاً کنترل‌کننده‌های پذیرش را به‌صورت موانع ناگهانی و بدون توضیح تجربه می‌کنند. با آشکارسازی متریک‌های سیاست در داشبوردهای مشترک Grafana، تیم‌ها فوراً متوجه می‌شوند کدام قوانین در کدام قسمت از خوشه شکست می‌خورند و به این ترتیب امنیت از یک مانع به بازخورد سلف‌سرویس تبدیل می‌شود. 🔒

سادگی مدیریت با Native Tooling: نیازی به یادگیری زبان‌های تخصصی سنگین نیست. Kyverno به طور کامل بر استاندارد YAML و CEL تکیه دارد و VictoriaMetrics به‌صورت بومی از پرس‌وجوهای PromQL پشتیبانی می‌کند؛ بنابراین متخصصان می‌توانند بدون نیاز به دانش عمیق اختصاصی، سیاست‌ها را تغییر دهند یا داشبوردها را تنظیم کنند.

کاهش سربار هزینه‌ای: خوشه‌های پرترافیک می‌توانند هزاران درخواست پذیرش در دقیقه تولید کنند. سیستم‌های نظارتی سنتی ممکن است برای ذخیره این متریک‌های با کاردینالیته بالا هزینه و مصرف RAM قابل‌توجهی ایجاد کنند. استفاده از یک باطن سری زمانی کارآمد مانند VictoriaMetrics تضمین می‌کند که تیم‌ها دید جامعی از سیاست‌ها داشته باشند بدون تحمیل هزینه‌های ذخیره‌سازی بالا.

چالش‌های عملیاتی که حل می‌شوند:

1. حذف سربار زبان تخصصی: اتخاذ Policy as Code اغلب به زبان‌های غیر بومی نیاز دارد که منحنی یادگیری ایجاد می‌کند و فقط عده‌ای می‌توانند قوانین را بنویسند یا مدیریت کنند. Kyverno این مشکل را با استفاده از YAML و CEL برای مدیریت سیاست‌های Kubernetes حل می‌کند.

2. مدیریت مقیاس‌پذیری متریک‌های با کاردینالیته بالا: ردیابی هر درخواست پذیرش و شکست اعتبارسنجی می‌تواند حجم عظیمی از نقاط سری زمانی تولید کند. VictoriaMetrics یک پایگاه داده سری زمانی است که می‌تواند میلیون‌ها نقطه داده را با سربار حافظه کم پردازش کند. رابط Cardinality Explorer آن به تیم‌ها کمک می‌کند برچسب‌هایی را که بیشترین فضا را اشغال می‌کنند شناسایی کنند تا زیرساخت نظارتی کارآمد باقی بماند.

3. جلوگیری از مشاهده سطحی برای قوانین اجرا شده: اجرای سیاست گاهی به‌صورت یک دیوار نامرئی عمل می‌کند که توسعه‌دهنده را از علت یک رد شدن بی‌اطلاع می‌گذارد. این معماری با ارسال تله‌متری موتور سیاست به داشبوردهای بلادرنگ، ردیابی چرایی و فراوانی تخلفات را ممکن می‌سازد.

فاز 1: استقرار معماری — ابتدا Kyverno را برای کنترل پذیرش نصب کنید و سپس VictoriaMetrics را به‌عنوان پشتیبان سری زمانی راه‌اندازی کنید.

فاز 2: پیکربندی vmagent برای خراش دادن endpoint متریک Kyverno (پورت 8000) و ارسال نقاط داده به VictoriaMetrics، تا تله‌متری به‌صورت مستقیم جمع‌آوری شود. برای نمونه، یک فرمان نصب vmagent به‌گونه‌ای پیکربندی می‌شود که remoteWrite را به آدرس VictoriaMetrics هدایت کند و scrape interval را تنظیم نماید.

--install vmagent victoriametrics/victoria-metrics-agent 
--set 'remoteWrite[0].url=http://vm-victoria-metrics-single-server.default.svc.cluster.local:8428/api/v1/write' 
--set 'scrape_interval: 10s' 
--set 'scrape_configs:
 - job_name: kyverno
   metrics_path: /metrics
   static_configs:
   - targets:
     - kyverno-svc-metrics.kyverno.svc.cluster.local:8000' 
--set 'podLabels.environment=demo' 
--set 'podLabels.team=observability'

curl http://localhost:8429/targets
# انتظار می‌رود پاسخ شامل target حالت=UP و متریک‌های مربوط به اهداف باشد

استقرار نمونه‌های برنامه «خوب» و «بد» نشان می‌دهد که چگونه انتظارات روشن می‌تواند رفتار را هدایت کند. مثلاً برنامه‌ای که برچسب‌های Kubernetes لازم را ندارد، باعث از دست رفتن متادیتا، طبقه‌بندی نامشخص منابع و فقدان مالکیت می‌شود که روی قابلیت مشاهده، تخصیص هزینه، حاکمیت و واکنش به حادثه تأثیر می‌گذارد.

apiVersion: برنامه‌ها/نسخه 1
نوع: فراداده
استقرار:
  نام: مشخصات برنامه بد
  کپی‌ها: 2
  انتخابگر:
    matchLabels:
      برنامه: الگوی برنامه بد
  فراداده:
    برچسب‌ها:
      برنامه: برنامه بد
      برنامه-شناسه-تصادفی: "12345"
  مشخصات:
    کانتینرها:
    - نام: nginx
      تصویر: nginx

apiVersion: apps/v1
نوع: فراداده
استقرار:
  نام: فضای نام برنامه خوب
  مشخصات:
    نسخه‌ها: 2
    انتخابگر:
      matchLabels:
        برنامه: الگوی برنامه خوب
  فراداده:
    برچسب‌ها:
      برنامه: محیط
      تیم: نمایشی
  مشخصات پلتفرم:
    کانتینرها:
    - نام: nginx
      تصویر: nginx

رابط کاربری VictoriaMetrics از طریق port-forwarding در Kubernetes در دسترس قرار می‌گیرد. Kyverno وضعیت سیاست‌ها را بازمی‌گرداند و VictoriaMetrics (vmui) به متریک‌های جمع‌آوری‌شده دسترسی می‌دهد تا تأیید شود داده‌ها جذب شده و Kyverno به‌درستی خراشیده می‌شود.

kubectl port-forward svc/vm-victoria-metrics-single-server 8428:8428
kubectl port-forward -n kyverno svc/kyverno-svc 8000:8000

چارچوب چرخه‌عمر پنج خط‌مشی: برای فراتر رفتن از اجرای ساده و قابل مشاهده کردن رفتار سیاست‌ها، یک چارچوب ساختاریافته معرفی می‌شود که کل چرخه حیات یک منبع را پوشش می‌دهد. به‌جای نگاه کردن به سیاست‌ها به‌عنوان قواعد جدا، آن‌ها را به‌عنوان جریان پیوسته‌ای از تصمیم‌ها و رویدادها مدل‌سازی می‌کنیم که قابل پیگیری، اندازه‌گیری و مرتبط‌سازی هستند.

1. اعتبارسنجی خط‌مشی — نمونه‌ای از خط‌مشی‌ای که وجود برچسب‌های اجباری را تأیید می‌کند. این اعتبارسنجی در زمان پذیرش اجرا می‌شود تا هر درخواست استقرار قبل از ذخیره در etcd ارزیابی شود و از انتشار پیکربندی نامناسب جلوگیری نماید.

apiVersion: kyverno.io/v1
نوع: ClusterPolicy
نام: required-observability-labels
spec:
  validationFailureAction: enforce
  background: false
  rules:
  - name: match-required-labels
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "Missing required observability labels: app, env, team"
      pattern:
        metadata:
          labels:
            app: "?*"
            env: "?*"
            team: "?*"

2. خط‌مشی جهش (Mutate) — برای کاهش اصطکاک توسعه‌دهنده، می‌توان خط‌مشی‌ای تعریف کرد که برچسب‌های مورد نیاز را هنگام ایجاد منبع به‌صورت خودکار تزریق کند و تجربه توسعه را مختل نکند.

apiVersion: kyverno.io/v1
نوع: ClusterPolicy
metadata:
  name: add-safe-observability-labels
spec:
  rules:
  - name: add-labels-to-pods-only
    match:
      resources:
        kinds:
        - Pod
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            app: "default-app"
            env: "demo"
            team: "observability"

با این فرایندها، Kyverno امکان کنترل و اعمال قوانین را می‌دهد و VictoriaMetrics داده‌های تله‌متری را به شکلی کارآمد ذخیره و قابل پرس‌وجو می‌سازد. ترکیب این دو کمک می‌کند تا سیاست‌ها قابل مشاهده، اندازه‌گیری و قابل اقدام شوند؛ که در نهایت به کاهش اصطکاک توسعه‌دهندگان و بهبود حاکمیت در مقیاس منجر می‌شود. 🚀