Kubernetes Pod Pending Durumu: Neden Pod’larınız Planlanmıyor?

Kubernetes ortamında Pod’larınız ‘Pending’ durumunda mı takılı kaldı? Bu kapsamlı rehber, Pod’ların neden planlanmadığını anlamanıza, yaygın sorunları gidermenize ve sistemlerinizi verimli çalıştırmanıza yardımcı olacak.

Modern bulut yerel uygulamaların temelini oluşturan Kubernetes, container’ları düzenlemek ve yönetmek için vazgeçilmez bir platformdur. Ancak, bu karmaşık ekosistemde zaman zaman beklenmedik durumlarla karşılaşmak kaçınılmazdır. Özellikle Pod’larınızın sürekli ‘Pending’ (beklemede) durumunda kalması, geliştiriciler ve operasyon ekipleri için sıkça karşılaşılan ve can sıkıcı bir sorundur. Peki, Pod’larınız neden planlanmıyor ve bu durum iş akışınızı nasıl etkiliyor? İşte bu soruların yanıtlarını derinlemesine inceleyeceğiz.

Bir Pod’un ‘Pending’ durumunda kalması, Kubernetes Scheduler’ının onu çalıştıracak uygun bir Node (işçi düğümü) bulamadığı anlamına gelir. Bu durum, uygulamanızın dağıtılamamasına, hizmet dışı kalmasına veya performansta düşüş yaşanmasına yol açabilir. Dolayısıyla, bu durumun temel nedenlerini anlamak ve etkili sorun giderme yöntemleri bilmek, sağlıklı ve istikrarlı bir Kubernetes kümesi sürdürmek için kritik öneme sahiptir. Bu makale boyunca, ‘Pending’ durumunun arkasındaki mekanizmaları, yaygın nedenlerini, pratik sorun giderme adımlarını ve ileri düzey stratejileri adım adım keşfedeceğiz. Amacımız, ister yeni başlayan ister deneyimli bir DevOps mühendisi olun, bu karmaşık durumu daha iyi anlamanızı ve hızla çözmenizi sağlamaktır.

Konuyu derinlemesine incelemeye başlamadan önce, Kubernetes’in temel yapı taşlarını ve Pod planlama sürecini anlamak, sorunların kök nedenine inmek için ilk adımdır. Bu sayede, karşılaştığınız ‘Pending’ durumlarının sadece bir semptom olduğunu ve asıl problemin daha derinlerde yatabileceğini daha net görebiliriz. Haydi, Kubernetes dünyasının temel kavramlarına bir göz atalım.

Kubernetes’in Temelleri ve Pod Planlaması Nasıl İşler?

Kubernetes ekosisteminde Pod’ların düzgün bir şekilde planlanması, uygulamalarınızın kesintisiz çalışmasının anahtarıdır. Bu bölüm, Kubernetes’in temel bileşenlerini ve bir Pod’un yaşam döngüsündeki planlama aşamasının nasıl işlediğini açıklayarak, ‘Pending’ durumunun nedenlerini anlamak için sağlam bir temel oluşturacaktır.

Pod Nedir ve Neden Önemlidir?

Kubernetes’teki en küçük dağıtılabilir birim olan Pod, bir veya daha fazla container’ı (genellikle Docker container’larını) barındıran soyut bir yapıdır. Bir Pod içerisindeki tüm container’lar aynı ağ ve depolama kaynaklarını paylaşır. Örneğin, bir web sunucusu container’ı ile onun loglarını toplayan bir yan araba (sidecar) container’ı aynı Pod içinde yer alabilir. Pod’lar geçici (ephemeral) olup, belirli bir Node üzerinde çalıştırılır. Bir Pod’un ömrü, o Pod’u barındıran Node’un ömrüne veya Pod’un kendi hatasına bağlıdır. Eğer bir Pod ölürse, Kubernetes yeni bir Pod oluşturarak onu yenisiyle değiştirir.

Pod’lar, uygulamalarınızı ölçeklendirmenin ve yönetmenin temel yoludur. Bu nedenle, bir Pod’un ‘Pending’ durumunda takılı kalması, uygulamanızın ölçeklenememesi veya hiç dağıtılamaması anlamına gelir. Bu durum, kullanıcı deneyimini doğrudan etkiler ve iş sürekliliği açısından kritik sorunlara yol açabilir.

Scheduler’ın Rolü ve Pod Yaşam Döngüsü Evreleri

Kubernetes kümesinin kalbindeki bileşenlerden biri olan Scheduler, yeni oluşturulan veya güncellenen Pod’ları hangi Node üzerinde çalıştırılacağına karar veren önemli bir kontrol düzlemi bileşenidir. Bir kullanıcı yeni bir Pod oluşturduğunda (veya bir Deployment, StatefulSet gibi controller yeni bir Pod talep ettiğinde), Scheduler devreye girer. Görevi oldukça basittir: kümedeki mevcut Node’lar arasından Pod için en uygun olanı bulmak.

Scheduler bu kararı verirken bir dizi faktörü göz önünde bulundurur:

• Kaynak Gereksinimleri: Pod’un istediği CPU, bellek gibi kaynaklar Node’da yeterli mi?
• Node Affinities/Anti-Affinites: Pod’un belirli Node’larda çalışması veya belirli Node’lardan uzak durması için tanımlanmış kurallar var mı?
• Taints ve Tolerations: Node’lar üzerinde Pod’ların girmesini engelleyen “taint”ler var mı ve Pod bu taint’lere “toleration” gösteriyor mu?
• Depolama Gereksinimleri: Pod’un bağlı olduğu Persistent Volume’lar ilgili Node’a erişebilir durumda mı?
• Node Seçiciler (Node Selectors): Pod’un yalnızca belirli etiketlere sahip Node’larda çalışmasını sağlayan bir kural var mı?

Pod’un yaşam döngüsü çeşitli evrelerden (Phases) oluşur:

1. Pending: Pod kabul edildi, ancak henüz bir Node üzerinde çalıştırılacak container’ları oluşturulmadı. Bu evre, Scheduler’ın uygun bir Node bulamaması, kaynak yetersizliği veya imaj çekme sorunları gibi nedenlerle takılı kalabilir.
2. Running: Pod, bir Node üzerinde çalışır durumda. En az bir container’ı başlamış veya başlatılıyor.
3. Succeeded: Pod’daki tüm container’lar başarılı bir şekilde sonlandı ve yeniden başlatılmayacak.
4. Failed: Pod’daki tüm container’lar sonlandı ve en az biri başarısız oldu.
5. Unknown: Pod’un durumu bilinemiyor, genellikle Node ile iletişim sorunlarından kaynaklanır.

Dolayısıyla, ‘Pending’ durumu, bu yaşam döngüsünün ilk ve en kritik adımıdır. Scheduler, Pod için bir “ev” bulamadığında, Pod bu durumda kalır ve uygulamamız asla başlamaz. Bir sonraki bölümde, Pod’ların bu ‘Pending’ durumunda kalmasının en yaygın nedenlerini daha detaylı inceleyeceğiz ve bu sorunlara nasıl yaklaşacağımızı göreceğiz.

Pod Pending Durumunun En Yaygın Nedenleri Nelerdir?

‘Pending’ durumunda kalan bir Pod, genellikle belirli bir temel sorunun işaretidir. Bu sorunlar, basit yapılandırma hatalarından karmaşık altyapı sınırlamalarına kadar geniş bir yelpazeyi kapsayabilir. Bu bölümde, Pod’ların neden planlanamadığına dair en yaygın nedenleri ve her bir senaryo için nasıl teşhis ve çözüm adımları izleyebileceğinizi detaylandıracağız. Bu sorunları anlamak, sorun giderme sürecini önemli ölçüde hızlandıracaktır.

Kaynak Yetersizlikleri (CPU, Bellek, GPU)

Bir Pod’un ‘Pending’ durumunda kalmasının en sık karşılaşılan nedenlerinden biri, talep ettiği kaynakların (CPU, bellek veya özel donanımlar gibi) Kubernetes kümesindeki hiçbir Node tarafından karşılanamamasıdır. Her Pod, manifest dosyasında resources.requests ve resources.limits belirtebilir. requests, Scheduler’ın Pod’u planlarken göz önünde bulundurduğu minimum kaynak garantisidir. Eğer kümedeki hiçbir Node, Pod’un talep ettiği bu kaynakları boşta tutamıyorsa, Pod ‘Pending’ durumunda kalır.

Örneğin, 2 CPU ve 4GB bellek talep eden bir Pod düşünün:

apiVersion: v1
kind: Pod
metadata:
  name: benim-kaynak-podum
spec:
  containers:
  - name: web-app
    image: nginx
    resources:
      requests:
        memory: "4Gi"
        cpu: "2"
      limits:
        memory: "6Gi"
        cpu: "3"
    

Eğer kümenizdeki tüm Node'lar zaten doluya yakınsa ve bu kaynakları sağlayabilecek boş kapasite yoksa, Scheduler bu Pod'u hiçbir yere yerleştiremez. Bu durumda Pod, uygun bir Node bulunana kadar beklemeye devam edecektir. Bu sorunu teşhis etmek için kubectl describe pod komutunu kullanarak event'ları kontrol etmelisiniz. Genellikle "FailedScheduling" mesajıyla birlikte "Insufficient cpu" veya "Insufficient memory" gibi uyarılar görürsünüz.

Çözüm olarak, Pod'un talep ettiği kaynakları gözden geçirebilir, daha az kaynak talep etmesini sağlayabilir veya kümenize yeni Node'lar ekleyerek genel kapasiteyi artırabilirsiniz. Ayrıca, kubectl top nodes komutu ile Node'larınızın mevcut kaynak kullanımını izleyerek dar boğazları tespit edebilirsiniz.

Node Kapasite Sorunları ve Sistem Kaynakları

Kaynak yetersizliklerine ek olarak, Node'ların genel kapasitesi de Pod planlamasını etkileyebilir. Bir Node üzerinde yeterli CPU veya bellek görünse bile, sistemin kendisi için ayırdığı kaynaklar veya disk alanı gibi diğer kritik faktörler Pod'un yerleşmesini engelleyebilir. Örneğin, bir Node'un disk alanı dolmak üzereyse, Kubernetes bu Node'a yeni Pod'lar planlamayabilir. Özellikle imajları indirmek için yeterli disk alanı olmadığında bu durum sıkça yaşanır.

Yine, kubectl describe pod komutu, Scheduler'ın neden başarısız olduğuna dair önemli ipuçları sunar. Eğer disk alanı sorunu varsa, "DiskPressure" veya "ImageGCFailed" gibi uyarılar görebilirsiniz. Node'ların disk durumunu kontrol etmek için kubectl describe node komutunu kullanabilirsiniz.

