Bu yazımızda OpenShift üzerinde SDN ve OVN CNI kavramları hakkında konuşacağız.

Doğada var olan canlılar, istemeseler bile bir şekilde iletişim kurarlar ve bu iletişimi de belirli yollarla ve yöntemlerle gerçekleştirirler.
Örneğin; bir karınca, başka bir karınca ile “feromon” adı verilen bir kimyasal madde aracılığıyla iletişim kurar. Antenleriyle bu maddeye temas ettiğinde koloni içindeki bilgileri, mevcut durumu, tehlikeleri ya da yiyeceklerin bulunduğu konumu diğerlerine aktarır. Yani iletişim kurarak haberleşmeyi sağlar.

Peki, bu iletişim mekanizmasını OpenShift üzerinde nasıl sağlarız?

Bildiğimiz üzere OpenShift, ister sanallaştırma ortamında ister bare metal (fiziksel sunucular) üzerinde çalıştırılabilir. Bu ortam üzerinde bir veya binlerce Pod aynı anda çalışabilir. Pod’ların birbirleriyle ve dış dünya ile iletişim kurmasını sağlayan yine bir veya birden fazla servis olabilir.

Tam da bu noktada devreye, haberleşmeyi sağlayan bazı kavramlar girer. Bu kavramlardan en önemlisi: CNI (Container Network Interface)’dir.

CNI (Container Network Interface) Nedir?

CNI, Kubernetes ve OpenShift ortamlarında çalışan Pod’ların ağ bağlantısını kuran ve yöneten eklenti standardıdır.

OpenShift ortamında Pod’lar sürekli dinamik şekilde oluşur ve silinir.

• Pod hata alabilir ve sonlandırılabilir.
• Trafik yükü artarsa otomatik olarak yeni Pod’lar oluşturulabilir.
• Manuel olarak replica sayısı artırıldığında Pod sayısı da artar.
• Tersi durumda, ölçek küçültülürse Pod sayısı azalır.

Tüm bu dinamik değişiklikler sırasında Pod’ların IP adresleri de sürekli değişir. İşte bu noktada CNI eklentisi sayesinde bu süreç otomatik olarak yönetilir.

Kısaca süreç şöyle işler,

1️⃣ Kubelet ajanı, container’ın yaşam döngüsünü takip eder ve gerekli bilgiyi Container Runtime’a iletir.
2️⃣ Container Runtime (Docker, Podman, CRI-O, Containerd vb.), CNI eklentisine ADD veya DEL komutlarını gönderir.
3️⃣ CNI eklentisi bu komutlara göre network yapılandırmasını yapar ve Pod’u sanal ağa bağlar.

Sonuç olarak Pod’lar, hiçbir manuel işlem gerekmeksizin dinamik şekilde IP alır, sanal ağa bağlanır ve iletişim kurabilir hâle gelir.

✅ Bu sayede:

• Pod’lar arası iletişim otomatik olarak sağlanır.
• Yeni oluşturulan veya silinen Pod’lar için ağ yapılandırması manuel müdahale olmadan yapılır.
• Ölçeklenebilir, esnek ve güvenli bir ağ altyapısı sağlanır.

Şimdi bu temel kavramı öğrendiğimize göre bir sonraki adımda OpenShift’te kullanılan iki önemli CNI çözümü olan SDN ve OVN-Kubernetes’i inceleyebiliriz. Bunun yanı sıra K8S üzerinde Cilium,Flannel,Calico vs. çözümlerde vardır.

Şimdi bu pluginleri kısaca açıklayaylım;

OPENSHIFT SDN

1) veth Oluşturma:
Pod oluşturulduğunda, çalıştığı node üzerindeki SDN ajanı bu pod için bir virtual Ethernet pair (veth) oluşturur. Bunu bir kablo gibi düşünebilirsiniz: bir ucu podun içindeki eth0 arayüzüne bağlanır, diğer ucu ise node üzerinde bulunan sanal switch olan OVS (Open vSwitch)’e bağlanır. Bu sayede pod artık servislerle, diğer pod’larla veya node’larla iletişim kurabilecek duruma gelir.

2) IP Atama:
Pod’un iletişim kurabilmesi için bir IP adresine ihtiyaç vardır. CNI bu noktada devreye girer ve pod’a overlay ağ içinden benzersiz bir IP adresi atar. Her node’un kendine ait bir subnet’i bulunur (örneğin 10.128.0.0/24) ve pod bu subnet’ten bir IP alır.

3) Tünel Bilgilerinin Dağıtımı:
SDN Controller, tüm node’ların subnet bilgilerini ve pod IP’lerini bilir ve bu bilgileri dağıtır. Bu sayede bir node’daki pod, başka bir node’daki pod’a ulaşmak istediğinde hedefin nerede olduğunu bilir ve iletişim sağlanır.

