Kubernetes Kümelerinde Proxy Ayarları: DevOps Mühendisleri için Kapsamlı Rehber

Kurumsal bir ortamda veya bir güvenlik duvarının arkasında Kubernetes dağıtımı yaparken, dış kaynaklara erişim için bir proxy sunucusunun ayarlanması sıkça gereklidir. Bu, konteyner görüntülerinin indirilmesi, paketlerin güncellenmesi ve dış API'lerle etkileşim için kritik öneme sahiptir. Bu kılavuzda, Kubernetes'te proxy ayarlarının tüm seviyelerini inceleyeceğiz - düğüm yapılandırmasından bireysel podlara kadar.

Kubernetes kümelerinde proxyye neden ihtiyaç var

Kubernetes kümeleri, kurumsal ortamda genellikle sınırlı internet erişimi olan izole ağlarda çalışır. Proxy sunucusu birkaç kritik görevi yerine getirir:

• Konteyner görüntülerinin indirilmesi — Docker Hub, Google Container Registry, özel kayıtlar dış erişim gerektirir
• Paketlerin güncellenmesi — konteynerler içinde apt, yum, pip ile bağımlılıkların kurulması
• Dış API'lere erişim — bulut hizmetleri, izleme, günlükleme ile entegrasyon
• Güvenlik — trafik kontrolü, alan adı filtreleme, isteklerin günlüklenmesi
• Önbellekleme — aynı kaynaklara tekrar eden isteklerin hızlandırılması

Doğru proxy ayarı yapılmadığında, uygulamaları dağıtmaya çalışırken "image pull failed", "connection timeout" veya "network unreachable" gibi hatalarla karşılaşabilirsiniz. Bu, her saniyenin para kaybı olduğu otomatik CI/CD boru hatları için özellikle kritiktir.

Kubernetes'te proxy ayar seviyeleri

Kubernetes çok katmanlı bir mimariye sahiptir ve proxy, görevlerine bağlı olarak her seviyede ayarlanmalıdır:

Her seviye ayrı bir ayar gerektirir ve herhangi birinin atlanması sorunlara yol açabilir. Örneğin, sadece Docker için proxy ayarlarsanız, ancak podlar için ayarlamazsanız, görüntüler indirilebilir, ancak konteynerler içindeki uygulamalar dış API'lere erişemez.

Docker ve containerd için proxy ayarı

Container runtime, dış kayıtlarından konteyner görüntülerinin indirilmesinden sorumlu olduğu için ayarlanması gereken ilk bileşendir. Her iki popüler runtime için ayarları inceleyelim.

Docker için proxy ayarı

Docker için, Docker hizmetine ortam değişkenlerini ekleyecek bir systemd drop-in dosyası oluşturmalısınız:

# Yapılandırma için dizin oluştur
sudo mkdir -p /etc/systemd/system/docker.service.d

# Proxy ayarları içeren dosya oluştur
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 yapılandırmasını yeniden yükle
sudo systemctl daemon-reload

# Docker'ı yeniden başlat
sudo systemctl restart docker

# Ayarların uygulandığını kontrol et
sudo systemctl show --property=Environment docker

Bundan sonra Docker, proxy sunucusu üzerinden görüntüleri indirebilecektir. Çalıştığını kontrol etmek için şu komutu kullanabilirsiniz:

docker pull nginx:latest

Containerd için proxy ayarı

Containerd, modern Kubernetes kümelerinde ana container runtime olarak kullanılmaktadır. Proxy ayarı biraz farklıdır:

# Yapılandırma için dizin oluştur
sudo mkdir -p /etc/systemd/system/containerd.service.d

# Proxy ayarları içeren dosya oluştur
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

# Yapılandırmayı yeniden yükle
sudo systemctl daemon-reload
sudo systemctl restart containerd

# Durumu kontrol et
sudo systemctl status containerd

Kubelet için proxy yapılandırması

Kubelet, her küme düğümünde çalışan Kubernetes ajanıdır. API sunucusuna ve dış kaynaklara erişimi de gereklidir. Ayar, Kubernetes'in kurulum yöntemine bağlıdır.

kubeadm kümeleri için

Eğer kubeadm kullanıyorsanız, proxy ayarlarını systemd üzerinden yapmalısınız:

# Kubelet yapılandırması için dizin oluştur
sudo mkdir -p /etc/systemd/system/kubelet.service.d

# Proxy ayarları içeren dosya oluştur
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'i yeniden başlat
sudo systemctl daemon-reload
sudo systemctl restart kubelet

Yönetilen Kubernetes için (EKS, GKE, AKS)

Yönetilen Kubernetes hizmetlerinde kubelet ayarları genellikle düğüm başlatma parametreleri veya kullanıcı verisi betikleri aracılığıyla yapılır. Örneğin, AWS EKS için:

#!/bin/bash
# EKS işçi düğümleri için kullanıcı verisi betiği