Çözüm olarak, Node'ların disk alanını temizlemek, eski imajları silmek veya daha büyük diskli Node'lar eklemek gerekebilir. Ayrıca, Node'ların sağlık durumunu ve kaynak kullanımını düzenli olarak izlemek, bu tür sorunları önceden tespit etmenize yardımcı olacaktır.

Depolama ve Persistent Volume Sorunları

Uygulamalar genellikle kalıcı depolama gerektirir. Kubernetes'te bu, Persistent Volume (PV) ve Persistent Volume Claim (PVC) kavramlarıyla yönetilir. Eğer bir Pod, bir PVC'ye bağlıysa ve bu PVC'nin ilişkili PV'si bulunamıyor, oluşturulamıyor veya talep edilen erişim moduna (örneğin, ReadWriteMany) sahip uygun bir PV yoksa, Pod 'Pending' durumunda kalabilir. Özellikle depolama sınıflarının (StorageClass) yanlış yapılandırılması veya altyapı sağlayıcısında depolama provizyonu sorunları bu duruma yol açar.

Yine kubectl describe pod ve kubectl describe pvc komutları ile durum kontrol edilebilir. "Failed to provision volume" veya "No PersistentVolumes available for this claim" gibi mesajlar depolama sorunlarına işaret eder.

Çözüm, StorageClass yapılandırmasını kontrol etmek, altyapı sağlayıcınızda yeterli depolama kaynağı olduğundan emin olmak veya mevcut PV'lerin erişim modlarının Pod'un gereksinimlerini karşıladığından emin olmaktır. Yeni bir StorageClass tanımlamak veya mevcutları düzenlemek gerekebilir.

Ağ Yapılandırma Hataları (CNI)

Kubernetes kümeleri, Pod'ların birbirleriyle ve dış dünyayla iletişim kurmasını sağlayan bir Container Network Interface (CNI) eklentisine dayanır (örneğin, Calico, Flannel, Cilium). Eğer CNI eklentisi düzgün çalışmıyor, yanlış yapılandırılmış veya Node'larda gerekli ağ bileşenleri başlatılamıyorsa, Pod'lar 'Pending' durumunda kalabilir. Bazen Pod'lar "Network not configured" gibi hatalarla karşılaşır ve bu nedenle bir IP adresi alamaz.

Bu sorun genellikle Pod'un IP adresi alamadığı veya ağ ile ilgili bir hata mesajıyla kendini gösterir. kubectl logs -n kube-system komutuyla CNI Pod'larının loglarını incelemek ve Node'lardaki ağ arayüzlerini kontrol etmek faydalı olabilir.

Çözüm, CNI eklentisinin kurulumunu ve yapılandırmasını doğrulamak, gerekli güvenlik grubu/firewall kurallarının açık olduğundan emin olmak ve Node'ların ağ ayarlarını kontrol etmektir. Bazen CNI Pod'larının yeniden başlatılması veya CNI eklentisinin yeniden kurulması gerekebilir.

İmaj Çekme Problemleri

Bir Pod'un container'larını başlatabilmesi için öncelikle gerekli Docker (veya OCI uyumlu) imajlarının Node'a çekilmesi gerekir. Eğer bu imaj çekme işlemi herhangi bir nedenle başarısız olursa, Pod 'Pending' durumunda kalacaktır (daha sonra genellikle 'ImagePullBackOff' durumuna geçer ama başlangıçta 'Pending' olabilir). Bu tür sorunların yaygın nedenleri şunlardır:

• Yanlış İmaj Adı/Etiketi: İmaj adı veya etiketi yanlış yazılmış.
• Erişim Problemleri: Özel (private) bir imaj deposuna (örneğin Docker Hub private repo, AWS ECR, GCP GCR) erişim yetkisi yok veya Kubernetes Secret yanlış yapılandırılmış.
• Ağ Problemleri: Node'un imaj deposuna erişiminde ağ kesintisi veya firewall engeli var.
• İmaj Deposu Sorunları: İmaj deposu kapalı veya aşırı yüklenmiş.

kubectl describe pod komutunun çıktısında "Failed to pull image" veya "ImagePullBackOff" gibi hata mesajları görmelisiniz. Ayrıca, Node'un containerd veya docker servis loglarını incelemek de faydalı olabilir.

Çözüm olarak, imaj adını ve etiketini doğrulamak, gerekli imagePullSecrets'ın doğru yapılandırıldığından emin olmak, Node'ların imaj deposuna ağ erişimi olup olmadığını kontrol etmek ve imaj deposunun durumunu kontrol etmek gerekir.

Node Seçim Kısıtlamaları ve Tolerasyonların Rolü Nedir?

Kubernetes Scheduler'ı, Pod'ları uygun Node'lara yerleştirirken sadece kaynakları değil, aynı zamanda tanımlanmış kısıtlamaları da göz önünde bulundurur. Bu kısıtlamalar, Pod'ların belirli özelliklere sahip Node'lara yerleşmesini sağlamak veya belirli Node'lardan uzak durmasını sağlamak için kullanılır. Yanlış yapılandırılmış veya anlaşılmamış Node seçim kısıtlamaları, Pod'ların 'Pending' durumunda kalmasına sıkça neden olur.

Node Selector ve Affinity/Anti-affinity Kullanımı

