1. GİRİŞ

Kubernetes ağ katmanı, konteynerleştirilmiş uygulamaların güvenli, ölçeklenebilir ve taşınabilir şekilde iletişim kurmasını sağlayan karmaşık bir ekosistemi temsil eder. Konu günümüzde önemini artırıyor çünkü mikroservis mimarileri, dağıtık sistemler ve yüksek trafikli servisler ağ davranışına bağımlı olarak performans ve güvenlikle doğrudan ilişkilidir. Ayrıca service mesh ve eBPF tabanlı CNI'ler gibi yenilikler ağ tasarımını yeniden tanımlıyor; bu nedenle mühendislerin Kubernetes networking'in derinliklerini anlaması gerekiyor.

Neden bugün önemli?

• Dağıtık uygulamalarda servisler arası iletişim performansı doğrudan kullanıcı deneyimini etkiler.
• Güvenlik talepleri (segmentation, zero trust) ağ politikaları ve runtime kontroller ile sağlanır.
• GitOps ve CI/CD ile otomasyon arttıkça, ağ konfigürasyonlarının versiyonlanması ve otomatik uygulanması kritik hale geldi.

Kimler için önemli?

• Platform mühendisleri, SRE ekipleri ve ağ mühendisleri
• Mikroservis mimarisi üzerinde çalışan backend geliştiriciler
• Güvenlik mühendisleri ve compliance ekipleri

Hangi problemleri çözüyor?

• Pod‑to‑pod iletişiminin tutarlı IP/port modelinde sağlanması
• Servis keşfi ve yük dengeleme
• Ağ izolasyonu, politika bazlı erişim kontrolü ve trafik yönlendirme

2. KAVRAMSAL TEMELLER

2.1 Temel kavramlar

• Pod ağı (Pod network): Her pod'un kendine ait IP adresine sahip olduğu ve pod'ların doğrudan birbirleriyle IP seviyesinde iletişim kurabildiği model.
• CNI (Container Network Interface): Kubernetes'te ağ sağlayıcılarının entegrasyon noktası; Calico, Cilium, Flannel, Weave gibi implementasyonlar CNI spec'ine uyar.
• Service: Bir veya daha fazla pod grubuna tekil erişim noktası sağlayan Kubernetes kaynak nesnesi (ClusterIP, NodePort, LoadBalancer).
• Ingress: L7 HTTP/HTTPS trafiğini cluster dışından uygulamaya yönlendiren kaynak; Ingress Controller bunu uygular.
• NetworkPolicy: Pod seviyesinde inbound/outbound trafik kısıtlaması tanımlayan kaynak.
• Service Mesh: Sidecar proxy tabanlı katman ile servisler arası iletişimde güvenlik, gözlemlenebilirlik ve traffic control sağlayan yapı (Istio, Linkerd, Consul).

2.2 Terminoloji ve doğrudan etkileri

• Overlay vs Underlay: Overlay (VXLAN, Geneve) pod ağını host ağından izole ederken underlay doğrudan fiziksel ağ yapılarını kullanır; seçim performans, MTU ve operasyonal karmaşıklığı etkiler.
• eBPF: Kernel seviyesinde çalışma sağlayan teknoloji; Cilium gibi modern CNI'lerde yüksek performanslı networking, observability ve policy enforcement sunar.
• DNS (CoreDNS): Service discovery için cluster‑internal DNS sağlar; performans ve caching kritik önem taşır.

3. NASIL ÇALIŞIR? — Teknik Mimari ve Veri Akışı

3.1 Pod IP modelinin mantığı

Kubernetes tasarım felsefesinde "her pod bir IP adresi" ilkesidir. Bu model ile servis discovery ve yönlendirme basitçe IP tabanlı çalışır. Kube‑proxy veya eBPF tabanlı datapath mekanizmaları Service IP'lerini backend pod IP'lerine yönlendirir. Pod'lar aynı namespace veya farklı namespace'ler arasında doğrudan IP ile iletişim kurabilir; ağ politikaları bu temel üzerine erişim kısıtlaması uygular.

3.2 Service discovery ve load balancing

Service objesi temelinde üç ana tip vardır:

