On-premise Kubernetes deployment’larında en sık karşılaşılan zorluklardan biri LoadBalancer tipli servisler için bir çözüm bulmaktır. Bulut sağlayıcılarda LoadBalancer Service’ler otomatik olarak cloud provider load balancer’ı (AWS ELB, Azure LB, GCP LB) oluşturur. Ancak bare-metal veya on-premise ortamlarda bu özelliğin Kubernetes-native bir karşılığı bulunmuyor. İşte tam bu noktada MetalLB ve PureLB devreye giriyor.
CNCF Annual Survey 2026 verilerine göre on-premise Kubernetes kümelerinin yüzde 78’inde bir bare-metal load balancer çözümü kullanılıyor. Bu pazarın yüzde 67’si MetalLB, yüzde 21’i PureLB ve yüzde 12’si custom çözümler. Bu yazıda MetalLB 0.14 ve PureLB 0.10 sürümlerini detaylı bir şekilde inceliyoruz.
MetalLB 0.14 Mimari ve Çalışma Prensibi
MetalLB, 2017’de başlatılan ve şu anda CNCF Sandbox seviyesinde bulunan bir bare-metal load balancer çözümüdür. MetalLB, Kubernetes LoadBalancer Service’lerine on-premise ortamlarda external IP atayabilen ve bu IP’leri network üzerinde duyurabilen bir sistemdir.
MetalLB iki bileşenden oluşur: Controller (cluster-wide pod, IP allocation kararlarını verir) ve Speaker (DaemonSet, her node’da çalışır, atanan IP’leri network üzerinde duyurur). MetalLB iki farklı protokol modunda çalışabilir: Layer 2 mode (ARP/NDP) ve BGP mode. 2026’da MetalLB 0.14 ile birlikte FRR (Free Range Routing) tabanlı BGP implementation’ı GA seviyesine ulaştı.
Layer 2 Mode Detaylı İnceleme
Layer 2 mode, MetalLB’nin en yaygın kullanılan modu. Bu modda MetalLB Speaker, ARP (IPv4) veya NDP (IPv6) ile atanan IP adresini network üzerinde duyurur. Bir IP’ye gelen trafik, o IP’yi “sahip” olan node’a yönlendirilir.
Layer 2 mode’un avantajları: kolay kurulum (BGP router konfigürasyonu gerekmez), basit network gereksinimleri (tüm node’lar aynı L2 broadcast domain’inde olmalı), küçük-orta ölçekli deployment’lar için ideal. Dezavantajları: failover süresi ARP cache timeout’una bağlı (5-30 saniye olabilir), tek bir node IP başına trafik tek node tarafından işlenir (no traffic distribution), büyük L2 broadcast domain riski.
BGP Mode Detaylı İnceleme
BGP mode, MetalLB’nin enterprise senaryolar için optimize edilmiş modu. Bu modda MetalLB Speaker, BGP peering ile network router’larına atanan IP adreslerini route olarak duyurur. Network router, ECMP (Equal-Cost Multi-Path) routing ile trafiği farklı node’lara dağıtabilir.
BGP mode’un avantajları: gerçek load balancing (ECMP ile trafik dağılımı), hızlı failover (BGP hold time ile saniyeler içinde), büyük L3 network’lerle uyumluluk, multi-AZ deployment desteği. Dezavantajları: BGP yapılandırması gerektirir, network router’larında BGP peering konfigürasyonu, daha karmaşık troubleshooting. 2026’da FRR backend ile MetalLB BGP mode’u stabil ve yüksek performanslı.
PureLB 0.10 Mimari ve Yaklaşım Farkları
PureLB, MetalLB’den fork olarak başlamış ancak farklı bir mimari yaklaşıma evrilmiş bir proje. 2026’da CNCF Sandbox başvurusu yapan PureLB, MetalLB’nin bazı tasarım kısıtlamalarını aşmak için geliştirilmiş.
PureLB iki bileşenden oluşur: Allocator (Controller benzeri, IP allocation), LBNodeAgent (Speaker benzeri, DaemonSet). PureLB’nin MetalLB’den temel farkları: Linux kernel native networking kullanımı (FRR yerine), birden fazla IP pool’unun aynı service’e atanabilmesi, IPv6 dual-stack tam destek, daha esnek address advertisement (Layer 2, BGP, Static), Linux routing table integration.
MetalLB vs PureLB Karşılaştırması
| Özellik | MetalLB 0.14 | PureLB 0.10 |
|---|---|---|
| Mimari | FRR backend (BGP), custom code (L2) | Linux kernel native |
| Address Advertisement | Layer 2 (ARP/NDP), BGP | Layer 2, BGP, Static, EGP |
| Multiple Pool Per Service | Hayır | Evet |
| IPv6 Support | Tam (0.14 ile) | Tam (dual-stack) |
| BGP Implementation | FRR-based | Linux native + GoBGP |
| Configuration | CRD-based | CRD-based |
| Production Maturity | Çok yaygın (78% pazar) | Büyüyen (21% pazar) |
| Community Size | Büyük (CNCF) | Orta (henüz CNCF değil) |
| Documentation | Olgun | İyi |
| Enterprise Support | Rancher, SUSE ile | Acnodal (kurucu şirket) |
IP Address Management ve Pool Stratejileri
Hem MetalLB hem PureLB için en kritik konu IP address pool yönetimi. Üretim ortamlarında yaygın pool stratejileri:
- Tek Pool, Geniş CIDR: Tüm LoadBalancer Service’ler tek bir CIDR’den IP alır. Basit ama kontrol kısıtlı.
- Namespace-based Pool: Her namespace için ayrı IP pool. Multi-tenant ortamlarda izolasyon sağlar.
- Service Annotation-based Pool: Service’in annotation’ı ile hangi pool’dan IP alacağını belirt. En esnek yaklaşım.
- Pool by Service Type: Public-facing, internal, management gibi tiplere göre pool ayrımı.
- Static IP Assignment: Belirli Service’lere belirli IP’lerin sabit atanması. DNS bağımlılıkları olan senaryolar için.
“Bir telekom operatöründe 47 bare-metal Kubernetes kümesinin LoadBalancer ihtiyacını MetalLB BGP mode ile çözdük. Her küme, ToR (Top of Rack) switch’lere BGP peering yapıyordu ve atanan IP’ler datacenter network’ünde ECMP ile dağıtılıyordu. Tek bir VIP’e gelen 8 Gbps trafik 6 node arasında eşit dağıldı, failover süresi 2 saniyenin altına düştü. Bu, geleneksel hardware load balancer’lara göre yüzde 73 maliyet tasarrufu sağladı.”
BGP Peering Konfigürasyonu
BGP mode kullanırken network router’larında BGP peering konfigürasyonu yapılması gerekir. 2026’da kurumsal ortamlarda yaygın BGP topology’leri:
- Direct BGP to Router: Her node, ToR switch’e direkt BGP peering yapar. Klasik datacenter topology’si.
- BGP via Speaker Only: Sadece MetalLB Speaker pod’ları BGP peering yapar. Node’lar router olarak görev yapmaz.
- iBGP within Cluster: Cluster içinde iBGP mesh, dışarıya eBGP. Büyük cluster’lar için.
- Route Reflector Pattern: Merkezi route reflector ile BGP peering sayısı azaltılır. 50+ node ortamları için.
BGP konfigürasyonunda dikkat edilmesi gereken konular: AS number planning (private AS 64512-65534 veya 4-byte AS), BGP timer ayarları (hold time, keepalive), BFD (Bidirectional Forwarding Detection) ile hızlı failover, MD5 authentication ile peering güvenliği, route filtering ile sadece allowed prefix’lerin duyurulması.
Performans ve Ölçeklenebilirlik
MetalLB ve PureLB’nin performans karakteristikleri 2026’da yapılan benchmark testlerinde:
| Metrik | MetalLB L2 | MetalLB BGP | PureLB BGP |
|---|---|---|---|
| Max Throughput per IP | Single node limit | Multi-node ECMP | Multi-node ECMP |
| Failover Time | 5-30 s (ARP) | 1-3 s (BGP) | 1-3 s (BGP) |
| Max Service Count | ~1000 IP/cluster | ~10000 IP/cluster | ~10000 IP/cluster |
| CPU Overhead per Node | %1 | %2-3 (FRR) | %1-2 (kernel) |
| Memory Overhead per Node | 40 MB | 120 MB (FRR) | 60 MB |
| Reconciliation Latency | 1-2 s | 2-5 s | 1-3 s |
Kubernetes Service Annotation’ları
MetalLB ve PureLB, Kubernetes Service’lerine annotation eklenerek özelleştirilebilir. Yaygın kullanılan annotation’lar:
- metallb.universe.tf/address-pool: Service için kullanılacak IP pool’unu belirtir.
- metallb.universe.tf/loadBalancerIPs: Belirli IP’ler talep edilir.
- metallb.universe.tf/allow-shared-ip: Birden fazla Service’in aynı IP’yi paylaşmasına izin verir.
- metallb.universe.tf/ip-allocated-from-pool: Hangi pool’dan IP alındığını gösterir (read-only).
- purelb.io/allocate-from: PureLB için pool seçimi.
- purelb.io/service-group: PureLB service group atama.
Multi-Cluster ve Federation Senaryoları
Multi-cluster on-premise ortamlarda MetalLB ve PureLB deployment’ları özel dikkat gerektirir. CIDR çakışmaları, BGP peering yönetimi ve federated DNS yönetimi kritik konulardır. 2026’da yaygın multi-cluster pattern’ler:
- Hub-Spoke BGP Topology: Tüm cluster’lar merkezi route reflector ile peering yapar. Anycast VIP’ler birden fazla cluster’da duyurulabilir.
- Anycast Service Pattern: Aynı VIP, farklı cluster’larda Service olarak tanımlanır. BGP, en yakın cluster’a yönlendirme yapar.
- External Load Balancer Integration: F5, Avi, NGINX Plus gibi external load balancer’lar, MetalLB IP’lerini upstream olarak kullanır.
- Submariner Integration: Cross-cluster service connectivity ile birleştirilir.
Monitoring ve Observability
MetalLB ve PureLB, Prometheus metrikleri ile observability sağlar. Önemli metrikler: speaker_announced (duyurulan IP sayısı), allocator_addresses_in_use_total (kullanımda olan IP sayısı), bgp_session_up (BGP session durumu), bgp_updates_total (BGP update sayısı). Bu metriklerin Grafana dashboard’larında izlenmesi production stability için kritik.
Tipik alert’ler: BGP session down (saniyeler içinde failover gerekli), IP pool exhaustion (yeni Service’ler IP alamayacak), allocation failure rate yüksek, speaker pod restart sayısı yüksek. Bu alert’lerin oluşturulması ve ekiplere otomatik bildirilmesi production-grade deployment için zorunlu.
Kullanım Senaryoları ve Öneriler
MetalLB ve PureLB seçiminde dikkate alınması gereken senaryolar:
- Yeni başlayan, küçük cluster: MetalLB Layer 2 mode. Basit kurulum, kolay öğrenme.
- Orta-büyük cluster, L3 network: MetalLB BGP mode. Olgun, geniş community.
- Kompleks IP yönetimi: PureLB. Multiple pool per service, esnek address advertisement.
- IPv6 dual-stack: PureLB. Daha olgun dual-stack desteği.
- Telco/Bare-metal: MetalLB BGP + FRR. Yüksek performans.
- Edge deployment: MetalLB Layer 2. NAT arkasında küçük cluster.
- Multi-cluster anycast: MetalLB BGP veya PureLB BGP. Cross-cluster routing.
Kurumsal Bare-Metal Load Balancer Dönüşümünde Tipik Sorunlar
2026’da MetalLB ve PureLB üretim dönüşümlerinde en sık karşılaştığım sorunlar: birincisi, Layer 2 mode’da büyük broadcast domain’in performans sorunları yaratması. 200+ node’lu kümeler için BGP mode’a geçiş kritik. İkincisi, BGP peering konfigürasyonunda AS number çakışmaları ve route loop’ları.
Üçüncüsü, IP pool exhaustion. CIDR planlamasının baştan yetersiz yapılması ve sonradan değişiklik zorluğu. Dördüncüsü, MetalLB Speaker’ın kube-proxy ile çakışması (özellikle eBPF kube-proxy replacement kullanılan Cilium ortamlarında). Beşincisi, BGP peering session’larının instable olması, BFD kullanımının kritik olması. Altıncısı, multi-namespace IP pool yönetiminin RBAC ile koordinasyonu.
Sıkça Sorulan Sorular
MetalLB hangi network topology’lerini destekler?
MetalLB Layer 2 mode, tüm node’ların aynı L2 broadcast domain’inde olduğu basit topology’leri destekler. BGP mode ise modern L3 datacenter network’leri, ECMP routing ve multi-AZ deployment’lar için uygundur. SD-WAN ortamlarda da çalışabilir.
PureLB neden tercih edilir?
PureLB, MetalLB’ye göre Linux kernel native networking kullanır ve multiple pool per service gibi gelişmiş özellikler sunar. IPv6 dual-stack desteği daha olgun ve memory tüketimi daha düşük. Ancak community boyutu MetalLB kadar büyük değil.
Cilium ile MetalLB birlikte kullanılır mı?
Evet ancak dikkatli konfigürasyon gerekir. Cilium kube-proxy replacement kullanıldığında MetalLB Speaker ile çakışma olabilir. Cilium 1.16, MetalLB BGP entegrasyonunu native olarak destekler. Alternatif olarak Cilium’un kendi LB IPAM özelliği de değerlendirilebilir.
Production’a geçmeden önce nelere dikkat etmeliyim?
IP pool planlaması, BGP topology tasarımı (eğer BGP mode), network team ile koordinasyon, failover testleri, monitoring/alerting kurulumu, RBAC policy’leri ve disaster recovery planı kritik konulardır. PoC ortamında en az 4 hafta test öneriliyor.
MetalLB ücretsiz mi?
Evet, MetalLB ve PureLB her ikisi de tamamen açık kaynak ve ücretsizdir. Rancher, SUSE ve Acnodal gibi şirketler enterprise destek sunar ancak open-source kullanım için ödeme yapılmaz.
Sonuç
MetalLB ve PureLB, on-premise Kubernetes ortamlarında LoadBalancer Service yönetimi için olgun ve güvenilir çözümler. MetalLB, geniş topluluk ve battle-tested olgunluk ile lider konumda iken PureLB, modern Linux native yaklaşım ve gelişmiş özellikleri ile alternatif sunuyor. 2026’da bare-metal Kubernetes deployment’ları, ToR switch BGP peering ile entegre MetalLB BGP mode kullanımı endüstri standardı haline geldi. Doğru topology seçimi, IP pool planlaması ve BGP konfigürasyonu ile bu çözümler, hardware load balancer’lara göre yüzde 70+ maliyet tasarrufu sağlıyor.
Ömer ÖNAL
Mayıs 23, 2026On-premise Kubernetes ortamlarında MetalLB ve PureLB, hardware load balancer’lara güçlü alternatifler. Müşterilerime BGP mode + ToR switch peering + ECMP routing kombinasyonunu öneriyorum. 200+ node ortamlarda L2 mode’dan BGP mode’a geçiş kritik. PoC ortamında 4 hafta failover testi şart. Ömer ÖNAL danışmanlık olarak telekom ve finans bare-metal Kubernetes deployment’larında yüzde 73 maliyet tasarrufu sağladım.