yoklateknik mülakat
GelişimGeçmiş

DevOps / Cloud K8s Observability Troubleshooting Mülakat Soruları

75 doğrulanmış DevOps / Cloud K8s Observability Troubleshooting mülakat sorusu — cevaplarıyla çöz, açıklamalarıyla öğren, gerçek simülasyonda kendini test et.

Gerçek simülasyonu dene →

Örnek sorular

K8s Observability TroubleshootingZorluk 1
Kubernetes'te Pod fazı Running aslında neyi garanti eder?
  • aPod'daki tüm container'lar readiness kontrollerini geçmiştir
  • bEn az bir container oluşturulmuş ve çalışıyordur✓
  • cPod, kendisini seçen her Service'in Endpoints'ine eklenmiştir
  • dPod'un container'ları oluşturulduğundan beri hiç yeniden başlamamıştır
Açıklama:Running, yalnızca Pod'un zamanlandığı ve en az bir container'ın ayakta olduğu anlamına gelir; readiness hakkında hiçbir şey söylemez — bir container readiness probe'unda başarısız olursa Pod READY 0/1 iken de Running olabilir.
K8s Observability TroubleshootingZorluk 1
$ kubectl get pod crash-pod
NAME        READY   STATUS             RESTARTS      AGE
crash-pod   0/1     CrashLoopBackOff   4 (37s ago)   3m

Buradaki CrashLoopBackOff durumu ne anlama gelir?
  • aPod, cluster'daki hiçbir Node'a zamanlanamadı
  • bContainer'ın image'ı registry'den çekilemedi
  • cPod, bir PersistentVolumeClaim'in bağlanmasını bekliyor
  • dContainer her yeniden başlatmadan kısa süre sonra tekrar çöküyor✓
Açıklama:CrashLoopBackOff, container'ın tekrar tekrar çöktüğü ve restartPolicy nedeniyle kubelet'in yeniden denediği, ancak her denemeyi anında değil artan bir bekleme süresiyle yaptığı anlamına gelir.
K8s Observability TroubleshootingZorluk 2
Bir Pod'un tek container'ı command: ["sh", "-c", "exit 1"] ile tanımlanmış ve restartPolicy: Always (varsayılan) ayarlı. Pod oluşturulduktan hemen sonra ne olur?
  • aHemen sıfırdan farklı bir kodla çıkış yapar; kubelet yeniden başlatır, CrashLoopBackOff görünür✓
  • bKomut geçersiz olduğu için Pod Pending durumunda kalır
  • cContainer bir kez başlar, çıkış yapar ve komut tamamlandığı için Pod fazı Succeeded olur
  • dkubectl, komutun uzun süre çalışan bir process olmaması nedeniyle manifest'i apply anında reddeder
Açıklama:Sıfırdan farklı bir kodla çıkış yapmak, ne kadar hızlı olursa olsun bir başarısızlık sayılır; restartPolicy: Always ile kubelet container'ı yeniden başlatmaya devam eder ve birkaç ardışık başarısızlıktan sonra gösterilen durum CrashLoopBackOff olur.
K8s Observability TroubleshootingZorluk 2
$ kubectl describe pod oom-pod
    ...
    Last State:     Terminated
      Reason:       OOMKilled
    Restart Count:  3

Reason: OOMKilled, container'ın neden sonlandırıldığı hakkında ne söyler?
  • aContainer'ın liveness probe'u art arda üç kez başarısız oldu
  • bNode, container'ın image'ını çekerken disk alanı tükendi
  • cContainer, memory limit'ini aştı ve sonlandırıldı✓
  • dContainer'ın process'i kendiliğinden 0 koduyla çıkış yaptı
Açıklama:OOMKilled, container memory limit'ini aştığında raporlanır; kernel'in out-of-memory killer'ı process'i sonlandırır ve kubelet bunu genel bir sıfırdan farklı çıkış yerine bu özel nedenle raporlar.
K8s Observability TroubleshootingZorluk 1
Bir container'ın liveness probe'u (failureThreshold'u aşacak şekilde) tekrar tekrar başarısız olursa ne olur?
  • aPod, tüm Service Endpoints'lerinden çıkarılır ama container değişmeden çalışmaya devam eder
  • bkubelet, container'ı öldürür ve Pod'un restart policy'sine göre yeniden başlatır✓
  • cPod silinir ve farklı bir Node'a yeniden zamanlanır
  • dKubernetes, Node'u zamanlanamaz olarak işaretler
Açıklama:Başarısız olan bir liveness probe, kubelet'e container'ın sağlıksız olduğunu ve yeniden başlatılması gerektiğini söyler; kubelet container'ı öldürüp yerine yeni bir örnek başlatır, bu da Pod'un restart sayacını artırır.
K8s Observability TroubleshootingZorluk 2
Bir Service'in arkasındaki Pod'da readinessProbe sürekli başarısız oluyor:
$ kubectl get pod readiness-fail-pod
NAME                 READY   STATUS    RESTARTS   AGE
readiness-fail-pod   0/1     Running   0          40s

$ kubectl get endpoints readiness-demo-svc
NAME                 ENDPOINTS   AGE
readiness-demo-svc               40s

Bu çıktıyı en iyi ne açıklar?
  • aContainer çöktü ve kubelet onu yeniden başlatmak üzere
  • bPod bir Node'a zamanlanamadı
  • cService'in label selector'ı Pod'un etiketleriyle hiç eşleşmiyor
  • dContainer hâlâ çalışıyor ama Service'in Endpoints'inden çıkarıldı✓
Açıklama:Başarısız bir readiness probe yalnızca trafik yönlendirmesini etkiler: Pod RESTARTS 0 ile Running kalır, ama kubelet onu ready-olmayan olarak işaretler, bu yüzden endpoint controller onu tekrar geçene kadar Service'in Endpoints'inden çıkarır.

Uzmanlığa göre

AWS 450Azure 450GCP 450Kubernetes 450Linux 450Terraform 450

Kıdeme göre

DevOps / Cloud JuniorDevOps / Cloud MidDevOps / Cloud Senior

Diğer alanlar

BackendFrontendFullstackAI EngineerVeritabanıMobilGüvenlikQA / Test OtomasyonuData EngineerOyun GeliştirmeML Engineer

3375 soruluk DevOps / Cloud bankasında kendini sına.

Mülakata başla