Pod'ları belirli Node'lara atamanın birkaç yolu vardır:

• Node Selector: Bu, en basit yöntemdir. Pod manifestinde belirli bir Node etiketi belirtirsiniz ve Pod yalnızca o etikete sahip Node'larda planlanır. Eğer kümede bu etikete sahip bir Node yoksa veya var olanlar yeterli kaynağa sahip değilse, Pod 'Pending' kalacaktır.

  
  apiVersion: v1
  kind: Pod
  metadata:
    name: benim-ozel-podum
  spec:
    nodeSelector:
      disktype: ssd
    containers:
    - name: web-app
      image: nginx
              

  Yukarıdaki Pod, sadece disktype: ssd etiketine sahip Node'larda çalışabilir. Eğer kümenizde böyle bir Node yoksa, Pod planlanmayacaktır.

• Node Affinity/Anti-affinity: Node Selector'dan daha esnek ve güçlü bir mekanizmadır. Pod'ların belirli Node'lara "çekim" (affinity) veya "itme" (anti-affinity) göstermesini sağlar. İki tür affinity vardır:
  • requiredDuringSchedulingIgnoredDuringExecution: Pod'un planlanması için bu kural kesinlikle karşılanmalıdır. Karşılanmazsa Pod 'Pending' kalır.
  • preferredDuringSchedulingIgnoredDuringExecution: Bu kural tercihtir; mümkünse uyulur, ancak uyulmaması Pod'un planlanmasını engellemez.

  Örneğin, belirli bir bölgede (region) çalışmayı tercih eden bir Pod:

  
  apiVersion: v1
  kind: Pod
  metadata:
    name: benim-bolge-podum
  spec:
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: topology.kubernetes.io/region
              operator: In
              values:
              - us-east-1
    containers:
    - name: web-app
      image: nginx
              

  Eğer kümede us-east-1 bölgesinde bir Node yoksa veya bu Node uygun kaynaklara sahip değilse, Pod 'Pending' kalacaktır. Anti-affinity ise Pod'ların belirli Node'lardan uzak durmasını sağlar, örneğin belirli bir Node'daki diğer Pod'larla birlikte çalışmasını engellemek için kullanılabilir.

Taints ve Tolerations ile Node Dışı Bırakma

Taints ve Tolerations, Kubernetes'in gelişmiş planlama özelliklerinden biridir ve Pod'ların belirli Node'lara yerleşmesini "engellemek" için kullanılır. Bir Node'a "taint" ekleyerek, o Node'un belirli Pod'ları kabul etmeyeceğini belirtirsiniz. Ancak, Pod'lar bu "taint"lere "toleration" gösterirse, o Node üzerinde planlanabilirler.

Bir Node'a taint eklemek için:

kubectl taint nodes node1 key=value:NoSchedule
    

Bu komut, node1 üzerine key=value:NoSchedule taint'ini ekler. NoSchedule etkisi, bu taint'e tolerasyon göstermeyen Pod'ların bu Node'a planlanmamasını sağlar.

Bir Pod'un bu taint'e tolerasyon göstermesi için:

apiVersion: v1
kind: Pod
metadata:
  name: benim-toleransli-podum
spec:
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"
  containers:
  - name: web-app
    image: nginx
    

Eğer bir Pod'un gerekli tolerasyonu yoksa ve Node'da bu Pod'u engelleyen bir taint varsa, Pod 'Pending' durumunda kalacaktır. Genellikle bu durum, özel iş yükleri (GPU Pod'ları, kontrol düzlemi Pod'ları) için Node'ları izole etmek amacıyla kullanılır.

Pod Priority ve Preemption

Kubernetes 1.14'ten itibaren sunulan Pod Priority ve Preemption (öncelik ve ön alım), yüksek öncelikli Pod'ların düşük öncelikli Pod'ları Node'lardan çıkararak kendi yerini açmasını sağlar. Eğer kümede kaynak yetersizliği varsa ve yüksek öncelikli bir Pod planlanamıyorsa, Scheduler, düşük öncelikli Pod'ları sonlandırarak kendisine yer açmaya çalışabilir. Ancak, bu mekanizma doğru yapılandırılmadığında veya kaynaklar tamamen tükenmişse, yüksek öncelikli Pod bile 'Pending' kalabilir.

Pod'lara öncelik atamak için PriorityClass kaynakları tanımlanır ve Pod'lar bu sınıfı referans alır:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "Bu PriorityClass yüksek öncelikli Pod'lar içindir."
    

apiVersion: v1
kind: Pod
metadata:
name: benim-yuksek-oncelikli-podum
spec:
priorityClassName: high-priority
containers:
- name: web-app
image: nginx

Eğer öncelik ve ön alım mekanizmaları beklediğiniz gibi çalışmıyorsa ve Pod'lar hala 'Pending' kalıyorsa, kümenizin genel kaynak durumunu ve PriorityClass tanımlarınızı gözden geçirmelisiniz. kubectl describe pod komutundaki event'lar, ön alım denemelerinin başarısız olup olmadığına dair bilgiler içerebilir.

Gerçek Dünya Senaryoları: Pod Planlama Sorunlarına Yaklaşımlar

Teorik bilgileri pekiştirmek için, gerçek dünyada sıkça karşılaşılan iki vaka analizini inceleyelim. Bu senaryolar, yukarıda bahsedilen nedenlerin nasıl ortaya çıktığını ve bu durumlarda adım adım nasıl sorun giderme yapılması gerektiğini gösterecektir.

