कुबरनेट्स क्लस्टरों में प्रॉक्सी सेटअप: देवऑप्स इंजीनियरों के लिए पूर्ण गाइड

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

Kubernetes क्लस्टरों में प्रॉक्सी की आवश्यकता क्यों है

कॉर्पोरेट वातावरण में Kubernetes क्लस्टर अक्सर सीमित इंटरनेट पहुंच के साथ अलग-थलग नेटवर्क में काम करते हैं। प्रॉक्सी सर्वर कई महत्वपूर्ण कार्यों को हल करता है:

• कंटेनर छवियों को डाउनलोड करना — Docker Hub, Google Container Registry, निजी रजिस्ट्रियों को बाहरी पहुंच की आवश्यकता होती है
• पैकेज अपडेट करना — कंटेनरों के भीतर apt, yum, pip के माध्यम से निर्भरताएँ स्थापित करना
• बाहरी API तक पहुंच — क्लाउड सेवाओं, निगरानी, लॉगिंग के साथ एकीकरण
• सुरक्षा — ट्रैफ़िक नियंत्रण, डोमेन फ़िल्टरिंग, अनुरोध लॉगिंग
• कैशिंग — समान संसाधनों के लिए पुनः अनुरोधों को तेज करना

प्रॉक्सी की सही सेटिंग के बिना, आप "image pull failed", "connection timeout" या "network unreachable" जैसी त्रुटियों का सामना करेंगे जब आप एप्लिकेशन तैनात करने का प्रयास करेंगे। यह विशेष रूप से स्वचालित CI/CD पाइपलाइनों के लिए महत्वपूर्ण है, जहां हर सेकंड का डाउनटाइम पैसे की लागत होती है।

Kubernetes में प्रॉक्सी सेटअप के स्तर

Kubernetes की बहु-स्तरीय आर्किटेक्चर है, और प्रॉक्सी को कार्यों के आधार पर प्रत्येक स्तर पर सेटअप करने की आवश्यकता होती है:

प्रत्येक स्तर को अलग सेटअप की आवश्यकता होती है, और किसी एक को छोड़ने से समस्याएँ हो सकती हैं। उदाहरण के लिए, यदि आप केवल Docker के लिए प्रॉक्सी सेट करते हैं, लेकिन पॉड्स के लिए नहीं, तो छवियाँ डाउनलोड होंगी, लेकिन कंटेनरों के भीतर एप्लिकेशन बाहरी API से संपर्क नहीं कर सकेंगे।

Docker और containerd के लिए प्रॉक्सी सेटअप

कंटेनर रनटाइम पहला घटक है जिसे सेटअप करने की आवश्यकता होती है, क्योंकि यह बाहरी रजिस्ट्रियों से कंटेनर छवियों को डाउनलोड करने के लिए जिम्मेदार है। हम दोनों लोकप्रिय रनटाइम के लिए सेटअप पर विचार करेंगे।

Docker के लिए प्रॉक्सी सेटअप

Docker के लिए, एक systemd ड्रॉप-इन फ़ाइल बनानी होगी, जो 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

NO_PROXY में 169.254.169.254 को जोड़ना न भूलें — यह AWS के मेटाडेटा सेवा का पता है, जिसे प्रॉक्सी के बिना पहुंच योग्य होना चाहिए।

पॉड स्तर पर प्रॉक्सी सेटअप

भले ही आपने Docker और kubelet के लिए प्रॉक्सी सेट किया हो, लेकिन पॉड्स के भीतर एप्लिकेशन स्वचालित रूप से प्रॉक्सी का उपयोग नहीं करेंगे। Kubernetes मैनिफेस्ट में पर्यावरण चर को स्पष्ट रूप से निर्दिष्ट करना आवश्यक है।

Deployment मैनिफेस्ट के माध्यम से सेटअप

सबसे सरल तरीका यह है कि कंटेनर स्पेसिफिकेशन में पर्यावरण चर जोड़ें:

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 का उपयोग

प्रत्येक Deployment में प्रॉक्सी सेटिंग्स को डुप्लिकेट करने से बचने के लिए, एक 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 का उपयोग Deployment में करें:

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" त्रुटि

