← العودة إلى المدونة
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

بروكسي لوحدة التحكم في الدخول Kubernetes: الإعداد الكامل في مجموعة K8s مع أمثلة على التكوينات

نستعرض كيفية إعداد خادم بروكسي بشكل صحيح في وحدة التحكم Ingress الخاصة بـ Kubernetes - من التكوين الأساسي لـ NGINX إلى تدوير عناوين IP الساكنة لتجاوز الحظر.

📅٢٧ صفر ١٤٤٨ هـ
```html

إذا كانت مجموعة K8s الخاصة بك تقوم بإجراء طلبات خارجية - إلى واجهات برمجة التطبيقات الخاصة بالشركاء، إلى الأسواق، إلى منصات الإعلان - عاجلاً أم آجلاً ستواجه حظرًا بناءً على IP. تدير وحدة التحكم Ingress حركة المرور الواردة بنفسها، ولكن الطلبات الصادرة عبر الحاويات تحتاج إلى مخطط منفصل مع بروكسي. في هذه المقالة، نناقش كيفية إعداد ذلك بشكل صحيح: من اختيار نوع البروكسي إلى تكوينات YAML المحددة لوحدة التحكم Ingress الخاصة بـ NGINX وTraefik.

لماذا بروكسي في Kubernetes: سيناريوهات حقيقية

Kubernetes هو منظم، ومعظم المقالات حوله تتحدث عن حركة المرور الواردة: كيفية إعداد Ingress، كيفية إصدار شهادة TLS، كيفية توجيه الطلبات إلى الخدمات. لكن هناك جانب آخر: حركة المرور الصادرة من الحاويات. هنا تظهر المشاكل مع الحظر، القيود الجغرافية، والحدود بناءً على IP.

دعونا نناقش مهام معينة حيث يصبح البروكسي في مجموعة K8s ضرورة:

  • جمع وتحليل الأسعار. تقوم مجموعتك بتشغيل CronJob كل 15 دقيقة لجمع البيانات من Wildberries وOzon وAmazon. بدون تدوير IP، بعد 2-3 ساعات ستحصل على حظر على نطاق IP الخاص بمزود الخدمة السحابية الخاص بك.
  • العمل مع واجهات برمجة التطبيقات الإعلانية. واجهة برمجة التطبيقات الخاصة بـ Facebook Marketing، واجهة برمجة التطبيقات الخاصة بـ TikTok Ads، واجهة برمجة التطبيقات الخاصة بـ Google Ads - جميعها تتعقب مصدر الطلبات. إذا كانت عشرات الحاويات ترسل طلبات من نفس IP لمركز البيانات، فهذا يعد محفزًا للحظر التلقائي.
  • اختبار الجغرافيا. يجب أن يعرض خدمتك محتوى مختلفًا للمستخدمين من دول مختلفة. من خلال البروكسي، يمكن للحاويات تقليد الطلبات من المناطق المطلوبة للاختبارات التلقائية.
  • تجاوز القيود المؤسسية. في بعض البنى التحتية، يجب أن تمر جميع حركة المرور الصادرة عبر بروكسي مؤسسي - هذا مطلب للامتثال.
  • العمل مع واجهات برمجة التطبيقات الشريكة التي تحتوي على قائمة بيضاء لـ IP. عندما يسمح الشريك بالطلبات فقط من IPs معينة، بينما تتوسع مجموعتك وتغير العناوين - فإن البروكسي مع IPs الثابتة يحل المشكلة.

من المهم فهم الفصل المعماري: تدير وحدة التحكم Ingress حركة المرور الواردة (من المستخدمين إلى خدماتك)، بينما البروكسي للطلبات الصادرة هو مهمة منفصلة. ومع ذلك، فإنهما مرتبطان: غالبًا ما يتم تعيين تكوين البروكسي على مستوى نفس وحدة التحكم Ingress أو من خلال التعليقات التوضيحية التي يقرأها.

💡 الفصل الأساسي

في هذه المقالة، نناقش سيناريوهين: (1) إعداد وحدة التحكم Ingress كبروكسي عكسي للخوادم الخارجية، و(2) توجيه حركة المرور الصادرة من الحاويات عبر خادم بروكسي خارجي. كلا السيناريوهين شائعان في الإنتاج.

أي نوع من البروكسي تختار لمجموعة K8s

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

نوع البروكسي السرعة خطر الحظر أفضل سيناريو في K8s
مراكز البيانات عالية عالية واجهات برمجة التطبيقات الداخلية، الامتثال المؤسسي، التكاملات الشريكة مع قائمة بيضاء لـ IP
مقيمين متوسطة منخفضة جمع بيانات الأسواق، العمل مع واجهات برمجة التطبيقات الإعلانية، اختبار الجغرافيا
متحركين متوسطة أدنى واجهة برمجة التطبيقات الخاصة بـ Facebook Ads، واجهة برمجة التطبيقات الخاصة بـ TikTok، المهام ذات الحمل العالي مع خطر الحظر

بالنسبة لمعظم المهام في مجموعة K8s، المتعلقة بجمع البيانات أو العمل مع منصات الإعلان، فإن الخيار الأمثل هو بروكسي مقيم مع تدوير. إنها توفر IPs حقيقية لمستخدمي المنازل، وتعتبر خوارزميات حماية المواقع هذه الطلبات كحركة مرور عادية من المتصفح.

من حيث البروتوكول، فإن بروكسي HTTP/HTTPS هو الأكثر شمولاً لـ K8s - حيث تدعمه جميع عملاء HTTP الشائعين في أي لغة برمجة من خلال متغيرات البيئة القياسية HTTP_PROXY وHTTPS_PROXY. يحتاج SOCKS5 فقط للبروتوكولات غير القياسية أو عندما يتطلب الأمر بروكسي ليس فقط HTTP.

إعداد البروكسي عبر وحدة التحكم Ingress الخاصة بـ NGINX

وحدة التحكم Ingress الخاصة بـ NGINX هي الخيار الأكثر شيوعًا في K8s. دعونا نناقش سيناريوهين: إعداد NGINX كبروكسي عكسي للخادم الخارجي عبر خادم بروكسي، والإعداد العالمي للبروكسي الصادر لوحدة التحكم نفسها.

التعليقات التوضيحية لتوجيه الطلبات إلى الخادم الخارجي

تدعم وحدة التحكم Ingress الخاصة بـ NGINX التعليقات التوضيحية لإدارة سلوك البروكسي. إذا كنت بحاجة إلى أن يقوم Ingress بتمرير الطلبات إلى خدمة خارجية عبر بروكسي وسيط، استخدم ConfigMap مع تكوين مخصص: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
data:
  # بروكسي HTTP عالمي للطلبات الصادرة من NGINX
  http-snippet: |
    proxy_connect_timeout 10s;
    proxy_read_timeout 30s;
    proxy_send_timeout 30s;
  # إعداد الخادم الخارجي عبر البروكسي
  use-proxy-protocol: "false"
  proxy-real-ip-cidr: "0.0.0.0/0"

موارد Ingress مع التعليقات التوضيحية للبروكسي

يمكن تعيين معلمات البروكسي لمورد Ingress منفصل من خلال التعليقات التوضيحية. هذا مفيد عندما تتطلب الخدمات المختلفة أوقات انتظار وإعدادات مختلفة: 

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-service-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: "nginx"
    # أوقات انتظار البروكسي
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "10"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "60"
    # حجم المخزن المؤقت
    nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"
    nginx.ingress.kubernetes.io/proxy-buffers-number: "8"
    # تمرير IP الحقيقي للعميل
    nginx.ingress.kubernetes.io/use-forwarded-headers: "true"
    nginx.ingress.kubernetes.io/forwarded-for-header: "X-Forwarded-For"
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

إعداد بروكسي خارجي للطلبات الصادرة من حاوية NGINX

إذا كانت وحدة التحكم Ingress الخاصة بـ NGINX تحتاج إلى إجراء طلبات صادرة عبر بروكسي خارجي (على سبيل المثال، للتحقق من صحة نقاط النهاية الخارجية)، يجب تعيين متغيرات البيئة في نشر وحدة التحكم: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  template:
    spec:
      containers:
      - name: controller
        image: registry.k8s.io/ingress-nginx/controller:v1.9.4
        env:
        - name: HTTP_PROXY
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: http-proxy-url
        - name: HTTPS_PROXY
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: https-proxy-url
        - name: NO_PROXY
          value: "localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.cluster.local"

لاحظ المتغير NO_PROXY - فهو مهم للغاية. بدونه، ستذهب جميع حركة المرور داخل المجموعة أيضًا عبر البروكسي الخارجي، مما سيكسر التفاعل بين الخدمات. في NO_PROXY، يجب دائمًا تضمين نطاقات RFC-1918 واللاحقة .cluster.local.

إعداد البروكسي في وحدة التحكم Ingress الخاصة بـ Traefik

Traefik هو بديل شائع لوحدة التحكم Ingress الخاصة بـ NGINX، خاصة عند استخدامه مع Helm وفي المجموعات المدارة (k3s، Docker Swarm، Nomad). يحتوي Traefik على نظام تكوين خاص به عبر CRD (تعريفات الموارد المخصصة) وتكوينات ثابتة/ديناميكية.

التكوين الثابت لـ Traefik مع البروكسي

apiVersion: v1
kind: ConfigMap
metadata:
  name: traefik-config
  namespace: traefik
data:
  traefik.yaml: |
    # التكوين الثابت لـ Traefik
    entryPoints:
      web:
        address: ":80"
      websecure:
        address: ":443"
    
    # الإعدادات للعمل خلف بروكسي
    serversTransport:
      insecureSkipVerify: false
      maxIdleConnsPerHost: 200
      dialTimeout: 10s
      responseHeaderTimeout: 30s
    
    # تسجيل لتشخيص البروكسي
    log:
      level: INFO
    
    accessLog:
      fields:
        headers:
          defaultMode: keep
          names:
            X-Forwarded-For: keep
            X-Real-IP: keep

البرمجيات الوسيطة لإضافة رؤوس البروكسي

في Traefik، يمكنك إنشاء برمجية وسيطة ستضيف أو تعدل الرؤوس عند تمرير الطلبات. هذا مفيد لضمان تمرير IP الحقيقي للعميل بشكل صحيح عبر سلسلة البروكسي: 

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: proxy-headers
  namespace: production
spec:
  headers:
    customRequestHeaders:
      X-Forwarded-Proto: "https"
    # إزالة الرؤوس التي قد تكشف عن البنية التحتية
    customResponseHeaders:
      X-Powered-By: ""
      Server: ""
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: my-app-route
  namespace: production
spec:
  entryPoints:
    - websecure
  routes:
  - match: Host(`myapp.example.com`)
    kind: Rule
    middlewares:
    - name: proxy-headers
    services:
    - name: my-service
      port: 80

متغيرات البيئة لنشر Traefik

بالمثل لـ NGINX، نقوم بتعيين متغيرات البيئة لـ Traefik عبر قيم Helm أو مباشرة في النشر. عند استخدام مخطط Helm، يتم ذلك عبر values.yaml: 

# values.yaml لمخطط Helm الخاص بـ Traefik
deployment:
  enabled: true
  kind: Deployment
  
env:
  - name: HTTP_PROXY
    valueFrom:
      secretKeyRef:
        name: proxy-credentials
        key: http-proxy-url
  - name: HTTPS_PROXY
    valueFrom:
      secretKeyRef:
        name: proxy-credentials
        key: https-proxy-url
  - name: NO_PROXY
    value: "localhost,127.0.0.1,10.96.0.0/12,10.244.0.0/16,.cluster.local,.svc"

بروكسي عبر متغيرات البيئة في الحاويات

الطريقة الأكثر شمولاً لإعداد بروكسي صادر لأي حاوية هي عبر متغيرات البيئة القياسية. تعمل هذه الطريقة بغض النظر عن لغة البرمجة والإطار: Python requests، Go net/http، Node.js axios، Java HttpClient - جميعها تقرأ HTTP_PROXY وHTTPS_PROXY تلقائيًا.

الخيار 1: مباشرة في مواصفات الحاوية

apiVersion: v1
kind: Pod
metadata:
  name: scraper-pod
  namespace: production
spec:
  containers:
  - name: scraper
    image: mycompany/scraper:latest
    env:
    - name: HTTP_PROXY
      value: "http://username:[email protected]:8080"
    - name: HTTPS_PROXY
      value: "http://username:[email protected]:8080"
    - name: NO_PROXY
      value: "localhost,127.0.0.1,10.0.0.0/8,.cluster.local"
    resources:
      requests:
        memory: "128Mi"
        cpu: "100m"
      limits:
        memory: "256Mi"
        cpu: "500m"

⚠️ لا تخزن بيانات الاعتماد بشكل علني!

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

الخيار 2: عبر ConfigMap لعدة حاويات

إذا كانت البروكسي تستخدمها عدة نشرات، فمن الملائم إخراج الإعدادات إلى ConfigMap وربطها عبر envFrom: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: proxy-config
  namespace: production
data:
  NO_PROXY: "localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,.cluster.local,.svc.cluster.local"
  PROXY_TIMEOUT: "30"
  PROXY_MAX_RETRIES: "3"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: price-monitor
  namespace: production
spec:
  replicas: 5
  selector:
    matchLabels:
      app: price-monitor
  template:
    metadata:
      labels:
        app: price-monitor
    spec:
      containers:
      - name: monitor
        image: mycompany/price-monitor:v2.1
        envFrom:
        - configMapRef:
            name: proxy-config
        - secretRef:
            name: proxy-credentials
        ports:
        - containerPort: 8080

الخيار 3: WebhookAdmissionController المتحول

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

تدوير IP وإدارة مجموعة البروكسي في K8s

البروكسي الثابت جيد للامتثال المؤسسي، ولكنه سيء للمهام التي تحتاج إلى تجنب الحظر. إذا كانت 50 من الحاويات الخاصة بك ترسل طلبات عبر نفس IP، سيتم حظر هذا IP بسرعة كبيرة. الحل هو تدوير البروكسي.

مخطط مع Proxy Sidecar

أحد الأنماط هو تشغيل وكيل البروكسي كحاوية sidecar بجانب التطبيق الرئيسي. يستقبل sidecar الطلبات على localhost:8080 ويعيد توجيهها عبر مجموعة بروكسي خارجية تدور: 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: scraper-with-proxy-sidecar
  namespace: production
spec:
  replicas: 10
  selector:
    matchLabels:
      app: scraper
  template:
    metadata:
      labels:
        app: scraper
    spec:
      containers:
      # التطبيق الرئيسي
      - name: scraper
        image: mycompany/scraper:latest
        env:
        - name: HTTP_PROXY
          value: "http://localhost:8080"
        - name: HTTPS_PROXY
          value: "http://localhost:8080"
        - name: NO_PROXY
          value: "localhost,127.0.0.1,.cluster.local"
      
      # Sidecar: وكيل بروكسي محلي مع تدوير
      - name: proxy-rotator
        image: mycompany/proxy-rotator:latest
        ports:
        - containerPort: 8080
        env:
        - name: PROXY_LIST_URL
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: api-endpoint
        - name: ROTATION_INTERVAL
          value: "60"  # تدوير كل 60 ثانية
        resources:
          requests:
            memory: "64Mi"
            cpu: "50m"
          limits:
            memory: "128Mi"
            cpu: "200m"

مخطط مع خدمة بروكسي مركزية

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

apiVersion: v1
kind: Service
metadata:
  name: proxy-gateway
  namespace: proxy-system
spec:
  selector:
    app: proxy-gateway
  ports:
  - name: http
    port: 8080
    targetPort: 8080
  - name: socks5
    port: 1080
    targetPort: 1080
  type: ClusterIP
---
# الحاويات تستخدم البروكسي عبر DNS الداخلي
# HTTP_PROXY=http://proxy-gateway.proxy-system.svc.cluster.local:8080

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

تخزين بيانات اعتماد البروكسي في أسرار Kubernetes

يعد التخزين الآمن لبيانات الاعتماد مطلبًا أساسيًا لأي مجموعة إنتاج. لا تقم أبدًا بإدراج اسم المستخدم/كلمة المرور للبروكسي مباشرة في ملفات YAML التي يتم تخزينها في مستودع Git.

إنشاء سر للبروكسي

# الإنشاء عبر kubectl (القيم مشفرة في base64 تلقائيًا)
kubectl create secret generic proxy-credentials \
  --namespace=production \
  --from-literal=http-proxy-url='http://user:[email protected]:8080' \
  --from-literal=https-proxy-url='http://user:[email protected]:8080' \
  --from-literal=socks5-proxy-url='socks5://user:[email protected]:1080'

# التحقق من السر الذي تم إنشاؤه
kubectl get secret proxy-credentials -n production -o yaml

ملف YAML لسر

apiVersion: v1
kind: Secret
metadata:
  name: proxy-credentials
  namespace: production
  labels:
    app: proxy-config
    managed-by: ops-team
type: Opaque
# القيم مشفرة في base64
# echo -n 'http://user:pass@proxy:8080' | base64
stringData:
  # stringData يسمح بتحديد القيم بشكل علني
  # Kubernetes يقوم بتشفيرها تلقائيًا في base64
  http-proxy-url: "http://user:[email protected]:8080"
  https-proxy-url: "http://user:[email protected]:8080"
  proxy-host: "gate.proxycove.com"
  proxy-port: "8080"
  proxy-username: "user"
  proxy-password: "password"

استخدام السر في النشر

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-worker
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-worker
  template:
    metadata:
      labels:
        app: api-worker
    spec:
      containers:
      - name: worker
        image: mycompany/api-worker:latest
        env:
        - name: HTTP_PROXY
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: http-proxy-url
        - name: HTTPS_PROXY
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: https-proxy-url
        - name: NO_PROXY
          value: "localhost,127.0.0.1,10.0.0.0/8,.cluster.local"
        # للتطبيقات التي تقرأ المضيف/المنفذ بشكل منفصل
        - name: PROXY_HOST
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: proxy-host
        - name: PROXY_PORT
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: proxy-port

التكامل مع خزانات الأسرار الخارجية

في بيئة الشركات، يُوصى باستخدام External Secrets Operator لمزامنة الأسرار من HashiCorp Vault أو AWS Secrets Manager أو Azure Key Vault. يسمح ذلك بتحديث بيانات اعتماد البروكسي تلقائيًا دون تدخل يدوي وإعادة تشغيل الحاويات: 

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: proxy-credentials-ext
  namespace: production
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: proxy-credentials
    creationPolicy: Owner
  data:
  - secretKey: http-proxy-url
    remoteRef:
      key: secret/proxy/proxycove
      property: http_proxy_url
  - secretKey: https-proxy-url
    remoteRef:
      key: secret/proxy/proxycove
      property: https_proxy_url

تشخيص الأخطاء الشائعة عند إعداد البروكسي في K8s

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

المشكلة 1: حركة المرور داخل المجموعة تمر عبر البروكسي

الأعراض: الحاويات تتوقف عن رؤية بعضها البعض، يتعطل حل DNS داخل المجموعة، الخدمات لا تستجيب. السبب - لم يتم تعيين المتغير NO_PROXY.

الحد الأدنى من القيمة المطلوبة NO_PROXY 

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

المشكلة 2: البروكسي لا يُطبق على حاوية معينة

التشخيص: ادخل إلى الحاوية وتحقق من متغيرات البيئة: 

# التحقق من متغيرات البيئة في الحاوية
kubectl exec -it <pod-name> -n production -- env | grep -i proxy

# اختبار الاتصال عبر البروكسي من الحاوية
kubectl exec -it <pod-name> -n production -- curl -v --proxy http://proxy:8080 https://httpbin.org/ip

# التحقق من أن السر تم تركيبه بشكل صحيح
kubectl exec -it <pod-name> -n production -- env | grep PROXY

المشكلة 3: أخطاء TLS عند استخدام بروكسي HTTPS

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

# إنشاء ConfigMap مع شهادة CA
kubectl create configmap proxy-ca-cert \
  --from-file=proxy-ca.crt=./proxy-ca.crt \
  -n production

# تركيبها في الحاوية
spec:
  containers:
  - name: app
    volumeMounts:
    - name: proxy-ca
      mountPath: /etc/ssl/certs/proxy-ca.crt
      subPath: proxy-ca.crt
  volumes:
  - name: proxy-ca
    configMap:
      name: proxy-ca-cert

المشكلة 4: طلبات بطيئة عبر البروكسي

إذا كانت الطلبات عبر البروكسي أبطأ بكثير من الطلبات المباشرة - تحقق من:

  • حل DNS: تأكد من أن طلبات DNS لا تمر عبر البروكسي (أضف إلى NO_PROXY)
  • اتصالات Keep-alive: قم بإعداد مجموعة اتصالات لخادم البروكسي
  • الموقع الجغرافي: يجب أن يكون خادم البروكسي قريبًا جسديًا من المورد المستهدف
  • نوع البروكسي: لمهام السرعة العالية، ضع في اعتبارك بروكسي مراكز البيانات - حيث توفر الحد الأدنى من التأخير

أوامر مفيدة للتشخيص

# تحقق من سجلات وحدة التحكم Ingress
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx --tail=100

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

# اختبار اتصال البروكسي من الحاوية
kubectl run test-proxy --image=curlimages/curl --rm -it --restart=Never -- \
  curl -x http://user:pass@proxy:8080 -v https://httpbin.org/ip

# تحقق من أن السر موجود ويحتوي على المفاتيح المطلوبة
kubectl get secret proxy-credentials -n production -o jsonpath='{.data}' | python3 -c "
import sys, json, base64
data = json.load(sys.stdin)
for k, v in data.items():
    print(f'{k}: {base64.b64decode(v).decode()[:20]}...')
"

الخاتمة والتوصيات

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

  • لوحدة التحكم Ingress الخاصة بـ NGINX - استخدم التعليقات التوضيحية لضبط معلمات البروكسي على مستوى موارد Ingress الفردية، ومتغيرات البيئة في النشر للإعدادات العالمية لحركة المرور الصادرة.
  • لـ Traefik - امزج بين التكوين الثابت عبر ConfigMap مع البرمجيات الوسيطة لإدارة الرؤوس.
  • للحاويات - المتغيرات القياسية HTTP_PROXY / HTTPS_PROXY عبر الأسرار - هي الطريقة الأكثر شمولاً وأمانًا.
  • قم دائمًا بتعيين NO_PROXY - وإلا ستتعطل حركة المرور داخل المجموعة.
  • لا تخزن أبدًا بيانات اعتماد البروكسي بشكل علني في المانيفستات أو في Git.
  • للإنتاج - استخدم External Secrets Operator لتدوير بيانات الاعتماد تلقائيًا.

إذا كانت مجموعة K8s الخاصة بك تقوم بمهام تتطلب استقرار IP و الحد الأدنى من خطر الحظر - جمع البيانات، العمل مع واجهات برمجة التطبيقات الإعلانية، اختبار الجغرافيا - نوصي باستخدام بروكسي مقيم. إنها توفر IPs حقيقية لمستخدمي المنازل، والتي تعتبرها خوارزميات الحماية كحركة مرور شرعية. لمهام ذات متطلبات عالية للسرعة وأقل مخاطر الحظر من منصات الهاتف المحمول، تعتبر البروكسي المتحرك خيارًا ممتازًا - حيث تعمل عبر شبكات 4G/5G الحقيقية لمزودي الخدمة.

```