Kyverno بالعربي: امنع أخطاء Kubernetes قبل الـ Deploy

هتعرف هنا إزاي تمنع خطأ شائع في Kubernetes قبل ما يدخل الكلاستر: container من غير resource limits. النتيجة العملية: أعطال أقل، مراجعات أسرع، وقرار أوضح بين Audit وEnforce.

مستوى القارئ: متوسط. الافتراض إنك بتستخدم Kubernetes بالفعل، وعندك فريق بينشر YAML أو Helm charts على بيئات staging وproduction.

المشكلة باختصار

الطريقة الشائعة إن الفريق يراجع ملفات Kubernetes يدويًا في pull request. الطريقة دي بتفشل لما عدد الخدمات يزيد، أو لما chart جاهز من طرف ثالث يدخل من غير مراجعة كافية. اللي بيحصل فعلاً إن deployment صغير من غير memory limit يشتغل عادي، وبعد يوم ضغط يزاحم خدمات تانية على نفس node.

لو عندك 40 microservice وكل واحدة بتعمل deploy مرتين في الأسبوع، فأنت قدام 80 فرصة أسبوعيًا لخطأ config بسيط. حتى لو المراجعة اليدوية بتاخد 5 دقائق لكل PR، ده حوالي 6 ساعات ونصف شهريًا على فحص قابل للأتمتة.

الفكرة: Policy-as-Code بدل المراجعة اليدوية

Kyverno هو admission controller لكلاستر Kubernetes. بمعنى بسيط: أي object جديد، مثل Pod أو Deployment، يعدي على بوابة فحص قبل ما Kubernetes يقبله. لو الـ object مخالف للسياسة، Kyverno يرفضه أو يسجل مخالفة حسب الوضع اللي اخترته.

مثال قريب: عندك باب شركة عليه موظف أمن. الموظف مش بيصلح الكارت، لكنه يقرر هل الكارت صالح للدخول أم لا. Kyverno يعمل نفس الشيء مع YAML. هو لا يكتب architecture بدل الفريق، لكنه يمنع config واضح إنه خطر.

علميًا، Kyverno يستخدم سياسات declarative داخل Kubernetes، ويدعم validation وmutation وgeneration. في validation تحديدًا، تقدر تختار Audit لتسجيل المخالفة فقط، أو Enforce لمنع الإنشاء أو التحديث المخالف. هذا مذكور في توثيق Kyverno الرسمي لقواعد التحقق.

مثال عملي: امنع Pods بدون memory وCPU limits

ركز في السياسة دي. هي تمنع أي Pod في namespaces محددة لو container مفيهوش requests وlimits للـ CPU والذاكرة. ابدأ بها على staging بوضع Audit لمدة أسبوع، وبعدها حوّلها إلى Enforce لو عدد المخالفات بقى مفهوم.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-container-resources
spec:
  validationFailureAction: Audit
  background: true
  rules:
    - name: require-requests-and-limits
      match:
        any:
          - resources:
              kinds:
                - Pod
              namespaces:
                - staging
                - production
      validate:
        message: "كل container لازم يحتوي على CPU/memory requests وlimits."
        pattern:
          spec:
            containers:
              - name: "*"
                resources:
                  requests:
                    cpu: "?*"
                    memory: "?*"
                  limits:
                    cpu: "?*"
                    memory: "?*"

طبّقها بهذا الشكل:

kubectl apply -f require-container-resources.yaml
kubectl get clusterpolicy require-container-resources
kubectl get policyreport -A

بعد أسبوع، لو المخالفات اتصلحت، غيّر validationFailureAction إلى Enforce. المكسب هنا إن أي deploy مخالف هيتوقف قبل ما يضغط على node. التكلفة إن بعض الـ charts القديمة هتحتاج values إضافية، وبعض فرق التطوير هتشتكي أول يومين لأن الخطأ بقى ظاهرًا بدل ما يكون مخفيًا.

سيناريو واقعي بالأرقام

افترض إن عندك متجر إلكتروني بـ 50K زائر يوميًا، وخدمة search بتستهلك ذاكرة بشكل متذبذب. من غير limits، pod واحد ممكن يسحب 1.5GB بدل 400MB وقت indexing، فيضغط على node عليها checkout وpayment. مش لازم الخدمة تقع فورًا؛ أحيانًا تبدأ latency تزيد من 180ms إلى 900ms، وبعدها تكتشف المشكلة من التنبيهات.

بالسياسة السابقة، أي deployment جديد لازم يصرّح بالـ requests والـ limits. حتى لو الرقم مش مثالي من أول مرة، وجوده يخلي scheduler عنده معلومة أفضل، ويخلي المراجعة الفنية تدور حول رقم واضح بدل سؤال عام: هل الخدمة آمنة؟

Audit ولا Enforce؟

أفضل طريقة تبدأ بها هي Audit. ده يسمح للتطبيقات الحالية تكمل شغلها، وفي نفس الوقت يديك تقرير بالمخالفات. الـ trade-off هنا واضح: Audit لا يمنع الخطر فورًا، لكنه يقلل احتمالية تعطيل الفريق. Enforce يمنع الخطأ فورًا، لكنه ممكن يكسر deploy مهم لو السياسات لم تتدرج.

قاعدة عملية: استخدم Audit لمدة 7 إلى 14 يومًا على سياسة جديدة. لو عدد المخالفات أقل من 5 لكل فريق، حوّلها إلى Enforce. لو المخالفات أكبر من كدا، المشكلة غالبًا مش في الأداة؛ المشكلة إن standards نفسها مش واضحة للفرق.

متى لا تستخدم هذه الطريقة

لا تبدأ بـ Kyverno لو الكلاستر نفسه غير مستقر، أو لو الفريق لا يملك baseline واضح للـ resources. السياسة الصارمة فوق بنية غير مفهومة هتزود الضوضاء. كمان لو أنت على Kubernetes v1.30 أو أحدث وتحتاج validation بسيطة جدًا بـ CEL فقط، راجع ValidatingAdmissionPolicy الأصلي في Kubernetes؛ قد يكون كافيًا لبعض الحالات الخفيفة.

استخدم Kyverno لما تحتاج reporting، background scans، exceptions، أو سياسات أوسع من validation البسيطة. أما لو المطلوب شرط واحد داخلي وسهل، فالأداة الأخف قد تكون أفضل.

المصادر

• Kyverno Validate Rules: يشرح Audit وEnforce وسلوك validation.
• Kyverno ClusterPolicy Overview: يشرح ترتيب mutation وvalidation داخل السياسات.
• Kubernetes Validating Admission Policy: بديل declarative مبني على CEL ومناسب لبعض حالات validation.
• Kyverno ValidatingPolicy: يوضح الفرق بين ValidatingPolicy وValidatingAdmissionPolicy.

الخطوة التالية

افتح أكثر namespace عليه deploys متكررة، وشغّل السياسة السابقة بوضع Audit لمدة أسبوع. بعد ما تشوف PolicyReport، اختار أهم مخالفة واحدة وحوّلها إلى Enforce بدل ما تحاول تقفل كل شيء مرة واحدة.