• ClusterIP: Cluster içi erişim sağlayan sanal IP.
• NodePort: Her node'da açılan port üzerinden erişim sağlar (genelde load balancer ile birlikte kullanılır).
• LoadBalancer: Cloud provider entegrasyonları aracılığıyla dış dünya için L4 load balancer rezervasyonu sağlar.

Kube‑proxy (iptables/ipvs) veya eBPF ile Service IP'sine gelen trafik uygun backend pod'lara yönlendirilir. IPVS, iptables'e göre yüksek performans sunar; eBPF ise kernel seviyesinde programlanabilirlik ve düşük latency avantajı sağlar.

3.3 Ingress layer ve L7 routing

Ingress Controller'lar (NGINX, Traefik, HAProxy, Contour) L7 trafiğini yönetir; TLS termination, path/host-based routing, rate limiting, WAF entegrasyonları ve authentication middleware'leri Ingress katmanında uygulanır. Ingress kaynakları deklaratif olarak YAML ile tanımlanır ve GitOps ile yönetilebilir.

3.4 NetworkPolicy çalışması

NetworkPolicy kaynakları pod etiketleriyle eşleşen kuralları tanımlar. Temel model: default deny (tüm trafiği engelle) ve gerektiği kadar izin verme ilkesidir. CNI implementasyonu NetworkPolicy spec'ini nasıl uygulayacağı konusunda farklılık gösterebilir (örn. Calico geniş ACL yetenekleri sunar, Cilium eBPF ile performanslı enforcement yapar).

3.5 Service Mesh ile veri yolu ve kontrol düzlemi ayrımı

Service mesh, sidecar proxy'leri (Envoy vb.) kullanarak veri yolunu (data plane) ve kontrol düzlemini ayırır. Control plane (Istio Pilot, Linkerd control plane) routing, policy ve certificate yönetimini sağlar. Mesh, mTLS, fine‑grained traffic shifting, retries, circuit breaking ve distributed tracing gibi özelliklerle uygulamaların ağırlıklı olarak L7 üzerinde yönetilmesini sağlar.

4. POPÜLER CNI PLUGINLERİNİN KARŞILAŞTIRMASI

4.1 Calico

Calico hem L3 routing hem de NetworkPolicy enforcement için yaygın tercih edilen bir CNI'dir. BGP tabanlı peering, eBPF hızlandırma (Calico eBPF mode) ve policy yazımı açısından güçlüdür. Kurumsal güvenlik gereksinimleri ve geniş policy yetenekleri için uygundur.

4.2 Cilium

Cilium, eBPF kullanarak yüksek performanslı datapath, L7 policy enforcement ve zengin observability (flows, traces) sağlar. Modern mikroservis ortamları için performans ve güvenlik avantajı sunar. Ayrıca Hubble ile network telemetry sağlar.

4.3 Flannel

Flannel, basit overlay (VXLAN) pod ağı sağlayıcısıdır. Basitlik ve kolay kurulum avantajı vardır ancak performans ve policy yetenekleri sınırlıdır; küçük veya test cluster'ları için uygundur.

4.4 Weave Net

Weave Net, mesh yapı benzeri overlay sunar ve küçük‑orta ölçekli cluster'larda kolay kurulum avantajı sağlar. Ancak eBPF tabanlı modern çözümler kadar performans sağlamayabilir.

4.5 Seçim kriterleri

• Performans: eBPF tabanlı Cilium önde.
• Policy yetenekleri: Calico güçlüdür, Cilium L7'e kadar destekler.
• Operasyonel basitlik: Flannel ve Weave kolay kurulum sunar.
• Cloud/native entegrasyon: Managed CNI ve cloud network özellikleri değerlendirilmeli.

5. SERVICE MESH: NE ZAMAN VE NASIL KULLANILMALI?

5.1 Service mesh'in sağladığı faydalar

• mTLS ile servisler arası güvenli iletişim
• Fine‑grained traffic control: canary, traffic shifting, mirroring
• Observability: distributed tracing, request logs, metrics
• Policy enforcement ve circuit breaking gibi runtime güvenlik kontrolleri