# Sistem için proxy ayarı
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 için ayar
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'ye 169.254.169.254 eklemeyi unutmayın — bu, proxy olmadan erişilmesi gereken AWS metadata hizmetinin adresidir.

Pod seviyesinde proxy ayarı

Docker ve kubelet için proxy ayarlarını yapmış olsanız bile, podlar içindeki uygulamalar otomatik olarak proxy kullanmaz. Kubernetes manifestolarında ortam değişkenlerini açıkça belirtmeniz gerekir.

Deployment manifestosu aracılığıyla ayar

En basit yol, konteyner spesifikasyonuna ortam değişkenlerini eklemektir:

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

Merkezi yapılandırma için ConfigMap kullanımı

Her Deployment'da proxy ayarlarını tekrarlamamak için bir ConfigMap oluşturun:

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"

Ardından, bu ConfigMap'i Deployment'da kullanın:

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

Bu yaklaşım yönetimi kolaylaştırır: proxy adresi değiştiğinde, sadece ConfigMap'i güncellemek yeterlidir ve podlar yeniden başlatıldığında yeni ayarlar otomatik olarak uygulanır.

MutatingWebhook ile otomatik enjekte etme

Tüm podlara proxy değişkenlerini otomatik olarak eklemek için MutatingAdmissionWebhook kullanabilirsiniz. Bu, kendi webhook hizmetinizi geliştirmenizi gerektiren gelişmiş bir yaklaşımdır, ancak manifestoları değiştirmeden merkezi olarak ayarları yönetmenizi sağlar.

DOĞRU NO_PROXY yapılandırması

NO_PROXY değişkeni, hangi adreslerin ve alan adlarının proxy sunucusunu atlaması gerektiğini belirler. NO_PROXY'nin yanlış yapılandırılması, Kubernetes kümelerinde en yaygın sorunların başında gelir.

Kubernetes için zorunlu istisnalar

Aşağıdaki adresler ve aralıklar HER ZAMAN NO_PROXY'de olmalıdır:

Tam NO_PROXY yapılandırması örneği

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

Proxy üzerinden çalışacak şekilde kubectl ayarı

Eğer proxy arkasında bulunan bir çalışma istasyonundan bir küme yönetiyorsanız, kubectl için ortam değişkenlerini ayarlayın:

# Linux/macOS için - ~/.bashrc veya ~/.zshrc dosyasına ekleyin
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 için
$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"

Bundan sonra kubectl, küme API sunucusuna proxy üzerinden bağlanabilecektir. Çalıştığını kontrol edin:

kubectl cluster-info
kubectl get nodes

Kimlik doğrulamalı proxy ayarı

Eğer proxy sunucusu kimlik doğrulaması gerektiriyorsa, kimlik bilgilerini URL'ye ekleyin:

export HTTP_PROXY=http://username:password@proxy.company.com:8080
export HTTPS_PROXY=http://username:password@proxy.company.com:8080

Tipik sorunların teşhisi ve çözümü

Doğru ayar yapılandırmasına rağmen sorunlar ortaya çıkabilir. En sık karşılaşılan hataları ve çözümlerini inceleyelim.

Görüntüleri indirirken "ImagePullBackOff" hatası

Belirtiler: Podlar başlatılamıyor, olaylarda "Failed to pull image" veya "connection timeout" hatası gösteriliyor.

Teşhis:

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

# Docker/containerd'deki proxy ayarlarını kontrol et
sudo systemctl show --property=Environment docker
sudo systemctl show --property=Environment containerd

# Düğümde görüntüyü manuel olarak indirmeyi dene
sudo docker pull nginx:latest
sudo crictl pull nginx:latest

Çözüm: Proxy'nin container runtime için ayarlandığından ve görüntü kayıt defterinin alan adının NO_PROXY'de olmadığından emin olun.

Küme içinde DNS çözümleme sorunları

Belirtiler: Podlar, DNS adlarıyla birbirlerine erişemiyor (örneğin, service-name.namespace.svc.cluster.local).

Teşhis:

# Pod'dan DNS'i kontrol et
kubectl run -it --rm debug --image=busybox --restart=Never -- nslookup kubernetes.default

# Pod'daki proxy değişkenlerini kontrol et
kubectl exec -it <pod-name> -- env | grep PROXY

Çözüm: NO_PROXY'ye .cluster.local ve .svc ekleyin.

Dış API'lere erişimde yavaşlık veya zaman aşımı

Belirtiler: Uygulamalar yavaş çalışıyor veya dış hizmetlere isteklerde zaman aşımı alıyor.

Teşhis:

# Pod'dan proxy'nin erişilebilirliğini kontrol et
kubectl exec -it <pod-name> -- curl -v -x http://proxy.company.com:8080 https://www.google.com

# Yanıt süresini ölç
kubectl exec -it <pod-name> -- time curl -x http://proxy.company.com:8080 https://api.example.com

