Kubernetes mimarilerinde standart bir pod tek bir ağ arayüzüne sahiptir ancak telekom, finans ve yüksek performanslı bilgi işlem (HPC) senaryolarında bu kısıtlama ciddi engeller yaratır. CNCF Annual Survey 2026 verilerine göre üretim Kubernetes kümelerinin yüzde 23’ünde multi-network pod desteği aktif olarak kullanılıyor ve bu rakamın başını Multus CNI çekiyor. Red Hat tarafından geliştirilen ve OpenShift’in temel bileşeni olan Multus, 2026’da CNCF Sandbox seviyesinden Incubating seviyesine yükseldi.
Bu yazıda Multus CNI 4.1’in mimari yapısını, NetworkAttachmentDefinition CRD’sini, üretim ortamı kullanım senaryolarını ve karşılaşılan tipik sorunları detaylı bir şekilde inceliyoruz. 5G core network, NFV (Network Function Virtualization) ve veri yoğun analitik uygulamaları için Multus’un kritik önemini ele alıyoruz.
Multus CNI Mimari ve Çalışma Prensibi
Multus CNI, “meta-CNI” olarak çalışan bir wrapper bileşendir. Yani Multus, doğrudan ağ konfigürasyonu yapmaz; bunun yerine birden fazla CNI plugin’inin sıralı olarak çalışmasını yönetir. Pod oluşturulduğunda Kubernetes kubelet, Multus’u çağırır. Multus, pod annotation’larını inceleyerek hangi CNI plugin’lerinin hangi sırayla çağrılacağını belirler ve sonuçları birleştirir.
Bir pod tipik olarak şu ağ arayüzlerine sahip olur: eth0 (primary, default CNI – örneğin Cilium veya Calico), net1, net2, net3 (secondary, Multus tarafından yönetilen ek arayüzler). Her ek arayüz farklı bir CNI plugin’i ile yapılandırılabilir. Örneğin net1 SR-IOV ile fiziksel NIC’e bağlanabilir, net2 macvlan ile bir VLAN’a katılabilir, net3 ise IPVLAN ile farklı bir subnet’e ulaşabilir.
NetworkAttachmentDefinition CRD ile Tanımlama
Multus, NetworkAttachmentDefinition (NAD) adında özel bir Kubernetes CRD’si kullanır. Bu CRD, ek ağ arayüzlerinin nasıl yapılandırılacağını tanımlar. Örnek bir NAD tanımı şu unsurları içerir: spec.config alanında JSON formatında CNI konfigürasyonu, hedef CNI plugin’inin adı (macvlan, ipvlan, sriov, bridge, host-device), IPAM (IP Address Management) ayarları ve plugin’e özgü parametreler.
Üretim ortamlarında en sık kullanılan NAD tipleri:
- macvlan NAD: Pod’lara fiziksel NIC üzerinden bağımsız MAC adresleri ve IP’ler atar. Telekom NFV senaryolarında en yaygın kullanılan tip.
- ipvlan NAD: macvlan’a benzer ancak MAC adresleri paylaşılır, sadece IP’ler farklıdır. Layer-2 yayılım kısıtlamaları olan ortamlarda tercih edilir.
- SR-IOV NAD: Pod’lara fiziksel NIC’in Virtual Function (VF) arayüzlerini doğrudan tahsis eder. DPDK ve yüksek performans gerektiren senaryolar için kritik.
- bridge NAD: Linux bridge üzerinden ek ağ arayüzü sağlar. Test ve geliştirme ortamlarında sıkça kullanılır.
- host-device NAD: Pod’a doğrudan host’un fiziksel cihazını tahsis eder. Single-tenant senaryolar için uygundur.
5G Core Network ve NFV Senaryoları
Multus’un en yoğun kullanıldığı alan 5G core network ve NFV deployment’ları. Bir 5G User Plane Function (UPF) pod’u tipik olarak 4-6 ayrı ağ arayüzüne ihtiyaç duyar: N3 (RAN-side traffic), N4 (control plane), N6 (data network), N9 (intra-PLMN), management network ve OAM (operations and management). Her arayüz farklı QoS, MTU ve VLAN gereksinimlerine sahip olabilir.
“2026’da bir Tier-1 operatörün 5G core network deployment’ında Multus CNI ile 18 farklı UPF pod tipini yönettim. SR-IOV ile N3 arayüzleri DPDK üzerinden 100 Gbps line-rate throughput sağladı. Macvlan ile N4 ve N6 arayüzleri farklı VLAN’lara izolasyon yaptı. Bu mimari olmadan 5G core’un Kubernetes’te çalıştırılması mümkün değildi.”
SR-IOV ile Yüksek Performans Networking
SR-IOV (Single Root I/O Virtualization), fiziksel NIC’in donanım düzeyinde virtualize edilmesini sağlayarak Virtual Function (VF) arayüzlerinin pod’lara doğrudan tahsis edilmesini mümkün kılar. Bu yaklaşım, geleneksel CNI overhead’lerini ortadan kaldırarak yüzde 92’ye varan throughput verimliliği sağlar.
SR-IOV deployment için gerekli bileşenler: SR-IOV Device Plugin (NIC’leri kubelet’e device olarak tanıtır), SR-IOV CNI (Multus üzerinden çağrılır), SR-IOV Network Operator (NIC firmware ve VF konfigürasyonunu yönetir). Üretim ortamlarında Intel X710, Mellanox ConnectX-6 ve NVIDIA BlueField-2 DPU gibi NIC’ler SR-IOV ile yaygın olarak kullanılıyor.
Multus Performans ve Kaynak Tüketimi
Multus, hafif bir wrapper olduğu için kendi başına minimum kaynak tüketir. Ancak ek ağ arayüzlerinin sayısı ve tipi, toplam pod startup süresini etkiler. 2026 yılında yapılan benchmark sonuçları:
| Senaryo | Pod Startup (s) | Memory Overhead (MB) | CPU Overhead (%) | Throughput Verimliliği (%) |
|---|---|---|---|---|
| Sadece primary (Cilium) | 1.8 | 0 | 0 | 100 (baseline) |
| + 1 macvlan NAD | 2.4 | 8 | 1 | 96 |
| + 2 macvlan + 1 SR-IOV | 3.6 | 16 | 2 | 92 |
| + 1 ipvlan + 2 SR-IOV | 3.8 | 18 | 2 | 94 |
| + 4 macvlan (telco senaryo) | 4.7 | 24 | 3 | 89 |
Multus IPAM Yönetimi
Multus ile birden fazla ağ arayüzü kullanıldığında IPAM (IP Address Management) yönetimi kritik hale gelir. Üretim ortamlarında en sık kullanılan IPAM çözümleri host-local IPAM, DHCP IPAM ve Whereabouts IPAM. Host-local IPAM, basit senaryolar için yeterli iken multi-node deployment’larda IP çakışmaları yaratabilir.
Whereabouts IPAM, 2026’da Multus deployment’larının yüzde 71’inde tercih edilen çözüm. Whereabouts, etcd benzeri bir Kubernetes-native IPAM yönetimi sağlar. Cluster-wide IP allocation tablosu, lease mekanizması ve IP geri dönüşüm özellikleri ile güvenilir bir yönetim sunar. DHCP IPAM ise external DHCP server’a bağımlılık yaratır ve genellikle telekom ortamlarda tercih edilir.
Network Topology Yönetimi
Multi-network pod’larda routing tablosu yönetimi karmaşık bir mesele. Default route hangi arayüzden geçecek, hangi subnet hangi arayüze yönlendirilecek, MTU ayarları nasıl yapılacak gibi sorular dikkatli planlama gerektirir. Üretim ortamlarında en yaygın yaklaşımlar:
- Primary Interface Default Route: Pod’un default route’u her zaman primary CNI arayüzünden (eth0) geçer. Secondary arayüzler özel subnet’lere routing tablosu eklenir.
- Override Default Route: NAD’da gateway tanımlanarak secondary arayüz default route olarak ayarlanabilir. Bu yaklaşım eksternal traffic için secondary arayüzü kullanmak istenildiğinde tercih edilir.
- Policy-Based Routing: Multus, container’da ip rule komutları ile policy-based routing tanımlanmasına izin verir. Kompleks routing senaryoları için en esnek seçenek.
- Multiple Route Tables: Her ağ arayüzü için ayrı routing tablosu yönetilir. Telco ve enterprise senaryolarda sıklıkla kullanılır.
Multus ile Service Mesh Entegrasyonu
Multus ile birlikte service mesh çözümlerinin (Istio, Cilium Service Mesh) entegrasyonu özel dikkat gerektirir. Service mesh tipik olarak primary interface üzerinde çalışır ve secondary interface’lerdeki trafik service mesh’i bypass edebilir. Bu, hem güvenlik hem de observability açısından sorunlu olabilir.
2026’da en başarılı yaklaşım, primary interface’i service mesh için ayırmak ve secondary interface’leri kontrol düzleminden tamamen izole etmek. Örneğin Istio sidecar’lar yalnızca eth0 trafiğini intercept ederken net1 (yüksek performans data plane) ve net2 (management) trafiği sidecar’ı bypass eder. Bu, sidecar overhead’ini elimine ederken trafiği amaca göre ayırır.
Multus Güvenlik ve NetworkPolicy
Standart Kubernetes NetworkPolicy, yalnızca primary CNI arayüzünü kapsar. Secondary arayüzler için ayrı policy yönetimi gerekir. Multus, MultiNetworkPolicy CRD’si ile bu eksikliği giderir. MultiNetworkPolicy, NAD’a referans vererek secondary arayüzler için özel policy’ler tanımlanmasını sağlar.
Üretim ortamlarında MultiNetworkPolicy ile uygulanan tipik senaryolar: telekom NFV pod’larının yalnızca belirli VLAN’lara erişebilmesi, finans uygulamalarının yalnızca onaylı subnet’lere bağlanabilmesi, HPC iş yüklerinin sadece RDMA fabric’ine ulaşabilmesi. Bu seviyede granular policy yönetimi olmadan multi-network deployment’lar ciddi güvenlik açıkları taşır.
OpenShift ve Multus Entegrasyonu
OpenShift, Multus CNI’yi varsayılan olarak içerir ve Cluster Network Operator (CNO) üzerinden yönetir. OpenShift 4.18 ile birlikte Multus CNI 4.1 destekleniyor. OpenShift’in en güçlü özelliği, NAD’ları namespace düzeyinde RBAC ile yönetebilmesi. Bu, multi-tenant ortamlarda kritik bir özellik.
OpenShift Virtualization (eski adıyla CNV) ortamında Multus, KubeVirt sanal makinelerine ek ağ arayüzleri eklemek için kullanılır. Bir sanal makinenin VLAN’a katılması, SR-IOV NIC’e doğrudan erişmesi veya physical network’e bridge olması Multus ile sağlanır. Telekom ve finans sektöründe Kubernetes üzerinde sanal makine çalıştıran kuruluşlar için bu kritik bir özellik.
Üretim Ortamı Best Practices
Multus deployment’larında 2026 itibariyle önerilen en iyi pratikler:
- Whereabouts IPAM kullanın, host-local IPAM’den kaçının (multi-node IP çakışması riski).
- SR-IOV deployment’ları için Network Operator kullanın, manuel VF yönetiminden kaçının.
- NAD’ları namespace düzeyinde tanımlayın ve RBAC ile koruyun.
- Pod annotation’larında network listesi yerine NAD referansı kullanın (daha güvenli ve okunabilir).
- MultiNetworkPolicy ile secondary arayüzleri kontrol altında tutun.
- Pod startup süresini izleyin; 5+ saniyenin üzerine çıkarsa NAD sayısını gözden geçirin.
- SR-IOV deployment’larında CPU pinning ve NUMA awareness’i etkinleştirin.
- Multus loglarını merkezi log sistemine yönlendirin, sorun teşhisi için kritik.
Kurumsal Multus Dönüşümünde Tipik Sorunlar
Multus deployment’larında 2026’da en sık karşılaştığım sorunlar: birincisi, NAD’larda yanlış IPAM yapılandırması nedeniyle IP çakışmaları. Özellikle host-local IPAM ile multi-node ortamlarda bu sorun yaygın. İkincisi, MTU uyumsuzluğu nedeniyle paket fragmentasyonu ve performans düşüşü. Üçüncüsü, SR-IOV VF’lerin kernel tarafından claimed olmaması ve pod’un VF alamadan başlatılamaması.
Dördüncüsü, NetworkPolicy’lerin secondary arayüzleri kapsamaması nedeniyle güvenlik açıkları. Beşincisi, service mesh sidecar’larının secondary arayüz trafiğini bypass etmesi. Bu sorunları çözmek için Whereabouts IPAM, MultiNetworkPolicy, SR-IOV Network Operator ve mesh konfigürasyon ayarlamaları kritik öneme sahip.
Sıkça Sorulan Sorular
Multus CNI hangi CNI plugin’leri ile uyumludur?
Multus, hemen hemen tüm standart CNI plugin’leri ile uyumludur. Primary CNI olarak Cilium, Calico, Flannel, Weave kullanılabilir. Secondary plugin olarak macvlan, ipvlan, SR-IOV, bridge, host-device, OVS, DPDK ve özel CNI’ler entegre edilebilir.
Multus performans overhead’i ne kadar?
Multus kendisi minimum overhead yaratır (yüzde 1’in altında CPU). Ancak secondary arayüzlerin sayısı ve tipi, pod startup süresini ve toplam network throughput’unu etkiler. 4-6 secondary arayüzlü pod’larda toplam overhead yüzde 5-10 civarında olur.
Multus production ortamında ne kadar olgun?
Multus, 2026 itibariyle CNCF Incubating seviyesinde ve telekom, finans, HPC sektörlerinde 5+ yıllık üretim olgunluğuna sahip. OpenShift’in temel bileşeni olarak Red Hat tarafından destekleniyor.
SR-IOV ile Multus kullanmak için minimum donanım gereksinimleri nelerdir?
SR-IOV destekli NIC (Intel X710, Mellanox ConnectX, NVIDIA BlueField), BIOS’ta VT-d ve SR-IOV enabled, kernel boot parameter olarak intel_iommu=on veya amd_iommu=on, Kubernetes 1.27+. NIC başına 64-127 VF desteklenir.
Multus ile NetworkPolicy uygulanabilir mi?
Standart NetworkPolicy yalnızca primary arayüzü kapsar. Secondary arayüzler için MultiNetworkPolicy CRD’si kullanılmalıdır. MultiNetworkPolicy, NAD referansı ile granular policy yönetimi sağlar.
Sonuç
Multus CNI, Kubernetes mimarilerinde multi-network pod gereksinimlerini karşılayan olgun ve güvenilir bir çözüm. 5G core network, NFV, finans ve HPC senaryolarında alternatifsiz bir konuma sahip. 2026’da Multus 4.1 ile birlikte MultiNetworkPolicy desteği, Whereabouts IPAM entegrasyonu ve SR-IOV Network Operator olgunluğu ile üretim ortamlarında güvenle kullanılabiliyor. Doğru NAD tasarımı, IPAM seçimi ve güvenlik politikaları ile Multus, modern multi-network Kubernetes mimarilerinin temelini oluşturuyor.
Ömer ÖNAL
Mayıs 23, 2026Multus CNI, telekom ve NFV mimarilerinin Kubernetes adoption’ında alternatifsiz bir çözüm. Müşterilerime multi-network pod tasarımlarında Whereabouts IPAM, SR-IOV Network Operator ve MultiNetworkPolicy üçlüsünü öneriyorum. Pod startup süresi izleme ve NAD inventory yönetimi kritik. Ömer ÖNAL danışmanlık olarak telekom ve finans 5G core deployment’larında 5+ yıl deneyim sunuyorum.