Kubernetes Ingress Controller için Proxy: yapılandırma

```html

K8s kümeniz dışa doğru istekler yapıyorsa - ortak API'lere, pazar yerlerine, reklam platformlarına - bir noktada IP engellemeleri ile karşılaşacaksınız. Ingress Controller kendisi gelen trafiği yönetir, ancak podlar aracılığıyla giden istekler için ayrı bir proxy şemasına ihtiyaç vardır. Bu yazıda, bunu doğru bir şekilde nasıl yapılandıracağınızı inceliyoruz: proxy türünün seçilmesinden, NGINX Ingress ve Traefik için belirli YAML yapılandırmalarına kadar.

Kubernetes'te proxy neden gerekli: gerçek senaryolar

Kubernetes bir orkestratördür ve çoğu makale, gelen trafiği ele alır: Ingress nasıl yapılandırılır, TLS sertifikası nasıl verilir, istekler hizmetlere nasıl yönlendirilir. Ancak başka bir tarafı da vardır: podlardan çıkan trafik. İşte burada engellemeler, coğrafi kısıtlamalar ve IP limitleri ile ilgili sorunlar ortaya çıkar.

K8s kümesinde proxy'nin gereklilik haline geldiği belirli görevleri inceleyelim:

Fiyatların parsellenmesi ve izlenmesi. Kümeniz her 15 dakikada bir CronJob çalıştırıyor ve Wildberries, Ozon, Amazon'dan veri topluyor. IP döngüsü olmadan, 2-3 saat içinde bulut sağlayıcınızın IP aralığında yasak alırsınız.
Reklam API'leri ile çalışma. Facebook Marketing API, TikTok Ads API, Google Ads API - hepsi isteklerin kaynağını izler. Eğer onlarca pod bir veri merkezi IP'sinden istek gönderiyorsa, bu otomatik yasaklama için bir tetikleyicidir.
Coğrafi testler. Servisiniz, farklı ülkelerden gelen kullanıcılara farklı içerikler göstermelidir. Proxy aracılığıyla podlar, otomatik testler için gerekli bölgelerden istekleri taklit edebilir.
Kurumsal kısıtlamaların aşılması. Bazı altyapılarda, tüm çıkan trafik kurumsal bir proxy üzerinden gitmelidir - bu, uyum gereksinimidir.
IP beyaz listesindeki ortak API'lerle çalışma. Ortak, yalnızca belirli IP'lerden gelen istekleri kabul ediyorsa ve kümeniz ölçeklenip adresleri değiştiriyorsa - statik IP'li bir proxy sorunu çözer.

Mimari ayrımı anlamak önemlidir: Ingress Controller gelen trafiği yönetir (kullanıcılardan hizmetlerinize), ancak çıkan istekler için proxy ayrı bir görevdir. Bununla birlikte, bunlar bağlantılıdır: proxy yapılandırması genellikle aynı Ingress Controller seviyesinde veya onun okuduğu anotasyonlar aracılığıyla belirlenir.

💡 Temel ayrım

Bu yazıda iki senaryoyu inceliyoruz: (1) Ingress Controller'ı dış upstream sunucular için ters proxy olarak yapılandırma ve (2) podlardan çıkan trafiği dış proxy sunucusu aracılığıyla yönlendirme. Her iki senaryo da üretimde karşılaşılmaktadır.

K8s kümesi için hangi proxy türünü seçmeliyim

Proxy türünün seçimi, kümenizin ne kadar süre boyunca engellenmeden çalışabileceğini doğrudan etkiler. Veri merkezi IP'leri en ucuz olanlardır, ancak bunları tanımlamak ve engellemek kolaydır. Yerleşik ve mobil IP'ler daha pahalıdır, ancak gerçek bir kullanıcının taklit edilmesi gereken görevler için çok daha güvenilirdir.

Proxy Türü	Hız	Engellenme Riski	K8s'de En İyi Senaryo
Veri Merkezi	Yüksek	Yüksek	İç API'ler, kurumsal uyum, IP beyaz listesi ile ortak entegrasyonlar
Yerleşik	Orta	Düşük	Pazar yerlerinin parsellenmesi, reklam API'leri ile çalışma, coğrafi testler
Mobil	Orta	Minimum	Facebook Ads API, TikTok API, yasaklama riski olan yüksek yük görevleri

K8s kümesindeki çoğu görev için, özellikle parselleme veya reklam platformları ile ilgili olanlar için, en iyi seçim döngüsel yerleşik proxy'lerdir. Gerçek ev kullanıcılarının IP'lerini sağlarlar ve web sitelerinin koruma algoritmaları bu tür istekleri normal tarayıcı trafiği olarak algılar.

K8s için protokol açısından en evrensel olanı HTTP/HTTPS proxy'dir - tüm popüler HTTP istemcileri tarafından desteklenir ve her programlama dilinde standart ortam değişkenleri HTTP_PROXY ve HTTPS_PROXY aracılığıyla okunur. SOCKS5 yalnızca standart olmayan protokoller için veya yalnızca HTTP'yi proxylemek gerektiğinde gereklidir.

NGINX Ingress Controller aracılığıyla proxy yapılandırması

NGINX Ingress Controller, K8s'deki en yaygın seçenektir. İki senaryoyu inceleyelim: NGINX'i dış bir upstream'e proxy sunucusu olarak yapılandırma ve kontrolör için küresel bir çıkış proxy yapılandırması.

Upstream'e istekleri proxylemek için anotasyonlar

NGINX Ingress, proxy davranışını yönetmek için anotasyonları destekler. Ingress'in dış bir servise istekleri ara proxy üzerinden iletmesini istiyorsanız, özel bir yapılandırma ile ConfigMap kullanın:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
data:
  # NGINX için çıkış istekleri için küresel HTTP proxy
  http-snippet: |
    proxy_connect_timeout 10s;
    proxy_read_timeout 30s;
    proxy_send_timeout 30s;
  # Proxy üzerinden upstream yapılandırması
  use-proxy-protocol: "false"
  proxy-real-ip-cidr: "0.0.0.0/0"

Proxy için anotasyonlarla Ingress kaynağı

Ayrı bir Ingress kaynağı için proxy parametrelerini anotasyonlar aracılığıyla belirleyebilirsiniz. Bu, farklı hizmetlerin farklı zaman aşımı ve ayar gerektirdiği durumlarda yararlıdır:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-service-ingress
  namespace: production
  annotations:
    kubernetes.io/ingress.class: "nginx"
    # Proxy zaman aşım süreleri
    nginx.ingress.kubernetes.io/proxy-connect-timeout: "10"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "60"
    # Tampon boyutu
    nginx.ingress.kubernetes.io/proxy-buffer-size: "16k"
    nginx.ingress.kubernetes.io/proxy-buffers-number: "8"
    # Gerçek istemci IP'sinin iletilmesi
    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 podunun çıkış istekleri için dış proxy yapılandırması

Eğer NGINX Ingress Controller'ın dış bir proxy üzerinden çıkış istekleri yapması gerekiyorsa (örneğin, dış uç noktaların sağlık kontrolü için), kontrolörün Dağıtımında ortam değişkenlerini belirtmeniz gerekir:

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 değişkenine dikkat edin - bu kritik öneme sahiptir. Olmadan, tüm iç küme trafiği de dış proxy üzerinden gidecek ve hizmetler arasındaki etkileşimi bozacaktır. NO_PROXY içinde her zaman RFC-1918 aralıklarını ve .cluster.local son ekini ekleyin.

Traefik Ingress Controller'da proxy yapılandırması

Traefik, özellikle Helm ile birlikte ve yönetilen kümelerde (k3s, Docker Swarm, Nomad) popüler bir NGINX Ingress alternatifidir. Traefik, CRD (Özel Kaynak Tanımları) aracılığıyla kendi yapılandırma sistemine ve statik/dinamik yapılandırmalara sahiptir.

Proxy ile Traefik'in statik yapılandırması

apiVersion: v1
kind: ConfigMap
metadata:
  name: traefik-config
  namespace: traefik
data:
  traefik.yaml: |
    # Traefik'in statik yapılandırması
    entryPoints:
      web:
        address: ":80"
      websecure:
        address: ":443"
    
    # Proxy ile çalışma ayarları
    serversTransport:
      insecureSkipVerify: false
      maxIdleConnsPerHost: 200
      dialTimeout: 10s
      responseHeaderTimeout: 30s
    
    # Proxy için tanılama kaydı
    log:
      level: INFO
    
    accessLog:
      fields:
        headers:
          defaultMode: keep
          names:
            X-Forwarded-For: keep
            X-Real-IP: keep

Proxy başlıklarını eklemek için Middleware

Traefik'te, istekleri iletme sırasında başlıkları ekleyen veya değiştiren bir Middleware oluşturabilirsiniz. Bu, gerçek istemci IP'sinin proxy zinciri aracılığıyla doğru bir şekilde iletilmesi için yararlıdır:

apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: proxy-headers
  namespace: production
spec:
  headers:
    customRequestHeaders:
      X-Forwarded-Proto: "https"
    # Altyapıyı açığa çıkarabilecek başlıkları kaldır
    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 Dağıtımı için ortam değişkenleri

NGINX'te olduğu gibi, Traefik için ortam değişkenlerini Helm değerleri aracılığıyla veya doğrudan Dağıtımda belirleyebilirsiniz. Helm şemasını kullanırken, bu values.yaml aracılığıyla yapılır:

# Traefik Helm şeması için 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"

Podlar içinde ortam değişkenleri aracılığıyla proxy

Herhangi bir pod için çıkış proxy'sini yapılandırmanın en evrensel yolu, standart ortam değişkenleri aracılığıyladır. Bu yöntem, programlama dili ve çerçevesinden bağımsız olarak çalışır: Python istekleri, Go net/http, Node.js axios, Java HttpClient - hepsi HTTP_PROXY ve HTTPS_PROXY değerlerini otomatik olarak okur.

Seçenek 1: Doğrudan Pod Spec içinde

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"

⚠️ Kimlik bilgilerini açıkta saklamayın!

Yukarıdaki örnek, görsellik açısından gösterilmiştir. Üretimde proxy kimlik bilgileri her zaman Kubernetes Secret içinde saklanmalı ve secretKeyRef aracılığıyla iletilmelidir. Daha fazla bilgi için aşağıdaki Secrets bölümüne bakın.

Seçenek 2: Birden fazla pod için ConfigMap aracılığıyla

Eğer proxy'ler birden fazla Dağıtım kullanıyorsa, ayarları ConfigMap'e çıkarmak ve envFrom aracılığıyla bağlamak uygundur:

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

Seçenek 3: Mütasyon WebhookAdmissionController

Tüm podların proxy kullanmasının zorunlu olduğu kurumsal kümelerde, tüm oluşturulan podlara otomatik olarak proxy ortam değişkenlerini ekleyen bir mütasyon admission webhook'u ayarlayabilirsiniz. Bu çözüm, uyum gereksinimlerinin tüm çıkan trafiğin kurumsal proxy üzerinden gitmesini gerektirdiği kurumsal altyapılarda kullanılır. Böyle bir webhook'un uygulanması bu yazının kapsamını aşar, ancak varlığını bilmek önemlidir.

K8s'de IP döngüsü ve proxy havuzunu yönetme

Statik proxy, kurumsal uyum için iyi bir çözümdür, ancak engellemelerden kaçınmanız gereken görevler için kötü bir seçimdir. Eğer 50 pod'unuz aynı IP üzerinden istek gönderiyorsa, bu IP çok hızlı bir şekilde engellenecektir. Çözüm - proxy döngüsüdür.

Proxy Sidecar Şeması

Bir desen, proxy ajanını ana uygulamanın yanında bir sidecar konteyner olarak çalıştırmaktır. Sidecar, localhost:8080 üzerinde gelen istekleri alır ve bunları dönen bir dış proxy havuzuna iletir:

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:
      # Ana uygulama
      - 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: döngüsel yerleşik proxy ajanı
      - 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"  # her 60 saniyede bir döngü
        resources:
          requests:
            memory: "64Mi"
            cpu: "50m"
          limits:
            memory: "128Mi"
            cpu: "200m"

Merkezi Proxy Servis Şeması

Alternatif bir yaklaşım, tüm podların başvurduğu tek bir Proxy Servisidir. Bu, yönetimi daha kolay hale getirir: sadece bir Secret'ı proxy kimlik bilgileri ile güncellemek yeterlidir ve tüm podlar otomatik olarak yeni verileri kullanmaya başlar.

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
---
# Podlar proxy'yi iç DNS üzerinden kullanır
# HTTP_PROXY=http://proxy-gateway.proxy-system.svc.cluster.local:8080

Anonimlik ve engellenme riskinin minimum olduğu görevler için (örneğin, pazar yerlerinin parsellenmesi veya reklam API'leri ile çalışma), döngüsel yerleşik proxy'leri kullanmanızı öneririz - bunlar gerçek ev kullanıcılarının IP'lerini sağlar ve bu da kümenizden gelen trafiği normal tarayıcı trafiği ile ayırt edilemez hale getirir.

Kubernetes Secrets içinde proxy kimlik bilgilerini saklama

Kimlik bilgilerini güvenli bir şekilde saklamak, herhangi bir üretim kümesi için zorunlu bir gerekliliktir. Asla proxy kullanıcı adı/şifresini doğrudan Git deposunda saklanan YAML manifestolarına yerleştirmeyin.

Proxy için Secret oluşturma

# kubectl ile oluşturma (değerler otomatik olarak base64 olarak kodlanır)
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'

# Oluşturulan Secret'ı kontrol etme
kubectl get secret proxy-credentials -n production -o yaml

Secret için YAML manifestosu

apiVersion: v1
kind: Secret
metadata:
  name: proxy-credentials
  namespace: production
  labels:
    app: proxy-config
    managed-by: ops-team
type: Opaque
# Değerler base64 olarak kodlanmıştır
# echo -n 'http://user:pass@proxy:8080' | base64
stringData:
  # stringData, değerleri açık bir şekilde belirtmeye izin verir
  # Kubernetes bunları otomatik olarak base64 olarak kodlar
  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'ta Secret kullanma

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"
        # Ayrı olarak host/port okuyan uygulamalar için
        - name: PROXY_HOST
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: proxy-host
        - name: PROXY_PORT
          valueFrom:
            secretKeyRef:
              name: proxy-credentials
              key: proxy-port

Dış gizli depolarla entegrasyon

Kurumsal ortamda, HashiCorp Vault, AWS Secrets Manager veya Azure Key Vault'tan gizli bilgilerin senkronizasyonu için External Secrets Operator kullanılması önerilir. Bu, proxy kimlik bilgilerini manuel müdahale olmadan ve podları yeniden başlatmadan otomatik olarak güncellemeyi sağlar:

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'de proxy yapılandırması ile ilgili tanılama ve yaygın hatalar

Doğru yapılandırmaya rağmen sorunlar ortaya çıkabilir. En yaygın olanları ve tanılama yöntemlerini inceleyelim.

Sorun 1: İç küme trafiği proxy üzerinden gidiyor

Belirti: podlar birbirlerini göremez, iç küme DNS çözümü bozulur, hizmetler yanıt vermez. Sebep - NO_PROXY değişkeni ayarlanmamıştır.

Standart bir K8s kümesi için minimum gerekli NO_PROXY değeri:

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

Sorun 2: Proxy belirli bir pod'a uygulanmıyor

Tanılama: pod'a girin ve ortam değişkenlerini kontrol edin:

# Pod'daki ortam değişkenlerini kontrol etme
kubectl exec -it <pod-name> -n production -- env | grep -i proxy

# Pod'dan proxy üzerinden bağlantı testi
kubectl exec -it <pod-name> -n production -- curl -v --proxy http://proxy:8080 https://httpbin.org/ip

# Secret'ın doğru bir şekilde monte edildiğini kontrol etme
kubectl exec -it <pod-name> -n production -- env | grep PROXY

Sorun 3: HTTPS proxy kullanırken TLS hataları

Eğer proxy kendinden imzalı bir sertifika veya kurumsal CA kullanıyorsa, uygulamalar TLS doğrulama hataları alacaktır. Çözüm - proxy CA sertifikasını güvenilirler arasına eklemektir:

# CA sertifikası ile ConfigMap oluşturma
kubectl create configmap proxy-ca-cert \
  --from-file=proxy-ca.crt=./proxy-ca.crt \
  -n production

# Pod'a monte etme
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

Sorun 4: Proxy üzerinden yavaş istekler

Eğer proxy üzerinden yapılan istekler doğrudan olanlardan önemli ölçüde yavaşsa, kontrol edin:

DNS çözümü: DNS isteklerinin proxy üzerinden gitmediğinden emin olun (ekleyin NO_PROXY)
Keep-alive bağlantıları: proxy sunucusuna bağlantı havuzunu ayarlayın
Coğrafi konum: proxy sunucusu hedef kaynağa fiziksel olarak yakın olmalıdır
Proxy türü: yüksek hızlı görevler için veri merkezi proxy'lerini düşünün - bunlar minimum gecikme sağlar

Tanılama için yararlı komutlar

# Ingress Controller loglarını kontrol etme
kubectl logs -n ingress-nginx -l app.kubernetes.io/name=ingress-nginx --tail=100

# Pod olaylarını kontrol etme
kubectl describe pod <pod-name> -n production

# Pod'dan proxy bağlantı testi
kubectl run test-proxy --image=curlimages/curl --rm -it --restart=Never -- \
  curl -x http://user:pass@proxy:8080 -v https://httpbin.org/ip

# Secret'ın var olduğunu ve gerekli anahtarları içerdiğini kontrol etme
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]}...')
"

Sonuç ve öneriler

Kubernetes'te proxy yapılandırması, tek seferlik bir görev değil, kümenin ağ güvenliği mimarisinin bir parçasıdır. Özetleyelim:

NGINX Ingress Controller için - belirli Ingress kaynakları seviyesinde proxy ayarlarını yapılandırmak için anotasyonları ve küresel çıkış trafiği ayarları için Dağıtımda ortam değişkenlerini kullanın.
Traefik için - başlıkları yönetmek için ConfigMap aracılığıyla statik yapılandırmayı Middleware ile birleştirin.
Podlar için - HTTP_PROXY / HTTPS_PROXY standart değişkenleri aracılığıyla Secrets - en evrensel ve güvenli yaklaşımdır.
Her zaman NO_PROXY'yi ayarlayın - aksi takdirde iç küme trafiği bozulacaktır.
Proxy kimlik bilgilerini asla açıkta saklamayın manifestolar veya Git içinde.
Üretim için - otomatik kimlik bilgisi döngüsü için External Secrets Operator kullanın.

Eğer K8s kümeniz, IP'nin kararlılığı ve engellenme riskinin minimum olduğu görevleri yerine getiriyorsa - parselleme, reklam API'leri ile çalışma, coğrafi testler - döngüsel yerleşik proxy'leri kullanmanızı öneririz. Bunlar, koruma algoritmalarının meşru trafik olarak algıladığı gerçek ev kullanıcılarının IP'lerini sağlar. Hız ve engellenme riskinin minimum olduğu mobil platformlar için mobil proxy'ler mükemmel bir seçimdir - bunlar gerçek 4G/5G ağları üzerinden çalışır.