Kubernetes'te Proxy

Kubernetes'te Pod'lar ve Service'ler için proxy'ler öncelikle giden (egress) trafik için ortam değişkenleri, ayrıntılı kontrol ve service mesh entegrasyonu için sidecar container'lar, gelen (ingress) trafiğin yönetimi için de Ingress kaynakları veya Service türleri üzerinden yapılandırılır. Bu makale, bir Kubernetes ortamında proxy yapılandırmalarının nasıl uygulanacağını ayrıntılı olarak anlatır.

Pod'lar için egress proxy yapılandırması

Pod'ların dış ağlara erişmek, güvenlik politikalarını uygulamak veya küme dışına giden trafiği yönlendirmek için sıklıkla bir egress proxy'ye ihtiyacı olur.

Ortam değişkenleri

Bir Pod içindeki uygulamalar için egress proxy yapılandırmanın en doğrudan yolu, standart HTTP/HTTPS proxy ortam değişkenleridir. Birçok uygulama ve istemci kütüphanesi bu değişkenleri otomatik olarak dikkate alır.

• HTTP_PROXY: HTTP istekleri için proxy sunucusunu belirtir.
• HTTPS_PROXY: HTTPS istekleri için proxy sunucusunu belirtir.
• NO_PROXY: Proxy'yi atlaması gereken sunucu adlarının, alan adlarının veya IP adreslerinin virgülle ayrılmış listesi. Küme içi iletişim için kritiktir (örneğin kubernetes.default.svc, 10.0.0.0/8, *.svc.cluster.local).

Bu değişkenler Pod'un container tanımında belirtilir.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-proxy
spec:
  containers:
  - name: my-app
    image: my-application-image:latest
    env:
    - name: HTTP_PROXY
      value: "http://proxy.internal.domain:3128"
    - name: HTTPS_PROXY
      value: "http://proxy.internal.domain:3128"
    - name: NO_PROXY
      value: "localhost,127.0.0.1,.svc,.cluster.local,10.0.0.0/8" # Örnek: kendi küme CIDR'nize göre ayarlayın

Dinamik proxy yapılandırması için Init Container'lar

Daha karmaşık senaryolarda, bir Init Container ana uygulama container'ı başlamadan önce proxy yapılandırmasını hazırlayabilir veya sertifika enjekte edebilir. Bu şu durumlarda kullanışlıdır:

• Proxy bilgilerinin bir yapılandırma servisinden alınması.
• Kümenin dahili IP aralıklarına göre NO_PROXY listelerinin üretilmesi.
• Proxy'nin gerektirdiği özel CA sertifikalarının enjekte edilmesi.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-init-proxy
spec:
  initContainers:
  - name: init-proxy-config
    image: alpine/git # Örnek: yapılandırmayı çekmek için basit bir imaj
    command: ["sh", "-c", "echo 'HTTP_PROXY=http://dynamic-proxy:3128' > /mnt/proxy/config"]
    volumeMounts:
    - name: proxy-config-volume
      mountPath: /mnt/proxy
  containers:
  - name: my-app
    image: my-application-image:latest
    command: ["sh", "-c", ". /mnt/proxy/config && exec my-app-binary"] # Yapılandırmayı yükle
    volumeMounts:
    - name: proxy-config-volume
      mountPath: /mnt/proxy
  volumes:
  - name: proxy-config-volume
    emptyDir: {}

Egress için sidecar proxy'ler

Sidecar proxy, uygulama container'ıyla aynı Pod içinde çalışır. Uygulama container'ından çıkan tüm trafiği yakalayıp proxy üzerinden yönlendirir. Bu desen şunları sağlar:

• Ağ şeffaflığı: Uygulama container'ının proxy'den haberdar olması gerekmez; proxy mantığını sidecar üstlenir.
• Merkezî politika: Egress politikaları (örneğin izin/ret listeleri, hız sınırlama, kimlik doğrulama) uygulamadan bağımsız olarak sidecar düzeyinde uygulanabilir.
• Gözlemlenebilirlik: Sidecar, tüm giden trafik için metrik, log ve trace üretebilir.