5.2 Dezavantajlar ve maliyetler

• Operational complexity: sidecar yönetimi, certificate lifecycle, kontrol düzlemi bakımı
• Performans overhead: sidecar proxy latency ve resource tüketimi
• Debug ve troubleshooting zorluğu: ekstra hop'lar ve proxy'lerin etkisini izleme gereksinimi

5.3 Ne zaman tercih edilmeli?

Service mesh genelde mikroservis sayısı arttığında, güvenlik ve observability gereksinimleri karmaşıklaştığında ve progressive delivery (canary/traffic shift) ihtiyaçları ortaya çıktığında tercih edilir. Küçük monolitik uygulamalar için genelde gereksizdir.

6. GÜVENLİK, POLICY VE COMPLIANCE

6.1 Default deny yaklaşımı

Güvenli bir başlangıç: namespace bazlı veya cluster genelinde default deny uygulanmalı, sadece gerekli trafiğe izin verilmeli. NetworkPolicy'lerin test edilmesi ve canary rollout ile devreye alınması önerilir.

6.2 Zero Trust ve mTLS

Service mesh veya istio gibi çözümler ile mTLS implementasyonu, hizmetlerin birbirlerini kimliklendirmesini sağlar. Ayrıca identity‑based access control (service account, SPIFFE) ile daha güçlü güvenlik sağlanır.

6.3 Runtime policy enforcement

NetworkPolicy dışında eBPF tabanlı kontroller, L7 filtering ve WAF entegrasyonları runtime güvenliğini artırır. Policy as code ile YAML tanımlar pipeline'da doğrulanmalı ve CI ile birlikte deploy edilmelidir.

7. OBSERVABILITY: NETWORK TELEMETRY VE DEBUG

7.1 Metrics ve tracing

Prometheus ile pod/node network metrikleri, CNI veya service mesh metrikleri toplanmalıdır. OpenTelemetry ile distributed tracing toplanarak latency root cause analysis yapılabilir. eBPF tabanlı Hubble veya Cilium Flow monitoring daha derin telemetry sağlar.

7.2 Packet capture ve debugging

tcpdump, wireshark, istioctl proxy‑dump ve eBPF tabanlı araçlar network troubleshooting için kullanılmalıdır. Packet capture işlemleri yüksek maliyetli olabileceği için hedefli ve kısa süreli çalıştırılmalıdır.

7.3 NetworkPolicy testing

Policy'leri manuel test etmek yerine automation (kube‑test, chaos network tests) ve CI pipeline'larında policy validation uygulanmalıdır. Canary rollouts ile policy değişiklikleri önce staging'de doğrulanmalıdır.

8. EN İYİ PRATİKLER

Production kullanımı

• Default deny network policy yaklaşımını benimseyin; küçük, izin bazlı erişimler tanımlayın.
• Pod resource limits ve network QoS ayarları ile performansı koruyun.
• MTU, overlay/underlay ve IP exhaustion risklerini planlayın (cluster büyümesi dikkate alınarak CIDR seçimleri yapılmalı).
• Ingress ve Load Balancer yapılarını TLS termination, WAF ve rate limiting ile güçlendirin.

Performans optimizasyonu

• eBPF tabanlı CNI'leri değerlendirin; IPVS veya eBPF ile datapath overhead'ini azaltın.
• Service topology ve locality ile trafik yolunu kısaltın; node affinity ile locality sağlayın.
• Horizontal autoscaling ve cluster autoscaler ile trafik dalgalanmalarını yönetin.

Güvenlik

• Service account ve RBAC ile network identity'lerini yönetin; service identity'lerini short‑lived certificate ile sağlayın.
• Image scanning, signed images ve supply chain kontrollerini ağ politikalarıyla entegre edin.

9. SIK YAPILAN HATALAR

• Pod IP CIDR planlamasını yapmadan hızlı cluster oluşturmak ve IP exhaustion'a neden olmak.
• Default allow network policy ile başlamak ve zamanla çok fazla izin birikmesine izin vermek.
• Service mesh'e doğrudan production'da geçiş yapmak, yeterli test ve observability olmadan maliyet ve operasyonel sorunlar yaratır.
• MTU ve overlay konfigurasyonunu gözardı ederek fragmentation ve performans kaybına sebep olmak.