Vaka Analizi 1: Kritik Uygulama Pod'u Kaynak Tükenmesi Nedeniyle Pending Kalıyor

Bir e-ticaret platformu işlettiğinizi varsayın. Kara Cuma indirimi nedeniyle beklenmedik bir trafik artışı yaşanıyor ve sisteminiz otomatik olarak yeni Pod'lar ölçeklendirmeye çalışıyor. Ancak, ana sipariş işleme servisiniz için oluşturulan yeni Pod'lar sürekli 'Pending' durumunda kalıyor.

Teşhis Adımları:

1. Pod Durumunu Kontrol Edin:

   
   kubectl get pods -n e-commerce | grep order-processor
   # Çıktı:
   # order-processor-abcde-fghij   0/1     Pending   0          2m
               

   Pod'un 'Pending' olduğunu görüyoruz.

2. Pod'u Daha Detaylı İnceleyin:

   
   kubectl describe pod order-processor-abcde-fghij -n e-commerce
               

   Event'lar bölümünde şuna benzer bir mesaj görünüyor:

   
   ...
   Events:
     Type     Reason            Age   From               Message
     ----     ------            ----  ----               -------
     Warning  FailedScheduling  30s   default-scheduler  0/5 nodes are available: 5 Insufficient cpu.
               

   Burada açıkça "Insufficient cpu" (yetersiz CPU) hatasını görüyoruz. Yani kümedeki 5 Node'un hiçbirinde Pod'un talep ettiği kadar CPU kaynağı boşta değil.

3. Node Kaynak Durumunu Kontrol Edin:

   
   kubectl top nodes
   # Çıktı:
   # NAME         CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
   # node-1       1800m        90%    7Gi             85%
   # node-2       1900m        95%    7.2Gi           90%
   # ... (diğer Node'lar da benzer şekilde yüksek kullanımda)
               

   Görünüşe göre tüm Node'lar CPU kaynakları açısından neredeyse tamamen dolu. Sipariş işleme Pod'u muhtemelen 2 CPU çekirdeği talep ediyordu ve bu talebi karşılayacak hiçbir Node kalmadı.

Çözüm Adımları:

1. Küme Ölçeklendirme (Tercih Edilen): En iyi çözüm, kümenize daha fazla Node eklemektir. Bulut sağlayıcınızın otomatik ölçeklendirme (Cluster Autoscaler) özelliğini yapılandırın veya manuel olarak yeni işçi düğümleri sağlayın.
2. Pod Kaynak Taleplerini Azaltma (Geçici Çözüm): Eğer hemen yeni Node ekleyemiyorsanız, sipariş işleme Pod'unun CPU requests değerini geçici olarak düşürebilirsiniz. Ancak bu, Pod'un performansını olumsuz etkileyebilir ve sadece acil durumlarda düşünülmelidir.

   
   # ...
   resources:
     requests:
       cpu: "1"  # 2'den 1'e düşürüldü
   # ...
               

3. Düşük Öncelikli Pod'ları Temizleme: Eğer kümede daha az kritik iş yükleri varsa ve Pod'larınızda PriorityClass tanımladıysanız, düşük öncelikli Pod'ların manuel olarak silinmesi, yüksek öncelikli Pod'lara yer açabilir.

Vaka Analizi 2: Özel GPU Pod'u Yanlış Taint/Toleration Yapılandırması Nedeniyle Pending Kalıyor

Makine öğrenimi eğitim işleri için özel GPU Node'ları olan bir Kubernetes kümeniz var. Yeni bir GPU eğitim Pod'unu dağıttınız, ancak Pod 'Pending' durumunda kalıyor ve GPU Node'larına planlanmıyor.

Teşhis Adımları:

1. Pod Durumunu Kontrol Edin:

   
   kubectl get pods | grep gpu-trainer
   # Çıktı:
   # gpu-trainer-xyz12-uvw34   0/1     Pending   0          5m
               

2. Pod'u İnceleyin:

   
   kubectl describe pod gpu-trainer-xyz12-uvw34
               

   Event'lar bölümünde şuna benzer bir mesaj görülebilir:

   
   ...
   Events:
     Type     Reason            Age   From               Message
     ----     ------            ----  ----               -------
     Warning  FailedScheduling  1m    default-scheduler  0/3 nodes are available: 1 node(s) had untolerated taint {gpu: "true"}, 2 node(s) didn't match node selector.
               

   Bu mesaj bize iki ipucu veriyor: bir Node'da "gpu: true" taint'i var ve Pod bu taint'e tolerasyon göstermiyor. Diğer iki Node ise Pod'un nodeSelector kuralını karşılamıyor.

3. GPU Node Taint'lerini Kontrol Edin:

   
   kubectl describe node gpu-node-01 | grep Taints
   # Çıktı:
   # Taints:             gpu=true:NoSchedule
               

   GPU Node'unda gpu=true:NoSchedule taint'inin olduğunu doğruladık.

4. Pod Manifestini Kontrol Edin: GPU Pod manifestine baktığınızda, tolerations bölümünün eksik olduğunu fark ettiniz. Ayrıca, nodeSelector kuralı da yanlış yazılmış olabilir veya hiç belirtilmemiş olabilir.

Çözüm Adımları:

1. Pod Manifestine Tolerasyon Ekleme: Pod'un GPU Node'una planlanabilmesi için gerekli tolerasyonu eklemelisiniz:

   
   apiVersion: v1
   kind: Pod
   metadata:
     name: benim-gpu-trainer
   spec:
     tolerations:
     - key: "gpu"
       operator: "Equal"
       value: "true"
       effect: "NoSchedule"
     # Eğer nodeSelector da eksikse veya yanlışsa, onu da düzeltin
     nodeSelector:
       accelerator: nvidia-gpu
     containers:
     - name: cuda-app
       image: nvidia/cuda:11.4.0-base-ubuntu20.04
       resources:
         limits:
           nvidia.com/gpu: 1
               

2. Node Etiketlerini Kontrol Etme: Eğer Node'lar nodeSelector tarafından beklenen etikete sahip değilse, Node'lara doğru etiketi eklediğinizden emin olun:

   
   kubectl label node gpu-node-01 accelerator=nvidia-gpu
               

Bu vaka analizleri, 'Pending' durumundaki Pod'ları teşhis etmenin ve çözmenin, kubectl describe ve kubectl top gibi araçlarla başlayarak, adım adım mantıksal bir çıkarım süreci olduğunu göstermektedir. Önemli olan, hata mesajlarını doğru okumak ve küme yapınızı iyi anlamaktır.

Pod Planlama Sorunları Nasıl Teşhis Edilir ve Çözülür?

Bir Pod'un 'Pending' durumunda kalmasıyla karşılaştığınızda, sistemli bir yaklaşım izlemek sorun giderme sürecini hızlandırır. Bu bölümde, Kubernetes Pod planlama sorunlarını teşhis etmek ve çözmek için kullanabileceğiniz temel araçları ve adımları ele alacağız.

kubectl describe pod ve kubectl logs Kullanımı

Kubernetes'te sorun gidermenin olmazsa olmazı kubectl komut satırı aracıdır. Özellikle kubectl describe pod komutu, bir Pod hakkında detaylı bilgi almanızı sağlar ve 'Pending' durumunun temel nedenini genellikle burada bulabilirsiniz.

kubectl describe pod  -n 
    

Bu komutun çıktısında dikkat etmeniz gereken başlıca yerler şunlardır:

• Status: Pod'un mevcut durumu (Pending, Running vb.).
• Events (Olaylar): Bu bölüm, Pod'un yaşam döngüsü boyunca meydana gelen tüm olayları listeler. Scheduler'ın neden bir Node bulamadığını (FailedScheduling), kaynak yetersizliklerini (Insufficient cpu/memory), taint/toleration uyuşmazlıklarını veya imaj çekme hatalarını (Failed to pull image, ImagePullBackOff) burada görebilirsiniz.
• Resource Requests/Limits: Pod'un talep ettiği ve sınırladığı kaynak miktarlarını kontrol edin. Bu değerler çok yüksekse veya mevcut Node kapasitesiyle uyuşmuyorsa, sorun burada olabilir.
• Node Selector/Affinity/Tolerations: Pod'un Node seçim kısıtlamalarını kontrol edin. Yanlış yapılandırılmış bir kural Pod'un planlanmasını engelleyebilir.

Eğer Pod 'Pending' durumundan çıktıktan sonra sorun yaşıyorsa (örneğin 'CrashLoopBackOff'a düşüyorsa), Pod'un loglarını incelemek için kubectl logs komutunu kullanabilirsiniz:

kubectl logs  -n 
kubectl logs  -c  -n  # Belirli bir container için
    

Bu komut, Pod içerisindeki uygulamanın başlangıç sırasında karşılaştığı hataları ortaya çıkarabilir.

Event'ları Takip Etmek

Sadece belirli bir Pod'un event'larını değil, aynı zamanda genel küme event'larını da izlemek, sistem genelindeki sorunları anlamanıza yardımcı olabilir. kubectl get events komutu, son olayları listeler. Ancak bu çıktı genellikle çok kalabalık olabilir.

Daha hedefli bir yaklaşım için, event'ları filtreleyebilirsiniz:

kubectl get events --field-selector type=Warning -n 
kubectl get events --field-selector involvedObject.kind=Pod,involvedObject.name= -n 
    

Bu şekilde, özellikle 'Warning' seviyesindeki olaylara odaklanarak veya belirli bir Pod ile ilgili tüm olayları inceleyerek sorun giderme süresini kısaltabilirsiniz.

Node Durumlarını İncelemek

Pod'ların bir Node'a planlanamaması genellikle o Node'un kendisiyle veya kaynaklarıyla ilgili bir sorundan kaynaklanır. Node'ların durumunu kontrol etmek, bu tür sorunları belirlemek için kritik bir adımdır.

kubectl get nodes
# Çıktı:
# NAME       STATUS   ROLES    AGE   VERSION
# node-1     Ready       1d    v1.23.5
# node-2     Ready       1d    v1.23.5
# node-3     NotReady    1d    v1.23.5  # Bir Node NotReady durumunda!
    

Eğer bir Node 'NotReady' durumundaysa, o Node'a Pod planlanmaz. Node'un neden 'NotReady' olduğunu anlamak için kubectl describe node komutunu kullanın. Node üzerinde kaynak yetersizliği (DiskPressure, MemoryPressure, PIDPressure) veya ağ sorunları gibi durumlar Conditions bölümünde listelenir.

Ayrıca, Node'ların mevcut kaynak kullanımını görmek için:

kubectl top nodes
    

Bu komut, Node'ların CPU ve bellek kullanımını gösterir ve hangi Node'ların kaynak açısından sıkışık olduğunu hızlıca anlamanızı sağlar.

Monitoring Araçları

Gelişmiş Kubernetes ortamlarında Prometheus, Grafana, Datadog veya ELK Stack gibi monitoring ve loglama araçları, Pod planlama sorunlarını proaktif olarak tespit etmek ve derinlemesine analiz etmek için paha biçilmezdir. Bu araçlar sayesinde:

• Node'ların geçmiş kaynak kullanım trendlerini görebilir, kaynak tükenmeden önce önlem alabilirsiniz.
• Scheduler'ın event'larını daha okunabilir grafikler ve alarmlar şeklinde izleyebilirsiniz.
• Pod'ların ve Node'ların sağlık durumunu merkezi bir yerden takip edebilir, anormallikleri hızla tespit edebilirsiniz.
• Uygulama loglarını toplayıp analiz ederek Pod'un içindeki sorunları daha kolay belirleyebilirsiniz.

Bu araçlar, manuel kubectl komutlarına kıyasla daha geniş kapsamlı ve otomatize edilmiş bir görünüm sunar, böylece sorunlara daha hızlı müdahale edebilirsiniz.

İleri Düzey İpuçları ve En İyi Uygulamalar

Pod planlama sorunlarını gidermenin yanı sıra, bu sorunları baştan önlemek ve kümenizi daha dirençli hale getirmek için bazı ileri düzey teknikler ve en iyi uygulamalar mevcuttur. Bu ipuçları, özellikle büyük ve karmaşık Kubernetes ortamlarında önemli faydalar sağlayacaktır.

Cluster Autoscaler ve Vertical Pod Autoscaler

• Cluster Autoscaler (CA): Kaynak yetersizliği nedeniyle 'Pending' kalan Pod'lar için en etkili çözümlerden biri Cluster Autoscaler'dır. CA, Kubernetes kümesindeki 'Pending' Pod'ları algılar ve bu Pod'ları barındırmak için yeterli Node yoksa, altyapı sağlayıcınızdan (AWS, GCP, Azure vb.) otomatik olarak yeni Node'lar talep eder. Bu sayede, manuel müdahaleye gerek kalmadan kümenizin kapasitesi dinamik olarak artırılır.
• Vertical Pod Autoscaler (VPA): VPA, Pod'larınızın geçmiş kaynak kullanımını analiz ederek CPU ve bellek requests ve limits değerlerini otomatik olarak ayarlar. Bu, Pod'larınızın gereğinden fazla kaynak talep etmesini engelleyerek Node'lardaki israfı azaltır ve Scheduler'ın daha verimli planlama yapmasına yardımcı olur. Ayrıca, Pod'ların kaynak yetersizliği nedeniyle 'Pending' kalma olasılığını da düşürür, çünkü her Pod'un ihtiyaç duyduğu gerçekçi kaynakları talep etmesini sağlar.

Özel Scheduler'lar ve Gelişmiş Planlama Stratejileri

Çoğu durumda, Kubernetes'in varsayılan Scheduler'ı yeterlidir. Ancak, belirli iş yükleri veya karmaşık kurallar için özel bir Scheduler geliştirmeniz gerekebilir. Örneğin, çok katı SLA'lara sahip Pod'lar, belirli donanım topolojileri veya çok özel optimizasyon gereksinimleri olan durumlar için özel bir Scheduler yazılabilir. Bu, Pod planlama mantığını tamamen sizin kontrolünüze verir. Ayrıca, Scheduler Extenders kullanarak varsayılan Scheduler'ın davranışını genişletebilirsiniz.

Kaynak Limitlerinin Akıllıca Ayarlanması

Pod'larınız için doğru resources.requests ve resources.limits değerlerini belirlemek, 'Pending' durumunu önlemede kritik öneme sahiptir:

• Requests: Pod'un çalışması için minimum garanti edilen kaynaklardır. Çok düşük ayarlarsanız, Pod performans sorunları yaşayabilir; çok yüksek ayarlarsanız, kümede yer bulmakta zorlanabilir.
• Limits: Pod'un kullanabileceği maksimum kaynaklardır. Bu limitler, bir Pod'un tüm Node kaynaklarını tüketmesini engelleyerek diğer Pod'ları korur.

Kaynak limitlerini belirlerken geçmiş kullanım verilerini (monitoring araçlarından) kullanmak ve test etmek önemlidir. Gelişigüzel değerler atamak yerine, uygulamalarınızın gerçek ihtiyaçlarına göre bu değerleri ayarlayın.

Mobil Uyumlu Tasarım Yaklaşımları

Makale formatının mobil cihazlarda da rahatlıkla okunabilir olması, içeriğin geniş kitlelere ulaşması açısından önemlidir. HTML yapınızın mobil uyumlu olması için aşağıdaki yaklaşımları benimseyebilirsiniz:

• Duyarlı Tasarım (Responsive Design): CSS medya sorguları (media queries) kullanarak ekran boyutuna göre sayfa düzenini, font boyutlarını ve resim boyutlarını ayarlayabilirsiniz. Örneğin, mobil cihazlarda tek sütunlu bir düzen tercih edilebilirken, masaüstünde çoklu sütunlu bir düzen kullanılabilir.
• Esnek Izgaralar ve Medya: Görsel içerikleri ve düzeni yüzde birimleri veya flexbox/ grid gibi CSS özellikleriyle oluşturarak farklı ekran boyutlarına otomatik olarak adapte olmasını sağlayın.
• Anlaşılır Font Boyutları: Küçük ekranlarda okunabilirliği artırmak için uygun font boyutları ve satır aralıkları kullanın.
• Görsel Hiyerarşi: Başlıkların, paragrafların ve liste öğelerinin hiyerarşisini net tutarak mobil kullanıcının içeriği kolayca tarayabilmesini sağlayın.

Bu makale, body içeriği sunduğundan, gerçek CSS medya sorguları ekleyemeyiz. Ancak bir CSS dosyasında bu HTML yapısını mobil uyumlu hale getirmek için şöyle bir kod parçacığı kullanılabilir:

/* style.css dosyasına eklenebilecek bir örnek */
@media screen and (max-width: 768px) {
    body {
        padding: 10px;
    }
    h2, h3 {
        font-size: 1.2em;
        line-height: 1.4;
    }
    p {
        font-size: 0.9em;
        line-height: 1.6;
    }
    /* Diğer elementler için responsive ayarlar */
}
    

Yukarıdaki örnekte gösterildiği gibi, mobil cihazlarda metin boyutları ve dolgu (padding) gibi özellikler ayarlanarak okunabilirlik artırılabilir. Bu HTML yapısı, doğru CSS ile mükemmel bir mobil deneyim sunabilir.

Sonuç: Daha Sağlıklı Bir Kubernetes Ortamı İçin Adımlar

Kubernetes'te Pod'ların 'Pending' durumunda kalması, kümenizin temel sağlık sorunlarının bir göstergesidir. Bu kapsamlı rehberde, Pod'ların neden planlanmadığını anlamak için temel kavramlardan, yaygın nedenlere, gerçek dünya senaryolarına ve etkili sorun giderme yöntemlerine kadar birçok konuyu ele aldık. Unutmayın ki, sorun gidermede en önemli adımlar doğru teşhis koymak ve sistemli bir yaklaşım benimsemektir.

Özetle, 'Pending' durumundaki Pod'ları hızla çözmek ve gelecekteki sorunları önlemek için şu stratejileri uygulayın: Pod ve Node kaynak taleplerini optimize edin, Node seçim kısıtlamalarını (taints, tolerations, affinity) dikkatlice yapılandırın, depolama ve ağ sorunlarını hızlıca tespit edin, imaj çekme problemlerini giderin ve en önemlisi, kümenizi sürekli izleyin. Cluster Autoscaler ve Vertical Pod Autoscaler gibi otomatikleştirme araçlarından faydalanmak, kümenizin dirençliliğini ve verimliliğini artıracaktır. Bu adımları izleyerek, Kubernetes ortamınızda daha sağlıklı, daha kararlı ve daha verimli bir çalışma sağlayabilir, uygulamalarınızın kesintisiz hizmet vermesini garanti edebilirsiniz.

Sıkça Sorulan Sorular (SSS)

Pod'um neden 'Pending' durumunda takılı kaldı?

Çoğunlukla kaynak yetersizlikleri (CPU, bellek), Node üzerinde doğru etiket veya tolerasyon eksikliği, depolama veya ağ sorunları ya da imaj çekme problemleri nedeniyle takılı kalır. kubectl describe pod komutuyla daha fazla detay bulabilirsiniz.

Kaynak yetersizliği hatasını nasıl düzeltirim?

Pod'un kaynak taleplerini (CPU, bellek) azaltabilir, kümenize yeni Node'lar ekleyebilir veya Cluster Autoscaler gibi otomatik ölçeklendirme araçlarını yapılandırabilirsiniz. Ayrıca, Vertical Pod Autoscaler kullanarak Pod'ların kaynak taleplerini optimize etmeyi düşünebilirsiniz.

Node üzerindeki taint'ler Pod planlamasını nasıl etkiler?

Bir Node üzerindeki taint'ler, o taint'e tolerasyon göstermeyen Pod'ların o Node üzerinde planlanmasını engeller. Eğer Pod'unuz belirli bir taint'e tolerasyon göstermiyorsa ve uygun başka bir Node yoksa, Pod 'Pending' durumunda kalır. Çözüm, Pod manifestine uygun tolerasyonu eklemektir.

ImagePullBackOff ile 'Pending' arasındaki fark nedir?

Başlangıçta bir Pod, imaj çekme işlemi başlamadan önce 'Pending' durumunda kalabilir. Eğer imaj çekme işlemi başlar ancak başarısız olursa, Pod'un durumu genellikle 'ImagePullBackOff' veya 'ErrImagePull' olarak değişir. 'Pending' daha genel bir bekleme durumunu ifade ederken, 'ImagePullBackOff' spesifik olarak imaj çekme hatasına işaret eder.

Pod'larım için doğru kaynak isteklerini ve limitlerini nasıl belirlerim?

Uygulamanızın performans testleri sırasında kaynak kullanımını izleyerek (örneğin Prometheus ve Grafana ile) gerçekçi değerler belirleyebilirsiniz. Başlangıçta biraz esneklik tanıyıp, zamanla ince ayar yapmak genellikle en iyi yaklaşımdır. Ayrıca, Vertical Pod Autoscaler bu süreci otomatikleştirmenize yardımcı olabilir.