Yaygın sidecar proxy'ler arasında Envoy (Istio tarafından kullanılır) ve Linkerd'in proxy'si bulunur.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-sidecar-egress
spec:
  containers:
  - name: my-app
    image: my-application-image:latest
    # Uygulama trafiği iptables kurallarıyla sidecar'a yönlendirilir
  - name: egress-proxy-sidecar
    image: envoyproxy/envoy:v1.28.0 # Örnek Envoy imajı
    ports:
    - containerPort: 15001 # Uygulamanın trafiği göndereceği port
    volumeMounts:
    - name: envoy-config
      mountPath: /etc/envoy
    # Envoy'un trafiği harici proxy'ye ya da doğrudan iletmesi için yapılandırma
    # (genellikle service mesh control plane tarafından yönetilir)
  volumes:
  - name: envoy-config
    configMap:
      name: egress-envoy-config

Service'ler için ingress proxy yapılandırması

Service'lere gelen trafik için Kubernetes, doğası gereği proxy içeren birkaç mekanizma sunar.

Kubernetes Service'leri (kube-proxy)

Her düğümde çalışan kube-proxy bileşeni, Kubernetes Service'lerinin sanal IP'sini (VIP) yönetir. Küme içindeki veya dışındaki bir istemci bir Service'in ClusterIP'sine bağlanmaya çalıştığında, kube-proxy trafiği yakalar ve o Service'i besleyen Pod'lardan birine iletir. Bu, Katman 4 (TCP/UDP) düzeyinde bir proxy ve yük dengeleyici işlevi görür.

• Mod: kube-proxy, iptables (varsayılan) veya ipvs modunda çalışır.
  • iptables: NAT ve yük dengeleme için iptables kurallarını kullanır.
  • ipvs: Daha gelişmiş yük dengeleme algoritmaları ve çok sayıda service için daha iyi performans amacıyla IP Virtual Server (IPVS) kullanır.

Bu proxy işlemi otomatiktir; Service'in kendisini tanımlamanın ötesinde Pod'larda veya Service'lerde açık bir yapılandırma gerektirmez.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP # kube-proxy tarafından dahili proxy'leme

Ingress kaynakları ve Ingress Controller'lar

Service'lere dışarıdan HTTP/HTTPS erişimi için bir Ingress kaynağı, bir Ingress Controller ile birlikte kullanılır. Ingress Controller'ın kendisi, küme içinde çalışan özelleşmiş bir proxy'dir.

• Ingress Controller: NGINX, HAProxy, Traefik ya da bir AWS ALB/GCE L7 Load Balancer controller'ı gibi bir proxy çalıştıran Pod (veya Pod kümesi). Ingress kaynaklarını izler ve proxy kurallarını dinamik olarak yapılandırır.
• Ingress kaynağı: Dış HTTP/HTTPS trafiğinin Service'lere yönlendirilmesine ilişkin kuralları tanımlar. Buna host tabanlı yönlendirme, path tabanlı yönlendirme ve TLS sonlandırma dahildir.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80
  tls: # İsteğe bağlı: Ingress Controller'da TLS sonlandırma
  - hosts:
    - api.example.com
    secretName: my-tls-secret

LoadBalancer türü Service'ler

LoadBalancer türünde bir Service oluşturulduğunda, harici bir yük dengeleyici (genellikle bulut sağlayıcısından) sağlanır. Bu harici yük dengeleyici bir proxy gibi davranarak trafiği Service'in NodePort'larına iletir; kube-proxy de trafiği oradan ilgili Pod'lara yönlendirir.

apiVersion: v1
kind: Service
metadata:
  name: my-external-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer # Bulut sağlayıcı LB'si üzerinden harici proxy'leme

Ingress için sidecar proxy'ler (Service Mesh)

