Konteyner teknolojileri d\u00fcnyas\u0131nda, uygulamalar\u0131m\u0131z\u0131n nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 anlamak kritik \u00f6neme sahiptir. \u00d6zellikle Kubernetes gibi orkestrasyon platformlar\u0131nda, verilerimizin g\u00fcvenli\u011fi ve s\u00fcreklili\u011fi en b\u00fcy\u00fck endi\u015felerimizden biridir. Peki, verilerimiz da\u011f\u0131t\u0131mlar\u0131m\u0131zda (deployments) zaten kal\u0131c\u0131ysa, neden StatefulSet’lere ihtiya\u00e7 duyar\u0131z? Bu makalede, bu sorunun ard\u0131ndaki nedenleri derinlemesine inceleyecek, StatefulSet’lerin rol\u00fcn\u00fc ve Deployment’lardan farklar\u0131n\u0131 somut \u00f6rneklerle a\u00e7\u0131klayaca\u011f\u0131z.<\/p>\n
G\u00fcn\u00fcm\u00fcz\u00fcn modern yaz\u0131l\u0131m geli\u015ftirme d\u00fcnyas\u0131nda, konteynerle\u015ftirme ve mikroservis mimarileri h\u0131zla yayg\u0131nla\u015f\u0131yor. Uygulamalar\u0131m\u0131z\u0131 izole edilmi\u015f, ta\u015f\u0131nabilir birimler halinde paketlemek, geli\u015ftirme, test ve da\u011f\u0131t\u0131m s\u00fcre\u00e7lerini b\u00fcy\u00fck \u00f6l\u00e7\u00fcde kolayla\u015ft\u0131r\u0131yor. Kubernetes gibi orkestrasyon platformlar\u0131 ise bu konteynerleri y\u00f6netmek, \u00f6l\u00e7eklendirmek ve y\u00fcksek kullan\u0131labilirliklerini sa\u011flamak i\u00e7in g\u00fc\u00e7l\u00fc ara\u00e7lar sunuyor. Ancak, bu kolayl\u0131klar\u0131n yan\u0131 s\u0131ra baz\u0131 karma\u015f\u0131k zorluklar da beraberinde geliyor. \u00d6zellikle, durum bilgisi tutan (stateful) uygulamalar\u0131n y\u00f6netimi, durum bilgisi tutmayan (stateless) uygulamalara g\u00f6re \u00e7ok daha zordur. Veritabanlar\u0131, mesaj kuyruklar\u0131, \u00f6nbellek sistemleri gibi durum bilgisi tutan uygulamalar, \u00e7al\u0131\u015f\u0131rken belirli bir duruma sahip olurlar ve bu durumun korunmas\u0131 hayati \u00f6nem ta\u015f\u0131r. Konteynerler do\u011fas\u0131 gere\u011fi ge\u00e7icidir; yeniden ba\u015flat\u0131ld\u0131klar\u0131nda veya silindiklerinde i\u00e7lerindeki veriler kaybolabilir. \u0130\u015fte tam bu noktada, verilerimizin g\u00fcvenli\u011fini ve s\u00fcreklili\u011fini sa\u011flamak i\u00e7in kulland\u0131\u011f\u0131m\u0131z mekanizmalar devreye girer. Deployment’lar, genellikle durum bilgisi tutmayan web sunucular\u0131 gibi uygulamalar i\u00e7in idealdir. Konteynerleri kolayca yeniden ba\u015flatabilir, g\u00fcncelleyebilir ve \u00f6l\u00e7eklendirebilirsiniz. Ancak, veritaban\u0131 gibi durum bilgisi tutan bir uygulamay\u0131 bir Deployment ile y\u00f6netmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131zda, her yeniden ba\u015flatma veya g\u00fcncelleme, verilerin kaybolmas\u0131 riskini beraberinde getirir. Bu durum, uygulamalar\u0131m\u0131z\u0131n g\u00fcvenilirli\u011fini ciddi \u015fekilde tehlikeye atar. Bu makalede, verilerinDeployment’larda nas\u0131l kal\u0131c\u0131 olabildi\u011fini ve buna ra\u011fmen neden StatefulSet’lere ihtiya\u00e7 duydu\u011fumuzu ad\u0131m ad\u0131m a\u00e7\u0131klayaca\u011f\u0131z.<\/p>\n
Kubernetes ekosisteminde, uygulamalar\u0131m\u0131z\u0131 y\u00f6netmek i\u00e7in iki temel kaynak t\u00fcr\u00fc bulunur: Deployment’lar ve StatefulSet’ler. Her ikisi de konteynerli uygulamalar\u0131m\u0131z\u0131 \u00e7al\u0131\u015ft\u0131rmak ve y\u00f6netmek i\u00e7in kullan\u0131l\u0131r, ancak kullan\u0131m alanlar\u0131 ve yetenekleri a\u00e7\u0131s\u0131ndan \u00f6nemli farkl\u0131l\u0131klar g\u00f6sterirler. Deployment’lar, genellikle durum bilgisi tutmayan (stateless) uygulamalar i\u00e7in tasarlanm\u0131\u015ft\u0131r. Durum bilgisi tutmayan bir uygulama, her iste\u011fi ba\u011f\u0131ms\u0131z olarak i\u015fleyebilir ve \u00f6nceki isteklerden veya kendi durumundan ba\u011f\u0131ms\u0131zd\u0131r. \u00d6rne\u011fin, bir web sunucusu veya bir API Gateway, genellikle durum bilgisi tutmayan bir uygulamad\u0131r. Deployment’lar, bu t\u00fcr uygulamalar\u0131n kolayca g\u00fcncellenmesini, geri al\u0131nmas\u0131n\u0131 ve \u00f6l\u00e7eklendirilmesini sa\u011flar. Bir Deployment’\u0131 g\u00fcncelledi\u011finizde, Kubernetes yeni konteynerleri ba\u015flat\u0131r ve eski konteynerleri yava\u015f yava\u015f durdurur. Bu s\u00fcre\u00e7, uygulaman\u0131n s\u00fcrekli olarak eri\u015filebilir olmas\u0131n\u0131 sa\u011flamak i\u00e7in tasarlanm\u0131\u015ft\u0131r. Veri kal\u0131c\u0131l\u0131\u011f\u0131 a\u00e7\u0131s\u0131ndan bak\u0131ld\u0131\u011f\u0131nda, Deployment’lar genellikle verileri kal\u0131c\u0131 hale getirmek i\u00e7in Persistent Volume (Kal\u0131c\u0131 Birim) ve Persistent Volume Claim (Kal\u0131c\u0131 Birim Talebi) gibi Kubernetes nesneleriyle birlikte kullan\u0131l\u0131r. Bu, konteyner yeniden ba\u015flat\u0131lsa bile verilerin depolama alan\u0131nda kalmas\u0131n\u0131 sa\u011flar. Ancak, Deployment’lar, hangi konteynerin hangi veriye eri\u015fece\u011fini veya hangi network kimli\u011fine sahip olaca\u011f\u0131n\u0131 garanti etmez. Her konteyner, yeni bir kimlikle yeniden ba\u015flat\u0131labilir.<\/p>\n
Di\u011fer yandan, StatefulSet’ler, durum bilgisi tutan (stateful) uygulamalar i\u00e7in \u00f6zel olarak tasarlanm\u0131\u015ft\u0131r. Veritabanlar\u0131, mesaj kuyruklar\u0131, da\u011f\u0131t\u0131lm\u0131\u015f depolama sistemleri gibi uygulamalar, kararl\u0131 a\u011f kimliklerine, kararl\u0131 depolamaya ve s\u0131ral\u0131, zarif da\u011f\u0131t\u0131m ve \u00f6l\u00e7eklendirmeye ihtiya\u00e7 duyarlar. StatefulSet’ler, bu ihtiya\u00e7lar\u0131 kar\u015f\u0131lamak i\u00e7in a\u015fa\u011f\u0131daki \u00f6zellikleri sunar:<\/p>\n
web-0<\/code>, web-1<\/code>, web-2<\/code> gibi adland\u0131r\u0131l\u0131r ve bu adlar kal\u0131c\u0131d\u0131r.<\/li>\n- Kararl\u0131 Depolama:<\/strong> Her StatefulSet pod’u, benzersiz ve kal\u0131c\u0131 bir depolama birimine sahip olabilir. Bu, her podun kendi verilerini g\u00fcvenli bir \u015fekilde saklamas\u0131n\u0131 sa\u011flar. Bir pod silinip yeniden olu\u015fturuldu\u011funda, ayn\u0131 depolama birimine yeniden ba\u011flan\u0131r.<\/li>\n
- S\u0131ral\u0131 Da\u011f\u0131t\u0131m ve \u00d6l\u00e7eklendirme:<\/strong> StatefulSet’ler, pod’lar\u0131 s\u0131ral\u0131 bir \u015fekilde da\u011f\u0131t\u0131r ve \u00f6l\u00e7eklendirir. \u00d6rne\u011fin, 3 replikadan olu\u015fan bir StatefulSet’te, pod’lar
web-0<\/code>, sonra web-1<\/code>, sonra web-2<\/code> \u015feklinde ba\u015flat\u0131l\u0131r. \u00d6l\u00e7eklendirme de ayn\u0131 \u015fekilde s\u0131ral\u0131 olarak ger\u00e7ekle\u015fir.<\/li>\n- Zarif Da\u011f\u0131t\u0131m ve Geri Alma:<\/strong> G\u00fcncellemeler ve geri almalar da s\u0131ral\u0131 ve kontroll\u00fc bir \u015fekilde yap\u0131l\u0131r. Bu, durum bilgisi tutan uygulamalar\u0131n kararl\u0131l\u0131\u011f\u0131n\u0131 korumak i\u00e7in \u00f6nemlidir.<\/li>\n<\/ul>\n
\u00d6zetle, Deployment’lar durum bilgisi tutmayan uygulamalar i\u00e7in esneklik ve kolay y\u00f6netim sunarken, StatefulSet’ler durum bilgisi tutan uygulamalar i\u00e7in gerekli olan kararl\u0131l\u0131k, benzersiz kimlik ve kontroll\u00fc ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc sa\u011flar.<\/p>\n
Deployment’larda Veri Kal\u0131c\u0131l\u0131\u011f\u0131: Persistent Volumes’\u0131n Rol\u00fc<\/h3>\n
Deployment’lar, temel olarak durum bilgisi tutmayan uygulamalar i\u00e7in tasarlanm\u0131\u015f olsalar da, verilerin kal\u0131c\u0131 olmas\u0131n\u0131 sa\u011flamak i\u00e7in Kubernetes’in sundu\u011fu Persistent Volume (PV) ve Persistent Volume Claim (PVC) mekanizmalar\u0131ndan faydalanabilirler. Bu mekanizma, konteynerlerin ya\u015fam d\u00f6ng\u00fcs\u00fcnden ba\u011f\u0131ms\u0131z olarak verilerin depolanmas\u0131n\u0131 sa\u011flar. Bir Deployment’\u0131, bir veritaban\u0131 \u00e7al\u0131\u015ft\u0131rmak i\u00e7in kullanmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131zda, verilerin kaybolmamas\u0131 i\u00e7in bu PV ve PVC’leri kullanman\u0131z gerekir. Temel fikir \u015fudur: Konteynerler ge\u00e7icidir, ancak depolama birimleri (PV’ler) kal\u0131c\u0131d\u0131r. PVC’ler ise bu kal\u0131c\u0131 depolama birimlerine eri\u015fmek i\u00e7in bir talep mekanizmas\u0131d\u0131r.<\/p>\n
S\u00fcre\u00e7 \u015fu \u015fekilde i\u015fler:<\/p>\n
\n- Persistent Volume (PV) Olu\u015fturma:<\/strong> \u00d6ncelikle, altta yatan depolama sisteminizde (\u00f6rne\u011fin, bir a\u011f depolama birimi, bulut sa\u011flay\u0131c\u0131n\u0131n depolama hizmeti veya yerel disk) kal\u0131c\u0131 bir depolama alan\u0131 tan\u0131mlan\u0131r. Bu, bir PV nesnesi olarak Kubernetes’e bildirilir. PV, depolama alan\u0131n\u0131n kapasitesi, eri\u015fim modlar\u0131 (\u00f6rne\u011fin, ReadWriteOnce, ReadOnlyMany) ve geri kazan\u0131m politikas\u0131 gibi \u00f6zelliklerini belirtir.<\/li>\n
- Persistent Volume Claim (PVC) Olu\u015fturma:<\/strong> Ard\u0131ndan, uygulaman\u0131z\u0131n bu depolama alan\u0131na eri\u015fmek i\u00e7in bir PVC olu\u015fturmas\u0131 gerekir. PVC, uygulaman\u0131n ihtiya\u00e7 duydu\u011fu depolama kapasitesi ve eri\u015fim modlar\u0131n\u0131 belirtir. Kubernetes, bu PVC’yi mevcut bir PV ile e\u015fle\u015ftirmeye \u00e7al\u0131\u015f\u0131r. E\u015fle\u015fme bulundu\u011funda, PVC bir PV’ye ba\u011flan\u0131r.<\/li>\n
- Deployment’ta PVC Kullan\u0131m\u0131:<\/strong> Deployment’\u0131n\u0131zdaki pod tan\u0131m\u0131nda, bu PVC’yi bir volume olarak belirtirsiniz. B\u00f6ylece, pod ba\u015flat\u0131ld\u0131\u011f\u0131nda, PVC’ye ba\u011fl\u0131 olan PV, pod i\u00e7indeki belirli bir dizine ba\u011flan\u0131r.<\/li>\n<\/ol>\n
Bu yakla\u015f\u0131m sayesinde, Deployment’taki bir pod yeniden ba\u015flat\u0131ld\u0131\u011f\u0131nda veya hatta silinip yeniden olu\u015fturuldu\u011funda, yeni pod ayn\u0131 PVC’ye ve dolay\u0131s\u0131yla ayn\u0131 PV’ye ba\u011flan\u0131r. Bu da verilerin kaybolmamas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, bir web uygulamas\u0131n\u0131n kullan\u0131c\u0131 taraf\u0131ndan y\u00fcklenen dosyalar\u0131n\u0131 saklamak i\u00e7in bu y\u00f6ntemi kullanabilirsiniz. Dosyalar PV’de sakland\u0131\u011f\u0131 s\u00fcrece, web sunucusu pod’u de\u011fi\u015fse bile dosyalar\u0131n\u0131z eri\u015filebilir kal\u0131r.<\/p>\n
Ancak, bu yakla\u015f\u0131m\u0131n baz\u0131 s\u0131n\u0131rl\u0131l\u0131klar\u0131 vard\u0131r. Deployment’lar, pod’lara kararl\u0131 a\u011f kimlikleri veya s\u0131ral\u0131 ba\u015flatma\/durdurma garantisi vermez. Her pod, Kubernetes taraf\u0131ndan benzersiz bir IP adresi ve DNS ad\u0131 al\u0131r. E\u011fer bir pod yeniden ba\u015flat\u0131l\u0131rsa, yeni bir IP adresi ve DNS ad\u0131 alabilir. Bu durum, baz\u0131 durum bilgisi tutan uygulamalar i\u00e7in sorun yaratabilir. \u00d6rne\u011fin, bir veritaban\u0131 k\u00fcmesinde, d\u00fc\u011f\u00fcmlerin birbirini belirli IP adresleri veya DNS adlar\u0131 \u00fczerinden bulmas\u0131 gerekiyorsa, Deployment’lar bu senaryoda yetersiz kal\u0131r.<\/p>\n
Ayr\u0131ca, PV’ler genellikle tek bir pod taraf\u0131ndan ba\u011flanabilen (ReadWriteOnce eri\u015fim modu) \u015fekilde yap\u0131land\u0131r\u0131l\u0131r. E\u011fer birden fazla pod’un ayn\u0131 anda ayn\u0131 depolama birimine yazmas\u0131 gerekiyorsa, bu durum karma\u015f\u0131k hale gelir. Bu t\u00fcr senaryolar i\u00e7in daha geli\u015fmi\u015f depolama \u00e7\u00f6z\u00fcmleri veya farkl\u0131 orkestrasyon yakla\u015f\u0131mlar\u0131 gerekebilir.<\/p>\n
Neden StatefulSet’lere \u0130htiya\u00e7 Duyuyoruz? Ger\u00e7ek D\u00fcnya Senaryolar\u0131<\/h3>\n
Deployment’lar Persistent Volume’lar ile birlikte kullan\u0131ld\u0131\u011f\u0131nda verileri kal\u0131c\u0131 hale getirebilse de, durum bilgisi tutan uygulamalar\u0131n karma\u015f\u0131k gereksinimlerini kar\u015f\u0131lamakta yetersiz kal\u0131rlar. \u0130\u015fte bu noktada StatefulSet’ler devreye girer ve kritik \u00f6nem kazan\u0131r. StatefulSet’ler, durum bilgisi tutan uygulamalar\u0131n ihtiya\u00e7 duydu\u011fu kararl\u0131l\u0131\u011f\u0131, benzersiz kimli\u011fi ve kontroll\u00fc ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc sa\u011flamak i\u00e7in tasarlanm\u0131\u015ft\u0131r.<\/p>\n
Senaryo 1: Da\u011f\u0131t\u0131lm\u0131\u015f Veritaban\u0131 K\u00fcmesi (\u00d6rn: PostgreSQL K\u00fcmesi)<\/strong><\/p>\nBir PostgreSQL k\u00fcmesi kurdu\u011fumuzu d\u00fc\u015f\u00fcnelim. Bu k\u00fcmede birden fazla veritaban\u0131 sunucusu bulunur ve bunlar birbirleriyle ileti\u015fim kurarak veri tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flarlar. Bu t\u00fcr bir sistemde, her veritaban\u0131 sunucusunun kararl\u0131 bir kimli\u011fi ve kararl\u0131 bir depolama alan\u0131 olmas\u0131 esast\u0131r. E\u011fer bir veritaban\u0131 sunucusu yeniden ba\u015flat\u0131l\u0131rsa, di\u011fer sunucular\u0131n onu tan\u0131mas\u0131 ve k\u00fcme i\u00e7inde do\u011fru \u015fekilde yerini almas\u0131 gerekir. Deployment’lar bu garantiyi vermez. Her yeniden ba\u015flatma, sunucunun IP adresini ve DNS ad\u0131n\u0131 de\u011fi\u015ftirebilir, bu da k\u00fcme i\u00e7indeki ileti\u015fimi bozar.<\/p>\n
StatefulSet’ler bu sorunu \u015fu \u015fekilde \u00e7\u00f6zer:<\/p>\n
\n- Her PostgreSQL sunucusu,
db-0<\/code>, db-1<\/code>, db-2<\/code> gibi benzersiz ve kararl\u0131 bir isme sahip olur.<\/li>\n- Her sunucu, kendi \u00f6zel Persistent Volume’una ba\u011flan\u0131r. B\u00f6ylece,
db-0<\/code>‘\u0131n verileri her zaman db-0<\/code>‘\u0131n PV’sinde saklan\u0131r.<\/li>\n- Kubernetes, pod’lar\u0131 s\u0131ral\u0131 olarak ba\u015flat\u0131r ve g\u00fcnceller. Bu, k\u00fcmenin kararl\u0131l\u0131\u011f\u0131n\u0131 korumaya yard\u0131mc\u0131 olur.<\/li>\n<\/ul>\n
Bu sayede, bir veritaban\u0131 sunucusu yeniden ba\u015flat\u0131lsa bile, di\u011fer sunucular onu kararl\u0131 kimli\u011fiyle tan\u0131r ve k\u00fcme sorunsuz \u00e7al\u0131\u015fmaya devam eder.<\/p>\n
Senaryo 2: Mesaj Kuyru\u011fu Sistemi (\u00d6rn: Kafka K\u00fcmesi)<\/strong><\/p>\nApache Kafka gibi mesaj kuyru\u011fu sistemleri, da\u011f\u0131t\u0131lm\u0131\u015f ve durum bilgisi tutan sistemlerdir. Kafka broker’lar\u0131n\u0131n (sunucular\u0131n\u0131n) k\u00fcme i\u00e7inde birbirini bulmas\u0131, veri replikasyonunu y\u00f6netmesi ve mesajlar\u0131 g\u00fcvenli bir \u015fekilde saklamas\u0131 gerekir. Bu i\u015flemler i\u00e7in broker’lar\u0131n kararl\u0131 kimliklere ve depolamaya ihtiyac\u0131 vard\u0131r.<\/p>\n
StatefulSet’ler, Kafka broker’lar\u0131n\u0131 y\u00f6netmek i\u00e7in idealdir:<\/p>\n
\n- Her Kafka broker’\u0131,
kafka-0<\/code>, kafka-1<\/code> gibi benzersiz ve kararl\u0131 bir isme sahip olur.<\/li>\n- Her broker, kendi \u00f6zel Persistent Volume’una ba\u011flanarak mesaj verilerini saklar.<\/li>\n
- StatefulSet’in s\u0131ral\u0131 ba\u015flatma ve \u00f6l\u00e7eklendirme \u00f6zellikleri, Kafka k\u00fcmesinin kararl\u0131l\u0131\u011f\u0131n\u0131 ve veri tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamaya yard\u0131mc\u0131 olur.<\/li>\n<\/ul>\n
Bu yap\u0131land\u0131rma, Kafka k\u00fcmesinin y\u00fcksek kullan\u0131labilirlik ve hata tolerans\u0131 sa\u011flamas\u0131n\u0131 m\u00fcmk\u00fcn k\u0131lar.<\/p>\n
Senaryo 3: Da\u011f\u0131t\u0131lm\u0131\u015f Anahtar-De\u011fer Deposu (\u00d6rn: etcd)<\/strong><\/p>\netcd, Kubernetes’in yap\u0131land\u0131rma verilerini saklamak i\u00e7in kulland\u0131\u011f\u0131 da\u011f\u0131t\u0131lm\u0131\u015f bir anahtar-de\u011fer deposudur. etcd’nin y\u00fcksek tutarl\u0131l\u0131k ve kullan\u0131labilirlik gerektirmesi, onu StatefulSet’ler i\u00e7in m\u00fckemmel bir aday yapar. etcd d\u00fc\u011f\u00fcmlerinin birbirini tan\u0131mas\u0131, veri replikasyonunu y\u00f6netmesi ve k\u00fcmenin genel durumunu korumas\u0131 gerekir.<\/p>\n
StatefulSet’ler, etcd d\u00fc\u011f\u00fcmlerini a\u015fa\u011f\u0131daki gibi y\u00f6netir:<\/p>\n
\n- Her etcd d\u00fc\u011f\u00fcm\u00fc,
etcd-0<\/code>, etcd-1<\/code> gibi kararl\u0131 bir isme ve a\u011f kimli\u011fine sahip olur.<\/li>\n- Her d\u00fc\u011f\u00fcm, kendi \u00f6zel Persistent Volume’una ba\u011flanarak etcd verilerini saklar.<\/li>\n
- StatefulSet’in garantiledi\u011fi s\u0131ral\u0131 da\u011f\u0131t\u0131m ve kimlik kararl\u0131l\u0131\u011f\u0131, etcd k\u00fcmesinin tutarl\u0131 ve g\u00fcvenilir \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar.<\/li>\n<\/ul>\n
Bu sayede, Kubernetes’in \u00e7ekirdek bile\u015fenleri olan etcd, g\u00fcvenli ve kararl\u0131 bir \u015fekilde \u00e7al\u0131\u015fabilir.<\/p>\n
Bu senaryolar, StatefulSet’lerin neden sadece “veri kal\u0131c\u0131l\u0131\u011f\u0131” sa\u011flaman\u0131n \u00f6tesine ge\u00e7ti\u011fini g\u00f6stermektedir. Onlar, durum bilgisi tutan uygulamalar\u0131n ihtiya\u00e7 duydu\u011fu karma\u015f\u0131k ya\u015fam d\u00f6ng\u00fcs\u00fc y\u00f6netimini, kararl\u0131 kimlikleri ve kontroll\u00fc etkile\u015fimleri sa\u011flamak i\u00e7in vazge\u00e7ilmezdir.<\/p>\n
StatefulSet’lerde Kararl\u0131 Kimlikler ve Depolama Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h3>\n
StatefulSet’lerin g\u00fcc\u00fc, durum bilgisi tutan uygulamalara sa\u011flad\u0131klar\u0131 kararl\u0131 kimlikler ve depolama mekanizmalar\u0131nda yatar. Bu iki \u00f6zellik, StatefulSet’leri Deployment’lardan ay\u0131ran temel farklard\u0131r ve durum bilgisi tutan uygulamalar\u0131n g\u00fcvenilir bir \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flarlar.<\/p>\n
Kararl\u0131 A\u011f Kimlikleri:<\/strong><\/p>\nBir StatefulSet olu\u015fturdu\u011funuzda, Kubernetes her bir pod’a benzersiz ve kal\u0131c\u0131 bir a\u011f kimli\u011fi atar. Bu kimlik, pod’un ad\u0131ndan ve DNS ad\u0131ndan olu\u015fur. \u00d6rne\u011fin, myapp<\/code> ad\u0131nda bir StatefulSet ve 3 replikas\u0131 varsa, pod’lar \u015fu \u015fekilde adland\u0131r\u0131l\u0131r:<\/p>\n\nmyapp-0<\/code><\/li>\nmyapp-1<\/code><\/li>\nmyapp-2<\/code><\/li>\n<\/ul>\nBu isimler, pod’un ya\u015fam d\u00f6ng\u00fcs\u00fc boyunca sabittir. Pod yeniden ba\u015flat\u0131lsa, \u00f6l\u00e7eklendirme i\u015flemiyle silinip yeniden olu\u015fturulsa bile, ayn\u0131 isimle geri d\u00f6ner. Bu durum, pod’un kendi DNS ad\u0131n\u0131n da sabit olmas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, myapp-0<\/code> pod’unun DNS ad\u0131, StatefulSet’in bulundu\u011fu alan ad\u0131yla birlikte (\u00f6rne\u011fin, myapp-0.myapp-service.default.svc.cluster.local<\/code>) her zaman ayn\u0131 kal\u0131r. Bu, pod’lar\u0131n birbirini veya d\u0131\u015f sistemleri belirli, de\u011fi\u015fmez isimler \u00fczerinden bulmas\u0131n\u0131 ve ileti\u015fim kurmas\u0131n\u0131 sa\u011flar. Bu \u00f6zellik, \u00f6zellikle da\u011f\u0131t\u0131lm\u0131\u015f sistemlerde, d\u00fc\u011f\u00fcmlerin birbirini tan\u0131mas\u0131 ve k\u00fcme i\u00e7indeki ileti\u015fimin kararl\u0131 olmas\u0131 gerekti\u011finde kritik \u00f6neme sahiptir.<\/p>\nKararl\u0131 Depolama:<\/strong><\/p>\nStatefulSet’ler, her pod i\u00e7in benzersiz ve kal\u0131c\u0131 depolama birimleri (Persistent Volumes) sa\u011flamak i\u00e7in VolumeClaimTemplates \u00f6zelli\u011fini kullan\u0131r. VolumeClaimTemplates, bir pod i\u00e7in Persistent Volume Claim (PVC) \u015fablonu tan\u0131mlar. StatefulSet, her pod i\u00e7in bu \u015fablondan bir PVC olu\u015fturur ve bu PVC’yi ilgili pod’a ba\u011flar.<\/p>\n
\u015e\u00f6yle bir \u00f6rnek d\u00fc\u015f\u00fcnelim:<\/p>\n
StatefulSet tan\u0131m\u0131nda \u015fu \u015fekilde bir VolumeClaimTemplates b\u00f6l\u00fcm\u00fc olabilir:<\/p>\n
\n spec:\n serviceName: \"myapp-service\"\n replicas: 3\n template:\n spec:\n containers:\n - name: myapp\n image: myapp-image\n volumeMounts:\n - name: data\n mountPath: \"\/app\/data\"\n volumeClaimTemplates:\n - metadata:\n name: data\n spec:\n accessModes: [ \"ReadWriteOnce\" ]\n resources:\n requests:\n storage: 1Gi\n <\/pre>\nBu yap\u0131land\u0131rma ile:<\/p>\n
\nmyapp-0<\/code> pod’u olu\u015fturuldu\u011funda, Kubernetes data-myapp-0<\/code> ad\u0131nda bir PVC olu\u015fturur ve bu PVC’yi uygun bir PV ile e\u015fle\u015ftirir. Bu PV, \/app\/data<\/code> dizinine ba\u011flan\u0131r.<\/li>\nmyapp-1<\/code> pod’u olu\u015fturuldu\u011funda, data-myapp-1<\/code> ad\u0131nda ayr\u0131 bir PVC olu\u015fturulur ve kendi PV’sine ba\u011flan\u0131r.<\/li>\nmyapp-2<\/code> pod’u olu\u015fturuldu\u011funda, data-myapp-2<\/code> ad\u0131nda ba\u015fka bir PVC olu\u015fturulur ve kendi PV’sine ba\u011flan\u0131r.<\/li>\n<\/ul>\nE\u011fer myapp-1<\/code> pod’u silinir ve yeniden olu\u015fturulursa, Kubernetes yine data-myapp-1<\/code> PVC’sini kullan\u0131r. Bu PVC, daha \u00f6nce myapp-1<\/code>‘e ba\u011fl\u0131 olan PV ile e\u015fle\u015ftirilir. Sonu\u00e7 olarak, myapp-1<\/code> pod’u yeniden ba\u015flat\u0131ld\u0131\u011f\u0131nda, \u00f6nceki verilerine eri\u015fmeye devam eder. Bu, verilerin pod’un ya\u015fam d\u00f6ng\u00fcs\u00fcnden ba\u011f\u0131ms\u0131z olarak korunmas\u0131n\u0131 sa\u011flar ve durum bilgisi tutan uygulamalar i\u00e7in hayati \u00f6nem ta\u015f\u0131r.<\/p>\nStatefulSet’lerin Y\u00f6netimi: Da\u011f\u0131t\u0131m, \u00d6l\u00e7eklendirme ve G\u00fcncelleme<\/h3>\n
StatefulSet’lerin sundu\u011fu bir di\u011fer \u00f6nemli avantaj, da\u011f\u0131t\u0131m, \u00f6l\u00e7eklendirme ve g\u00fcncelleme i\u015flemlerinin kontroll\u00fc ve s\u0131ral\u0131 bir \u015fekilde ger\u00e7ekle\u015ftirilmesidir. Bu \u00f6zellikler, durum bilgisi tutan uygulamalar\u0131n kararl\u0131l\u0131\u011f\u0131n\u0131 ve g\u00fcvenilirli\u011fini sa\u011flamak i\u00e7in tasarlanm\u0131\u015ft\u0131r.<\/p>\n
S\u0131ral\u0131 Da\u011f\u0131t\u0131m (Ordered Deployment):<\/strong><\/p>\nBir StatefulSet olu\u015fturuldu\u011funda, Kubernetes pod’lar\u0131 s\u0131ral\u0131 olarak ba\u015flat\u0131r. \u00d6rne\u011fin, 3 replikadan olu\u015fan bir StatefulSet i\u00e7in, pod’lar myapp-0<\/code>, ard\u0131ndan myapp-1<\/code>, sonra myapp-2<\/code> \u015feklinde ba\u015flat\u0131l\u0131r. Her pod’un ba\u015far\u0131yla ba\u015flat\u0131lmas\u0131 ve haz\u0131r hale gelmesi beklenir, ard\u0131ndan bir sonraki pod ba\u015flat\u0131l\u0131r. Bu s\u0131ral\u0131 ba\u015flatma, da\u011f\u0131t\u0131lm\u0131\u015f sistemlerde ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00f6netmek ve sistemin kararl\u0131 bir ba\u015flang\u0131\u00e7 durumuna ula\u015fmas\u0131n\u0131 sa\u011flamak i\u00e7in \u00f6nemlidir. \u00d6rne\u011fin, bir veritaban\u0131 k\u00fcmesinde, ilk ba\u015flat\u0131lan d\u00fc\u011f\u00fcm\u00fcn (db-0<\/code>) k\u00fcme lideri olarak atanmas\u0131 ve di\u011fer d\u00fc\u011f\u00fcmlerin (db-1<\/code>, db-2<\/code>) bu lidere ba\u011flanmas\u0131 gerekebilir. S\u0131ral\u0131 da\u011f\u0131t\u0131m, bu t\u00fcr senaryolar\u0131 kolayla\u015ft\u0131r\u0131r.<\/p>\nS\u0131ral\u0131 \u00d6l\u00e7eklendirme (Ordered Scaling):<\/strong><\/p>\nBir StatefulSet’in replika say\u0131s\u0131 de\u011fi\u015ftirildi\u011finde, \u00f6l\u00e7eklendirme i\u015flemi de s\u0131ral\u0131 olarak ger\u00e7ekle\u015fir. E\u011fer replika say\u0131s\u0131 art\u0131r\u0131l\u0131rsa, yeni pod’lar mevcut en y\u00fcksek numaral\u0131 pod’dan sonra s\u0131ral\u0131 olarak eklenir. \u00d6rne\u011fin, 3 replikadan 5 replikaya \u00e7\u0131k\u0131ld\u0131\u011f\u0131nda, myapp-3<\/code> ve myapp-4<\/code> pod’lar\u0131 s\u0131rayla ba\u015flat\u0131l\u0131r. Tersine, e\u011fer replika say\u0131s\u0131 azalt\u0131l\u0131rsa, en y\u00fcksek numaral\u0131 pod’lar (\u00f6rne\u011fin, myapp-4<\/code>, sonra myapp-3<\/code>) s\u0131ral\u0131 olarak durdurulur ve silinir. Bu, sistemin kararl\u0131l\u0131\u011f\u0131n\u0131 koruyarak ve veri tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flayarak \u00f6l\u00e7eklendirme i\u015fleminin g\u00fcvenli bir \u015fekilde yap\u0131lmas\u0131n\u0131 sa\u011flar.<\/p>\nS\u0131ral\u0131 G\u00fcncelleme (Ordered Updates):<\/strong><\/p>\nStatefulSet’lerde g\u00fcncellemeler de s\u0131ral\u0131 olarak ger\u00e7ekle\u015ftirilir. Kubernetes, StatefulSet’in updateStrategy<\/code> alan\u0131nda tan\u0131mlanan stratejiye g\u00f6re g\u00fcncellemeleri uygular. \u0130ki ana strateji vard\u0131r:<\/p>\n\n- RollingUpdate (Varsay\u0131lan):<\/strong> Bu stratejide, Kubernetes pod’lar\u0131 ters s\u0131ral\u0131 bir \u015fekilde g\u00fcnceller. Yani, en y\u00fcksek numaral\u0131 pod (\u00f6rne\u011fin,
myapp-2<\/code>) \u00f6nce g\u00fcncellenir, ard\u0131ndan myapp-1<\/code> ve son olarak myapp-0<\/code>. Her g\u00fcncelleme i\u015fleminde, eski pod durdurulur, yeni s\u00fcr\u00fcmle de\u011fi\u015ftirilir ve ba\u015flat\u0131l\u0131r. Bu, g\u00fcncellemeler s\u0131ras\u0131nda sistemin \u00e7al\u0131\u015f\u0131r durumda kalmas\u0131n\u0131 sa\u011flar.<\/li>\n- OnDelete:<\/strong> Bu stratejide, Kubernetes pod’lar\u0131 otomatik olarak g\u00fcncellemez. G\u00fcncelleme i\u015flemi, her pod manuel olarak silindi\u011finde ger\u00e7ekle\u015fir. Bu strateji, daha fazla kontrol gerektiren durumlar i\u00e7in uygundur, ancak daha fazla manuel m\u00fcdahale gerektirir.<\/li>\n<\/ul>\n
S\u0131ral\u0131 g\u00fcncelleme, \u00f6zellikle k\u00fcme i\u00e7indeki ba\u011f\u0131ml\u0131l\u0131klar\u0131n hassas oldu\u011fu durumlarda \u00f6nemlidir. \u00d6rne\u011fin, bir veritaban\u0131 k\u00fcmesinde, bir d\u00fc\u011f\u00fcm\u00fcn g\u00fcncellenmesi di\u011fer d\u00fc\u011f\u00fcmlerin \u00e7al\u0131\u015fma \u015feklini etkileyebilir. S\u0131ral\u0131 g\u00fcncelleme, bu etkileri en aza indirmeye yard\u0131mc\u0131 olur.<\/p>\n
Bu kontroll\u00fc y\u00f6netim \u00f6zellikleri, StatefulSet’leri, verilerin ve uygulaman\u0131n durumunun kritik oldu\u011fu durumlar i\u00e7in Deployment’lardan daha uygun bir se\u00e7enek haline getirir.<\/p>\n
Deployment’lar m\u0131, StatefulSet’ler mi? Ne Zaman Hangisini Kullanmal\u0131?<\/h3>\n
Bu noktaya kadar Deployment’lar ve StatefulSet’ler aras\u0131ndaki temel farklar\u0131 ve \u00f6zelliklerini inceledik. Peki, hangi durumda hangi kayna\u011f\u0131 kullanmal\u0131y\u0131z? Bu karar, b\u00fcy\u00fck \u00f6l\u00e7\u00fcde y\u00f6netmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131m\u0131z uygulaman\u0131n durum bilgisi tutma ihtiyac\u0131na ba\u011fl\u0131d\u0131r.<\/p>\n
Deployment’lar\u0131 Kullan\u0131n:<\/strong><\/p>\n\n- Durum Bilgisi Tutmayan Uygulamalar:<\/strong> E\u011fer uygulaman\u0131z her iste\u011fi ba\u011f\u0131ms\u0131z olarak i\u015fleyebiliyorsa ve \u00f6nceki isteklerden veya kendi durumundan ba\u011f\u0131ms\u0131zsa, Deployment’lar genellikle en iyi se\u00e7enektir. \u00d6rnekler: Web sunucular\u0131, API Gateway’ler, \u00f6n u\u00e7 uygulamalar\u0131, mikroservisler (e\u011fer kendi durumlar\u0131n\u0131 y\u00f6netmiyorlarsa).<\/li>\n
- Kolay \u00d6l\u00e7eklendirme ve G\u00fcncelleme \u0130htiyac\u0131:<\/strong> Durum bilgisi tutmayan uygulamalar genellikle daha s\u0131k \u00f6l\u00e7eklendirilir ve g\u00fcncellenir. Deployment’lar bu i\u015flemleri h\u0131zl\u0131 ve verimli bir \u015fekilde ger\u00e7ekle\u015ftirir.<\/li>\n
- Y\u00fcksek Eri\u015filebilirlik ve Hata Tolerans\u0131:<\/strong> Durum bilgisi tutmayan uygulamalar, bir pod’un kaybolmas\u0131 durumunda genellikle kolayca telafi edilebilir. Deployment’lar, pod’lar\u0131 otomatik olarak yeniden ba\u015flatarak y\u00fcksek eri\u015filebilirli\u011fi sa\u011flar.<\/li>\n
- Basit Veri Kal\u0131c\u0131l\u0131\u011f\u0131:<\/strong> E\u011fer uygulaman\u0131z\u0131n verilerini kal\u0131c\u0131 hale getirmeniz gerekiyorsa, ancak pod’lar\u0131n kararl\u0131 kimliklere veya s\u0131ral\u0131 y\u00f6netime ihtiyac\u0131 yoksa, Deployment’lar\u0131 Persistent Volume’lar ile birlikte kullanabilirsiniz.<\/li>\n<\/ul>\n
StatefulSet’leri Kullan\u0131n:<\/strong><\/p>\n\n- Durum Bilgisi Tutan Uygulamalar:<\/strong> Uygulaman\u0131z\u0131n \u00e7al\u0131\u015f\u0131rken belirli bir duruma sahip olmas\u0131 gerekiyorsa ve bu durumun korunmas\u0131 hayati \u00f6nem ta\u015f\u0131yorsa, StatefulSet’ler zorunludur. \u00d6rnekler: Veritabanlar\u0131 (PostgreSQL, MySQL, MongoDB), mesaj kuyruklar\u0131 (Kafka, RabbitMQ), da\u011f\u0131t\u0131lm\u0131\u015f \u00f6nbellekler (Redis Cluster), da\u011f\u0131t\u0131lm\u0131\u015f anahtar-de\u011fer depolar\u0131 (etcd, ZooKeeper).<\/li>\n
- Kararl\u0131 A\u011f Kimlikleri \u0130htiyac\u0131:<\/strong> Uygulaman\u0131zdaki d\u00fc\u011f\u00fcmlerin birbirini belirli, de\u011fi\u015fmez isimler \u00fczerinden bulmas\u0131 gerekiyorsa, StatefulSet’lerin kararl\u0131 a\u011f kimlikleri \u00f6zelli\u011fi kritiktir.<\/li>\n
- Kararl\u0131 Depolama \u0130htiyac\u0131:<\/strong> Her uygulaman\u0131n \u00f6rne\u011finin kendi \u00f6zel ve kal\u0131c\u0131 depolama alan\u0131na sahip olmas\u0131 gerekiyorsa, StatefulSet’lerin VolumeClaimTemplates \u00f6zelli\u011fi idealdir.<\/li>\n
- S\u0131ral\u0131 Da\u011f\u0131t\u0131m, \u00d6l\u00e7eklendirme ve G\u00fcncelleme Gereksinimi:<\/strong> Sisteminizin kararl\u0131 bir \u015fekilde da\u011f\u0131t\u0131lmas\u0131, \u00f6l\u00e7eklendirilmesi ve g\u00fcncellenmesi gerekiyorsa, StatefulSet’lerin sundu\u011fu s\u0131ral\u0131 y\u00f6netim \u00f6zellikleri vazge\u00e7ilmezdir.<\/li>\n
- Veri Tutarl\u0131l\u0131\u011f\u0131 ve Replikasyon Y\u00f6netimi:<\/strong> Da\u011f\u0131t\u0131lm\u0131\u015f sistemlerde veri tutarl\u0131l\u0131\u011f\u0131n\u0131 ve replikasyonu y\u00f6netmek i\u00e7in, d\u00fc\u011f\u00fcmlerin kararl\u0131 kimliklere ve depolamaya sahip olmas\u0131 gerekir. StatefulSet’ler bu gereksinimleri kar\u015f\u0131lar.<\/li>\n<\/ul>\n
\u00d6zetle, “Veri kal\u0131c\u0131ysa neden StatefulSet’lere ihtiya\u00e7 duyar\u0131z?” sorusunun cevab\u0131, sadece verinin kal\u0131c\u0131 olmas\u0131n\u0131n yeterli olmamas\u0131d\u0131r. Durum bilgisi tutan uygulamalar, verinin kal\u0131c\u0131l\u0131\u011f\u0131n\u0131n yan\u0131 s\u0131ra, kararl\u0131 kimliklere, kontroll\u00fc ya\u015fam d\u00f6ng\u00fclerine ve sistem i\u00e7indeki di\u011fer bile\u015fenlerle g\u00fcvenilir etkile\u015fimlere de ihtiya\u00e7 duyarlar. Bu ihtiya\u00e7lar\u0131 kar\u015f\u0131lamak i\u00e7in StatefulSet’ler, Deployment’lar\u0131n \u00f6tesinde bir \u00e7\u00f6z\u00fcm sunar.<\/p>\n
\u0130leri D\u00fczey Konular ve En \u0130yi Uygulamalar<\/h3>\n
StatefulSet’lerin g\u00fcc\u00fcnden tam olarak yararlanmak i\u00e7in baz\u0131 ileri d\u00fczey konular\u0131 ve en iyi uygulamalar\u0131 bilmek \u00f6nemlidir. Bu, hem performans\u0131n\u0131z\u0131 art\u0131racak hem de olas\u0131 sorunlar\u0131 \u00f6nlemenize yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n
1. G\u00fcncelleme Stratejileri (Update Strategies):<\/strong><\/p>\nYukar\u0131da bahsetti\u011fimiz RollingUpdate<\/code> ve OnDelete<\/code> stratejilerinin yan\u0131 s\u0131ra, StatefulSet’ler i\u00e7in daha geli\u015fmi\u015f g\u00fcncelleme stratejileri de mevcuttur. \u00d6rne\u011fin, Partitioned RollingUpdate<\/code> stratejisi, belirli bir say\u0131da pod’u ayn\u0131 anda g\u00fcncellemenize olanak tan\u0131r. Bu, b\u00fcy\u00fck k\u00fcme g\u00fcncellemelerinde daha kontroll\u00fc bir yakla\u015f\u0131m sunar. \u00d6rne\u011fin, 100 replikal\u0131 bir StatefulSet’te, yaln\u0131zca 10 tanesini ayn\u0131 anda g\u00fcncelleyerek olas\u0131 sorunlar\u0131n etkisini s\u0131n\u0131rlayabilirsiniz.<\/p>\n2. Pod Disruption Budgets (PDB):<\/strong><\/p>\nPDB’ler, bir uygulaman\u0131n belirli bir anda ka\u00e7 pod’unun \u00e7al\u0131\u015f\u0131r durumda olmas\u0131 gerekti\u011fini belirlemenizi sa\u011flar. Bu, \u00f6zellikle Kubernetes’in d\u00fc\u011f\u00fcm bak\u0131m\u0131 veya planl\u0131 olaylar s\u0131ras\u0131nda pod’lar\u0131 d\u00fc\u015f\u00fcrmesini engellemek i\u00e7in \u00f6nemlidir. StatefulSet’ler ile birlikte kullan\u0131ld\u0131\u011f\u0131nda, PDB’ler uygulaman\u0131z\u0131n kritik anlarda her zaman belirli say\u0131da \u00f6rne\u011fe sahip olmas\u0131n\u0131 garanti eder.<\/p>\n
\u00d6rnek PDB:<\/p>\n
\n apiVersion: policy\/v1\n kind: PodDisruptionBudget\n metadata:\n name: myapp-pdb\n spec:\n minAvailable: 2 # En az 2 pod her zaman \u00e7al\u0131\u015f\u0131r durumda olmal\u0131\n selector:\n matchLabels:\n app: myapp\n <\/pre>\n3. A\u011f Politikalar\u0131 (Network Policies):<\/strong><\/p>\nStatefulSet’lerle \u00e7al\u0131\u015fan uygulamalar\u0131n\u0131z\u0131n a\u011f trafi\u011fini y\u00f6netmek i\u00e7in Network Policies kullanmak \u00f6nemlidir. Bu, yaln\u0131zca izin verilen pod’lar\u0131n birbirleriyle ileti\u015fim kurabilmesini sa\u011flayarak g\u00fcvenlik duvar\u0131 g\u00f6revi g\u00f6r\u00fcr. \u00d6rne\u011fin, bir veritaban\u0131 StatefulSet’inin yaln\u0131zca belirli bir uygulaman\u0131n pod’lar\u0131 taraf\u0131ndan eri\u015filebilir olmas\u0131n\u0131 sa\u011flamak i\u00e7in bir Network Policy tan\u0131mlayabilirsiniz.<\/p>\n
4. Depolama Performans\u0131 ve Geri Kazan\u0131m Politikalar\u0131:<\/strong><\/p>\nStatefulSet’ler i\u00e7in kullan\u0131lan Persistent Volume’lar\u0131n performans\u0131, uygulaman\u0131z\u0131n performans\u0131n\u0131 do\u011frudan etkiler. Uygulaman\u0131z\u0131n I\/O gereksinimlerini kar\u015f\u0131layacak do\u011fru depolama s\u0131n\u0131f\u0131n\u0131 se\u00e7mek \u00f6nemlidir. Ayr\u0131ca, PV’lerin geri kazan\u0131m politikas\u0131 (Retain<\/code>, Delete<\/code>, Recycle<\/code>) de \u00f6nemlidir. Retain<\/code> politikas\u0131, bir PVC silindi\u011finde PV’nin verilerini saklar ve manuel olarak temizlenmesi gerekir. Bu, veri kayb\u0131n\u0131 \u00f6nlemek i\u00e7in genellikle tercih edilir.<\/p>\n5. G\u00f6zlem ve \u0130zleme (Observability):<\/strong><\/p>\nStatefulSet’lerle y\u00f6netilen uygulamalar\u0131n sa\u011fl\u0131\u011f\u0131n\u0131 ve performans\u0131n\u0131 izlemek kritiktir. Prometheus, Grafana gibi ara\u00e7larla metrikleri toplamak, loglar\u0131 analiz etmek ve uyar\u0131lar ayarlamak, olas\u0131 sorunlar\u0131 erken tespit etmenize ve \u00e7\u00f6zmenize yard\u0131mc\u0131 olur. \u00d6zellikle da\u011f\u0131t\u0131lm\u0131\u015f sistemlerde, her bir bile\u015fenin durumunu izlemek \u00f6nemlidir.<\/p>\n
Bu ileri d\u00fczey konular ve en iyi uygulamalar, StatefulSet’lerinizi daha verimli, g\u00fcvenli ve y\u00f6netilebilir hale getirmenize yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n
Sonu\u00e7: StatefulSet’ler Durum Bilgisi Tutman\u0131n Vazge\u00e7ilmezidir<\/h3>\n
Bu makalede, “E\u011fer veri kal\u0131c\u0131ysa neden StatefulSet’lere ihtiya\u00e7 duyar\u0131z?” sorusuna kapsaml\u0131 bir yan\u0131t arad\u0131k. Deployment’lar, Persistent Volume’lar ile birlikte kullan\u0131ld\u0131\u011f\u0131nda verileri kal\u0131c\u0131 hale getirebilse de, durum bilgisi tutan uygulamalar\u0131n karma\u015f\u0131k gereksinimlerini kar\u015f\u0131lamakta yetersiz kal\u0131rlar. StatefulSet’ler, kararl\u0131 a\u011f kimlikleri, kararl\u0131 depolama, s\u0131ral\u0131 da\u011f\u0131t\u0131m, \u00f6l\u00e7eklendirme ve g\u00fcncelleme gibi \u00f6zellikleriyle bu bo\u015flu\u011fu doldurur. Veritabanlar\u0131, mesaj kuyruklar\u0131 ve da\u011f\u0131t\u0131lm\u0131\u015f sistemler gibi durum bilgisi tutan uygulamalar i\u00e7in StatefulSet’ler, g\u00fcvenilirli\u011fi, tutarl\u0131l\u0131\u011f\u0131 ve y\u00f6netilebilirli\u011fi sa\u011flaman\u0131n vazge\u00e7ilmez bir yoludur. Veri kal\u0131c\u0131l\u0131\u011f\u0131 sadece bir ba\u015flang\u0131\u00e7 noktas\u0131d\u0131r; StatefulSet’ler, bu verilerin y\u00f6netildi\u011fi sistemin kendisinin de kararl\u0131 ve \u00f6ng\u00f6r\u00fclebilir olmas\u0131n\u0131 sa\u011flarlar.<\/p>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n\n- \n Soru:<\/strong> Bir Deployment’ta verileri kal\u0131c\u0131 hale getirmek i\u00e7in Persistent Volume kullan\u0131rsam, StatefulSet’e neden ihtiyac\u0131m olur?
\n
\n Cevap:<\/strong> Persistent Volume’lar verileri kal\u0131c\u0131 hale getirse de, Deployment’lar pod’lara kararl\u0131 a\u011f kimlikleri veya s\u0131ral\u0131 ya\u015fam d\u00f6ng\u00fcs\u00fc y\u00f6netimi garantisi vermez. Durum bilgisi tutan uygulamalar (veritabanlar\u0131, mesaj kuyruklar\u0131 vb.) bu kararl\u0131l\u0131\u011fa ihtiya\u00e7 duyar. StatefulSet’ler bu kararl\u0131l\u0131\u011f\u0131 sa\u011flar.\n <\/li>\n- \n Soru:<\/strong> StatefulSet’lerdeki pod isimleri neden her zaman ayn\u0131 kal\u0131r?
\n
\n Cevap:<\/strong> StatefulSet’ler, her pod’a benzersiz ve kal\u0131c\u0131 bir a\u011f kimli\u011fi atar. Bu kimlik, pod’un ad\u0131ndan ve DNS ad\u0131ndan olu\u015fur. Pod yeniden ba\u015flat\u0131lsa veya silinip yeniden olu\u015fturulsa bile, bu isim sabit kal\u0131r. Bu, da\u011f\u0131t\u0131lm\u0131\u015f sistemlerde d\u00fc\u011f\u00fcmlerin birbirini tan\u0131mas\u0131 i\u00e7in kritiktir.\n <\/li>\n- \n Soru:<\/strong> StatefulSet’lerdeki veriler silinir mi?
\n
\n Cevap:<\/strong> StatefulSet’ler, VolumeClaimTemplates kullanarak her pod i\u00e7in ayr\u0131 Persistent Volume’lar olu\u015fturur. Pod silinse bile, ba\u011fl\u0131 oldu\u011fu Persistent Volume’daki veriler, geri kazan\u0131m politikas\u0131na ba\u011fl\u0131 olarak (genellikle Retain<\/code> ile) saklan\u0131r. Veriler ancak Persistent Volume da silinirse kaybolur.\n <\/li>\n- \n Soru:<\/strong> StatefulSet’lerde bir g\u00fcncelleme s\u0131ras\u0131nda t\u00fcm pod’lar ayn\u0131 anda m\u0131 g\u00fcncellenir?
\n
\n Cevap:<\/strong> Varsay\u0131lan olarak, StatefulSet’lerde RollingUpdate<\/code> stratejisi kullan\u0131l\u0131r. Bu stratejide, pod’lar ters s\u0131ral\u0131 bir \u015fekilde (en y\u00fcksek numaral\u0131dan ba\u015flayarak) g\u00fcncellenir. Bu, g\u00fcncellemeler s\u0131ras\u0131nda sistemin \u00e7al\u0131\u015f\u0131r durumda kalmas\u0131n\u0131 sa\u011flar.\n <\/li>\n<\/ul>\n#Kubernetes #StatefulSet #Deployment #Konteyner #DevOps #BulutBili\u015fim<\/p>\n