Kubernetes‘te Pod’lar geçici yapılardır. Her yeniden başladıklarında farklı bir IP adresi aldıkları için onlara doğrudan bağlanmak sürdürülebilir değildir. Service nesnesi, bu değişken Pod grubunun önüne sabit bir sanal IP ve DNS ismi koyarak bir soyutlama katmanı oluşturur.
Bu rehberde önce basit bir Pod oluşturacak, ardından ClusterIP, NodePort ve LoadBalancer servis türlerini kurarak aralarındaki farkları görecek, Endpoints mantığını inceleyecek ve kube-proxy’nin iptables ile IPVS modlarında trafiği nasıl yönettiğini teknik olarak ele alacağız.
Pod Yapılandırması
Servisleri test edebilmek için önce trafiği karşılayacak bir Pod oluşturalım. Bu örnekte Apache (httpd) kullanacağız.
Pod Oluşturma
Aşağıdaki YAML dosyasını kullanarak bir Pod oluşturalım. YAML konfigürasyonu, bir pod tanımlar ve bu podu servisler tarafından tanınabilmesi için app: web-sunucu etiketiyle işaretler.
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 widelabels alanı kritik önemdedir. Service nesnesi Pod’ları bu etiket üzerinden bulur. Pod’u silip yeniden oluşturduğunuzda IP adresinin değiştiğini göreceksiniz. İşte Service bu değişimi kullanıcıdan gizler.
Küme İçi İletişim ClusterIP
Kubernetes’in varsayılan servis türü olan ClusterIP, servisin yalnızca küme içerisinden erişilmesini sağlar. Genellikle veritabanları gibi dış dünyaya kapalı kalması gereken katmanlar için tercih edilir.
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
Dış Dünyaya Açılan Kapı NodePort
NodePort, uygulamayı Node’un belirli bir portu üzerinden dış dünyaya açar. Genellikle test veya bare-metal ortamlarda kullanılır.
Dış Erişimi Yapılandırma
NodePort kullanarak, küme dışındaki bir makinenin IP’si ve atanan port üzerinden uygulamaya erişim sağlayabiliriz.
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.
Production Seviyesi LoadBalancer
LoadBalancer servis tipi production ortamları için tasarlanmıştır. Bulut sağlayıcı ile entegre çalışır ve harici bir IP adresi atar.
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.
Süreklilik Testi
Service’nin en güçlü özelliği Pod değişiminden etkilenmemesidir. httpd Pod’unu silelim ve yeniden oluşturalım.
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, iptables ve IPVS
Service fiizksel bie cihaz değildir. API server üzerinde bir kayıttır. Gerçek trafik yönlendirme işlemleri her bir Node’da çalışan kube proxy tarafından yapılır. Kube Proxy Service IP2ye gelen her trafiği izler ve işletim sistemi seviyesinde ağ kuralları yazar.
- iptables
- IPVS
Kubernetes varsayılan olarak iptables modunu kullanır ve servis yönlendirmeleri Linux çekirdeğinin iptables kuralları üzerinden yapılır. Kurallar zinciri üzerinden çalışır ve servis sayısı arttıkça performans düşebilir. IPVS ise hash tablosu yapısı kullanır. Yüksek trafik ardında daha sabit bir performans sağlar.
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.