Çözüm: Sorun proxy sunucusunun performansında olabilir. Gecikmeleri azaltmak için coğrafi olarak yakın residential proxy'ler kullanmayı düşünün.

Proxy üzerinden çalışırken SSL/TLS hataları

Belirtiler: "certificate verify failed" veya "SSL handshake failed" gibi hatalar.

Neden: Bazı proxy sunucuları SSL denetimi (HTTPS trafiğinin şifre çözümü) yapar, bu da proxy'nin kök sertifikasının yüklenmesini gerektirir.

Çözüm:

# Proxy sertifikası ile ConfigMap oluştur
kubectl create configmap proxy-ca-cert --from-file=ca.crt=/path/to/proxy-ca.crt

# Sertifikayı pod'a monte et ve sistem deposuna ekle
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

Üretimde proxy için en iyi uygulamalar

Kurumsal ortamda Kubernetes kümelerinin işletim deneyimlerine dayanarak, proxy ile güvenilir bir çalışma için öneriler:

1. Yüksek erişilebilir proxy sunucuları kullanın

Proxy, tüm küme için tek bir hata noktası haline gelir. Birden fazla proxy sunucusunu yük dengeleyici arkasında ayarlayın:

HTTP_PROXY=http://proxy-lb.company.com:8080

Burada proxy-lb.company.com — birden fazla proxy sunucusunun önündeki yük dengeleyicisidir.

2. Merkezi yapılandırma yönetimi

Her manifestoda sabit kodlama yerine proxy ayarlarını saklamak için ConfigMap veya Secret kullanın:

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. İzleme ve uyarı

Proxy sunucularının erişilebilirliğini izleyin ve sorunlar olduğunda uyarılar ayarlayın:

• Proxy yanıt süresi (yerel proxy'ler için < 100ms olmalıdır)
• Proxy bağlantı hatalarının sayısı
• Kümedeki ImagePullBackOff olaylarının sayısı
• Proxy sunucularındaki CPU ve ağ yükü

4. NO_PROXY istisnalarını belgeleyin

NO_PROXY'ye eklenen alan adları ve IP adresleri hakkında belge tutun. Bu, sorun giderme ve güvenlik denetiminde yardımcı olacaktır.

5. Değişiklikleri dev ortamında test edin

Üretimde proxy ayarlarını değiştirmeden önce her zaman dev/staging kümesinde test edin:

# Proxy'yi kontrol etmek için test podu
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"

# Dış kaynakların erişilebilirliğini kontrol et
kubectl exec -it proxy-test -- curl -v https://registry.k8s.io
kubectl exec -it proxy-test -- curl -v https://docker.io

6. Farklı görevler için farklı proxy türleri kullanın

Kritik bileşenler (görüntü indirme, küme API'si) için hızlı veri merkezi proxy'leri kullanın, coğrafi çeşitlilik gerektiren uygulamalar için ise residential veya mobil proxy'ler kullanın.

7. NO_PROXY listesini düzenli olarak güncelleyin

Yeni hizmetler eklediğinizde veya ağ topolojisini değiştirdiğinizde NO_PROXY'yi güncelleyin. Bunu Helm chart'ları veya Kustomize ile otomatikleştirin:

# Helm chart için 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

Sonuç

Kubernetes kümelerinde proxy ayarı, işletim sistemi ve container runtime'dan bireysel podlara kadar her seviyede dikkat gerektiren çok katmanlı bir görevdir. Doğru yapılandırma, kümenin kesintisiz çalışmasını, dış kaynaklara güvenli erişimi ve kurumsal güvenlik politikalarına uyumu sağlar.

Hatırlanması gereken ana noktalar:

• Proxy ayarlarını tüm seviyelerde yapın: OS, container runtime, kubelet, podlar
• NO_PROXY'yi doğru yapılandırın, kümenin tüm iç ağlarını dahil edin
• ConfigMap aracılığıyla merkezi yönetim kullanın
• Proxy sunucularının erişilebilirliğini ve performansını izleyin
• Üretimde uygulamadan önce değişiklikleri test edin

Kritik öneme sahip Kubernetes kümeleri için, yüksek erişilebilirlik ve düşük gecikme süreleri ile güvenilir veri merkezi proxy'leri kullanmanızı öneririz. Bu, altyapının kararlı çalışmasını sağlar ve ağ erişim sorunlarından kaynaklanan kesinti risklerini en aza indirir.

Sorunlarla karşılaştığınızda, sistematik bir teşhis yaklaşımı kullanın: her seviyedeki ayarları kontrol edin, günlükleri ve olayları analiz edin, bağlantıyı manuel olarak test edin. Kubernetes'teki proxy ile ilgili çoğu sorun, ortam değişkenlerinin ve NO_PROXY'nin doğru yapılandırılması ile çözülmektedir.