إعداد البروكسي في مجموعات Kubernetes: دليل كامل لمهندسي DevOps

عند نشر Kubernetes في بيئة مؤسسية أو خلف جدار ناري، غالبًا ما يكون هناك حاجة إلى إعداد خادم بروكسي للوصول إلى الموارد الخارجية. هذا أمر حيوي لتحميل صور الحاويات، تحديث الحزم، والتفاعل مع واجهات برمجة التطبيقات الخارجية. في هذا الدليل، سنستعرض جميع مستويات إعداد البروكسي في Kubernetes - من تكوين العقد إلى الحاويات الفردية.

لماذا تحتاج إلى بروكسي في مجموعات Kubernetes

تعمل مجموعات Kubernetes في البيئات المؤسسية غالبًا في شبكات معزولة ذات وصول محدود إلى الإنترنت. يقوم خادم البروكسي بحل العديد من المهام الحيوية:

• تحميل صور الحاويات - يتطلب Docker Hub، Google Container Registry، والسجلات الخاصة وصولًا خارجيًا
• تحديث الحزم - تثبيت التبعيات عبر apt، yum، pip داخل الحاويات
• الوصول إلى واجهات برمجة التطبيقات الخارجية - التكامل مع الخدمات السحابية، المراقبة، والتسجيل
• الأمان - التحكم في حركة المرور، تصفية النطاقات، تسجيل الطلبات
• التخزين المؤقت - تسريع الطلبات المتكررة إلى نفس الموارد

بدون إعداد البروكسي بشكل صحيح، ستواجه أخطاء مثل "فشل سحب الصورة"، "انتهاء مهلة الاتصال" أو "الشبكة غير قابلة للوصول" عند محاولة نشر التطبيقات. هذا أمر حيوي بشكل خاص لخطوط CI/CD التلقائية، حيث تكلف كل ثانية من التوقف أموالًا.

مستويات إعداد البروكسي في Kubernetes

يتمتع Kubernetes بهندسة متعددة المستويات، ويجب إعداد البروكسي في كل مستوى حسب المهام:

يتطلب كل مستوى إعدادًا منفصلًا، ويمكن أن يؤدي تخطي أي منها إلى مشاكل. على سبيل المثال، إذا قمت بإعداد البروكسي فقط لـ Docker، ولكن ليس للحاويات، فستتمكن من تحميل الصور، ولكن التطبيقات داخل الحاويات لن تتمكن من الوصول إلى واجهات برمجة التطبيقات الخارجية.

إعداد البروكسي لـ Docker و containerd

يعد وقت التشغيل للحاويات هو العنصر الأول الذي يجب إعداده، حيث إنه المسؤول عن تحميل صور الحاويات من السجلات الخارجية. دعونا نستعرض الإعداد لكلا وقتي التشغيل الشائعين.

إعداد البروكسي لـ Docker

يجب إنشاء ملف drop-in لـ systemd لـ Docker، والذي سيضيف المتغيرات البيئية إلى خدمة Docker:

# إنشاء دليل للتكوين
sudo mkdir -p /etc/systemd/system/docker.service.d

