MetalLB ile Bare Metal Kubernetes Servis Yayınlama

Bare metal Kubernetes çalıştıran ekiplerin çok sık yaşadığı bir gerçek var: cluster tarafı olgunlaşır, ingress yerleşir, observability oturur; ama dış dünyaya servis yayınlama adımı hâlâ elde tutulur. Bulut ortamında bu iş genelde LoadBalancer servisiyle birkaç dakikada çözülür. Kendi veri merkezinizde veya hibrit altyapınızda ise aynı ihtiyaç ağ ekibi, firewall kuralları, VIP yönetimi ve elle tutulan IP tabloları arasında dağılır. MetalLB bu boşluğu doldurur; fakat gerçek değeri yalnızca IP dağıtmak değil, Kubernetes ile ağ operasyonunu birbirine daha öngörülebilir biçimde bağlamaktır.

Problem aslında IP vermek değil

Birçok ekip MetalLB’yi sadece “Kubernetes’e dış IP verdiren araç” gibi konumlandırır. Bu eksik bir tanımdır. Asıl problem şudur:

• Hangi servislerin dış erişim alacağı net değildir.
• IP havuzları ile ağ segmentasyonu arasında sahiplik kopuktur.
• Failover davranışı L2 topolojiye veya routing tasarımına göre değişir.
• Uygulama ekipleri servis açmayı kolaylaştırırken platform ekibi risk kontrolünü kaybetmek istemez.

MetalLB kurulumu kolaydır; ama başarılı kullanım için ağ niyetinin de açık olması gerekir.

L2 mi, BGP mi?

Başlangıçta en kritik karar budur. L2 modu daha hızlı başlatılır. Özellikle tek veri merkezi, sınırlı node sayısı ve aynı broadcast domain içinde çalışan kümelerde iyi sonuç verir. Fakat L2 modunda VIP sahipliği bir node’dan diğerine taşınırken ağ davranışı topolojiye duyarlı olur.

BGP modu ise daha kurumsal ve ölçeklenebilir bir model sunar:

1. Ağ cihazlarıyla açık rota alışverişi yapılır.
2. Çoklu rack ya da çoklu segment senaryolarında daha tutarlı davranır.
3. Node arızasında erişim yolu daha öngörülebilir hâle gelir.

Benim önerim şudur: iki switch, tek oda ve sınırlı servis sayısı olan lab ya da küçük üretim ortamlarında L2 kabul edilebilir; kurumsal cluster’larda ise BGP düşünülmeden kalıcı tasarım yapılmamalıdır.

IP havuzu tasarımı neden önemlidir?

MetalLB kurulduktan sonra en sık yapılan hata, tek ve geniş bir IP havuzu tanımlayıp her yük dengeleyici servisini buna bırakmaktır. Bu model kısa vadede pratiktir ama denetim ve operasyon kalitesini düşürür. Daha iyi yaklaşım, havuzları niyete göre ayırmaktır:

• Kuzey-güney üretim trafiği
• İç ağdan erişilen servisler
• Geçici test veya migration servisleri
• Yönetim düzlemi bağımlılıkları

Bu ayrım sayesinde hangi IP aralığının hangi risk sınıfına ait olduğu görünür olur. Özellikle firewall ekibi, güvenlik ekibi ve platform ekibi aynı tabloya bakabilir.

Basit bir başlangıç tanımı

Aşağıdaki örnek, bare metal cluster için küçük ama yönetilebilir bir MetalLB kurulumu gösterir:

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: prod-external
  namespace: metallb-system
spec:
  addresses:
    - 10.40.20.120-10.40.20.139
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: prod-external
  namespace: metallb-system
spec:
  ipAddressPools:
    - prod-external
---
apiVersion: v1
kind: Service
metadata:
  name: edge-api
  annotations:
    metallb.universe.tf/address-pool: prod-external
spec:
  type: LoadBalancer
  selector:
    app: edge-api
  ports:
    - port: 443
      targetPort: 8443

Bu örnek küçük görünür; fakat servis açıklaması, havuz sahipliği ve segment niyeti tutarlıysa ileride BGP moduna geçmek de daha kolay olur.

Operasyon tarafında hangi kontroller şart?

MetalLB’yi yalnızca kube manifest seviyesiyle yönetmek yeterli değildir. Şu kontrolleri baştan kurmanızı öneririm:

• Kullanılan ve boşta kalan IP sayısını izleme
• Aynı havuzu paylaşan servislerin envanteri
• VIP değişim olayları için audit izi
• Dış IP alan servislerin onay modeli
• Ingress, gateway ve doğrudan LoadBalancer kullanımlarının ayrımı

Özellikle farklı ekiplerin aynı kümeyi kullandığı kurumsal yapılarda, “kim dış IP aldı” sorusu teknikten önce yönetişim sorusudur.

Ağ ekibi ile platform ekibi arasındaki sınır

Başarılı MetalLB kullanımında bu sınır çok nettir:

• Ağ ekibi: hangi VLAN, subnet, BGP peer ve kuzey-güney akışın kabul edildiğini belirler.
• Platform ekibi: bu sınırlar içinde Kubernetes nesneleri ve havuz politikalarını işletir.
• Uygulama ekipleri: servis talebini self-service deneyimle yapar ama kurumsal guardrail’ler dışına çıkmaz.

Bu ayrım yapılmadığında ya platform ekibi ağ tasarımı yapmaya başlar ya da ağ ekibi her servis değişikliğinde darboğaz olur.

Hangi senaryolarda dikkatli olunmalı?

MetalLB her problemi çözmez. Aşağıdaki durumlarda mimari karar daha dikkatli verilmelidir:

• Geniş L2 domain’lerde ARP davranışının belirsiz olduğu eski ağlar
• Sık değişen test cluster’larında IP kirlenmesi
• Aynı IP alanını tüketen eski fiziksel yük dengeleyiciler
• Gelişigüzel açılmış LoadBalancer servisleri nedeniyle yönetilemeyen dış yüzey

Bu ortamlarda önce servis yayınlama ilkelerini sadeleştirmek, sonra MetalLB kurmak daha doğru olur.

Sonuç

MetalLB ile bare metal Kubernetes servis yayınlama, “bulutta olan özelliği veri merkezine getirme” işi gibi görünse de aslında platform ve ağ ekipleri arasında daha sağlıklı bir sözleşme kurma fırsatıdır. IP havuzlarını niyete göre ayırır, L2 ve BGP kararını topolojiye göre verir ve dış IP kullanımını görünür kılarsanız bare metal Kubernetes ortamı çok daha yönetilebilir hâle gelir. MetalLB’nin gücü kurulum kolaylığında değil, servis yayınlamayı standartlaştırabilmesindedir.