Wenn Ihr K8s-Cluster externe Anfragen stellt – an Partner-APIs, an Marktplätze, an Werbeplattformen – werden Sie früher oder später mit IP-Sperren konfrontiert. Der Ingress Controller verwaltet selbst den eingehenden Datenverkehr, aber für ausgehende Anfragen über Pods ist ein separates Schema mit einem Proxy erforderlich. In diesem Artikel erklären wir, wie man dies richtig einrichtet: von der Auswahl des Proxytyps bis zu konkreten YAML-Konfigurationen für NGINX Ingress und Traefik.
Warum Proxys in Kubernetes: reale Szenarien
Kubernetes ist ein Orchestrator, und die meisten Artikel darüber sprechen über eingehenden Datenverkehr: wie man Ingress einrichtet, wie man ein TLS-Zertifikat ausstellt, wie man Anfragen an Dienste weiterleitet. Aber es gibt eine andere Seite: den ausgehenden Datenverkehr von Pods. Hier treten Probleme mit Sperren, Geo-Beschränkungen und IP-Limits auf.
Lassen Sie uns spezifische Aufgaben betrachten, bei denen Proxys in einem K8s-Cluster notwendig werden:
- Preise scrapen und überwachen. Ihr Cluster führt alle 15 Minuten einen CronJob aus und sammelt Daten von Wildberries, Ozon, Amazon. Ohne IP-Rotation erhalten Sie nach 2–3 Stunden eine Sperre für den gesamten IP-Bereich Ihres Cloud-Anbieters.
- Arbeiten mit Werbe-APIs. Facebook Marketing API, TikTok Ads API, Google Ads API – alle verfolgen die Quelle der Anfragen. Wenn Dutzende von Pods Anfragen von einer IP-Adresse eines Rechenzentrums senden, ist das ein Auslöser für eine automatische Sperre.
- Geolokationstests. Ihr Dienst muss unterschiedlichen Inhalt für Benutzer aus verschiedenen Ländern anzeigen. Über Proxys können Pods Anfragen aus den gewünschten Regionen für automatisierte Tests simulieren.
- Umgehung von Unternehmensbeschränkungen. In einigen Infrastrukturen muss der gesamte ausgehende Datenverkehr über einen Unternehmensproxy geleitet werden – dies ist eine Compliance-Anforderung.
- Arbeiten mit Partner-APIs mit IP-Whitelist. Wenn ein Partner Anfragen nur von bestimmten IPs zulässt und Ihr Cluster skaliert und Adressen ändert – löst ein Proxy mit statischen IPs das Problem.
Es ist wichtig, das architektonische Trennungsprinzip zu verstehen: Der Ingress Controller verwaltet den eingehenden Datenverkehr (von Benutzern zu Ihren Diensten), während der Proxy für ausgehende Anfragen eine separate Aufgabe ist. Dennoch sind sie miteinander verbunden: Die Proxy-Konfiguration wird oft auf der Ebene des gleichen Ingress Controllers oder über Annotationen festgelegt, die er liest.
💡 Wichtige Unterscheidung
In diesem Artikel behandeln wir zwei Szenarien: (1) die Einrichtung des Ingress Controllers als Reverse Proxy für externe Upstream-Server und (2) die Weiterleitung des ausgehenden Datenverkehrs von Pods über einen externen Proxy-Server. Beide Szenarien kommen in der Produktion vor.
Welchen Proxytyp für K8s-Cluster wählen
Die Wahl des Proxytyps hat direkten Einfluss darauf, wie lange Ihr Cluster ohne Sperren arbeiten kann. Rechenzentrums-IP-Adressen sind die günstigsten, aber leicht zu identifizieren und zu sperren. Residential und mobile IPs sind teurer, bieten jedoch deutlich mehr Zuverlässigkeit für Aufgaben, bei denen die Simulation eines echten Benutzers wichtig ist.
| Proxytyp | Geschwindigkeit | Sperrrisiko | Bester Anwendungsfall in K8s |
|---|---|---|---|
| Rechenzentrumsproxies | Hoch | Hoch | Interne APIs, Unternehmens-Compliance, Partnerintegrationen mit IP-Whitelist |
| Residential Proxies | Mittel | Niedrig | Scraping von Marktplätzen, Arbeiten mit Werbe-APIs, Geotests |
| Mobile Proxies | Mittel | Minimal | Facebook Ads API, TikTok API, hochbelastete Aufgaben mit Sperrrisiko |
Für die meisten Aufgaben in einem K8s-Cluster, die mit Scraping oder der Arbeit mit Werbeplattformen zu tun haben, ist die optimale Wahl residential Proxies mit Rotation. Sie bieten echte IPs von Haushaltsbenutzern, und die Schutzalgorithmen der Websites betrachten solche Anfragen als normalen Browserdatenverkehr.
Aus Protokollsicht ist der HTTP/HTTPS-Proxy für K8s am vielseitigsten – er wird von allen gängigen HTTP-Clients in jeder Programmiersprache über die Standard-Umgebungsvariablen HTTP_PROXY und HTTPS_PROXY unterstützt. SOCKS5 ist nur für nicht standardisierte Protokolle erforderlich oder wenn nicht nur HTTP proxiert werden soll.
Proxy über NGINX Ingress Controller einrichten
Der NGINX Ingress Controller ist die am weitesten verbreitete Option in K8s. Lassen Sie uns zwei Szenarien betrachten: die Konfiguration von NGINX als Reverse Proxy zu einem externen Upstream über einen Proxy-Server und die globale Konfiguration eines ausgehenden Proxys für den Controller selbst.
Annotationen für das Proxieren von Anfragen an Upstream
NGINX Ingress unterstützt Annotationen zur Steuerung des Proxyverhaltens. Wenn Sie möchten, dass Ingress Anfragen an einen externen Dienst über einen Zwischenproxy weiterleitet, verwenden Sie ein ConfigMap mit einer benutzerdefinierten Konfiguration:
apiVersion: v1
kind: ConfigMap
metadata:
name: nginx-ingress-controller
namespace: ingress-nginx
data:
# Globaler HTTP-Proxy für ausgehende Anfragen von NGINX
http-snippet: |
proxy_connect_timeout 10s;
proxy_read_timeout 30s;
proxy_send_timeout 30s;
# Konfiguration des Upstreams über einen Proxy
use-proxy-protocol: "false"
proxy-real-ip-cidr: "0.0.0.0/0"Ingress-Ressource mit Annotationen für Proxy
Für eine einzelne Ingress-Ressource können Proxyparameter über Annotationen festgelegt werden. Dies ist nützlich, wenn verschiedene Dienste unterschiedliche Zeitüberschreitungen und Einstellungen erfordern:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-service-ingress
namespace: production
annotations:
kubernetes.io/ingress.class: "nginx"
# Proxy-Zeitüberschreitungen
nginx.ingress.kubernetes.io/proxy-connect-timeout: "10"
nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
nginx.ingress.kubernetes.io/proxy-send-timeout: "60"
# Puffergröße
nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"
nginx.ingress.kubernetes.io/proxy-buffers-number: "8"
# Übertragung der realen IP des Clients
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: 80Einrichtung eines externen Proxys für ausgehende Anfragen des NGINX-Pods
Wenn der NGINX Ingress Controller selbst ausgehende Anfragen über einen externen Proxy stellen muss (z. B. für Health-Checks externer Endpunkte), müssen Umgebungsvariablen im Deployment des Controllers festgelegt werden:
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"
Beachten Sie die Variable NO_PROXY – sie ist entscheidend. Ohne sie wird der gesamte intra-cluster Verkehr ebenfalls über den externen Proxy geleitet, was die Interaktion zwischen den Diensten stört. In NO_PROXY sollten immer die RFC-1918-Bereiche und der Suffix .cluster.local enthalten sein.
Proxy im Traefik Ingress Controller einrichten
Traefik ist eine beliebte Alternative zum NGINX Ingress, insbesondere in Kombination mit Helm und in verwalteten Clustern (k3s, Docker Swarm, Nomad). Traefik hat sein eigenes Konfigurationssystem über CRD (Custom Resource Definitions) und statische/dynamische Konfigurationen.
Statische Traefik-Konfiguration mit Proxy
apiVersion: v1
kind: ConfigMap
metadata:
name: traefik-config
namespace: traefik
data:
traefik.yaml: |
# Statische Traefik-Konfiguration
entryPoints:
web:
address: ":80"
websecure:
address: ":443"
# Einstellungen für den Betrieb hinter einem Proxy
serversTransport:
insecureSkipVerify: false
maxIdleConnsPerHost: 200
dialTimeout: 10s
responseHeaderTimeout: 30s
# Logging zur Diagnose des Proxys
log:
level: INFO
accessLog:
fields:
headers:
defaultMode: keep
names:
X-Forwarded-For: keep
X-Real-IP: keepMiddleware zum Hinzufügen von Proxy-Headern
In Traefik können Sie eine Middleware erstellen, die Header beim Weiterleiten von Anfragen hinzufügt oder modifiziert. Dies ist nützlich, um die echte IP des Clients korrekt durch die Proxy-Kette weiterzuleiten:
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
name: proxy-headers
namespace: production
spec:
headers:
customRequestHeaders:
X-Forwarded-Proto: "https"
# Entfernen von Headern, die die Infrastruktur offenbaren könnten
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: 80Umgebungsvariablen für Traefik Deployment
Ähnlich wie bei NGINX legen wir Umgebungsvariablen für Traefik über Helm-Werte oder direkt im Deployment fest. Bei Verwendung des Helm-Charts geschieht dies über values.yaml:
# values.yaml für das Traefik Helm-Chart
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"Proxy über Umgebungsvariablen in Pods
Der universellste Weg, einen ausgehenden Proxy für jeden Pod einzurichten, ist über Standard-Umgebungsvariablen. Diese Methode funktioniert unabhängig von der Programmiersprache und dem Framework: Python requests, Go net/http, Node.js axios, Java HttpClient – alle lesen automatisch HTTP_PROXY und HTTPS_PROXY.
Option 1: Direkt in der Pod-Spezifikation
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"⚠️ Speichern Sie Anmeldeinformationen nicht im Klartext!
Das obige Beispiel dient nur zur Veranschaulichung. In der Produktion sollten Proxy-Anmeldeinformationen immer in Kubernetes Secrets gespeichert und über secretKeyRef übergeben werden. Weitere Informationen finden Sie im Abschnitt über Secrets weiter unten.
Option 2: Über ConfigMap für mehrere Pods
Wenn mehrere Deployments Proxys verwenden, ist es praktisch, die Einstellungen in einer ConfigMap auszulagern und sie über envFrom anzuschließen:
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: 8080Option 3: Mutierender WebhookAdmissionController
Für Unternehmenscluster, in denen alle Pods Proxys verwenden müssen, kann ein mutierender Admission Webhook eingerichtet werden, der automatisch Umgebungsvariablen für Proxys zu allen neu erstellten Pods hinzufügt. Diese Lösung wird in Enterprise-Infrastrukturen verwendet, in denen Compliance erfordert, dass der gesamte ausgehende Datenverkehr über einen Unternehmensproxy geleitet wird. Die Implementierung eines solchen Webhooks geht über den Rahmen dieses Artikels hinaus, aber es ist gut, von seiner Existenz zu wissen.
IP-Rotation und Verwaltung des Proxy-Pools in K8s
Ein statischer Proxy ist gut für Unternehmens-Compliance, aber schlecht für Aufgaben, bei denen Sperren vermieden werden müssen. Wenn 50 Ihrer Pods Anfragen über dieselbe IP senden, wird diese IP sehr schnell gesperrt. Die Lösung ist die Rotation des Proxys.
Schema mit Proxy Sidecar
Ein Muster ist, einen Proxy-Agenten als Sidecar-Container neben der Hauptanwendung zu starten. Das Sidecar nimmt Anfragen auf localhost:8080 entgegen und leitet sie über einen rotierenden Pool externer Proxys weiter:
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:
# Hauptanwendung
- 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: lokaler Proxy-Agent mit Rotation
- 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" # Rotation alle 60 Sekunden
resources:
requests:
memory: "64Mi"
cpu: "50m"
limits:
memory: "128Mi"
cpu: "200m"Schema mit zentralem Proxy-Service
Ein alternativer Ansatz ist ein zentraler Proxy-Service innerhalb des Clusters, auf den alle Pods zugreifen. Dies ist einfacher zu verwalten: Es genügt, ein Secret mit den Proxy-Anmeldeinformationen zu aktualisieren, und alle Pods beginnen automatisch, die neuen Daten zu verwenden.
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
---
# Pods verwenden den Proxy über den internen DNS
# HTTP_PROXY=http://proxy-gateway.proxy-system.svc.cluster.local:8080Für Aufgaben, bei denen Anonymität und minimales Risiko von Sperren entscheidend sind (z. B. Scraping von Marktplätzen oder Arbeiten mit Werbe-APIs), empfehlen wir die Verwendung von residential Proxys mit Rotation – sie bieten echte IPs von Haushaltsbenutzern, was den Datenverkehr aus Ihrem Cluster von normalem Browserdatenverkehr nicht unterscheidbar macht.
Speicherung von Proxy-Anmeldeinformationen in Kubernetes Secrets
Die sichere Speicherung von Anmeldeinformationen ist eine zwingende Anforderung für jeden Produktionscluster. Fügen Sie niemals Benutzernamen/Passwort des Proxys direkt in YAML-Manifeste ein, die in einem Git-Repository gespeichert sind.
Erstellen eines Secrets für den Proxy
# Erstellung über kubectl (Werte werden automatisch in base64 kodiert)
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'
# Überprüfung des erstellten Secrets
kubectl get secret proxy-credentials -n production -o yamlYAML-Manifests für Secrets
apiVersion: v1
kind: Secret
metadata:
name: proxy-credentials
namespace: production
labels:
app: proxy-config
managed-by: ops-team
type: Opaque
# Werte sind in base64 kodiert
# echo -n 'http://user:pass@proxy:8080' | base64
stringData:
# stringData ermöglicht es, Werte im Klartext anzugeben
# Kubernetes kodiert sie automatisch in 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"Verwendung von Secrets im 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"
# Für Anwendungen, die Host/Port separat lesen
- name: PROXY_HOST
valueFrom:
secretKeyRef:
name: proxy-credentials
key: proxy-host
- name: PROXY_PORT
valueFrom:
secretKeyRef:
name: proxy-credentials
key: proxy-portIntegration mit externen Secret-Speichern
In einer Enterprise-Umgebung wird empfohlen, den External Secrets Operator zu verwenden, um Secrets aus HashiCorp Vault, AWS Secrets Manager oder Azure Key Vault zu synchronisieren. Dies ermöglicht es, die Proxy-Anmeldeinformationen automatisch zu aktualisieren, ohne manuelles Eingreifen und ohne Neustart der Pods:
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_urlFehlerbehebung und typische Fehler bei der Proxy-Konfiguration in K8s
Selbst bei korrekter Konfiguration können Probleme auftreten. Lassen Sie uns die häufigsten und die Methoden zur Diagnose durchgehen.
Problem 1: Intra-Cluster-Datenverkehr geht über den Proxy
Symptom: Pods können sich nicht mehr gegenseitig sehen, die DNS-Auflösung innerhalb des Clusters bricht zusammen, Dienste antworten nicht. Grund: Die Variable NO_PROXY ist nicht konfiguriert.
Der minimal erforderliche Wert für NO_PROXY für einen Standard-K8s-Cluster lautet:
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.svcProblem 2: Proxy wird nicht auf einen bestimmten Pod angewendet
Diagnose: Gehen Sie in den Pod und überprüfen Sie die Umgebungsvariablen:
# Überprüfung der Umgebungsvariablen im Pod
kubectl exec -it <pod-name> -n production -- env | grep -i proxy
# Test der Verbindung über den Proxy aus dem Pod
kubectl exec -it <pod-name> -n production -- curl -v --proxy http://proxy:8080 https://httpbin.org/ip
# Überprüfung, ob das Secret korrekt gemountet ist
kubectl exec -it <pod-name> -n production -- env | grep PROXYProblem 3: TLS-Fehler bei Verwendung von HTTPS-Proxys
Wenn der Proxy ein selbstsigniertes Zertifikat oder eine Unternehmens-CA verwendet, erhalten Anwendungen Fehler bei der TLS-Überprüfung. Die Lösung besteht darin, das CA-Zertifikat des Proxys in die vertrauenswürdigen zu integrieren:
# Erstellung eines ConfigMap mit dem CA-Zertifikat
kubectl create configmap proxy-ca-cert \
--from-file=proxy-ca.crt=./proxy-ca.crt \
-n production
# Einbindung in den Pod
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-certProblem 4: Langsame Anfragen über den Proxy
Wenn Anfragen über den Proxy deutlich langsamer sind als direkte Anfragen, überprüfen Sie:
- DNS-Auflösung: Stellen Sie sicher, dass DNS-Anfragen nicht über den Proxy gehen (fügen Sie sie zu
NO_PROXYhinzu) - Keep-Alive-Verbindungen: Richten Sie einen Verbindungs-Pool zum Proxy-Server ein
- Geografische Lage: Der Proxy-Server sollte physisch nahe an der Zielressource sein
- Proxytyp: Für hochgeschwindigkeitsaufgaben ziehen Sie Rechenzentrumsproxies in Betracht – sie bieten minimale Latenz
Nützliche Befehle zur Diagnose
# Überprüfen der Logs des Ingress Controllers
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx --tail=100
# Überprüfen der Ereignisse des Pods
kubectl describe pod <pod-name> -n production
# Test der Proxy-Verbindung aus dem Pod
kubectl run test-proxy --image=curlimages/curl --rm -it --restart=Never -- \
curl -x http://user:pass@proxy:8080 -v https://httpbin.org/ip
# Überprüfen, ob das Secret existiert und die benötigten Schlüssel enthält
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]}...')
"Fazit und Empfehlungen
Die Einrichtung eines Proxys in Kubernetes ist keine einmalige Aufgabe, sondern Teil der Architektur der Netzwerksicherheit des Clusters. Lassen Sie uns die wichtigsten Punkte zusammenfassen:
- Für den NGINX Ingress Controller – verwenden Sie Annotationen zur Konfiguration der Proxy-Parameter auf der Ebene einzelner Ingress-Ressourcen und Umgebungsvariablen im Deployment für globale Einstellungen des ausgehenden Datenverkehrs.
- Für Traefik – kombinieren Sie statische Konfiguration über ConfigMap mit Middleware zur Verwaltung von Headern.
- Für Pods – die Standardvariablen
HTTP_PROXY/HTTPS_PROXYüber Secrets sind der universellste und sicherste Ansatz. - Stellen Sie immer
NO_PROXYein – andernfalls wird der intra-cluster Datenverkehr unterbrochen. - Speichern Sie niemals Proxy-Anmeldeinformationen im Klartext in Manifests oder in Git.
- Für die Produktion – verwenden Sie den External Secrets Operator für die automatische Rotation von Anmeldeinformationen.
Wenn Ihr K8s-Cluster Aufgaben ausführt, bei denen die Stabilität der IP und das minimale Risiko von Sperren entscheidend sind – Scraping, Arbeiten mit Werbe-APIs, Geotests – empfehlen wir die Verwendung von residential Proxys. Sie bieten echte IPs von Haushaltsbenutzern, die von den Schutzalgorithmen als legitimer Datenverkehr wahrgenommen werden. Für Aufgaben mit hohen Anforderungen an die Geschwindigkeit und minimalen Risiken von Sperren durch mobile Plattformen sind mobile Proxys ideal – sie arbeiten über echte 4G/5G-Netze von Anbietern.
```