10. GELECEK TRENDLER

1. eBPF'nin yükselişi: Kernel seviyesinde programlanabilir ağ, observability ve policy enforcement daha yaygın olacak; Cilium gibi projeler ön planda.
2. AI/ML destekli ağ optimizasyonu: Trafik desenlerini analiz ederek otomatik traffic steering, anomaly detection ve kapasite tahmini yapılacak.
3. Edge ve federated networking: Çoklu site/edge deployment'larda global routing ve güvenli federasyon çözümleri artacak.
4. Service mesh + CNI entegrasyonu: Data plane'in CNI eBPF ile birleşmesi, sidecar overhead'ini azaltacak ve mesh özelliklerini daha verimli hale getirecek.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Hangi CNI'yi seçmeliyim?

   İhtiyaçlarınıza göre seçin: performans ve L7 policy için Cilium; geniş policy yetenekleri için Calico; basit overlay için Flannel. Cloud provider'ın managed CNI entegrasyonları da değerlendirilmelidir.

2. 2. Service Mesh her zaman gerekli mi?

   Küçük ve az mikroservisli uygulamalarda genelde gerekmez. Güvenlik, observability ve ileri trafik yönetimi gereksinimleri yükseldiğinde tercih edilir.

3. 3. NetworkPolicy default deny nasıl uygulanır?

   Namespace'e tüm trafiği engelleyen podSelector: {} kuralı koyarak başlayın; ardından gerekli izinleri kademeli açın ve CI ile policy'leri test edin.

4. 4. eBPF ne getirir?

   Kernel içinde çalışarak düşük latency, yüksek throughput, gelişmiş observability ve L7 seviyesinde policy enforcement imkânı sunar.

5. 5. Ingress vs LoadBalancer farkı nedir?

   LoadBalancer genelde L4 seviyesinde cloud sağlayıcı tarafından sağlanan IP/port mapping; Ingress L7'de HTTP/HTTPS yönlendirme, TLS termination ve path/host routing sunar.

6. 6. DNS sorunlarını nasıl tespit ederim?

   CoreDNS logları, DNS lookup latency metriği, pod içinden dig/nslookup testleri ve DNS caching davranışını inceleyin. DNS ölçeklendirme ve cache ayarları performansı etkiler.

7. 7. MTU ve fragmentation sorunları nasıl giderilir?

   Overlay (VXLAN) kullanıldığında MTU'yu düşürün veya jumbo frame destekleyen fiziksel ağ kullanın. Fragmentation varsa path MTU discovery ve uygun MTU ayarlamaları yapılmalıdır.

8. 8. NetworkPolicy'leri test etmek için hangi araçlar var?

   kubectl, netshoot podları, calicoctl (Calico), cilium monitor/Hubble gibi araçlar ve otomasyon için network chaos testleri kullanabilirsiniz.

Anahtar Kavramlar

Pod network

Her pod'un kendine IP adresi aldığı ağ modeli.

CNI

Kubernetes için ağ sağlayıcı entegrasyon standardı (Calico, Cilium, Flannel vb.).

Service

Pod gruplarına tutarlı erişim sağlayan soyutlama (ClusterIP, NodePort, LoadBalancer).

Ingress

HTTP/HTTPS trafiğini yönlendiren L7 katman nesnesi.

NetworkPolicy

Pod seviyesinde erişim kontrol kuralları.

Öğrenme Yol Haritası

1. 0–1 ay: Kubernetes networking temel kavramları: pod IP, Service, Ingress, basit CNI kurulumu (Flannel) ile başlayın.
2. 1–3 ay: Calico veya Cilium ile ileri politika uygulamaları, NetworkPolicy yazımı ve CoreDNS tuning deneyimi kazanın.
3. 3–6 ay: Service mesh (Istio/Linkerd) deneyimi, tracing/metrics integration ve traffic management pratiklerini uygulayın.
4. 6–12 ay: eBPF, Hubble/Cilium observability, multi‑cluster networking ve edge/federated network senaryoları üzerinde çalışın.