Bir service mesh'te (örneğin Istio, Linkerd), uygulama container'ının hem gelen hem giden trafiğini yönetmek üzere Pod'lara sidecar proxy'ler enjekte edilir. Gelen trafikte sidecar, uygulamaya ulaşan trafiği yakalar ve uygulama container'ına iletmeden önce mesh politikalarını (örneğin kimlik doğrulama, yetkilendirme, trafik kaydırma, yeniden deneme, devre kesme) uygular.

Bu şunları sağlar:

• Politika uygulama: Servislerin nasıl iletişim kuracağı üzerinde ince ayarlı kontrol.
• Gözlemlenebilirlik: Servisler arası tüm iletişim için otomatik metrik, loglama ve dağıtık izleme.
• Trafik yönetimi: Gelişmiş yönlendirme yetenekleri (örneğin canary dağıtımları, A/B testleri).
• Güvenlik: Servisler arasında karşılıklı TLS (mTLS).

Sidecar enjeksiyonu ve yapılandırması genellikle service mesh'in control plane'i tarafından otomatikleştirilir.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-with-mesh-sidecar
  labels:
    app: my-app
    # Istio örneği: otomatik sidecar enjeksiyonunu tetikler
    istio-injection: enabled
spec:
  containers:
  - name: my-app
    image: my-application-image:latest
    ports:
    - containerPort: 8080
  # Istio control plane otomatik olarak bir 'istio-proxy' sidecar container'ı ekler
  # ve trafiği yönlendirmek için iptables kurallarını yapılandırır.

Proxy yaklaşımlarının karşılaştırması

Pratik hususlar

Sertifika yönetimi

Proxy'ler çoğu zaman TLS bağlantılarını sonlandırır veya başlatır.

• Ingress Controller'lar: TLS sertifikalarını genellikle Kubernetes Secret'ları üzerinden yönetir; bu da küme sınırında TLS sonlandırmaya olanak tanır.
• Sidecar proxy'ler: Bir service mesh'te sidecar'lar mTLS'i otomatik olarak yönetir ve genellikle mesh'in sertifika otoritesince verilen kısa ömürlü sertifikaları kullanır. Egress için, şifreli trafiği incelemek veya dahili servislere bağlanmak amacıyla özel CA'lara güvenmeleri gerekebilir.

Performans ve ek yük

Her proxy ağ yoluna bir sıçrama daha ekler ve bu da gecikmeyi artırabilir.

• kube-proxy: Yüksek düzeyde optimize edilmiştir. ipvs modu çok sayıda service olduğunda daha iyi performans sunar.
• Sidecar'lar: Pod başına CPU, bellek ve ağ ek yükü getirir. Bu ek yük, service mesh dağıtımlarında bir tasarım kriteridir.
• Ingress Controller'lar: Yüksek trafik hacimleri için uygun şekilde ölçeklenmezse darboğaza dönüşebilir.

Gözlemlenebilirlik

Proxy'ler telemetri toplamak için merkezî bir nokta sağlar.

• Loglar: Proxy'ler bağlantı ayrıntılarını, istek/yanıt header'larını ve hataları loglayabilir.
• Metrikler: İstek oranları, gecikmeler, hata oranları gibi standart metrikler toplanabilir.
• İzleme: Service mesh'teki sidecar proxy'ler, uygulama kodunu değiştirmeden dağıtık izlemeyi mümkün kılar.

Güvenlik

Proxy'ler güvenlik politikalarının uygulandığı kritik noktalardır.

• Erişim kontrolü: Proxy'ler gelen ve giden trafik için kimlik doğrulama ve yetkilendirme politikalarını uygulayabilir.
• Ağ segmentasyonu: Proxy'ler uygulama trafiğini yalıtarak, iletişim kurmaması gereken servisler arasında doğrudan bağlantı kurulmasını engelleyebilir.
• DDoS koruması: Harici proxy'ler (Ingress Controller'lar veya bulut LB'leri gibi) DDoS azaltma yetenekleri sunabilir.