4) VXLAN Üzerinden İletişim:
Pod’lar arası iletişim VXLAN tünelleri üzerinden gerçekleşir. Paketler kapsüllenerek Layer 2 paketleri, Layer 3 UDP paketlerinin içine alınır. Böylece fiziksel ağ üzerinden pod paketleri UDP paketi gibi taşınır.

5) Network Policy Kontrolü:
Tanımlı NetworkPolicy kuralları varsa, bu kurallar iptables’a çevrilir. Pod’a gelen trafik önce bu filtrelerden geçer ve tanımlı kurallara göre izin verilir veya reddedilir.

ÖZET:

Pod oluşturulur → SDN ajanı bir veth çifti oluşturur (bir ucu Pod’un eth0 arayüzüne, diğeri node üzerindeki OVS’e bağlanır).
Pod’a overlay IP atanır → Örneğin 10.128.x.x gibi benzersiz bir adres verilir.
SDN Controller, tüm node’ların subnet bilgilerini dağıtarak hangi Pod’un hangi node’da olduğunu bilir.
Node, diğer node’larla VXLAN tünelleri kurar ve encapsulation yöntemiyle Pod trafiğini taşır.
NetworkPolicy, iptables kuralları olarak uygulanır ve güvenlik kontrolleri bu seviyede yapılır.

OVN KUBERNETES,

1) Pod Oluşturma ve veth Bağlantısı:
Pod oluşturulduğunda ovn-controller, bu pod için bir veth çifti oluşturur ve onu OVS Logical Switch’e bağlar (SDN’deki gibi). Buradaki fark, her namespace için ayrı bir logical switch oluşturulmasıdır. Pod bu switch içerisinde bir port gibi davranır.

2) IP Atama ve Dağıtım:
Her node kendi subnet’ine sahiptir ve pod’a bir IP adresi atanır. Bu IP bilgisi OVN Northbound DB (NBDB)’ye kaydedilir. Ardından ovn-northd servisi bu bilgiyi Southbound DB (SBDB) formatına çevirir ve tüm ovn-controller’lara dağıtır. Böylece tüm node’lar pod’un IP’sini, hangi logical switch’e bağlı olduğunu ve routing tablosunu bilir.

3) Routing Tablosu Oluşturma:
Her node’daki ovn-controller, diğer node’ların topolojisini SBDB üzerinden öğrenir ve kendi routing tablolarını oluşturur. Bu sayede routing kararları merkezi bir kontrolcüye ihtiyaç duyulmadan dağıtık (distributed) şekilde alınır.

4) L3 Routing ve Geneve Tüneli:
Pod’lar arası trafik L3 routing ve Geneve tüneli üzerinden taşınır. Paket encapsule edilir ve Geneve (VXLAN’a benzer ama metadata destekli) üzerinden diğer node’a gönderilir. Geneve, pod trafiği hakkında ek metadata (örneğin policy ID, security context vb.) taşıyabilir ve bu da sisteme gelişmişlik kazandırır.

5) NetworkPolicy – OpenFlow:
NetworkPolicy kuralları OpenFlow kuralları olarak uygulanır. Bu kurallar doğrudan OVS’in flow tablolarına yazılır. Böylece kernel seviyesine inmeden switch katmanında çalışır. Policy kontrolü çok daha hızlı ve daha az CPU kaynağıyla yapılır.

ÖZET:
Pod oluşturulur → ovn-controller bir veth çifti oluşturur ve pod’u OVS Logical Switch’e bağlar.
Pod’a IP atanır → Bu bilgi NBDB → SBDB yoluyla tüm node’lara yayılır.
Node routing tablosunu oluşturur → ovn-controller diğer subnet bilgilerini öğrenip gerekli rotaları yazar.
Trafik yönlendirilir → Pod A → Pod B trafiğinde OVS, paketi Logical Router’a yönlendirir.
Encapsulation & Teslimat → Logical Router hedef subnet’in hangi node’da olduğunu bilir → paket Geneve encapsulation ile hedef node’a gönderilir, orada açılır ve pod’a teslim edilir.
NetworkPolicy uygulanır → Policy kuralları OpenFlow olarak OVS flow tablolarına yazılır; kernel seviyesine inmeden hızlı ve düşük CPU kullanımıyla güvenlik kontrolleri yapılır.

Kısaca, büyük ölçekli ortamlarda, node başına daha fazla pod çalıştırılması gerekiyorsa ve yüksek performans öncelikliyse OVN-Kubernetes tercih edilmelidir.
Ancak, daha basit ve kolay yönetilebilir bir yapı hedefliyorsanız ve küçük ölçekli bir ortamınız varsa OpenShift SDN uygun bir seçenek olacaktır.

Teşekkürler.