# إنشاء ملف بإعدادات البروكسي
sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf <<EOF
[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.cluster.local,.svc"
EOF

# إعادة تحميل تكوين systemd
sudo systemctl daemon-reload

# إعادة تشغيل Docker
sudo systemctl restart docker

# التحقق من تطبيق الإعدادات
sudo systemctl show --property=Environment docker

بعد ذلك، سيتمكن Docker من تحميل الصور عبر خادم البروكسي. يمكنك التحقق من العمل باستخدام الأمر:

docker pull nginx:latest

إعداد البروكسي لـ containerd

يتم استخدام containerd في مجموعات Kubernetes الحديثة كوقت التشغيل الأساسي للحاويات. إعداد البروكسي له يختلف قليلاً:

# إنشاء دليل للتكوين
sudo mkdir -p /etc/systemd/system/containerd.service.d

# إنشاء ملف بإعدادات البروكسي
sudo tee /etc/systemd/system/containerd.service.d/http-proxy.conf <<EOF
[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.cluster.local,.svc"
EOF

# إعادة تحميل التكوين
sudo systemctl daemon-reload
sudo systemctl restart containerd

# التحقق من الحالة
sudo systemctl status containerd

تكوين البروكسي لـ kubelet

kubelet هو وكيل Kubernetes الذي يعمل على كل عقدة في المجموعة. يحتاج أيضًا إلى الوصول إلى خادم API والموارد الخارجية. يعتمد الإعداد على طريقة تثبيت Kubernetes.

للمجموعات التي تستخدم kubeadm

إذا كنت تستخدم kubeadm، قم بإعداد البروكسي عبر systemd:

# إنشاء دليل لتكوين kubelet
sudo mkdir -p /etc/systemd/system/kubelet.service.d

# إنشاء ملف بإعدادات البروكسي
sudo tee /etc/systemd/system/kubelet.service.d/http-proxy.conf <<EOF
[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,10.96.0.0/12,10.244.0.0/16,.cluster.local,.svc"
EOF

# إعادة تحميل kubelet
sudo systemctl daemon-reload
sudo systemctl restart kubelet

لـ Kubernetes المدارة (EKS، GKE، AKS)

في خدمات Kubernetes المدارة، عادةً ما يتم إعداد kubelet من خلال معلمات بدء العقد أو سكربتات بيانات المستخدم. على سبيل المثال، لـ AWS EKS:

#!/bin/bash
# سكربت بيانات المستخدم لعقد العمل في EKS

# إعداد البروكسي للنظام
cat <<EOF >> /etc/environment
HTTP_PROXY=http://proxy.company.com:8080
HTTPS_PROXY=http://proxy.company.com:8080
NO_PROXY=localhost,127.0.0.1,169.254.169.254,.ec2.internal,.cluster.local
EOF

# الإعداد لـ kubelet
mkdir -p /etc/systemd/system/kubelet.service.d
cat <<EOF > /etc/systemd/system/kubelet.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,169.254.169.254,.ec2.internal,.cluster.local"
EOF

systemctl daemon-reload
systemctl restart kubelet

لاحظ إضافة 169.254.169.254 إلى NO_PROXY - هذا هو عنوان خدمة البيانات الوصفية لـ AWS، والذي يجب أن يكون متاحًا بدون بروكسي.

إعداد البروكسي على مستوى الحاويات

حتى إذا قمت بإعداد البروكسي لـ Docker و kubelet، فلن تستخدم التطبيقات داخل الحاويات البروكسي تلقائيًا. يجب تحديد المتغيرات البيئية بوضوح في المانيفستات الخاصة بـ Kubernetes.

الإعداد عبر مانيفست النشر

أسهل طريقة هي إضافة المتغيرات البيئية إلى مواصفات الحاوية:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-company/my-app:latest
        env:
        - name: HTTP_PROXY
          value: "http://proxy.company.com:8080"
        - name: HTTPS_PROXY
          value: "http://proxy.company.com:8080"
        - name: NO_PROXY
          value: "localhost,127.0.0.1,.cluster.local,.svc,10.0.0.0/8"
        ports:
        - containerPort: 8080

استخدام ConfigMap للإعداد المركزي

لتجنب تكرار إعدادات البروكسي في كل نشر، قم بإنشاء ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: proxy-config
  namespace: default
data:
  HTTP_PROXY: "http://proxy.company.com:8080"
  HTTPS_PROXY: "http://proxy.company.com:8080"
  NO_PROXY: "localhost,127.0.0.1,.cluster.local,.svc,10.0.0.0/8"

ثم استخدم هذا ConfigMap في النشر:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: my-company/my-app:latest
        envFrom:
        - configMapRef:
            name: proxy-config

تسهل هذه الطريقة الإدارة: عند تغيير عنوان البروكسي، يكفي تحديث ConfigMap، وبعد إعادة تشغيل الحاويات، سيتم تطبيق الإعدادات الجديدة تلقائيًا.

حقن تلقائي عبر MutatingWebhook

لإضافة متغيرات البروكسي تلقائيًا إلى جميع الحاويات، يمكنك استخدام MutatingAdmissionWebhook. هذه طريقة متقدمة تتطلب تطوير خدمة webhook خاصة، لكنها تسمح بإدارة الإعدادات مركزيًا دون تغيير مانيفستات التطبيقات.

التكوين الصحيح لـ NO_PROXY

تحدد متغير NO_PROXY العناوين والنطاقات التي يجب أن تتجاوز خادم البروكسي. يعد الإعداد غير الصحيح لـ NO_PROXY هو السبب الأكثر شيوعًا للمشكلات في مجموعات Kubernetes.

استثناءات إلزامية لـ Kubernetes

يجب أن تكون العناوين والنطاقات التالية دائمًا في NO_PROXY:

مثال على التكوين الكامل لـ NO_PROXY

NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,10.96.0.0/12,.cluster.local,.svc,.default.svc,.default.svc.cluster.local,kubernetes.default.svc,kubernetes.default.svc.cluster.local

إعداد kubectl للعمل عبر البروكسي

إذا كنت تدير مجموعة من محطة عمل تقع خلف بروكسي، قم بإعداد المتغيرات البيئية لـ kubectl:

# لـ Linux/macOS - أضف إلى ~/.bashrc أو ~/.zshrc
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,kubernetes.default.svc,.cluster.local

# لـ Windows PowerShell
$env:HTTP_PROXY="http://proxy.company.com:8080"
$env:HTTPS_PROXY="http://proxy.company.com:8080"
$env:NO_PROXY="localhost,127.0.0.1,kubernetes.default.svc,.cluster.local"

بعد ذلك، سيتمكن kubectl من الاتصال بخادم API للمجموعة عبر البروكسي. تحقق من العمل:

kubectl cluster-info
kubectl get nodes

إعداد البروكسي مع المصادقة

إذا كان خادم البروكسي يتطلب مصادقة، أضف بيانات الاعتماد إلى عنوان URL:

export HTTP_PROXY=http://username:password@proxy.company.com:8080
export HTTPS_PROXY=http://username:password@proxy.company.com:8080

تشخيص وحل المشكلات الشائعة

حتى مع الإعداد الصحيح، قد تحدث مشكلات. دعونا نستعرض الأخطاء الأكثر شيوعًا وطرق حلها.

خطأ "ImagePullBackOff" عند تحميل الصور

الأعراض: لا تعمل الحاويات، تظهر الأخطاء في الأحداث "فشل سحب الصورة" أو "انتهاء مهلة الاتصال".

التشخيص:

# تحقق من أحداث الحاوية
kubectl describe pod <pod-name>

# تحقق من إعدادات البروكسي في Docker/containerd
sudo systemctl show --property=Environment docker
sudo systemctl show --property=Environment containerd

# حاول تحميل الصورة يدويًا على العقدة
sudo docker pull nginx:latest
sudo crictl pull nginx:latest

الحل: تأكد من إعداد البروكسي لوقت تشغيل الحاويات وأن نطاق سجل الصور ليس في NO_PROXY.

مشكلات في حل DNS داخل المجموعة

الأعراض: لا تستطيع الحاويات التواصل مع بعضها البعض عبر أسماء DNS (مثل service-name.namespace.svc.cluster.local).

التشخيص:

# تحقق من DNS من الحاوية
kubectl run -it --rm debug --image=busybox --restart=Never -- nslookup kubernetes.default

# تحقق من متغيرات البروكسي في الحاوية
kubectl exec -it <pod-name> -- env | grep PROXY

الحل: أضف .cluster.local و .svc إلى NO_PROXY.

بطء في الأداء أو انتهاء المهلة عند الوصول إلى واجهات برمجة التطبيقات الخارجية

الأعراض: تعمل التطبيقات ببطء أو تتلقى انتهاء مهلة عند الطلبات إلى الخدمات الخارجية.

التشخيص:

# تحقق من توفر البروكسي من الحاوية
kubectl exec -it <pod-name> -- curl -v -x http://proxy.company.com:8080 https://www.google.com

# قياس زمن الاستجابة
kubectl exec -it <pod-name> -- time curl -x http://proxy.company.com:8080 https://api.example.com

الحل: قد تكون المشكلة في أداء خادم البروكسي. ضع في اعتبارك استخدام بروكسي سكنية بموقع جغرافي قريب لتقليل التأخيرات.

أخطاء SSL/TLS عند العمل عبر البروكسي

الأعراض: أخطاء مثل "فشل التحقق من الشهادة" أو "فشل المصافحة SSL".

السبب: تقوم بعض خوادم البروكسي بتنفيذ فحص SSL (فك تشفير حركة مرور HTTPS)، مما يتطلب تثبيت الشهادة الجذرية للبروكسي.

الحل:

# إنشاء ConfigMap مع شهادة البروكسي
kubectl create configmap proxy-ca-cert --from-file=ca.crt=/path/to/proxy-ca.crt

# قم بتركيب الشهادة في الحاوية وأضفها إلى التخزين النظامي
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        volumeMounts:
        - name: proxy-ca
          mountPath: /usr/local/share/ca-certificates/proxy-ca.crt
          subPath: ca.crt
      volumes:
      - name: proxy-ca
        configMap:
          name: proxy-ca-cert

أفضل الممارسات للبروكسي في الإنتاج

بناءً على تجربة تشغيل مجموعات Kubernetes في بيئة مؤسسية، إليك التوصيات لضمان عمل موثوق مع البروكسي:

1. استخدم خوادم بروكسي عالية التوفر

يصبح البروكسي نقطة فشل واحدة للمجموعة بأكملها. قم بإعداد عدة خوادم بروكسي خلف موازن تحميل:

HTTP_PROXY=http://proxy-lb.company.com:8080

حيث proxy-lb.company.com هو موازن التحميل أمام عدة خوادم بروكسي.

2. إدارة التكوين بشكل مركزي

استخدم ConfigMap أو Secret لتخزين إعدادات البروكسي بدلاً من التشفير في كل مانيفست:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-proxy-config
  namespace: kube-system
data:
  HTTP_PROXY: "http://proxy-lb.company.com:8080"
  HTTPS_PROXY: "http://proxy-lb.company.com:8080"
  NO_PROXY: "localhost,127.0.0.1,.cluster.local,.svc,10.0.0.0/8"

3. المراقبة والتنبيه

قم بإعداد مراقبة لتوافر خوادم البروكسي والتنبيهات عند حدوث مشاكل:

• زمن استجابة البروكسي (يجب أن يكون < 100ms للبروكسي المحلية)
• عدد أخطاء الاتصال بالبروكسي
• عدد أحداث ImagePullBackOff في المجموعة
• تحميل CPU والشبكة على خوادم البروكسي

4. وثق استثناءات NO_PROXY

احتفظ بوثائق حول النطاقات وعناوين IP المضافة إلى NO_PROXY ولماذا. سيساعد ذلك في تشخيص المشكلات وتدقيق الأمان.

5. اختبر التغييرات في بيئة التطوير

قبل تغيير إعدادات البروكسي في الإنتاج، اختبر دائمًا في مجموعة التطوير/المرحلة:

# حاوية اختبار للتحقق من البروكسي
apiVersion: v1
kind: Pod
metadata:
  name: proxy-test
spec:
  containers:
  - name: test
    image: curlimages/curl:latest
    command: ["sleep", "3600"]
    env:
    - name: HTTP_PROXY
      value: "http://new-proxy.company.com:8080"
    - name: HTTPS_PROXY
      value: "http://new-proxy.company.com:8080"

# تحقق من توافر الموارد الخارجية
kubectl exec -it proxy-test -- curl -v https://registry.k8s.io
kubectl exec -it proxy-test -- curl -v https://docker.io

6. استخدم أنواعًا مختلفة من البروكسي لمهام مختلفة

بالنسبة للمكونات الحيوية (تحميل الصور، واجهة برمجة التطبيقات للمجموعة)، استخدم بروكسي سريع مراكز البيانات، وللتطبيقات التي تتطلب تنوعًا جغرافيًا في IP - استخدم بروكسي سكنية أو موبايل.

7. قم بتحديث قائمة NO_PROXY بانتظام

عند إضافة خدمات جديدة أو تغيير الهيكل الشبكي، قم بتحديث NO_PROXY. قم بأتمتة ذلك عبر Helm charts أو Kustomize:

# values.yaml لـ Helm chart
proxy:
  enabled: true
  http: "http://proxy.company.com:8080"
  https: "http://proxy.company.com:8080"
  noProxy:
    - localhost
    - 127.0.0.1
    - .cluster.local
    - .svc
    - 10.0.0.0/8
    - internal-service.company.com

الخاتمة

إعداد البروكسي في مجموعات Kubernetes هو مهمة متعددة المستويات تتطلب الانتباه للتفاصيل في كل مستوى: من نظام التشغيل ووقت تشغيل الحاويات إلى الحاويات الفردية. يضمن التكوين الصحيح تشغيل المجموعة بسلاسة، والوصول الآمن إلى الموارد الخارجية، والامتثال لسياسات الأمان المؤسسية.

النقاط الرئيسية التي يجب تذكرها:

• قم بإعداد البروكسي على جميع المستويات: نظام التشغيل، وقت تشغيل الحاويات، kubelet، الحاويات
• قم بتكوين NO_PROXY بشكل صحيح، بما في ذلك جميع الشبكات الداخلية للمجموعة
• استخدم الإدارة المركزية عبر ConfigMap
• راقب توافر وأداء خوادم البروكسي
• اختبر التغييرات قبل تطبيقها في الإنتاج

لمجموعات Kubernetes الحيوية، نوصي باستخدام بروكسي مراكز البيانات الموثوقة ذات التوافر العالي والزمن المنخفض. سيوفر ذلك تشغيلًا مستقرًا للبنية التحتية ويقلل من مخاطر التوقف بسبب مشكلات الوصول الشبكي.

عند حدوث مشكلات، استخدم نهجًا منهجيًا للتشخيص: تحقق من الإعدادات في كل مستوى، قم بتحليل السجلات والأحداث، واختبر الاتصال يدويًا. يتم حل معظم مشكلات البروكسي في Kubernetes من خلال الإعداد الصحيح للمتغيرات البيئية و NO_PROXY.