← بازگشت به وبلاگ
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

پروکسی برای کنترلر ورودی کوبرنتیز: تنظیمات کامل در کلاستر K8s با مثال‌های پیکربندی

نحوه تنظیم صحیح پروکسی سرور در کنترلر ورودی کوبرنتیس را بررسی می‌کنیم - از پیکربندی پایه NGINX تا چرخش IP های مقیم برای دور زدن مسدودسازی‌ها.

📅۱۹ مرداد ۱۴۰۵
```html

اگر خوشه K8s شما درخواست‌های خارجی انجام می‌دهد — به API شرکا، به بازارها، به پلتفرم‌های تبلیغاتی — دیر یا زود با مسدودسازی‌های IP مواجه خواهید شد. Ingress Controller به خودی خود ترافیک ورودی را مدیریت می‌کند، اما برای درخواست‌های خروجی از طریق پادها به یک طرح جداگانه با پروکسی نیاز است. در این مقاله بررسی می‌کنیم که چگونه این را به درستی تنظیم کنیم: از انتخاب نوع پروکسی تا پیکربندی‌های خاص YAML برای NGINX Ingress و Traefik.

چرا پروکسی در Kubernetes: سناریوهای واقعی

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

بیایید به وظایف خاصی بپردازیم که در آن پروکسی در خوشه K8s ضروری می‌شود:

  • جمع‌آوری و نظارت بر قیمت‌ها. خوشه شما هر 15 دقیقه یک CronJob را اجرا می‌کند و داده‌ها را از Wildberries، Ozon، Amazon جمع‌آوری می‌کند. بدون چرخش IP، پس از 2–3 ساعت، شما با مسدودیت در کل دامنه IP ارائه‌دهنده ابری خود مواجه خواهید شد.
  • کار با API های تبلیغاتی. Facebook Marketing API، TikTok Ads API، Google Ads API — همه آن‌ها منبع درخواست‌ها را ردیابی می‌کنند. اگر ده‌ها پاد از یک IP مرکز داده درخواست ارسال کنند، این یک محرک برای مسدودسازی خودکار است.
  • آزمایش جغرافیایی. سرویس شما باید محتوای متفاوتی را برای کاربران از کشورهای مختلف نمایش دهد. از طریق پروکسی، پادها می‌توانند درخواست‌ها را از مناطق مورد نظر برای تست‌های خودکار شبیه‌سازی کنند.
  • دور زدن محدودیت‌های شرکتی. در برخی زیرساخت‌ها، تمام ترافیک خروجی باید از طریق پروکسی شرکتی عبور کند — این یک الزام compliance است.
  • کار با API های شرکتی با لیست سفید IP. زمانی که شریک فقط درخواست‌ها را از IP های خاص مجاز می‌کند و خوشه شما مقیاس‌پذیر است و آدرس‌ها را تغییر می‌دهد — پروکسی با IP های ثابت این مشکل را حل می‌کند.

مهم است که تفکیک معماری را درک کنیم: Ingress Controller ترافیک ورودی را مدیریت می‌کند (از کاربران به سرویس‌های شما)، و پروکسی برای درخواست‌های خروجی — یک وظیفه جداگانه است. با این حال، آن‌ها به هم مرتبط هستند: پیکربندی پروکسی اغلب در سطح همان Ingress Controller یا از طریق یادداشت‌هایی که می‌خواند، تعیین می‌شود.

💡 تفکیک کلیدی

در این مقاله دو سناریو را بررسی می‌کنیم: (1) تنظیم Ingress Controller به عنوان یک پروکسی معکوس برای سرورهای upstream خارجی، و (2) مسیریابی ترافیک خروجی از پادها از طریق یک سرور پروکسی خارجی. هر دو سناریو در تولید مشاهده می‌شوند.

کدام نوع پروکسی را برای خوشه K8s انتخاب کنیم

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

نوع پروکسی سرعت ریسک مسدودسازی بهترین سناریو در K8s
مرکز داده بالا بالا API های داخلی، compliance شرکتی، ادغام‌های شرکتی با لیست سفید IP
مقیم متوسط پایین جمع‌آوری داده‌های بازار، کار با API های تبلیغاتی، آزمایش جغرافیایی
موبایل متوسط حداقل Facebook Ads API، TikTok API، وظایف با بار بالا با ریسک مسدودسازی

برای اکثر وظایف در خوشه K8s که با جمع‌آوری داده‌ها یا کار با پلتفرم‌های تبلیغاتی مرتبط هستند، انتخاب بهینه — پروکسی‌های مقیم با چرخش است. آن‌ها IP های واقعی کاربران خانگی را ارائه می‌دهند و الگوریتم‌های محافظت از وب‌سایت‌ها چنین درخواست‌هایی را به عنوان ترافیک عادی مرورگر درک می‌کنند.

از نظر پروتکل، برای K8s، پروکسی HTTP/HTTPS بیشترین قابلیت را دارد — همه مشتریان HTTP محبوب در هر زبان برنامه‌نویسی از طریق متغیرهای محیطی استاندارد HTTP_PROXY و HTTPS_PROXY از آن پشتیبانی می‌کنند. SOCKS5 فقط برای پروتکل‌های غیر استاندارد یا زمانی که نیاز به پروکسی کردن نه تنها HTTP باشد، ضروری است.

تنظیم پروکسی از طریق NGINX Ingress Controller

NGINX Ingress Controller — رایج‌ترین گزینه در K8s است. بیایید دو سناریو را بررسی کنیم: تنظیم NGINX به عنوان یک پروکسی معکوس به upstream خارجی از طریق سرور پروکسی، و تنظیم جهانی پروکسی خروجی برای خود کنترل‌کننده.

یادداشت‌ها برای پروکسی کردن درخواست‌ها به upstream

NGINX Ingress از یادداشت‌ها برای مدیریت رفتار پروکسی پشتیبانی می‌کند. اگر نیاز دارید که 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;
  # تنظیم upstream از طریق پروکسی
  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 پاد

اگر خود NGINX Ingress Controller باید درخواست‌های خروجی را از طریق پروکسی خارجی انجام دهد (به عنوان مثال، برای health-check نقاط پایانی خارجی)، باید متغیرهای محیطی را در Deployment کنترل‌کننده تعیین کنید: 

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 را شامل کنید.

تنظیم پروکسی در Traefik Ingress Controller

Traefik — یک جایگزین محبوب برای NGINX Ingress، به ویژه در ترکیب با 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

Middleware برای افزودن هدرهای پروکسی

در Traefik می‌توان یک Middleware ایجاد کرد که هنگام ارسال درخواست‌ها، هدرها را اضافه یا تغییر دهد. این برای انتقال صحیح 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

متغیرهای محیطی برای Deployment Traefik

مشابه NGINX، برای Traefik متغیرهای محیطی را از طریق مقادیر Helm یا به طور مستقیم در Deployment تعیین می‌کنیم. هنگام استفاده از چارت 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 Secret ذخیره شوند و از طریق secretKeyRef منتقل شوند. جزئیات بیشتر در بخش مربوط به Secrets در زیر.

گزینه 2: از طریق ConfigMap برای چندین پاد

اگر پروکسی‌ها از چندین Deployment استفاده کنند، مناسب است که تنظیمات را به 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 تغییر دهنده تنظیم کرد که به طور خودکار متغیرهای محیطی پروکسی را به همه پادهای ایجاد شده اضافه کند. این راه‌حل در زیرساخت‌های شرکتی استفاده می‌شود که compliance نیاز دارد تا تمام ترافیک خروجی از طریق پروکسی شرکتی عبور کند. پیاده‌سازی چنین webhook فراتر از این مقاله است، اما باید از وجود آن آگاه باشید.

چرخش IP و مدیریت استخر پروکسی در K8s

پروکسی ثابت — برای compliance شرکتی خوب است، اما برای وظایفی که نیاز به جلوگیری از مسدودسازی دارند بد است. اگر 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"

طرح با Proxy Service مرکزی

رویکرد جایگزین — یک Proxy Service واحد درون خوشه است که همه پادها به آن مراجعه می‌کنند. این مدیریت را ساده‌تر می‌کند: کافی است یک Secret با اعتبارنامه‌های پروکسی را به‌روزرسانی کنید و همه پادها به طور خودکار از داده‌های جدید استفاده خواهند کرد. 

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

برای وظایفی که ناشناسی و حداقل ریسک مسدودسازی (به عنوان مثال، جمع‌آوری داده‌های بازار یا کار با API های تبلیغاتی) حیاتی است، توصیه می‌کنیم از پروکسی‌های مقیم با چرخش استفاده کنید — آن‌ها IP های واقعی کاربران خانگی را ارائه می‌دهند که ترافیک از خوشه شما را غیرقابل تشخیص از ترافیک عادی مرورگر می‌کند.

ذخیره‌سازی اعتبارنامه‌های پروکسی در Kubernetes Secrets

ذخیره‌سازی امن اعتبارنامه‌ها یک الزام برای هر خوشه تولید است. هرگز نام کاربری/گذرواژه پروکسی را به طور مستقیم در مانیفست‌های YAML که در مخزن Git ذخیره می‌شوند، وارد نکنید.

ایجاد Secret برای پروکسی

# ایجاد از طریق 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'

# بررسی Secret ایجاد شده
kubectl get secret proxy-credentials -n production -o yaml

مانیفست YAML Secret

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"

استفاده از Secret در Deployment

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

ادغام با ذخیره‌سازهای خارجی Secrets

در محیط‌های شرکتی، توصیه می‌شود از External Secrets Operator برای همگام‌سازی Secrets از 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 برای خوشه K8s استاندارد: 

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

# بررسی اینکه Secret به درستی متصل شده است
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 Controller
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

# بررسی اینکه Secret وجود دارد و شامل کلیدهای مورد نیاز است
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 یک وظیفه یک‌باره نیست، بلکه بخشی از معماری امنیت شبکه خوشه است. بیایید جمع‌بندی کنیم:

  • برای NGINX Ingress Controller — از یادداشت‌ها برای تنظیم پارامترهای پروکسی در سطح منابع Ingress جداگانه استفاده کنید و از متغیرهای محیطی در Deployment برای تنظیمات جهانی ترافیک خروجی.
  • برای Traefik — پیکربندی ایستا را از طریق ConfigMap با Middleware برای مدیریت هدرها ترکیب کنید.
  • برای پادها — متغیرهای استاندارد HTTP_PROXY / HTTPS_PROXY از طریق Secrets — بهترین و ایمن‌ترین رویکرد است.
  • همیشه NO_PROXY را تنظیم کنید — در غیر این صورت ترافیک درون‌خوشه‌ای مختل خواهد شد.
  • هرگز اعتبارنامه‌های پروکسی را به صورت واضح در مانیفست‌ها یا در Git ذخیره نکنید.
  • برای تولید — از External Secrets Operator برای چرخش خودکار اعتبارنامه‌ها استفاده کنید.

اگر خوشه K8s شما وظایفی را انجام می‌دهد که در آن ثبات IP و حداقل ریسک مسدودسازی حیاتی است — جمع‌آوری داده‌ها، کار با API های تبلیغاتی، آزمایش جغرافیایی — توصیه می‌کنیم از پروکسی‌های مقیم استفاده کنید. آن‌ها IP های واقعی کاربران خانگی را ارائه می‌دهند که الگوریتم‌های محافظت به عنوان ترافیک قانونی درک می‌کنند. برای وظایف با نیازهای بالا به سرعت و حداقل ریسک‌های مسدودسازی از طرف پلتفرم‌های موبایل، پروکسی‌های موبایل گزینه‌های عالی هستند — آن‌ها از طریق شبکه‌های واقعی 4G/5G اپراتورها کار می‌کنند.

```