Demo

Bir sabah uyandınız ve sisteminizdeki uygulamaların birbiriyle konuşamadığını, dışarıya istek atamadığını veya müşterilerin servislere erişemediğini fark ettiniz. Hata mesajları yetersiz ve her şey birbirine girmiş durumda.

Panik yapmak yerine, Kubernetes ağ mimarisini katman katman test ederek sorunu izole edeceğiz. Bu senaryoda ağ eklentisi olarak Cilium kullandığımızı varsayarak temelden (altyapıdan) uygulamaya doğru bir hata ayıklama (troubleshooting) süreci işleteceğiz.

1. Altyapı Kontrolü: CNI (Ağ Eklentisi) Hayatta mı?

Uygulamalara bakmadan önce, "Kablolar takılı mı?" sorusunun cevabını vermeliyiz. Cilium gibi ağ eklentileri kube-system namespace'inde çalışır.

Adım 1: Pod'ların Durumuna Bakmak

Ağ eklentimizin bileşenleri ayakta mı, yoksa sürekli yeniden mi başlıyor (CrashLoopBackOff)?

kubectl get pods -n kube-system

Örnek Çıktı:

NAME                               READY   STATUS    RESTARTS   AGE
cilium-6xfl8                       1/1     Running   0          3m
cilium-operator-58684c48c9-4rntb   1/1     Running   0          3m

Her şey Running durumunda. Eğer burada bir hata görseydik, kubectl logs -n kube-system cilium-6xfl8 komutuyla doğrudan logların içine girecektik.

Adım 2: Cilium CLI ile Derinlemesine Sağlık Taraması

Eğer Cilium CLI aracınız yüklüyse, tek bir komutla tüm ağ alt yapısının röntgenini çekebilirsiniz:

cilium status

Cilium:                OK
Operator:              OK
DaemonSet cilium:      Desired: 2, Ready: 2/2, Available: 2/2

Altyapımız sapasağlam! Sorun tesisatta değil, bir üst katmana geçebiliriz.

---

2. Görünmez Duvarlar: Network Policy Kontrolü

Altyapı çalışıyor ama Pod'umuz internete çıkamıyor veya başka bir servise bağlanamıyorsa, sorunun kaynağı genellikle sessizce trafiği düşüren (timeout verdiren) Network Policies'dir.

Adım 1: Kuralları Listelemek

Ortamımızda trafiği engelleyen bir kural olup olmadığına bakalım:

kubectl get networkpolicies -A

# ÇIKTI:
# NAMESPACE   NAME                  POD-SELECTOR   AGE
# default     default-deny-egress   <none>         7m

Listede şüpheli bir kural gördük: default-deny-egress.

Adım 2: Kuralı İncelemek ve Test Etmek

Bu kuralın ne yaptığını anlamak için içine bakalım:

kubectl describe networkpolicy default-deny-egress
# Çıktı bize bu kuralın "Egress" (dışarı giden trafik) için olduğunu ve hiçbir şeye izin vermediğini söyler.

Durumu fiziksel olarak kanıtlamak için geçici bir "test podu" ayağa kaldırıp Google'a istek atmayı deneyelim:

kubectl run --rm -i --tty debug --image=curlimages/curl --restart=Never -- curl www.google.com --connect-timeout 2

Sonuç: Komut donup kalır (Timeout). Dışarı çıkışımız kesin olarak yasaklanmış.

Çözüm: Sorunlu güvenlik duvarı kuralını silerek (veya düzelterek) trafiği açalım:

kubectl delete networkpolicy default-deny-egress

Kuralı sildikten sonra curl komutunu tekrar çalıştırdığınızda Google'dan anında yanıt aldığınızı göreceksiniz.

---

3. Yanlış Adres, Kör Servis: Service ve Pod Bağlantısı

İç ağ çalışıyor, güvenlik duvarı açık ama dışarıdaki kullanıcı nginx-service üzerinden sitemize giremiyor. Sorun nerede? Service'te mi yoksa Pod'da mı?

Adım 1: Sorunu İzole Etmek (Port-Forward Hayat Kurtarır)

Öncelikle uygulamanın (Pod'un) gerçekten çalışıp çalışmadığını anlamak için aradaki Service nesnesini bypass edip, kendi bilgisayarımızdan doğrudan Pod'a tünel açalım:

kubectl port-forward pod/nginx-deployment-56fcf95486-7d2dw 8080:80

Tarayıcınızdan http://localhost:8080 adresine gittiğinizde web siteniz açılıyorsa; tebrikler, uygulamanızda (Pod'da) hiçbir sorun yok! Suçlu tamamen Service nesnesindedir.

Adım 2: Service'in Adres Defterini (Endpoints) Kontrol Etmek

Bir önceki yazımızda öğrendiğimiz o meşhur rehbere bakalım. Acaba servisimiz arkadaki Pod'un IP'sini bulabilmiş mi?

kubectl describe svc nginx-service

Kritik Çıktı:

Selector:  app=nginx-website
Endpoints: <none>

İşte sorun tam karşımızda duruyor! Servisin adres defteri bomboş (<none>). Kubernetes, servisteki etiketler ile Pod'daki etiketleri eşleştirememiş.

Adım 3: Etiketleri (Labels) Düzeltmek

Hemen Pod'umuzun gerçek etiketine bakalım:

kubectl get pod nginx-deployment-56fcf95486-7d2dw -o=jsonpath='{.metadata.labels}'
# ÇIKTI: {"app":"nginx"}

Pod'un etiketi app=nginx, ama servisimiz app=nginx-website etiketini arıyor. Ufak bir yazım hatası bütün sistemi çökertmiş!

Servisi düzenleyip hatayı düzeltelim:

kubectl edit svc nginx-service
# Açılan dosyada "app: nginx-website" yazan yeri "app: nginx" olarak değiştirip kaydedin.

Mutlu Son:

Tekrar kontrol ettiğimizde adres defterinin dolduğunu göreceğiz:

kubectl describe svc nginx-service
# Endpoints: 10.0.0.247:80

Bağlantı sağlandı ve kriz çözüldü!