Kubernetes’te ExternalIPs Neden Gidiyor: Güvenlik ve Geçiş

Bu yazıda sana sadece ne değiştiğini anlatmayacağım. Asıl önemli olan şu: neden şimdi, neden riskliydi ve Türkiye’deki kurumlar bunu nasıl ele almalı? Ha bu arada, birkaç gerçek proje deneyimi ve geçiş önerisi de bırakacağım; çünkü teorik anlatım tek başına yetmiyor.

ExternalIPs aslında ne yapıyordu?

Küçük bir detay: externalIPs, kağıt üstünde basit bir şeydi: Service’e ekstra bir IP veriyorsun, trafik o IP’den de gelebiliyor. En çok da cloud olmayan ortamlarda, “load balancer yoksa bunu kullanırım” mantığıyla epey dolaştı. Hani eski sistemlerde NAT kuralı açıp işi çözdüğünü sanırsın ya… buna biraz benziyor.

Açıkçası, Ben 2019’da Ankara’da bir üretim ortamında buna benzer bir kurguya denk gelmiştim. Küçük ekipti, hızlı gitmek istiyorlardı ve dış dünyaya çıkış için externalIPs kullanmışlardı. İlk hafta her şey tatlıydı. İkinci haftada işe ağ ekibi ile uygulama ekibi birbirine girdi; çünkü IP yönlendirme davranışı beklenenden farklı çalışıyordu ve denetim izi zayıftı.

Kubernetes’in burada yaptığı şey şuydu: Service’i belirli IP’lerde dinler hâle getiriyordu. Ama problem şu ki bu yaklaşım, cluster içindeki herkesin tam güvenilir olduğu varsayımıyla tasarlanmıştı. Gerçek hayatta işe böyle bir dünya yok.

Neden sorunlu hâle geldi?

İşin kritik tarafı CVE-2020-8554 ile iyice görünür öldü. Eğer cluster’da herkes bayağı güvenilir değilse, kötü niyetli biri bu mekanizmayı kullanıp trafik yönlendirmesini bozabiliyor ya da başka servislerin trafiğine burnunu sokabiliyor. Kulağa abartı gibi geliyor. Değil; kurumsal ortamlarda çok katmanlı ağlar arasında bu tip açıklar gerçekten can sıkıyor.

Araya gireyim: Geçen sene Eylül 2025’te İstanbul’daki bir finans müşterisinde benzer güven modeli tartışması yaptık. Orada konu doğrudan externalIPs değildi (bizzat test ettim). Aynı zihniyet vardı: “zaten içerideyiz, sorun olmaz.” Tam orada durmak lazım işte… İçeride olmak artık otomatik güven anlamına gelmiyor.

Şimdi gelelim işin can alıcı noktasına.

Kısacası mesele performans değil; güven modeli. Bir özellik kolay çalışıyor diye doğru tasarım olmuş sayılmıyor.

Kubernetes 1.36 ile gelen resmî deprecation ne demek?

Peki yerine ne koyacağız?

Neyse uzatmayalım… Alternatifler var ve açıkçası çoğu daha temiz çalışıyor. En basit seçeneklerden biri manuel yönetilen LoadBalancer Service kullanmak olabilir; ama bunun da eksikleri var çünkü IP bilgisi spec içinde değil status içinde tutuluyor ve RBAC düzgünse sıradan kullanıcı kolay kolay oynayamıyor.

Daha kurumsal tarafta işe bence asıl doğru yaklaşım ingress controller, internal load balancer veya cloud provider’ın native LB entegrasyonu oluyor. Eğer bare-metal ya da on-prem gidiyorsan MetalLB gibi çözümler de masaya gelir (tabi topoloji uygunsa). Burada sihirli değnek yok; mimarı seçimi altyapıya göre yapmak gerekiyor.

Kısa bir not düşeyim buraya.

Küçük ekip mi, enterprise mı?

Küçük startup yapısındaysan mesele genelde hızdır.
Tek iki kişi platforma bakıyorsa en az sürtünmeyle çalışan çözümü seçersin. Basit bir ingress + cloud LB kombinasyonu çoğu zaman yeterli olur.
Ama yine de externalIPs‘e yaslanma alışkanlığı kazanma derim.
Peki neden?
Çünkü bugün pratik görünen şey yarın seni uğraştırabiliyor.

Büyük kurumsal yapıda işe tablo değişiyor.
Orada ağ güvenliği, change management, audit trail ve ayrıştırılmış yetkiler devreye giriyor — yanı “öldü mu öldü” yaklaşımı işlemiyor.
Böyle yerlerde ben önce politika koyarım, sonra servis modelini sadeleştiririm.
Az önce basit dedim ama aslında mesele biraz daha sert; kontrolsüz kolaylık uzun vadede pahalıya dönüyor.

Sahada gördüğüm geçiş hataları h3 ile anlatayım mı?

Aslında, Evet, anlatayım… En sık gördüğüm hata şu oluyor: ekip önce manifestleri topluca yamıyor, sonra test etmeden production’a itiyor.
Sonuç? Uygulama ayağa kalkıyor gibi görünüyor ama trafik farklı yerde kırılıyor.
Bu kadar mı?
Değil tabiî; bazen sorun sessizce büyüyor ve kimse ilk anda fark etmiyor.

Bence, Zonguldak’taki bir telekom müşterisinde 2024 sonunda buna yakın bir olay yaşadık.
Bir servis görünürde sağlıklıydı. Dış erişim beklenmedik biçimde kesildi; sebep yeni policy’nın bazı eski bağımlılıkları bloklamasıydı.
Çözüm işe şaşırtıcı derecede sade çıktı: önce hangi servislerin gerçekten dış IP kullandığını çıkardık, sonra kademeli migration planladık.
Neyse ki kriz büyümeden yakaladık.

Peki neden?

# Önce kullanım tespiti
kubectl get svc -A -o json | jq -r '
.items[]
| select(.spec.externalIPs != null)
| [.metadata.namespace,.metadata.name,.spec.externalIPs[]]
| @tsv'
# Ardından koruma politikası
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
name: deny-externalips
spec:
failurePolicy: Fail
matchConstraints:
resourceRules:
— apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE","UPDATE"]
resources: ["services"]
# Devamında externalIPs kontrolü policy expression ile yapılır...

Bütçe açısından bakınca ne değişiyor?

Bak şimdi, Bunu Türkiye’deki şirketler açısından değerlendirirsek maliyet tarafını TL bazında düşünmek şart oluyor çünkü kur farkı anlık oyunu bozuyor! Ucuz görünen bir çözüm bazen operasyon yüküyle pahalıya patlıyor; özellikle manuel IP yönetimi varsa insan hatası bedava değil.

Araya gireyim: Eğer bütçen kısıtlıysa önce mevcut cloud provider’ın sunduğu temel load balancer seçeneklerine bak derim.
Azure tarafında örneğin küçük başlangıç senaryolarında standart LB çoğu zaman yeterli olurken daha gelişmiş ihtiyaçlarda Application Gateway veya NGINX tabanlı ingress mantıklı hâle geliyor.
Bak şimdi burası önemli:
Bir servisin aylık faturası düşük olabilir ama operasyonda yarattığı risk yüksekse toplam sahip olma maliyeti yükselir;
işte o yüzden burada yalnızca ürün değil süreç de seçiyorsun;
bazen ucuz olan pahalı çıkar;
maalesef.