Kubernetes ortam\u0131nda Pod’lar\u0131n\u0131z ‘Pending’ durumunda m\u0131 tak\u0131l\u0131 kald\u0131? Bu kapsaml\u0131 rehber, Pod’lar\u0131n neden planlanmad\u0131\u011f\u0131n\u0131 anlaman\u0131za, yayg\u0131n sorunlar\u0131 gidermenize ve sistemlerinizi verimli \u00e7al\u0131\u015ft\u0131rman\u0131za yard\u0131mc\u0131 olacak.<\/p>\n
Modern bulut yerel uygulamalar\u0131n temelini olu\u015fturan Kubernetes, container’lar\u0131 d\u00fczenlemek ve y\u00f6netmek i\u00e7in vazge\u00e7ilmez bir platformdur. Ancak, bu karma\u015f\u0131k ekosistemde zaman zaman beklenmedik durumlarla kar\u015f\u0131la\u015fmak ka\u00e7\u0131n\u0131lmazd\u0131r. \u00d6zellikle Pod’lar\u0131n\u0131z\u0131n s\u00fcrekli ‘Pending’ (beklemede) durumunda kalmas\u0131, geli\u015ftiriciler ve operasyon ekipleri i\u00e7in s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan ve can s\u0131k\u0131c\u0131 bir sorundur. Peki, Pod’lar\u0131n\u0131z neden planlanm\u0131yor ve bu durum i\u015f ak\u0131\u015f\u0131n\u0131z\u0131 nas\u0131l etkiliyor? \u0130\u015fte bu sorular\u0131n yan\u0131tlar\u0131n\u0131 derinlemesine inceleyece\u011fiz.<\/p>\n
Bir Pod’un ‘Pending’ durumunda kalmas\u0131, Kubernetes Scheduler’\u0131n\u0131n onu \u00e7al\u0131\u015ft\u0131racak uygun bir Node (i\u015f\u00e7i d\u00fc\u011f\u00fcm\u00fc) bulamad\u0131\u011f\u0131 anlam\u0131na gelir. Bu durum, uygulaman\u0131z\u0131n da\u011f\u0131t\u0131lamamas\u0131na, hizmet d\u0131\u015f\u0131 kalmas\u0131na veya performansta d\u00fc\u015f\u00fc\u015f ya\u015fanmas\u0131na yol a\u00e7abilir. Dolay\u0131s\u0131yla, bu durumun temel nedenlerini anlamak ve etkili sorun giderme y\u00f6ntemleri bilmek, sa\u011fl\u0131kl\u0131 ve istikrarl\u0131 bir Kubernetes k\u00fcmesi s\u00fcrd\u00fcrmek i\u00e7in kritik \u00f6neme sahiptir. Bu makale boyunca, ‘Pending’ durumunun arkas\u0131ndaki mekanizmalar\u0131, yayg\u0131n nedenlerini, pratik sorun giderme ad\u0131mlar\u0131n\u0131 ve ileri d\u00fczey stratejileri ad\u0131m ad\u0131m ke\u015ffedece\u011fiz. Amac\u0131m\u0131z, ister yeni ba\u015flayan ister deneyimli bir DevOps m\u00fchendisi olun, bu karma\u015f\u0131k durumu daha iyi anlaman\u0131z\u0131 ve h\u0131zla \u00e7\u00f6zmenizi sa\u011flamakt\u0131r.<\/p>\n
Konuyu derinlemesine incelemeye ba\u015flamadan \u00f6nce, Kubernetes’in temel yap\u0131 ta\u015flar\u0131n\u0131 ve Pod planlama s\u00fcrecini anlamak, sorunlar\u0131n k\u00f6k nedenine inmek i\u00e7in ilk ad\u0131md\u0131r. Bu sayede, kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131z ‘Pending’ durumlar\u0131n\u0131n sadece bir semptom oldu\u011funu ve as\u0131l problemin daha derinlerde yatabilece\u011fini daha net g\u00f6rebiliriz. Haydi, Kubernetes d\u00fcnyas\u0131n\u0131n temel kavramlar\u0131na bir g\u00f6z atal\u0131m.<\/p>\n
Kubernetes ekosisteminde Pod’lar\u0131n d\u00fczg\u00fcn bir \u015fekilde planlanmas\u0131, uygulamalar\u0131n\u0131z\u0131n kesintisiz \u00e7al\u0131\u015fmas\u0131n\u0131n anahtar\u0131d\u0131r. Bu b\u00f6l\u00fcm, Kubernetes’in temel bile\u015fenlerini ve bir Pod’un ya\u015fam d\u00f6ng\u00fcs\u00fcndeki planlama a\u015famas\u0131n\u0131n nas\u0131l i\u015fledi\u011fini a\u00e7\u0131klayarak, ‘Pending’ durumunun nedenlerini anlamak i\u00e7in sa\u011flam bir temel olu\u015fturacakt\u0131r.<\/p>\n
Kubernetes’teki en k\u00fc\u00e7\u00fck da\u011f\u0131t\u0131labilir birim olan Pod, bir veya daha fazla container’\u0131 (genellikle Docker container’lar\u0131n\u0131) bar\u0131nd\u0131ran soyut bir yap\u0131d\u0131r. Bir Pod i\u00e7erisindeki t\u00fcm container’lar ayn\u0131 a\u011f ve depolama kaynaklar\u0131n\u0131 payla\u015f\u0131r. \u00d6rne\u011fin, bir web sunucusu container’\u0131 ile onun loglar\u0131n\u0131 toplayan bir yan araba (sidecar) container’\u0131 ayn\u0131 Pod i\u00e7inde yer alabilir. Pod’lar ge\u00e7ici (ephemeral) olup, belirli bir Node \u00fczerinde \u00e7al\u0131\u015ft\u0131r\u0131l\u0131r. Bir Pod’un \u00f6mr\u00fc, o Pod’u bar\u0131nd\u0131ran Node’un \u00f6mr\u00fcne veya Pod’un kendi hatas\u0131na ba\u011fl\u0131d\u0131r. E\u011fer bir Pod \u00f6l\u00fcrse, Kubernetes yeni bir Pod olu\u015fturarak onu yenisiyle de\u011fi\u015ftirir.<\/p>\n
Pod’lar, uygulamalar\u0131n\u0131z\u0131 \u00f6l\u00e7eklendirmenin ve y\u00f6netmenin temel yoludur. Bu nedenle, bir Pod’un ‘Pending’ durumunda tak\u0131l\u0131 kalmas\u0131, uygulaman\u0131z\u0131n \u00f6l\u00e7eklenememesi veya hi\u00e7 da\u011f\u0131t\u0131lamamas\u0131 anlam\u0131na gelir. Bu durum, kullan\u0131c\u0131 deneyimini do\u011frudan etkiler ve i\u015f s\u00fcreklili\u011fi a\u00e7\u0131s\u0131ndan kritik sorunlara yol a\u00e7abilir.<\/p>\n
Kubernetes k\u00fcmesinin kalbindeki bile\u015fenlerden biri olan Scheduler, yeni olu\u015fturulan veya g\u00fcncellenen Pod’lar\u0131 hangi Node \u00fczerinde \u00e7al\u0131\u015ft\u0131r\u0131laca\u011f\u0131na karar veren \u00f6nemli bir kontrol d\u00fczlemi bile\u015fenidir. Bir kullan\u0131c\u0131 yeni bir Pod olu\u015fturdu\u011funda (veya bir Deployment, StatefulSet gibi controller yeni bir Pod talep etti\u011finde), Scheduler devreye girer. G\u00f6revi olduk\u00e7a basittir: k\u00fcmedeki mevcut Node’lar aras\u0131ndan Pod i\u00e7in en uygun olan\u0131 bulmak.<\/p>\n
Scheduler bu karar\u0131 verirken bir dizi fakt\u00f6r\u00fc g\u00f6z \u00f6n\u00fcnde bulundurur:<\/p>\n
Pod’un ya\u015fam d\u00f6ng\u00fcs\u00fc \u00e7e\u015fitli evrelerden (Phases) olu\u015fur:<\/p>\n
Dolay\u0131s\u0131yla, ‘Pending’ durumu, bu ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fcn ilk ve en kritik ad\u0131m\u0131d\u0131r. Scheduler, Pod i\u00e7in bir “ev” bulamad\u0131\u011f\u0131nda, Pod bu durumda kal\u0131r ve uygulamam\u0131z asla ba\u015flamaz. Bir sonraki b\u00f6l\u00fcmde, Pod’lar\u0131n bu ‘Pending’ durumunda kalmas\u0131n\u0131n en yayg\u0131n nedenlerini daha detayl\u0131 inceleyece\u011fiz ve bu sorunlara nas\u0131l yakla\u015faca\u011f\u0131m\u0131z\u0131 g\u00f6rece\u011fiz.<\/p>\n
kubectl describe pod [pod-ad\u0131]<\/code> komutu genellikle size neden planlama yap\u0131lamad\u0131\u011f\u0131na dair de\u011ferli ipu\u00e7lar\u0131 verecektir.\n <\/div>\nPod Pending Durumunun En Yayg\u0131n Nedenleri Nelerdir?<\/h2>\n
‘Pending’ durumunda kalan bir Pod, genellikle belirli bir temel sorunun i\u015faretidir. Bu sorunlar, basit yap\u0131land\u0131rma hatalar\u0131ndan karma\u015f\u0131k altyap\u0131 s\u0131n\u0131rlamalar\u0131na kadar geni\u015f bir yelpazeyi kapsayabilir. Bu b\u00f6l\u00fcmde, Pod’lar\u0131n neden planlanamad\u0131\u011f\u0131na dair en yayg\u0131n nedenleri ve her bir senaryo i\u00e7in nas\u0131l te\u015fhis ve \u00e7\u00f6z\u00fcm ad\u0131mlar\u0131 izleyebilece\u011finizi detayland\u0131raca\u011f\u0131z. Bu sorunlar\u0131 anlamak, sorun giderme s\u00fcrecini \u00f6nemli \u00f6l\u00e7\u00fcde h\u0131zland\u0131racakt\u0131r.<\/p>\n
Kaynak Yetersizlikleri (CPU, Bellek, GPU)<\/h3>\n
Bir Pod’un ‘Pending’ durumunda kalmas\u0131n\u0131n en s\u0131k kar\u015f\u0131la\u015f\u0131lan nedenlerinden biri, talep etti\u011fi kaynaklar\u0131n (CPU, bellek veya \u00f6zel donan\u0131mlar gibi) Kubernetes k\u00fcmesindeki hi\u00e7bir Node taraf\u0131ndan kar\u015f\u0131lanamamas\u0131d\u0131r. Her Pod, manifest dosyas\u0131nda resources.requests<\/code> ve resources.limits<\/code> belirtebilir. requests<\/code>, Scheduler’\u0131n Pod’u planlarken g\u00f6z \u00f6n\u00fcnde bulundurdu\u011fu minimum kaynak garantisidir. E\u011fer k\u00fcmedeki hi\u00e7bir Node, Pod’un talep etti\u011fi bu kaynaklar\u0131 bo\u015fta tutam\u0131yorsa, Pod ‘Pending’ durumunda kal\u0131r.<\/p>\n\u00d6rne\u011fin, 2 CPU ve 4GB bellek talep eden bir Pod d\u00fc\u015f\u00fcn\u00fcn:<\/p>\n
\napiVersion: v1\nkind: Pod\nmetadata:\n name: benim-kaynak-podum\nspec:\n containers:\n - name: web-app\n image: nginx\n resources:\n requests:\n memory: \"4Gi\"\n cpu: \"2\"\n limits:\n memory: \"6Gi\"\n cpu: \"3\"\n <\/pre>\n<\/code><\/p>\n
E\u011fer k\u00fcmenizdeki t\u00fcm Node'lar zaten doluya yak\u0131nsa ve bu kaynaklar\u0131 sa\u011flayabilecek bo\u015f kapasite yoksa, Scheduler bu Pod'u hi\u00e7bir yere yerle\u015ftiremez. Bu durumda Pod, uygun bir Node bulunana kadar beklemeye devam edecektir. Bu sorunu te\u015fhis etmek i\u00e7in kubectl describe pod <\/code> komutunu kullanarak event'lar\u0131 kontrol etmelisiniz. Genellikle \"FailedScheduling\" mesaj\u0131yla birlikte \"Insufficient cpu\" veya \"Insufficient memory\" gibi uyar\u0131lar g\u00f6r\u00fcrs\u00fcn\u00fcz.<\/p>\n\u00c7\u00f6z\u00fcm olarak, Pod'un talep etti\u011fi kaynaklar\u0131 g\u00f6zden ge\u00e7irebilir, daha az kaynak talep etmesini sa\u011flayabilir veya k\u00fcmenize yeni Node'lar ekleyerek genel kapasiteyi art\u0131rabilirsiniz. Ayr\u0131ca, kubectl top nodes<\/code> komutu ile Node'lar\u0131n\u0131z\u0131n mevcut kaynak kullan\u0131m\u0131n\u0131 izleyerek dar bo\u011fazlar\u0131 tespit edebilirsiniz.<\/p>\nNode Kapasite Sorunlar\u0131 ve Sistem Kaynaklar\u0131<\/h3>\n
Kaynak yetersizliklerine ek olarak, Node'lar\u0131n genel kapasitesi de Pod planlamas\u0131n\u0131 etkileyebilir. Bir Node \u00fczerinde yeterli CPU veya bellek g\u00f6r\u00fcnse bile, sistemin kendisi i\u00e7in ay\u0131rd\u0131\u011f\u0131 kaynaklar veya disk alan\u0131 gibi di\u011fer kritik fakt\u00f6rler Pod'un yerle\u015fmesini engelleyebilir. \u00d6rne\u011fin, bir Node'un disk alan\u0131 dolmak \u00fczereyse, Kubernetes bu Node'a yeni Pod'lar planlamayabilir. \u00d6zellikle imajlar\u0131 indirmek i\u00e7in yeterli disk alan\u0131 olmad\u0131\u011f\u0131nda bu durum s\u0131k\u00e7a ya\u015fan\u0131r.<\/p>\n
Yine, kubectl describe pod <\/code> komutu, Scheduler'\u0131n neden ba\u015far\u0131s\u0131z oldu\u011funa dair \u00f6nemli ipu\u00e7lar\u0131 sunar. E\u011fer disk alan\u0131 sorunu varsa, \"DiskPressure\" veya \"ImageGCFailed\" gibi uyar\u0131lar g\u00f6rebilirsiniz. Node'lar\u0131n disk durumunu kontrol etmek i\u00e7in kubectl describe node <\/code> komutunu kullanabilirsiniz.<\/p>\n\u00c7\u00f6z\u00fcm olarak, Node'lar\u0131n disk alan\u0131n\u0131 temizlemek, eski imajlar\u0131 silmek veya daha b\u00fcy\u00fck diskli Node'lar eklemek gerekebilir. Ayr\u0131ca, Node'lar\u0131n sa\u011fl\u0131k durumunu ve kaynak kullan\u0131m\u0131n\u0131 d\u00fczenli olarak izlemek, bu t\u00fcr sorunlar\u0131 \u00f6nceden tespit etmenize yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n
Depolama ve Persistent Volume Sorunlar\u0131<\/h3>\n
Uygulamalar genellikle kal\u0131c\u0131 depolama gerektirir. Kubernetes'te bu, Persistent Volume (PV) ve Persistent Volume Claim (PVC) kavramlar\u0131yla y\u00f6netilir. E\u011fer bir Pod, bir PVC'ye ba\u011fl\u0131ysa ve bu PVC'nin ili\u015fkili PV'si bulunam\u0131yor, olu\u015fturulam\u0131yor veya talep edilen eri\u015fim moduna (\u00f6rne\u011fin, ReadWriteMany) sahip uygun bir PV yoksa, Pod 'Pending' durumunda kalabilir. \u00d6zellikle depolama s\u0131n\u0131flar\u0131n\u0131n (StorageClass) yanl\u0131\u015f yap\u0131land\u0131r\u0131lmas\u0131 veya altyap\u0131 sa\u011flay\u0131c\u0131s\u0131nda depolama provizyonu sorunlar\u0131 bu duruma yol a\u00e7ar.<\/p>\n
Yine kubectl describe pod <\/code> ve kubectl describe pvc <\/code> komutlar\u0131 ile durum kontrol edilebilir. \"Failed to provision volume\" veya \"No PersistentVolumes available for this claim\" gibi mesajlar depolama sorunlar\u0131na i\u015faret eder.<\/p>\n\u00c7\u00f6z\u00fcm, StorageClass yap\u0131land\u0131rmas\u0131n\u0131 kontrol etmek, altyap\u0131 sa\u011flay\u0131c\u0131n\u0131zda yeterli depolama kayna\u011f\u0131 oldu\u011fundan emin olmak veya mevcut PV'lerin eri\u015fim modlar\u0131n\u0131n Pod'un gereksinimlerini kar\u015f\u0131lad\u0131\u011f\u0131ndan emin olmakt\u0131r. Yeni bir StorageClass tan\u0131mlamak veya mevcutlar\u0131 d\u00fczenlemek gerekebilir.<\/p>\n
A\u011f Yap\u0131land\u0131rma Hatalar\u0131 (CNI)<\/h3>\n
Kubernetes k\u00fcmeleri, Pod'lar\u0131n birbirleriyle ve d\u0131\u015f d\u00fcnyayla ileti\u015fim kurmas\u0131n\u0131 sa\u011flayan bir Container Network Interface (CNI) eklentisine dayan\u0131r (\u00f6rne\u011fin, Calico, Flannel, Cilium). E\u011fer CNI eklentisi d\u00fczg\u00fcn \u00e7al\u0131\u015fm\u0131yor, yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f veya Node'larda gerekli a\u011f bile\u015fenleri ba\u015flat\u0131lam\u0131yorsa, Pod'lar 'Pending' durumunda kalabilir. Bazen Pod'lar \"Network not configured\" gibi hatalarla kar\u015f\u0131la\u015f\u0131r ve bu nedenle bir IP adresi alamaz.<\/p>\n
Bu sorun genellikle Pod'un IP adresi alamad\u0131\u011f\u0131 veya a\u011f ile ilgili bir hata mesaj\u0131yla kendini g\u00f6sterir. kubectl logs -n kube-system<\/code> komutuyla CNI Pod'lar\u0131n\u0131n loglar\u0131n\u0131 incelemek ve Node'lardaki a\u011f aray\u00fczlerini kontrol etmek faydal\u0131 olabilir.<\/p>\n\u00c7\u00f6z\u00fcm, CNI eklentisinin kurulumunu ve yap\u0131land\u0131rmas\u0131n\u0131 do\u011frulamak, gerekli g\u00fcvenlik grubu\/firewall kurallar\u0131n\u0131n a\u00e7\u0131k oldu\u011fundan emin olmak ve Node'lar\u0131n a\u011f ayarlar\u0131n\u0131 kontrol etmektir. Bazen CNI Pod'lar\u0131n\u0131n yeniden ba\u015flat\u0131lmas\u0131 veya CNI eklentisinin yeniden kurulmas\u0131 gerekebilir.<\/p>\n
\u0130maj \u00c7ekme Problemleri<\/h3>\n
Bir Pod'un container'lar\u0131n\u0131 ba\u015flatabilmesi i\u00e7in \u00f6ncelikle gerekli Docker (veya OCI uyumlu) imajlar\u0131n\u0131n Node'a \u00e7ekilmesi gerekir. E\u011fer bu imaj \u00e7ekme i\u015flemi herhangi bir nedenle ba\u015far\u0131s\u0131z olursa, Pod 'Pending' durumunda kalacakt\u0131r (daha sonra genellikle 'ImagePullBackOff' durumuna ge\u00e7er ama ba\u015flang\u0131\u00e7ta 'Pending' olabilir). Bu t\u00fcr sorunlar\u0131n yayg\u0131n nedenleri \u015funlard\u0131r:<\/p>\n
\n- Yanl\u0131\u015f \u0130maj Ad\u0131\/Etiketi:<\/strong> \u0130maj ad\u0131 veya etiketi yanl\u0131\u015f yaz\u0131lm\u0131\u015f.<\/li>\n
- Eri\u015fim Problemleri:<\/strong> \u00d6zel (private) bir imaj deposuna (\u00f6rne\u011fin Docker Hub private repo, AWS ECR, GCP GCR) eri\u015fim yetkisi yok veya Kubernetes Secret yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f.<\/li>\n
- A\u011f Problemleri:<\/strong> Node'un imaj deposuna eri\u015fiminde a\u011f kesintisi veya firewall engeli var.<\/li>\n
- \u0130maj Deposu Sorunlar\u0131:<\/strong> \u0130maj deposu kapal\u0131 veya a\u015f\u0131r\u0131 y\u00fcklenmi\u015f.<\/li>\n<\/ul>\n
kubectl describe pod <\/code> komutunun \u00e7\u0131kt\u0131s\u0131nda \"Failed to pull image\" veya \"ImagePullBackOff\" gibi hata mesajlar\u0131 g\u00f6rmelisiniz. Ayr\u0131ca, Node'un containerd<\/code> veya docker<\/code> servis loglar\u0131n\u0131 incelemek de faydal\u0131 olabilir.<\/p>\n\u00c7\u00f6z\u00fcm olarak, imaj ad\u0131n\u0131 ve etiketini do\u011frulamak, gerekli imagePullSecrets<\/code>'\u0131n do\u011fru yap\u0131land\u0131r\u0131ld\u0131\u011f\u0131ndan emin olmak, Node'lar\u0131n imaj deposuna a\u011f eri\u015fimi olup olmad\u0131\u011f\u0131n\u0131 kontrol etmek ve imaj deposunun durumunu kontrol etmek gerekir.<\/p>\n\n Uzman \u0130pucu: \u00c7ok say\u0131da Pod'u ayn\u0131 anda ba\u015flatt\u0131\u011f\u0131n\u0131zda imaj \u00e7ekme limitlerine tak\u0131lmamak i\u00e7in imajlar\u0131n\u0131z\u0131 yerel bir registry cache'inde bar\u0131nd\u0131rmay\u0131 veya daha h\u0131zl\u0131 CDN'ler kullanmay\u0131 d\u00fc\u015f\u00fcnebilirsiniz.\n <\/div>\nNode Se\u00e7im K\u0131s\u0131tlamalar\u0131 ve Tolerasyonlar\u0131n Rol\u00fc Nedir?<\/h2>\n
Kubernetes Scheduler'\u0131, Pod'lar\u0131 uygun Node'lara yerle\u015ftirirken sadece kaynaklar\u0131 de\u011fil, ayn\u0131 zamanda tan\u0131mlanm\u0131\u015f k\u0131s\u0131tlamalar\u0131 da g\u00f6z \u00f6n\u00fcnde bulundurur. Bu k\u0131s\u0131tlamalar, Pod'lar\u0131n belirli \u00f6zelliklere sahip Node'lara yerle\u015fmesini sa\u011flamak veya belirli Node'lardan uzak durmas\u0131n\u0131 sa\u011flamak i\u00e7in kullan\u0131l\u0131r. Yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f veya anla\u015f\u0131lmam\u0131\u015f Node se\u00e7im k\u0131s\u0131tlamalar\u0131, Pod'lar\u0131n 'Pending' durumunda kalmas\u0131na s\u0131k\u00e7a neden olur.<\/p>\n
Node Selector ve Affinity\/Anti-affinity Kullan\u0131m\u0131<\/h3>\n
Pod'lar\u0131 belirli Node'lara ataman\u0131n birka\u00e7 yolu vard\u0131r:<\/p>\n
\n- \n Node Selector:<\/strong> Bu, en basit y\u00f6ntemdir. Pod manifestinde belirli bir Node etiketi belirtirsiniz ve Pod yaln\u0131zca o etikete sahip Node'larda planlan\u0131r. E\u011fer k\u00fcmede bu etikete sahip bir Node yoksa veya var olanlar yeterli kayna\u011fa sahip de\u011filse, Pod 'Pending' kalacakt\u0131r.<\/p>\n
\napiVersion: v1\nkind: Pod\nmetadata:\n name: benim-ozel-podum\nspec:\n nodeSelector:\n disktype: ssd\n containers:\n - name: web-app\n image: nginx\n <\/pre>\n<\/code><\/p>\n
Yukar\u0131daki Pod, sadece disktype: ssd<\/code> etiketine sahip Node'larda \u00e7al\u0131\u015fabilir. E\u011fer k\u00fcmenizde b\u00f6yle bir Node yoksa, Pod planlanmayacakt\u0131r.<\/p>\n<\/li>\n- \n Node Affinity\/Anti-affinity:<\/strong> Node Selector'dan daha esnek ve g\u00fc\u00e7l\u00fc bir mekanizmad\u0131r. Pod'lar\u0131n belirli Node'lara \"\u00e7ekim\" (affinity) veya \"itme\" (anti-affinity) g\u00f6stermesini sa\u011flar. \u0130ki t\u00fcr affinity vard\u0131r:<\/p>\n
\nrequiredDuringSchedulingIgnoredDuringExecution<\/code>: Pod'un planlanmas\u0131 i\u00e7in bu kural kesinlikle kar\u015f\u0131lanmal\u0131d\u0131r. Kar\u015f\u0131lanmazsa Pod 'Pending' kal\u0131r.<\/li>\npreferredDuringSchedulingIgnoredDuringExecution<\/code>: Bu kural tercihtir; m\u00fcmk\u00fcnse uyulur, ancak uyulmamas\u0131 Pod'un planlanmas\u0131n\u0131 engellemez.<\/li>\n<\/ul>\n\u00d6rne\u011fin, belirli bir b\u00f6lgede (region) \u00e7al\u0131\u015fmay\u0131 tercih eden bir Pod:<\/p>\n
\napiVersion: v1\nkind: Pod\nmetadata:\n name: benim-bolge-podum\nspec:\n affinity:\n nodeAffinity:\n requiredDuringSchedulingIgnoredDuringExecution:\n nodeSelectorTerms:\n - matchExpressions:\n - key: topology.kubernetes.io\/region\n operator: In\n values:\n - us-east-1\n containers:\n - name: web-app\n image: nginx\n <\/pre>\n<\/code><\/p>\n
E\u011fer k\u00fcmede us-east-1<\/code> b\u00f6lgesinde bir Node yoksa veya bu Node uygun kaynaklara sahip de\u011filse, Pod 'Pending' kalacakt\u0131r. Anti-affinity ise Pod'lar\u0131n belirli Node'lardan uzak durmas\u0131n\u0131 sa\u011flar, \u00f6rne\u011fin belirli bir Node'daki di\u011fer Pod'larla birlikte \u00e7al\u0131\u015fmas\u0131n\u0131 engellemek i\u00e7in kullan\u0131labilir.<\/p>\n<\/li>\n<\/ul>\nTaints ve Tolerations ile Node D\u0131\u015f\u0131 B\u0131rakma<\/h3>\n
Taints ve Tolerations, Kubernetes'in geli\u015fmi\u015f planlama \u00f6zelliklerinden biridir ve Pod'lar\u0131n belirli Node'lara yerle\u015fmesini \"engellemek\" i\u00e7in kullan\u0131l\u0131r. Bir Node'a \"taint\" ekleyerek, o Node'un belirli Pod'lar\u0131 kabul etmeyece\u011fini belirtirsiniz. Ancak, Pod'lar bu \"taint\"lere \"toleration\" g\u00f6sterirse, o Node \u00fczerinde planlanabilirler.<\/p>\n
Bir Node'a taint eklemek i\u00e7in:<\/p>\n
\nkubectl taint nodes node1 key=value:NoSchedule\n <\/pre>\n<\/code><\/p>\n
Bu komut, node1<\/code> \u00fczerine key=value:NoSchedule<\/code> taint'ini ekler. NoSchedule<\/code> etkisi, bu taint'e tolerasyon g\u00f6stermeyen Pod'lar\u0131n bu Node'a planlanmamas\u0131n\u0131 sa\u011flar.<\/p>\nBir Pod'un bu taint'e tolerasyon g\u00f6stermesi i\u00e7in:<\/p>\n
\napiVersion: v1\nkind: Pod\nmetadata:\n name: benim-toleransli-podum\nspec:\n tolerations:\n - key: \"key\"\n operator: \"Equal\"\n value: \"value\"\n effect: \"NoSchedule\"\n containers:\n - name: web-app\n image: nginx\n <\/pre>\n<\/code><\/p>\n
E\u011fer bir Pod'un gerekli tolerasyonu yoksa ve Node'da bu Pod'u engelleyen bir taint varsa, Pod 'Pending' durumunda kalacakt\u0131r. Genellikle bu durum, \u00f6zel i\u015f y\u00fckleri (GPU Pod'lar\u0131, kontrol d\u00fczlemi Pod'lar\u0131) i\u00e7in Node'lar\u0131 izole etmek amac\u0131yla kullan\u0131l\u0131r.<\/p>\n
Pod Priority ve Preemption<\/h3>\n
Kubernetes 1.14'ten itibaren sunulan Pod Priority ve Preemption (\u00f6ncelik ve \u00f6n al\u0131m), y\u00fcksek \u00f6ncelikli Pod'lar\u0131n d\u00fc\u015f\u00fck \u00f6ncelikli Pod'lar\u0131 Node'lardan \u00e7\u0131kararak kendi yerini a\u00e7mas\u0131n\u0131 sa\u011flar. E\u011fer k\u00fcmede kaynak yetersizli\u011fi varsa ve y\u00fcksek \u00f6ncelikli bir Pod planlanam\u0131yorsa, Scheduler, d\u00fc\u015f\u00fck \u00f6ncelikli Pod'lar\u0131 sonland\u0131rarak kendisine yer a\u00e7maya \u00e7al\u0131\u015fabilir. Ancak, bu mekanizma do\u011fru yap\u0131land\u0131r\u0131lmad\u0131\u011f\u0131nda veya kaynaklar tamamen t\u00fckenmi\u015fse, y\u00fcksek \u00f6ncelikli Pod bile 'Pending' kalabilir.<\/p>\n
Pod'lara \u00f6ncelik atamak i\u00e7in PriorityClass<\/code> kaynaklar\u0131 tan\u0131mlan\u0131r ve Pod'lar bu s\u0131n\u0131f\u0131 referans al\u0131r:<\/p>\n\napiVersion: scheduling.k8s.io\/v1\nkind: PriorityClass\nmetadata:\n name: high-priority\nvalue: 1000000\nglobalDefault: false\ndescription: \"Bu PriorityClass y\u00fcksek \u00f6ncelikli Pod'lar i\u00e7indir.\"\n <\/pre>\n<\/code><\/p>\n
<\/pre>\n<\/code>
\napiVersion: v1
\nkind: Pod
\nmetadata:
\n name: benim-yuksek-oncelikli-podum
\nspec:
\n priorityClassName: high-priority
\n containers:
\n - name: web-app
\n image: nginx
\n <\/code><\/p>\n
E\u011fer \u00f6ncelik ve \u00f6n al\u0131m mekanizmalar\u0131 bekledi\u011finiz gibi \u00e7al\u0131\u015fm\u0131yorsa ve Pod'lar hala 'Pending' kal\u0131yorsa, k\u00fcmenizin genel kaynak durumunu ve PriorityClass tan\u0131mlar\u0131n\u0131z\u0131 g\u00f6zden ge\u00e7irmelisiniz. kubectl describe pod <\/code> komutundaki event'lar, \u00f6n al\u0131m denemelerinin ba\u015far\u0131s\u0131z olup olmad\u0131\u011f\u0131na dair bilgiler i\u00e7erebilir.<\/p>\nGer\u00e7ek D\u00fcnya Senaryolar\u0131: Pod Planlama Sorunlar\u0131na Yakla\u015f\u0131mlar<\/h2>\n
Teorik bilgileri peki\u015ftirmek i\u00e7in, ger\u00e7ek d\u00fcnyada s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan iki vaka analizini inceleyelim. Bu senaryolar, yukar\u0131da bahsedilen nedenlerin nas\u0131l ortaya \u00e7\u0131kt\u0131\u011f\u0131n\u0131 ve bu durumlarda ad\u0131m ad\u0131m nas\u0131l sorun giderme yap\u0131lmas\u0131 gerekti\u011fini g\u00f6sterecektir.<\/p>\n
Vaka Analizi 1: Kritik Uygulama Pod'u Kaynak T\u00fckenmesi Nedeniyle Pending Kal\u0131yor<\/h3>\n
Bir e-ticaret platformu i\u015fletti\u011finizi varsay\u0131n. Kara Cuma indirimi nedeniyle beklenmedik bir trafik art\u0131\u015f\u0131 ya\u015fan\u0131yor ve sisteminiz otomatik olarak yeni Pod'lar \u00f6l\u00e7eklendirmeye \u00e7al\u0131\u015f\u0131yor. Ancak, ana sipari\u015f i\u015fleme servisiniz i\u00e7in olu\u015fturulan yeni Pod'lar s\u00fcrekli 'Pending' durumunda kal\u0131yor.<\/p>\n
Te\u015fhis Ad\u0131mlar\u0131:<\/h4>\n\n- Pod Durumunu Kontrol Edin:<\/strong>\n
\nkubectl get pods -n e-commerce | grep order-processor\n# \u00c7\u0131kt\u0131:\n# order-processor-abcde-fghij 0\/1 Pending 0 2m\n <\/pre>\n<\/code><\/p>\n
Pod'un 'Pending' oldu\u011funu g\u00f6r\u00fcyoruz.<\/p>\n<\/li>\n
- Pod'u Daha Detayl\u0131 \u0130nceleyin:<\/strong>\n
\nkubectl describe pod order-processor-abcde-fghij -n e-commerce\n <\/pre>\n<\/code><\/p>\n
Event'lar b\u00f6l\u00fcm\u00fcnde \u015funa benzer bir mesaj g\u00f6r\u00fcn\u00fcyor:<\/p>\n
\n...\nEvents:\n Type Reason Age From Message\n ---- ------ ---- ---- -------\n Warning FailedScheduling 30s default-scheduler 0\/5 nodes are available: 5 Insufficient cpu.\n <\/pre>\n<\/code><\/p>\n
Burada a\u00e7\u0131k\u00e7a \"Insufficient cpu\" (yetersiz CPU) hatas\u0131n\u0131 g\u00f6r\u00fcyoruz. Yani k\u00fcmedeki 5 Node'un hi\u00e7birinde Pod'un talep etti\u011fi kadar CPU kayna\u011f\u0131 bo\u015fta de\u011fil.<\/p>\n<\/li>\n
- Node Kaynak Durumunu Kontrol Edin:<\/strong>\n
\nkubectl top nodes\n# \u00c7\u0131kt\u0131:\n# NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%\n# node-1 1800m 90% 7Gi 85%\n# node-2 1900m 95% 7.2Gi 90%\n# ... (di\u011fer Node'lar da benzer \u015fekilde y\u00fcksek kullan\u0131mda)\n <\/pre>\n<\/code><\/p>\n
G\u00f6r\u00fcn\u00fc\u015fe g\u00f6re t\u00fcm Node'lar CPU kaynaklar\u0131 a\u00e7\u0131s\u0131ndan neredeyse tamamen dolu. Sipari\u015f i\u015fleme Pod'u muhtemelen 2 CPU \u00e7ekirde\u011fi talep ediyordu ve bu talebi kar\u015f\u0131layacak hi\u00e7bir Node kalmad\u0131.<\/p>\n<\/li>\n<\/ol>\n
\u00c7\u00f6z\u00fcm Ad\u0131mlar\u0131:<\/h4>\n\n- K\u00fcme \u00d6l\u00e7eklendirme (Tercih Edilen):<\/strong> En iyi \u00e7\u00f6z\u00fcm, k\u00fcmenize daha fazla Node eklemektir. Bulut sa\u011flay\u0131c\u0131n\u0131z\u0131n otomatik \u00f6l\u00e7eklendirme (Cluster Autoscaler) \u00f6zelli\u011fini yap\u0131land\u0131r\u0131n veya manuel olarak yeni i\u015f\u00e7i d\u00fc\u011f\u00fcmleri sa\u011flay\u0131n.<\/li>\n
- Pod Kaynak Taleplerini Azaltma (Ge\u00e7ici \u00c7\u00f6z\u00fcm):<\/strong> E\u011fer hemen yeni Node ekleyemiyorsan\u0131z, sipari\u015f i\u015fleme Pod'unun CPU
requests<\/code> de\u011ferini ge\u00e7ici olarak d\u00fc\u015f\u00fcrebilirsiniz. Ancak bu, Pod'un performans\u0131n\u0131 olumsuz etkileyebilir ve sadece acil durumlarda d\u00fc\u015f\u00fcn\u00fclmelidir.\n\n# ...\nresources:\n requests:\n cpu: \"1\" # 2'den 1'e d\u00fc\u015f\u00fcr\u00fcld\u00fc\n# ...\n <\/pre>\n<\/code>\n <\/li>\n
- D\u00fc\u015f\u00fck \u00d6ncelikli Pod'lar\u0131 Temizleme:<\/strong> E\u011fer k\u00fcmede daha az kritik i\u015f y\u00fckleri varsa ve Pod'lar\u0131n\u0131zda
PriorityClass<\/code> tan\u0131mlad\u0131ysan\u0131z, d\u00fc\u015f\u00fck \u00f6ncelikli Pod'lar\u0131n manuel olarak silinmesi, y\u00fcksek \u00f6ncelikli Pod'lara yer a\u00e7abilir.<\/li>\n<\/ol>\nVaka Analizi 2: \u00d6zel GPU Pod'u Yanl\u0131\u015f Taint\/Toleration Yap\u0131land\u0131rmas\u0131 Nedeniyle Pending Kal\u0131yor<\/h3>\n
Makine \u00f6\u011frenimi e\u011fitim i\u015fleri i\u00e7in \u00f6zel GPU Node'lar\u0131 olan bir Kubernetes k\u00fcmeniz var. Yeni bir GPU e\u011fitim Pod'unu da\u011f\u0131tt\u0131n\u0131z, ancak Pod 'Pending' durumunda kal\u0131yor ve GPU Node'lar\u0131na planlanm\u0131yor.<\/p>\n
Te\u015fhis Ad\u0131mlar\u0131:<\/h4>\n\n- Pod Durumunu Kontrol Edin:<\/strong>\n
\nkubectl get pods | grep gpu-trainer\n# \u00c7\u0131kt\u0131:\n# gpu-trainer-xyz12-uvw34 0\/1 Pending 0 5m\n <\/pre>\n<\/code>\n <\/li>\n
- Pod'u \u0130nceleyin:<\/strong>\n
\nkubectl describe pod gpu-trainer-xyz12-uvw34\n <\/pre>\n<\/code><\/p>\n
Event'lar b\u00f6l\u00fcm\u00fcnde \u015funa benzer bir mesaj g\u00f6r\u00fclebilir:<\/p>\n
\n...\nEvents:\n Type Reason Age From Message\n ---- ------ ---- ---- -------\n 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.\n <\/pre>\n<\/code><\/p>\n
Bu mesaj bize iki ipucu veriyor: bir Node'da \"gpu: true\" taint'i var ve Pod bu taint'e tolerasyon g\u00f6stermiyor. Di\u011fer iki Node ise Pod'un nodeSelector<\/code> kural\u0131n\u0131 kar\u015f\u0131lam\u0131yor.<\/p>\n<\/li>\n- GPU Node Taint'lerini Kontrol Edin:<\/strong>\n
\nkubectl describe node gpu-node-01 | grep Taints\n# \u00c7\u0131kt\u0131:\n# Taints: gpu=true:NoSchedule\n <\/pre>\n<\/code><\/p>\n
GPU Node'unda gpu=true:NoSchedule<\/code> taint'inin oldu\u011funu do\u011frulad\u0131k.<\/p>\n<\/li>\n- Pod Manifestini Kontrol Edin:<\/strong> GPU Pod manifestine bakt\u0131\u011f\u0131n\u0131zda,
tolerations<\/code> b\u00f6l\u00fcm\u00fcn\u00fcn eksik oldu\u011funu fark ettiniz. Ayr\u0131ca, nodeSelector<\/code> kural\u0131 da yanl\u0131\u015f yaz\u0131lm\u0131\u015f olabilir veya hi\u00e7 belirtilmemi\u015f olabilir.<\/li>\n<\/ol>\n\u00c7\u00f6z\u00fcm Ad\u0131mlar\u0131:<\/h4>\n\n- Pod Manifestine Tolerasyon Ekleme:<\/strong> Pod'un GPU Node'una planlanabilmesi i\u00e7in gerekli tolerasyonu eklemelisiniz:\n
\napiVersion: v1\nkind: Pod\nmetadata:\n name: benim-gpu-trainer\nspec:\n tolerations:\n - key: \"gpu\"\n operator: \"Equal\"\n value: \"true\"\n effect: \"NoSchedule\"\n # E\u011fer nodeSelector da eksikse veya yanl\u0131\u015fsa, onu da d\u00fczeltin\n nodeSelector:\n accelerator: nvidia-gpu\n containers:\n - name: cuda-app\n image: nvidia\/cuda:11.4.0-base-ubuntu20.04\n resources:\n limits:\n nvidia.com\/gpu: 1\n <\/pre>\n<\/code>\n <\/li>\n
- Node Etiketlerini Kontrol Etme:<\/strong> E\u011fer Node'lar
nodeSelector<\/code> taraf\u0131ndan beklenen etikete sahip de\u011filse, Node'lara do\u011fru etiketi ekledi\u011finizden emin olun:\n\nkubectl label node gpu-node-01 accelerator=nvidia-gpu\n <\/pre>\n<\/code>\n <\/li>\n<\/ol>\n
Bu vaka analizleri, 'Pending' durumundaki Pod'lar\u0131 te\u015fhis etmenin ve \u00e7\u00f6zmenin, kubectl describe<\/code> ve kubectl top<\/code> gibi ara\u00e7larla ba\u015flayarak, ad\u0131m ad\u0131m mant\u0131ksal bir \u00e7\u0131kar\u0131m s\u00fcreci oldu\u011funu g\u00f6stermektedir. \u00d6nemli olan, hata mesajlar\u0131n\u0131 do\u011fru okumak ve k\u00fcme yap\u0131n\u0131z\u0131 iyi anlamakt\u0131r.<\/p>\nPod Planlama Sorunlar\u0131 Nas\u0131l Te\u015fhis Edilir ve \u00c7\u00f6z\u00fcl\u00fcr?<\/h2>\n
Bir Pod'un 'Pending' durumunda kalmas\u0131yla kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131zda, sistemli bir yakla\u015f\u0131m izlemek sorun giderme s\u00fcrecini h\u0131zland\u0131r\u0131r. Bu b\u00f6l\u00fcmde, Kubernetes Pod planlama sorunlar\u0131n\u0131 te\u015fhis etmek ve \u00e7\u00f6zmek i\u00e7in kullanabilece\u011finiz temel ara\u00e7lar\u0131 ve ad\u0131mlar\u0131 ele alaca\u011f\u0131z.<\/p>\n
kubectl describe pod<\/code> ve kubectl logs<\/code> Kullan\u0131m\u0131<\/h3>\nKubernetes'te sorun gidermenin olmazsa olmaz\u0131 kubectl<\/code> komut sat\u0131r\u0131 arac\u0131d\u0131r. \u00d6zellikle kubectl describe pod<\/code> komutu, bir Pod hakk\u0131nda detayl\u0131 bilgi alman\u0131z\u0131 sa\u011flar ve 'Pending' durumunun temel nedenini genellikle burada bulabilirsiniz.<\/p>\n\nkubectl describe pod -n \n <\/pre>\n<\/code><\/p>\n
Bu komutun \u00e7\u0131kt\u0131s\u0131nda dikkat etmeniz gereken ba\u015fl\u0131ca yerler \u015funlard\u0131r:<\/p>\n
\n- Status:<\/strong> Pod'un mevcut durumu (Pending, Running vb.).<\/li>\n
- Events (Olaylar):<\/strong> Bu b\u00f6l\u00fcm, Pod'un ya\u015fam d\u00f6ng\u00fcs\u00fc boyunca meydana gelen t\u00fcm olaylar\u0131 listeler. Scheduler'\u0131n neden bir Node bulamad\u0131\u011f\u0131n\u0131 (
FailedScheduling<\/code>), kaynak yetersizliklerini (Insufficient cpu\/memory<\/code>), taint\/toleration uyu\u015fmazl\u0131klar\u0131n\u0131 veya imaj \u00e7ekme hatalar\u0131n\u0131 (Failed to pull image<\/code>, ImagePullBackOff<\/code>) burada g\u00f6rebilirsiniz.<\/li>\n- Resource Requests\/Limits:<\/strong> Pod'un talep etti\u011fi ve s\u0131n\u0131rlad\u0131\u011f\u0131 kaynak miktarlar\u0131n\u0131 kontrol edin. Bu de\u011ferler \u00e7ok y\u00fcksekse veya mevcut Node kapasitesiyle uyu\u015fmuyorsa, sorun burada olabilir.<\/li>\n
- Node Selector\/Affinity\/Tolerations:<\/strong> Pod'un Node se\u00e7im k\u0131s\u0131tlamalar\u0131n\u0131 kontrol edin. Yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f bir kural Pod'un planlanmas\u0131n\u0131 engelleyebilir.<\/li>\n<\/ul>\n
E\u011fer Pod 'Pending' durumundan \u00e7\u0131kt\u0131ktan sonra sorun ya\u015f\u0131yorsa (\u00f6rne\u011fin 'CrashLoopBackOff'a d\u00fc\u015f\u00fcyorsa), Pod'un loglar\u0131n\u0131 incelemek i\u00e7in kubectl logs<\/code> komutunu kullanabilirsiniz:<\/p>\n\nkubectl logs -n \nkubectl logs -c -n # Belirli bir container i\u00e7in\n <\/pre>\n<\/code><\/p>\n
Bu komut, Pod i\u00e7erisindeki uygulaman\u0131n ba\u015flang\u0131\u00e7 s\u0131ras\u0131nda kar\u015f\u0131la\u015ft\u0131\u011f\u0131 hatalar\u0131 ortaya \u00e7\u0131karabilir.<\/p>\n
Event'lar\u0131 Takip Etmek<\/h3>\n
Sadece belirli bir Pod'un event'lar\u0131n\u0131 de\u011fil, ayn\u0131 zamanda genel k\u00fcme event'lar\u0131n\u0131 da izlemek, sistem genelindeki sorunlar\u0131 anlaman\u0131za yard\u0131mc\u0131 olabilir. kubectl get events<\/code> komutu, son olaylar\u0131 listeler. Ancak bu \u00e7\u0131kt\u0131 genellikle \u00e7ok kalabal\u0131k olabilir.<\/p>\nDaha hedefli bir yakla\u015f\u0131m i\u00e7in, event'lar\u0131 filtreleyebilirsiniz:<\/p>\n
\nkubectl get events --field-selector type=Warning -n \nkubectl get events --field-selector involvedObject.kind=Pod,involvedObject.name= -n \n <\/pre>\n<\/code><\/p>\n
Bu \u015fekilde, \u00f6zellikle 'Warning' seviyesindeki olaylara odaklanarak veya belirli bir Pod ile ilgili t\u00fcm olaylar\u0131 inceleyerek sorun giderme s\u00fcresini k\u0131saltabilirsiniz.<\/p>\n
Node Durumlar\u0131n\u0131 \u0130ncelemek<\/h3>\n
Pod'lar\u0131n bir Node'a planlanamamas\u0131 genellikle o Node'un kendisiyle veya kaynaklar\u0131yla ilgili bir sorundan kaynaklan\u0131r. Node'lar\u0131n durumunu kontrol etmek, bu t\u00fcr sorunlar\u0131 belirlemek i\u00e7in kritik bir ad\u0131md\u0131r.<\/p>\n
\nkubectl get nodes\n# \u00c7\u0131kt\u0131:\n# NAME STATUS ROLES AGE VERSION\n# node-1 Ready 1d v1.23.5\n# node-2 Ready 1d v1.23.5\n# node-3 NotReady 1d v1.23.5 # Bir Node NotReady durumunda!\n <\/pre>\n<\/code><\/p>\n
E\u011fer bir Node 'NotReady' durumundaysa, o Node'a Pod planlanmaz. Node'un neden 'NotReady' oldu\u011funu anlamak i\u00e7in kubectl describe node <\/code> komutunu kullan\u0131n. Node \u00fczerinde kaynak yetersizli\u011fi (DiskPressure, MemoryPressure, PIDPressure) veya a\u011f sorunlar\u0131 gibi durumlar Conditions<\/code> b\u00f6l\u00fcm\u00fcnde listelenir.<\/p>\nAyr\u0131ca, Node'lar\u0131n mevcut kaynak kullan\u0131m\u0131n\u0131 g\u00f6rmek i\u00e7in:<\/p>\n
\nkubectl top nodes\n <\/pre>\n<\/code><\/p>\n
Bu komut, Node'lar\u0131n CPU ve bellek kullan\u0131m\u0131n\u0131 g\u00f6sterir ve hangi Node'lar\u0131n kaynak a\u00e7\u0131s\u0131ndan s\u0131k\u0131\u015f\u0131k oldu\u011funu h\u0131zl\u0131ca anlaman\u0131z\u0131 sa\u011flar.<\/p>\n
Monitoring Ara\u00e7lar\u0131<\/h3>\n
Geli\u015fmi\u015f Kubernetes ortamlar\u0131nda Prometheus, Grafana, Datadog veya ELK Stack gibi monitoring ve loglama ara\u00e7lar\u0131, Pod planlama sorunlar\u0131n\u0131 proaktif olarak tespit etmek ve derinlemesine analiz etmek i\u00e7in paha bi\u00e7ilmezdir. Bu ara\u00e7lar sayesinde:<\/p>\n
\n- Node'lar\u0131n ge\u00e7mi\u015f kaynak kullan\u0131m trendlerini g\u00f6rebilir, kaynak t\u00fckenmeden \u00f6nce \u00f6nlem alabilirsiniz.<\/li>\n
- Scheduler'\u0131n event'lar\u0131n\u0131 daha okunabilir grafikler ve alarmlar \u015feklinde izleyebilirsiniz.<\/li>\n
- Pod'lar\u0131n ve Node'lar\u0131n sa\u011fl\u0131k durumunu merkezi bir yerden takip edebilir, anormallikleri h\u0131zla tespit edebilirsiniz.<\/li>\n
- Uygulama loglar\u0131n\u0131 toplay\u0131p analiz ederek Pod'un i\u00e7indeki sorunlar\u0131 daha kolay belirleyebilirsiniz.<\/li>\n<\/ul>\n
Bu ara\u00e7lar, manuel kubectl<\/code> komutlar\u0131na k\u0131yasla daha geni\u015f kapsaml\u0131 ve otomatize edilmi\u015f bir g\u00f6r\u00fcn\u00fcm sunar, b\u00f6ylece sorunlara daha h\u0131zl\u0131 m\u00fcdahale edebilirsiniz.<\/p>\n\n Uzman \u0130pucu: Kubernetes k\u00fcmenizin sa\u011fl\u0131kl\u0131 ve kararl\u0131 \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamak i\u00e7in proaktif olmal\u0131s\u0131n\u0131z. Monitoring ve alarm sistemlerini do\u011fru kurarak, Pod'lar\u0131n\u0131z 'Pending' durumuna d\u00fc\u015fmeden potansiyel sorunlar\u0131 tespit edebilir ve \u00f6nleyici tedbirler alabilirsiniz.\n <\/div>\n\u0130leri D\u00fczey \u0130pu\u00e7lar\u0131 ve En \u0130yi Uygulamalar<\/h2>\n
Pod planlama sorunlar\u0131n\u0131 gidermenin yan\u0131 s\u0131ra, bu sorunlar\u0131 ba\u015ftan \u00f6nlemek ve k\u00fcmenizi daha diren\u00e7li hale getirmek i\u00e7in baz\u0131 ileri d\u00fczey teknikler ve en iyi uygulamalar mevcuttur. Bu ipu\u00e7lar\u0131, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k Kubernetes ortamlar\u0131nda \u00f6nemli faydalar sa\u011flayacakt\u0131r.<\/p>\n
Cluster Autoscaler ve Vertical Pod Autoscaler<\/h3>\n\n- \n Cluster Autoscaler (CA):<\/strong> Kaynak yetersizli\u011fi nedeniyle 'Pending' kalan Pod'lar i\u00e7in en etkili \u00e7\u00f6z\u00fcmlerden biri Cluster Autoscaler'd\u0131r. CA, Kubernetes k\u00fcmesindeki 'Pending' Pod'lar\u0131 alg\u0131lar ve bu Pod'lar\u0131 bar\u0131nd\u0131rmak i\u00e7in yeterli Node yoksa, altyap\u0131 sa\u011flay\u0131c\u0131n\u0131zdan (AWS, GCP, Azure vb.) otomatik olarak yeni Node'lar talep eder. Bu sayede, manuel m\u00fcdahaleye gerek kalmadan k\u00fcmenizin kapasitesi dinamik olarak art\u0131r\u0131l\u0131r.\n <\/li>\n
- \n Vertical Pod Autoscaler (VPA):<\/strong> VPA, Pod'lar\u0131n\u0131z\u0131n ge\u00e7mi\u015f kaynak kullan\u0131m\u0131n\u0131 analiz ederek CPU ve bellek
requests<\/code> ve limits<\/code> de\u011ferlerini otomatik olarak ayarlar. Bu, Pod'lar\u0131n\u0131z\u0131n gere\u011finden fazla kaynak talep etmesini engelleyerek Node'lardaki israf\u0131 azalt\u0131r ve Scheduler'\u0131n daha verimli planlama yapmas\u0131na yard\u0131mc\u0131 olur. Ayr\u0131ca, Pod'lar\u0131n kaynak yetersizli\u011fi nedeniyle 'Pending' kalma olas\u0131l\u0131\u011f\u0131n\u0131 da d\u00fc\u015f\u00fcr\u00fcr, \u00e7\u00fcnk\u00fc her Pod'un ihtiya\u00e7 duydu\u011fu ger\u00e7ek\u00e7i kaynaklar\u0131 talep etmesini sa\u011flar.\n <\/li>\n<\/ul>\n\u00d6zel Scheduler'lar ve Geli\u015fmi\u015f Planlama Stratejileri<\/h3>\n
\u00c7o\u011fu durumda, Kubernetes'in varsay\u0131lan Scheduler'\u0131 yeterlidir. Ancak, belirli i\u015f y\u00fckleri veya karma\u015f\u0131k kurallar i\u00e7in \u00f6zel bir Scheduler geli\u015ftirmeniz gerekebilir. \u00d6rne\u011fin, \u00e7ok kat\u0131 SLA'lara sahip Pod'lar, belirli donan\u0131m topolojileri veya \u00e7ok \u00f6zel optimizasyon gereksinimleri olan durumlar i\u00e7in \u00f6zel bir Scheduler yaz\u0131labilir. Bu, Pod planlama mant\u0131\u011f\u0131n\u0131 tamamen sizin kontrol\u00fcn\u00fcze verir. Ayr\u0131ca, Scheduler Extenders<\/a> kullanarak varsay\u0131lan Scheduler'\u0131n davran\u0131\u015f\u0131n\u0131 geni\u015fletebilirsiniz.<\/p>\nKaynak Limitlerinin Ak\u0131ll\u0131ca Ayarlanmas\u0131<\/h3>\n
Pod'lar\u0131n\u0131z i\u00e7in do\u011fru resources.requests<\/code> ve resources.limits<\/code> de\u011ferlerini belirlemek, 'Pending' durumunu \u00f6nlemede kritik \u00f6neme sahiptir:<\/p>\n\n- Requests:<\/strong> Pod'un \u00e7al\u0131\u015fmas\u0131 i\u00e7in minimum garanti edilen kaynaklard\u0131r. \u00c7ok d\u00fc\u015f\u00fck ayarlarsan\u0131z, Pod performans sorunlar\u0131 ya\u015fayabilir; \u00e7ok y\u00fcksek ayarlarsan\u0131z, k\u00fcmede yer bulmakta zorlanabilir.<\/li>\n
- Limits:<\/strong> Pod'un kullanabilece\u011fi maksimum kaynaklard\u0131r. Bu limitler, bir Pod'un t\u00fcm Node kaynaklar\u0131n\u0131 t\u00fcketmesini engelleyerek di\u011fer Pod'lar\u0131 korur.<\/li>\n<\/ul>\n
Kaynak limitlerini belirlerken ge\u00e7mi\u015f kullan\u0131m verilerini (monitoring ara\u00e7lar\u0131ndan) kullanmak ve test etmek \u00f6nemlidir. Geli\u015fig\u00fczel de\u011ferler atamak yerine, uygulamalar\u0131n\u0131z\u0131n ger\u00e7ek ihtiya\u00e7lar\u0131na g\u00f6re bu de\u011ferleri ayarlay\u0131n.<\/p>\n
Mobil Uyumlu Tasar\u0131m Yakla\u015f\u0131mlar\u0131<\/h3>\n
Makale format\u0131n\u0131n mobil cihazlarda da rahatl\u0131kla okunabilir olmas\u0131, i\u00e7eri\u011fin geni\u015f kitlelere ula\u015fmas\u0131 a\u00e7\u0131s\u0131ndan \u00f6nemlidir. HTML yap\u0131n\u0131z\u0131n mobil uyumlu olmas\u0131 i\u00e7in a\u015fa\u011f\u0131daki yakla\u015f\u0131mlar\u0131 benimseyebilirsiniz:<\/p>\n
\n- Duyarl\u0131 Tasar\u0131m (Responsive Design):<\/strong> CSS medya sorgular\u0131 (media queries) kullanarak ekran boyutuna g\u00f6re sayfa d\u00fczenini, font boyutlar\u0131n\u0131 ve resim boyutlar\u0131n\u0131 ayarlayabilirsiniz. \u00d6rne\u011fin, mobil cihazlarda tek s\u00fctunlu bir d\u00fczen tercih edilebilirken, masa\u00fcst\u00fcnde \u00e7oklu s\u00fctunlu bir d\u00fczen kullan\u0131labilir.<\/li>\n
- Esnek Izgaralar ve Medya:<\/strong> G\u00f6rsel i\u00e7erikleri ve d\u00fczeni y\u00fczde birimleri veya
flexbox<\/code>\/ grid<\/code> gibi CSS \u00f6zellikleriyle olu\u015fturarak farkl\u0131 ekran boyutlar\u0131na otomatik olarak adapte olmas\u0131n\u0131 sa\u011flay\u0131n.<\/li>\n- Anla\u015f\u0131l\u0131r Font Boyutlar\u0131:<\/strong> K\u00fc\u00e7\u00fck ekranlarda okunabilirli\u011fi art\u0131rmak i\u00e7in uygun font boyutlar\u0131 ve sat\u0131r aral\u0131klar\u0131 kullan\u0131n.<\/li>\n
- G\u00f6rsel Hiyerar\u015fi:<\/strong> Ba\u015fl\u0131klar\u0131n, paragraflar\u0131n ve liste \u00f6\u011felerinin hiyerar\u015fisini net tutarak mobil kullan\u0131c\u0131n\u0131n i\u00e7eri\u011fi kolayca tarayabilmesini sa\u011flay\u0131n.<\/li>\n<\/ul>\n
Bu makale, body<\/code> i\u00e7eri\u011fi sundu\u011fundan, ger\u00e7ek CSS medya sorgular\u0131 ekleyemeyiz. Ancak bir CSS dosyas\u0131nda bu HTML yap\u0131s\u0131n\u0131 mobil uyumlu hale getirmek i\u00e7in \u015f\u00f6yle bir kod par\u00e7ac\u0131\u011f\u0131 kullan\u0131labilir:<\/p>\n\n\/* style.css dosyas\u0131na eklenebilecek bir \u00f6rnek *\/\n@media screen and (max-width: 768px) {\n body {\n padding: 10px;\n }\n h2, h3 {\n font-size: 1.2em;\n line-height: 1.4;\n }\n p {\n font-size: 0.9em;\n line-height: 1.6;\n }\n \/* Di\u011fer elementler i\u00e7in responsive ayarlar *\/\n}\n <\/pre>\n