Kubernetes‘deki Pod birimlerinin geçici doğası ağ yönetimini karmaşık hale getirir. Her yeniden başlatma işleminde değişen IP adresleri doğrudan bağlantı kurmayı imkansız kıldığı için Service nesnesi devreye girer. Bu yapı Pod grubunun önünde sabit bir sanal IP ve DNS tanımlayarak kararlı bir soyutlama katmanı inşa eder. Bu incelemede standart bir Pod kurulumunun ardından ClusterIP, NodePort ve LoadBalancer türlerini yapılandıracağız. Ayrıca Endpoints çalışma prensibiyle birlikte kube proxy bileşeninin iptables ve IPVS modları üzerindeki trafik yönlendirme yeteneklerini analiz edeceğiz.
İş Yükü Hazırlığı ve Pod Dağıtımı
Sistem üzerindeki ağ trafiğini ve servis yönlendirmelerini analiz etmek için öncelikle standart bir iş yükü oluşturmamız gerekiyor. Bu senaryoda kararlı yapısıyla bilinen Apache yani httpd imajını tercih ediyoruz. Aşağıdaki yapılandırma dosyası temel bir Pod tanımı yaparken aynı zamanda bu birimi servislerin hedef alabilmesi için özel bir etiketle işaretliyor.
apiVersion: v1
kind: Pod
metadata:
name: httpd-pod
labels:
app: web-sunucu
spec:
containers:
- name: apache-container
image: httpd:latest
ports:
- containerPort: 80*Soyutlama Katmanı (Abstraction Layer): Ppodların sürekli değişen IP’lerini gizleyerek, kullanıcıya basit ve değişmez bir arayüz sunan yapıdır.
Uygulama
kubectl apply -f pod.yaml
kubectl get pods -o wideKubernetes servisleri pod seçimini tamamen etiketler üzerinden gerçekleştirir. Yeniden başlatılan her birim yeni bir kimlik kazansa bile servis bu birimi etiketi sayesinde anında tanır. Bu mekanizma değişken IP adreslerini kullanıcıdan gizleyerek sistemin kararlı çalışmasına olanak tanır.
Dahili Ağ Yönetimi ve ClusterIP
Kubernetes ağının standart servis tipi olan ClusterIP yalnızca küme içi erişimler için tasarlanmıştır. Bu yapı dış dünyaya tamamen kapalı kalarak güvenliği en üst seviyeye çıkarır. Genellikle veritabanı veya iç servis katmanları gibi doğrudan internete açılmaması gereken kritik bileşenler için kullanılır.
Dahili Servis Kurulumu
Aşağıdaki tanım, 80 portu üzerinden gelen talepleri, hedef podun 80 portuna yönlendiren bir iç ağ servisidir.
apiVersion: v1
kind: Service
metadata:
name: ic-servis
spec:
type: ClusterIP
selector:
app: web-sunucu
ports:
- protocol: TCP
port: 80
targetPort: 80Selector (Seçici): Servisin, hangi podlara trafik göndereceğini belirlemek için kullandığı etiket mekanizmasıdır.
Uygulama
kubectl apply -f clusterip.yamlCluster içinden test etmek için
kubectl run test --image=busybox -it --rm -- wget -qO- http://ic-servisService IP sabit kalır, Pod değişse bile trafik kesilmez.
port→ Servisin cluster içindeki portutargetPort→ Pod içindeki uygulamanın portu
NodePort ile Harici Erişim Sağlama
Kubernetes üzerindeki bir uygulamayı dış dünyaya açmanın en temel yollarından biri NodePort servisidir. Bu yöntem her bir sunucu düğümü üzerinde belirli bir portu rezerve ederek trafiği içeriye aktarır. Genellikle test süreçlerinde veya bulut sağlayıcısı olmayan fiziksel sunucu ortamlarında tercih edilen bir çözümdür.
Dış Trafik İçin Erişim Noktası Belirleme
Kubernetes üzerinde koşan bir servise küme dışındaki bir bilgisayardan ulaşmak için NodePort servisinden yararlanılır. Sistem her bir fiziksel veya sanal makinenin IP adresini bir giriş kapısı olarak kullanır ve bu adrese bir port numarası ekler. Bu sayede dışarıdaki cihazlar uygulamayı sanki yerel bir sunucuymuş gibi kolayca görebilir.
apiVersion: v1
kind: Service
metadata:
name: dis-erisim-servisi
spec:
type: NodePort
selector:
app: web-sunucu
ports:
- port: 80
targetPort: 80
nodePort: 32000Düğüm (Node): Üzerinde podların çalıştığı, fiziksel veya sanal bir sunucu makinesidir.
Uygulama
kubectl apply -f nodeport.yamlHizmetin ayrıntılarını görüntülemek için
kubectl describe service dis-erisim-servisiErişim formatı
http://NodeIP:32000NodePort 30000–32767 arası bir port aralığı kullanır. Production’da doğrudan tercih edilmez çünkü her Node dış dünyaya açılmış olur.
Bulut Entegrasyonlu Yük Dengeleme Sistemi
LoadBalancer servis türü modern bulut sağlayıcıların sunduğu imkanları kullanarak ağ trafiğini yönetir. Sisteme dahil edildiği andan itibaren bulut altyapısı üzerinden bir dış IP adresi atayarak trafiği dengeler. Bu yöntem özellikle yüksek erişilebilirlik gerektiren kurumsal uygulamalar için standart bir yapı sunar.
Yük Dengeleyici Servisini Kurma
apiVersion: v1
kind: Service
metadata:
name: ana-giris-servisi
spec:
type: LoadBalancer
selector:
app: web-sunucu
ports:
- port: 80
targetPort: 80Kontrol et:
kubectl get service ana-giris-servisiEXTERNAL-IP alanı dolduğunda uygulama internete açılmıştır.
LoadBalancer (Yük Dengeleyici): Gelen yoğun trafiği karşılayıp, arka plandaki sunuculara (node’lara) eşit ve sağlıklı bir şekilde dağıtan cihaz veya yazılımdır.
Dinamik Yapılarda Bağlantı Sürekliliği
Service yapısının temel avantajı pod seviyesindeki değişiklikleri kullanıcıya yansıtmamasıdır. Örnek olarak kullandığımız httpd birimini silip yeni bir tane oluşturduğumuzda servis katmanının kesintisiz çalıştığı gözlemlenir. Bu mekanizma modern sistemlerdeki yüksek erişilebilirlik ihtiyacını karşılayan en önemli unsurdur.
kubectl delete pod httpd-podYeni Pod oluşur. Service otomatik olarak yeni IP’yi Endpoints listesine ekler. Kullanıcı bağlantısı kesilmez.
Endpoints’i kontrol edelim.
kubectl get endpoints ic-servisKaynakların Temizlenmesi
kubectl delete pod httpd-pod
kubectl delete service ic-servis dis-erisim-servisi ana-giris-servisiEndpoint: Bir servisin trafiği yönlendirdiği podların o anki gerçek IP adreslerinin tutulduğu dinamik listedir.
Kube Proxy ile Trafik Yönlendirme Modları
Servis yapısı fiziksel bir donanım değil API sunucusu üzerinde tutulan dijital bir kayıttır. Asıl trafik yönlendirme görevini her düğümde aktif olarak çalışan kube proxy bileşeni üstlenir. Bu bileşen servis adreslerine gelen istekleri takip eder ve işletim sistemi düzeyinde gerekli ağ kurallarını oluşturur. Standart olarak sunulan iptables modu kuralları bir liste halinde işlerken gelişmiş bir seçenek olan IPVS modu hash tablosu yapısını kullanarak çok daha yüksek performans sunar.
Sık Sorulan Sorular
Trafik Pod’lara hangi mantıkla dağıtılır?
Varsayılan olarak kube-proxy trafiği Pod’lara rastgele dağıtır. Eğer aynı kullanıcının hep aynı Pod’a gitmesini isterseniz, servis tanımına sessionAffinity: ClientIP eklemeniz gerekir.
Servis IP’si var ama trafik gitmiyor, neden?
En büyük şüpheli Selector uyuşmazlığıdır. Servisdeki etiket ile Pod’daki etiket birebir aynı değilse bağ kurulamaz. Ayrıca Pod hazır durumunda değilse, servis trafiği o Pod’a yönlendirmez.
NodePort yerine neden LoadBalancer tercih edilmeli?
NodePort 30000+ gibi portlar kullanır ve güvenliği zayıflatır. LoadBalancer ise profesyoneldir. Size standart bir IP (80/443 portu gibi) verir ve bulut altyapısıyla tam uyumlu çalışarak trafiği dengeler.
IPVS modu iptables’dan neden daha hızlıdır?
iptables, kuralları uzun bir liste olarak tutar. Servis arttıkça bu listeyi taramak sistemi yorar. IPVS ise kuralları bir Hash Tablosu içinde saklar. Bu sayede 10 servis ile 10.000 servis arasında yönlendirme hızı açısından hiçbir fark oluşmaz.