कुबरनेट्स इनग्रेस कंट्रोलर के लिए प्रॉक्सी: K8s क्लस्टर में कॉन्फ़िगरेशन के उदाहरणों के साथ पूर्ण सेटअप

```html

यदि आपका K8s क्लस्टर बाहरी अनुरोध करता है - साझेदारों के API, मार्केटप्लेस, विज्ञापन प्लेटफार्मों के लिए - sooner या later आप IP के आधार पर ब्लॉकिंग का सामना करेंगे। Ingress Controller अपने आप में आने वाले ट्रैफ़िक को प्रबंधित करता है, लेकिन पॉड्स के माध्यम से आउटगोइंग अनुरोधों के लिए एक अलग प्रॉक्सी योजना की आवश्यकता होती है। इस लेख में हम समझते हैं कि इसे सही तरीके से कैसे सेट करें: प्रॉक्सी के प्रकार के चयन से लेकर NGINX Ingress और Traefik के लिए विशिष्ट YAML कॉन्फ़िग तक।

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 से अनुरोध भेजते हैं, तो यह स्वचालित ब्लॉकिंग के लिए ट्रिगर है।
• भू-स्थान परीक्षण। आपकी सेवा को विभिन्न देशों के उपयोगकर्ताओं के लिए विभिन्न सामग्री दिखानी चाहिए। प्रॉक्सी के माध्यम से पॉड्स आवश्यक क्षेत्रों से अनुरोधों की नकल कर सकते हैं।
• कॉर्पोरेट सीमाओं को दरकिनार करना। कुछ बुनियादी ढाँचों में, सभी आउटगोइंग ट्रैफ़िक को कॉर्पोरेट प्रॉक्सी के माध्यम से जाना चाहिए - यह अनुपालन की आवश्यकता है।
• IP की श्वेतसूची के साथ साझेदार API के साथ काम करना। जब साझेदार केवल विशिष्ट IP से अनुरोधों की अनुमति देते हैं, और आपका क्लस्टर स्केल करता है और पते बदलता है - स्थिर IP के साथ प्रॉक्सी समस्या को हल करती है।

आर्किटेक्चरल विभाजन को समझना महत्वपूर्ण है: Ingress Controller आने वाले ट्रैफ़िक का प्रबंधन करता है (उपयोगकर्ताओं से आपकी सेवाओं की ओर), और आउटगोइंग अनुरोधों के लिए प्रॉक्सी एक अलग कार्य है। फिर भी, वे जुड़े हुए हैं: प्रॉक्सी की कॉन्फ़िगरेशन अक्सर उसी Ingress Controller के स्तर पर या उन एनोटेशनों के माध्यम से निर्धारित की जाती है जिन्हें यह पढ़ता है।

💡 महत्वपूर्ण विभाजन

इस लेख में हम दो परिदृश्यों पर चर्चा करते हैं: (1) बाहरी अपस्ट्रीम सर्वरों के लिए Ingress Controller को रिवर्स प्रॉक्सी के रूप में सेट करना, और (2) पॉड्स से आउटगोइंग ट्रैफ़िक को बाहरी प्रॉक्सी सर्वर के माध्यम से रूट करना। दोनों परिदृश्य प्रोडक्शन में मिलते हैं।

K8s क्लस्टर के लिए कौन सा प्रॉक्सी प्रकार चुनें

प्रॉक्सी के प्रकार का चयन सीधे इस पर प्रभाव डालता है कि आपका क्लस्टर बिना ब्लॉकिंग के कितनी देर तक काम कर सकता है। डेटा सेंटर IP सबसे सस्ते होते हैं, लेकिन इन्हें पहचानना और ब्लॉक करना आसान होता है। रेजिडेंट और मोबाइल IP महंगे होते हैं, लेकिन वास्तविक उपयोगकर्ता की नकल करने वाले कार्यों के लिए काफी विश्वसनीय होते हैं।

प्रॉक्सी प्रकार	गति	ब्लॉकिंग का जोखिम	K8s में सबसे अच्छा परिदृश्य
डेटा सेंटर	उच्च	उच्च	आंतरिक API, कॉर्पोरेट अनुपालन, श्वेतसूची वाले साझेदार एकीकरण
रेजिडेंट	मध्यम	कम	मार्केटप्लेस की पार्सिंग, विज्ञापन 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 को रिवर्स प्रॉक्सी के रूप में सेट करना और स्वयं नियंत्रक के लिए आउटगोइंग प्रॉक्सी की वैश्विक सेटिंग।

अपस्ट्रीम के लिए अनुरोधों को प्रॉक्सी करने के लिए एनोटेशन

NGINX Ingress प्रॉक्सी के व्यवहार को प्रबंधित करने के लिए एनोटेशन का समर्थन करता है। यदि आपको Ingress को एक मध्यवर्ती प्रॉक्सी के माध्यम से बाहरी सेवा को अनुरोध भेजने की आवश्यकता है, तो कस्टम कॉन्फ़िग के साथ ConfigMap का उपयोग करें:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
data:
  # NGINX के लिए आउटगोइंग अनुरोधों के लिए वैश्विक HTTP प्रॉक्सी
  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 पॉड के लिए आउटगोइंग अनुरोधों के लिए बाहरी प्रॉक्सी सेटअप

यदि स्वयं NGINX Ingress Controller को बाहरी प्रॉक्सी के माध्यम से आउटगोइंग अनुरोध करने की आवश्यकता है (उदाहरण के लिए, बाहरी एंडपॉइंट्स के लिए स्वास्थ्य जांच के लिए), तो नियंत्रक के 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

Traefik Deployment के लिए पर्यावरण चर

NGINX के समान, Traefik के लिए हम Helm values के माध्यम से या सीधे Deployment में पर्यावरण चर सेट करते हैं। Helm चार्ट का उपयोग करते समय, यह values.yaml के माध्यम से किया जाता है:

# Traefik Helm चार्ट के लिए values.yaml
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: सीधे Pod Spec में

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"

विकल्प 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: म्यूटेटिंग वेबहुक एडमिशन कंट्रोलर

कॉर्पोरेट क्लस्टरों के लिए, जहाँ सभी पॉड्स को प्रॉक्सी का उपयोग करना आवश्यक है, एक म्यूटेटिंग एडमिशन वेबहुक सेट किया जा सकता है जो सभी बनाए गए पॉड्स में प्रॉक्सी पर्यावरण चर को स्वचालित रूप से जोड़ता है। यह समाधान एंटरप्राइज इन्फ्रास्ट्रक्चर में उपयोग किया जाता है, जहाँ अनुपालन की आवश्यकता होती है कि सभी आउटगोइंग ट्रैफ़िक कॉर्पोरेट प्रॉक्सी के माध्यम से जाए। ऐसे वेबहुक का कार्यान्वयन इस लेख के दायरे से बाहर है, लेकिन इसके अस्तित्व के बारे में जानना महत्वपूर्ण है।

K8s में IP रोटेशन और प्रॉक्सी पूल प्रबंधन

स्थिर प्रॉक्सी कॉर्पोरेट अनुपालन के लिए अच्छा है, लेकिन उन कार्यों के लिए खराब है जहाँ ब्लॉकिंग से बचना आवश्यक है। यदि आपके 50 पॉड्स एक ही IP के माध्यम से अनुरोध भेजते हैं, तो उस IP को बहुत जल्दी ब्लॉक कर दिया जाएगा। समाधान - प्रॉक्सी की रोटेशन।

प्रॉक्सी साइडकार योजना

एक पैटर्न है - प्रॉक्सी एजेंट को मुख्य एप्लिकेशन के बगल में साइडकार कंटेनर के रूप में चलाना। साइडकार 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"
      
      # साइडकार: रोटेशन के साथ स्थानीय प्रॉक्सी एजेंट
      - 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"

केंद्रीय प्रॉक्सी सेवा योजना

एक वैकल्पिक दृष्टिकोण - क्लस्टर के भीतर एक एकल प्रॉक्सी सेवा, जिसे सभी पॉड्स द्वारा संदर्भित किया जाता है। यह प्रबंधन में सरल है: एक प्रॉक्सी क्रेडेंशियल्स के साथ एक 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

Secret का 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"

Deployment में Secret का उपयोग

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

बाहरी सीक्रेट स्टोरेज के साथ एकीकरण

एंटरप्राइज वातावरण में, HashiCorp Vault, AWS Secrets Manager या Azure Key Vault से सीक्रेट्स को समन्वयित करने के लिए External Secrets Operator का उपयोग करने की सिफारिश की जाती है। यह प्रॉक्सी क्रेडेंशियल्स को स्वचालित रूप से अपडेट करने की अनुमति देता है बिना मैनुअल हस्तक्षेप और पॉड्स को पुनः प्रारंभ किए:

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 चर सेट नहीं है।

मानक K8s क्लस्टर के लिए 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

# जाँचें कि Secret सही ढंग से माउंट हुआ है
kubectl exec -it <pod-name> -n production -- env | grep PROXY

समस्या 3: HTTPS प्रॉक्सी का उपयोग करते समय TLS त्रुटियाँ

यदि प्रॉक्सी स्व-हस्ताक्षरित प्रमाणपत्र या कॉर्पोरेट CA का उपयोग करती है, तो एप्लिकेशन TLS सत्यापन में त्रुटियाँ प्राप्त करेंगे। समाधान - प्रॉक्सी के CA प्रमाणपत्र को विश्वसनीय में जोड़ना:

# CA प्रमाणपत्र के साथ ConfigMap बनाना
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 में जोड़ें)
• कीप-एलाइव कनेक्शन: प्रॉक्सी सर्वर के लिए कनेक्शन पूल सेट करें
• भौगोलिक स्थान: प्रॉक्सी सर्वर को लक्षित संसाधन के निकट भौतिक रूप से होना चाहिए
• प्रॉक्सी का प्रकार: उच्च गति वाले कार्यों के लिए डेटा सेंटर प्रॉक्सी पर विचार करें - ये न्यूनतम विलंबता प्रदान करते हैं

निदान के लिए उपयोगी कमांड

# 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 नेटवर्क के माध्यम से काम करते हैं।