लक्षण: पॉड्स शुरू नहीं होते, घटनाओं में "Failed to pull image" या "connection timeout" त्रुटि दिखाई देती है।

निदान:

# पॉड की घटनाएँ जांचें
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

समाधान: NO_PROXY में .cluster.local और .svc जोड़ें।

बाहरी API से संपर्क करते समय धीमी कार्यक्षमता या टाइमआउट

लक्षण: एप्लिकेशन धीमी गति से काम करते हैं या बाहरी सेवाओं के लिए अनुरोध करते समय टाइमआउट प्राप्त करते हैं।

निदान:

# पॉड से प्रॉक्सी की उपलब्धता की जांच करें
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 त्रुटियाँ

लक्षण: "certificate verify failed" या "SSL handshake failed" जैसी त्रुटियाँ।

कारण: कुछ प्रॉक्सी सर्वर 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. उत्पादन में बदलाव का परीक्षण करें

उत्पादन में प्रॉक्सी सेटिंग्स को बदलने से पहले हमेशा dev/staging क्लस्टर में परीक्षण करें:

# प्रॉक्सी की जांच के लिए परीक्षण पॉड
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. विभिन्न कार्यों के लिए विभिन्न प्रकार के प्रॉक्सी का उपयोग करें

महत्वपूर्ण घटकों (छवियों को डाउनलोड करना, क्लस्टर API) के लिए तेज डेटा सेंटर प्रॉक्सी का उपयोग करें, और उन एप्लिकेशनों के लिए जो IP के भौगोलिक विविधता की आवश्यकता होती है - निवासी या मोबाइल प्रॉक्सी।

7. NO_PROXY सूची को नियमित रूप से अपडेट करें

नए सेवाओं को जोड़ने या नेटवर्क टोपोलॉजी में बदलाव करते समय NO_PROXY को अपडेट करें। इसे Helm चार्ट या Kustomize के माध्यम से स्वचालित करें:

# Helm चार्ट के लिए values.yaml
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 क्लस्टरों में प्रॉक्सी सेटअप एक बहु-स्तरीय कार्य है, जिसमें प्रत्येक स्तर पर विवरण पर ध्यान देने की आवश्यकता होती है: ऑपरेटिंग सिस्टम और कंटेनर रनटाइम से लेकर व्यक्तिगत पॉड्स तक। सही कॉन्फ़िगरेशन क्लस्टर के निर्बाध संचालन, बाहरी संसाधनों तक सुरक्षित पहुंच और कॉर्पोरेट सुरक्षा नीतियों के अनुपालन को सुनिश्चित करता है।

याद रखने के लिए मुख्य बिंदु:

• प्रॉक्सी को सभी स्तरों पर सेट करें: OS, कंटेनर रनटाइम, kubelet, पॉड्स
• NO_PROXY को सही ढंग से कॉन्फ़िगर करें, जिसमें क्लस्टर के सभी आंतरिक नेटवर्क शामिल हैं
• ConfigMap के माध्यम से केंद्रीकृत प्रबंधन का उपयोग करें
• प्रॉक्सी सर्वरों की उपलब्धता और प्रदर्शन की निगरानी करें
• उत्पादन में लागू करने से पहले परिवर्तनों का परीक्षण करें

महत्वपूर्ण Kubernetes क्लस्टरों के लिए, उच्च उपलब्धता और कम विलंबता के साथ विश्वसनीय डेटा सेंटर प्रॉक्सी का उपयोग करने की सिफारिश की जाती है। यह अवसंरचना के स्थिर संचालन को सुनिश्चित करेगा और नेटवर्क पहुंच से संबंधित समस्याओं के कारण डाउनटाइम के जोखिम को कम करेगा।

समस्याओं के उत्पन्न होने पर, निदान के लिए एक प्रणालीबद्ध दृष्टिकोण का उपयोग करें: प्रत्येक स्तर पर सेटिंग्स की जांच करें, लॉग और घटनाओं का विश्लेषण करें, और मैन्युअल रूप से कनेक्शन का परीक्षण करें। Kubernetes में प्रॉक्सी से संबंधित अधिकांश समस्याएँ पर्यावरण चर और NO_PROXY की सही सेटिंग से हल होती हैं।