message-medicalÖrnekler

1. Senaryo Mimarisi ve Topoloji

Test ortamımız, Kubernetes ağının farklı iletişim katmanlarını simüle etmek için iki farklı Pod yapısı üzerine kurulmuştur. İlk olarak ortamdaki Pod'ların durumuna ve IP adreslerine bakalım.

Komut:

kubectl get pods -o wide

Çıktı:

NAME   READY   STATUS    RESTARTS   AGE   IP          NODE     NOMINATED NODE
pod1   2/2     Running   0          5m    10.0.0.57   node01   <none>
pod2   1/1     Running   0          5m    10.0.0.58   node01   <none>

(Gördüğünüz gibi Pod'lar node01 üzerinde çalışıyor ve CNI tarafından atanmış benzersiz IP'lere sahipler.)


A. Pod1 (Multi-Container Pod):

Bu Pod, Kubernetes'in "Sidecar" mimarisine örnektir. İçinde container1 (uyuyan istemci) ve nginx (web sunucusu) bulunur.

  • Test Amacı: Aynı Pod içindeki konteynerlerin, dışarı çıkmadan localhost üzerinden haberleşebildiğini kanıtlamak.

Komut (Pod'un içinden test):

kubectl exec -it pod1 -c container1 -- curl localhost:80

Beklenen Çıktı:

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
...

(Sonuç: container1, yan odasındaki nginx servisine ağ kablosuna bile değmeden, sadece localhost diyerek erişti.)


2. L3 Bağlantısı

Bu adım, Kubernetes'in "Düz Ağ" modelini kanıtlar. Yani "Her Pod, diğer her Pod ile NAT olmadan konuşabilir."

  • IP Tahsisi: CNI, Pod'lara Node'un IP bloğundan (192.168.x.x) tamamen bağımsız bir bloktan (10.0.0.x) IP vermiştir.

Komut (Pod1'den Pod2'ye Ping):

Beklenen Çıktı:

(Sonuç: İletişim doğrudan gerçekleşti. Arada NAT veya port yönlendirme olmadığı için IP adresleri değişmeden paketler yerine ulaştı.)


3. Altyapı ve CNI Entegrasyonu (L2 Bağlantısı)

Şimdi node01 sunucusuna SSH ile bağlanıp kaputu açalım. Sanal ağın CNI tarafından nasıl inşa edildiğini göreceğiz.

A. Sanal Ethernet (veth) Çiftleri

CNI, Pod'ları ana makinenin ağına bağlamak için sanal kablolar (veth) çeker.

Komut (Node üzerinde):

Beklenen Çıktı:

(Buradaki her veth... satırı, çalışan bir Pod'un fiziksel dünyaya açılan kapısıdır. @if3 ifadesi, kablonun diğer ucunun Pod'un içinde olduğunu gösterir.)

B. Pause Konteynerleri

Her Pod için arka planda çalışan ve ağ alanını (namespace) ayakta tutan "Pause" sürecini görelim.

Komut (Node üzerinde):

Beklenen Çıktı:

(Bu süreçler, Pod'ların "Tapu Sahibi"dir. Uygulamanız çökse bile bu süreç yaşadığı sürece Pod IP'si değişmez.)

C. Namespace İzolasyonu

Her Pod'un kendine ait izole bir Network Namespace olduğunu doğrulayalım.

Komut (Node üzerinde):

Beklenen Çıktı:

(Bu çıktı, nginx ve /pause süreçlerinin ana makinenin ağında değil, kendilerine özel hazırlanmış sanal odalarda (Namespace) çalıştığını kanıtlar.)


🎯 Özet

  1. Aynı Pod İçi: Konteynerler curl localhost ile konuşur.

  2. Farklı Pod'lar: Pod'lar birbirine ping 10.0.0.x ile doğrudan (NAT'sız) ulaşır.

  3. Altyapı: Tüm bu sihir, Node üzerindeki veth arayüzleri ve /pause konteynerleri sayesinde gerçekleşir.

Last updated