Kubernetes ortamlar\u0131nda uygulama konfig\u00fcrasyonlar\u0131n\u0131 y\u00f6netmek, \u00f6zellikle dinamik ve s\u00fcrekli de\u011fi\u015fen ihtiya\u00e7lar s\u00f6z konusu oldu\u011funda \u00f6nemli bir zorluktur. Geleneksel yakla\u015f\u0131mlar genellikle bir konfig\u00fcrasyon de\u011fi\u015fikli\u011fi sonras\u0131 uygulaman\u0131n veya podun yeniden ba\u015flat\u0131lmas\u0131n\u0131 gerektirir, bu da hizmet kesintilerine yol a\u00e7abilir. Ancak, Kubernetes’in sundu\u011fu g\u00fc\u00e7l\u00fc \u00f6zellikler sayesinde, podlar\u0131 yeniden ba\u015flatmaya gerek kalmadan ConfigMap’ler arac\u0131l\u0131\u011f\u0131yla konfig\u00fcrasyonlar\u0131 otomatik olarak g\u00fcncelleyebilir ve kesintisiz bir deneyim sa\u011flayabilirsiniz. Bu rehberde, ConfigMap’lerin volume mount mekanizmas\u0131 kullan\u0131larak podlar \u00fczerinde nas\u0131l canl\u0131 olarak g\u00fcncellenebilece\u011fini ad\u0131m ad\u0131m ele alaca\u011f\u0131z.<\/p>\n
Modern bulut yerel uygulamalar genellikle mikroservis mimarisine dayan\u0131r ve s\u00fcrekli entegrasyon\/s\u00fcrekli da\u011f\u0131t\u0131m (CI\/CD) s\u00fcre\u00e7leriyle desteklenir. Bu dinamik ortamda, bir uygulaman\u0131n davran\u0131\u015f\u0131n\u0131 etkileyen konfig\u00fcrasyon ayarlar\u0131n\u0131 de\u011fi\u015ftirmek s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan bir ihtiya\u00e7t\u0131r. \u00d6rne\u011fin, bir veritaban\u0131 ba\u011flant\u0131 dizesi, bir API anahtar\u0131, loglama seviyesi veya bir feature flag (\u00f6zellik bayra\u011f\u0131) gibi parametreler zaman zaman g\u00fcncellenmeyi gerektirebilir. Peki, her k\u00fc\u00e7\u00fck konfig\u00fcrasyon de\u011fi\u015fikli\u011fi i\u00e7in uygulaman\u0131z\u0131 bar\u0131nd\u0131ran Kubernetes podlar\u0131n\u0131 yeniden ba\u015flatmak ne anlama gelir? Bu, genellikle hizmet kesintisi, ge\u00e7ici eri\u015fim sorunlar\u0131 ve genel kullan\u0131c\u0131 deneyiminde bozulma demektir. Y\u00fcksek eri\u015filebilirlik (High Availability) ve i\u015f s\u00fcreklili\u011fi (Business Continuity) hedeflenen sistemlerde, bu t\u00fcr kesintiler kabul edilemez bir maliyete sahip olabilir.<\/p>\n
G\u00fcn\u00fcm\u00fcz\u00fcn rekabet\u00e7i dijital d\u00fcnyas\u0131nda, kullan\u0131c\u0131lar\u0131n beklentileri her zamankinden daha y\u00fcksek. Uygulamalar\u0131n 7\/24 kesintisiz \u00e7al\u0131\u015fmas\u0131, performans\u0131n her zaman \u00fcst d\u00fczeyde olmas\u0131 ve yeni \u00f6zelliklerin h\u0131zla devreye al\u0131nabilmesi kritik \u00f6neme sahiptir. Bir konfig\u00fcrasyon de\u011fi\u015fikli\u011fi y\u00fcz\u00fcnden dakikalarca hatta saniyelerce dahi olsa hizmet d\u0131\u015f\u0131 kalmak, marka itibar\u0131na zarar verebilir ve potansiyel m\u00fc\u015fteri kayb\u0131na yol a\u00e7abilir. Bu nedenle, podlar\u0131 yeniden ba\u015flatmadan konfig\u00fcrasyon g\u00fcncelleme<\/strong> yetene\u011fi, operasyonel verimlilik, maliyet tasarrufu ve kullan\u0131c\u0131 memnuniyeti a\u00e7\u0131s\u0131ndan hayati bir \u00f6neme sahiptir. Bu y\u00f6ntem, \u00f6zellikle A\/B testleri, b\u00f6lgesel ayar de\u011fi\u015fiklikleri veya anl\u0131k hata ay\u0131klama (debugging) senaryolar\u0131 gibi dinamik ortamlarda b\u00fcy\u00fck avantajlar sa\u011flar. B\u00f6ylece, DevOps ekipleri daha \u00e7evik hale gelir, da\u011f\u0131t\u0131m s\u00fcre\u00e7leri h\u0131zlan\u0131r ve genel sistem kararl\u0131l\u0131\u011f\u0131 art\u0131r\u0131l\u0131r. Kesintisiz hizmet sunabilme yetene\u011fi, modern altyap\u0131 y\u00f6netiminin temel ta\u015flar\u0131ndan biri haline gelmi\u015ftir ve bu rehberde ele alaca\u011f\u0131m\u0131z y\u00f6ntem tam da bu ihtiyaca yan\u0131t vermektedir.<\/p>\n Konfig\u00fcrasyonlar\u0131 dinamik olarak y\u00f6netmenin inceliklerine dalmadan \u00f6nce, Kubernetes’in bu s\u00fcre\u00e7te kulland\u0131\u011f\u0131 temel yap\u0131 ta\u015flar\u0131n\u0131 iyi anlamam\u0131z gerekiyor. Bu iki kritik bile\u015fen, ConfigMap’ler ve Volume Mount’lar, uygulaman\u0131z\u0131n esnekli\u011fini art\u0131rmak ve operasyonel y\u00fck\u00fc azaltmak i\u00e7in birlikte \u00e7al\u0131\u015f\u0131r.<\/p>\n Bir ConfigMap<\/strong>, Kubernetes’te uygulama konfig\u00fcrasyonu verilerini depolamak i\u00e7in kullan\u0131lan bir API nesnesidir. Kodunuzdan konfig\u00fcrasyonlar\u0131 ay\u0131rarak, uygulamalar\u0131n\u0131z\u0131n ta\u015f\u0131nabilirli\u011fini ve y\u00f6netilebilirli\u011fini art\u0131rman\u0131za olanak tan\u0131r. ConfigMap’ler genellikle key-value \u00e7iftleri \u015feklinde verileri saklar ve bu veriler daha sonra podlara enjekte edilebilir. \u00d6rne\u011fin, bir veritaban\u0131 URL’si, bir API anahtar\u0131 veya bir uygulama ayar\u0131 gibi hassas olmayan konfig\u00fcrasyonlar\u0131 saklamak i\u00e7in idealdirler. Hassas veriler i\u00e7in Secret’lar tercih edilmelidir. ConfigMap’ler, uygulama mant\u0131\u011f\u0131 ile konfig\u00fcrasyonun ayr\u0131lmas\u0131n\u0131 sa\u011flayarak, ayn\u0131 uygulama imaj\u0131n\u0131n farkl\u0131 ortamlarda (geli\u015ftirme, test, \u00fcretim) farkl\u0131 konfig\u00fcrasyonlarla \u00e7al\u0131\u015fmas\u0131na imkan tan\u0131r. Bu, \u00f6zellikle mikroservis tabanl\u0131 mimarilerde b\u00fcy\u00fck kolayl\u0131k sa\u011flar.<\/p>\n ConfigMap’lerin avantajlar\u0131 saymakla bitmez:<\/p>\n \u0130\u015fte basit bir ConfigMap \u00f6rne\u011fi:<\/p>\n <\/code><\/p>\n G\u00f6rd\u00fc\u011f\u00fcn\u00fcz gibi, tek bir ConfigMap i\u00e7inde hem basit anahtar-de\u011fer \u00e7iftleri hem de tam bir dosya i\u00e7eri\u011fi (properties veya JSON format\u0131nda) saklanabilir.<\/p>\n Kubernetes'te bir Volume<\/strong>, bir pod i\u00e7indeki container'lar taraf\u0131ndan eri\u015filebilen veri dizinidir. Volume'ler, container'lar yeniden ba\u015flat\u0131lsa bile verilerin kal\u0131c\u0131 olmas\u0131n\u0131 sa\u011flar (belirli volume t\u00fcrleri i\u00e7in) ve container'lar aras\u0131nda veri payla\u015f\u0131m\u0131n\u0131 kolayla\u015ft\u0131r\u0131r. Volume Mount<\/strong> ise, bir volume'\u00fcn pod i\u00e7indeki bir container'\u0131n dosya sistemine belirli bir yola ba\u011flanmas\u0131 i\u015flemidir. \u0130\u015fte bu noktada ConfigMap'ler devreye girer.<\/p>\n Bir ConfigMap'i bir pod'a volume olarak ba\u011flad\u0131\u011f\u0131n\u0131zda, ConfigMap i\u00e7indeki her bir anahtar-de\u011fer \u00e7ifti, belirtilen mount yolunda ayr\u0131 bir dosya olarak g\u00f6r\u00fcn\u00fcr. Anahtar, dosyan\u0131n ad\u0131 olurken, de\u011fer dosyan\u0131n i\u00e7eri\u011fini olu\u015fturur. \u00d6rne\u011fin, yukar\u0131daki Bu mekanizma sayesinde, uygulamalar\u0131n\u0131z konfig\u00fcrasyonlar\u0131na do\u011frudan dosya sisteminden, t\u0131pk\u0131 lokal bir dosyay\u0131 okur gibi eri\u015febilirler. Bu, \u00f6zellikle mevcut uygulamalar\u0131 Kubernetes'e ta\u015f\u0131rken veya dosya tabanl\u0131 konfig\u00fcrasyon sistemlerine ba\u011f\u0131ml\u0131 uygulamalar geli\u015ftirirken b\u00fcy\u00fck bir avantaj sa\u011flar. Geleneksel sistemlerdeki konfig\u00fcrasyon dosyalar\u0131n\u0131 do\u011frudan ConfigMap'lere d\u00f6n\u00fc\u015ft\u00fcrebilir ve uygulamalar\u0131n\u0131z\u0131n mevcut dosya okuma mant\u0131\u011f\u0131n\u0131 koruyarak Kubernetes ortam\u0131na entegre edebilirsiniz.<\/p>\n ConfigMap'lerin podlara volume olarak nas\u0131l ba\u011fland\u0131\u011f\u0131n\u0131 anlad\u0131ktan sonra, as\u0131l sorumuz \u015fu: \"Peki bu ConfigMap'ler g\u00fcncellendi\u011finde, podlar bunlar\u0131 yeniden ba\u015flat\u0131lmadan nas\u0131l alg\u0131l\u0131yor?\" \u0130\u015fte bu sorunun cevab\u0131, Kubernetes'in alt\u0131nda yatan ak\u0131ll\u0131 mekanizmalarda gizlidir.<\/p>\n Kubernetes ortam\u0131nda, bir ConfigMap bir pod'a volume olarak ba\u011fland\u0131\u011f\u0131nda, asl\u0131nda arka planda belirli bir s\u00fcre\u00e7 devreye girer. Bu s\u00fcre\u00e7, temelde kubelet ad\u0131 verilen Kubernetes ajan\u0131n\u0131n ve sanal dosya sisteminin bir kombinasyonuyla \u00e7al\u0131\u015f\u0131r. Kubelet, her d\u00fc\u011f\u00fcmde (node) \u00e7al\u0131\u015fan ve podlar\u0131n ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc y\u00f6neten birincil arac\u0131d\u0131r. ConfigMap'leri volume olarak ba\u011flad\u0131\u011f\u0131n\u0131zda, kubelet bu verileri d\u00fc\u011f\u00fcm\u00fcn dosya sisteminde, genellikle Bu dizin, pod i\u00e7indeki container'a ba\u011flanan ger\u00e7ek volume'd\u00fcr. Kubelet, varsay\u0131lan olarak yakla\u015f\u0131k 60 saniyelik periyotlarla (bu s\u00fcre Kubelet'in bu otomatik g\u00fcncelleme davran\u0131\u015f\u0131 harikad\u0131r, ancak tek ba\u015f\u0131na yeterli de\u011fildir. Uygulaman\u0131z\u0131n bu dosya sistemi de\u011fi\u015fikliklerini fark etmesi ve konfig\u00fcrasyonu yeniden y\u00fcklemesi gerekir. \u0130\u015fte burada devreye uygulama katman\u0131ndaki mant\u0131k giriyor. Uygulamalar\u0131n\u0131z, ConfigMap g\u00fcncellemelerini alg\u0131lamak i\u00e7in genellikle iki temel strateji kullan\u0131r:<\/p>\n Bir\u00e7ok programlama dili ve framework'\u00fc, dosya sistemi izleme veya periyodik dosya okuma i\u00e7in yerle\u015fik k\u00fct\u00fcphaneler sunar. \u00d6rne\u011fin, Node.js'de Bu dinamik g\u00fcncelleme yetene\u011fi sayesinde, A\/B testleri, feature flag'lerin anl\u0131k olarak a\u00e7\u0131l\u0131p kapat\u0131lmas\u0131 veya log seviyelerinin \u00e7al\u0131\u015fma zaman\u0131nda de\u011fi\u015ftirilmesi gibi senaryolar, uygulaman\u0131n hizmet kesintisi ya\u015famadan kolayca ger\u00e7ekle\u015ftirilebilir. Bu, \u00f6zellikle h\u0131zl\u0131 tempolu geli\u015ftirme ve operasyon ortamlar\u0131nda \u00e7evikli\u011fi ve esnekli\u011fi art\u0131r\u0131r.<\/p>\n Teorik bilgileri peki\u015ftirmek ve konuyu pratik bir \u015fekilde kavramak i\u00e7in \u015fimdi ad\u0131m ad\u0131m bir \u00f6rnek \u00fczerinden ConfigMap'in nas\u0131l olu\u015fturuldu\u011funu, bir poda nas\u0131l ba\u011fland\u0131\u011f\u0131n\u0131 ve g\u00fcncellendi\u011finde podun bu de\u011fi\u015fikli\u011fi nas\u0131l alg\u0131lad\u0131\u011f\u0131n\u0131 inceleyelim. Bu \u00f6rnekte basit bir Node.js uygulamas\u0131n\u0131 kullanaca\u011f\u0131z, ancak prensipler di\u011fer diller i\u00e7in de ge\u00e7erlidir.<\/p>\n \u0130lk olarak, uygulamam\u0131z\u0131n kullanaca\u011f\u0131 konfig\u00fcrasyon verilerini i\u00e7eren bir ConfigMap olu\u015ftural\u0131m. Bu ConfigMap'te bir kar\u015f\u0131lama mesaj\u0131 ve bir s\u00fcr\u00fcm bilgisi tutaca\u011f\u0131z.<\/p>\n <\/code><\/p>\n Bu ConfigMap'i Kubernetes k\u00fcmenize uygulamak i\u00e7in a\u015fa\u011f\u0131daki komutu kullan\u0131n:<\/p>\n <\/code><\/p>\n \u015eimdi, bu ConfigMap'i bir volume olarak ba\u011flayacak basit bir Node.js uygulamas\u0131n\u0131 i\u00e7eren bir Pod olu\u015ftural\u0131m. Uygulama, ba\u011flanan dosyalar\u0131 okuyacak ve HTTP iste\u011fi \u00fczerine i\u00e7eri\u011fini g\u00f6sterecek. Ayr\u0131ca, dosyalar\u0131n de\u011fi\u015fip de\u011fi\u015fmedi\u011fini kontrol etmek i\u00e7in basit bir mekanizma i\u00e7erecek.<\/p>\n \u00d6rnek Node.js uygulamam\u0131z ( <\/code><\/p>\n Bu Node.js uygulamas\u0131n\u0131 bir Docker imaj\u0131na d\u00f6n\u00fc\u015ft\u00fcrece\u011fiz. Basit bir Dockerfile:<\/p>\n <\/code><\/p>\n Bu Docker imaj\u0131n\u0131 olu\u015fturup Docker Hub'a (veya kendi \u00f6zel registry'nize) y\u00fcklemeniz gerekecek. \u00d6rne\u011fin, \u015eimdi Pod tan\u0131m\u0131n\u0131 olu\u015ftural\u0131m:<\/p>\n <\/code><\/p>\n Bu Pod'u da\u011f\u0131tmak i\u00e7in:<\/p>\n <\/code><\/p>\n Pod'un \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 kontrol edin:<\/p>\n <\/code><\/p>\n Pod loglar\u0131n\u0131 izleyerek konfig\u00fcrasyonun y\u00fcklendi\u011fini g\u00f6rebilirsiniz:<\/p>\n <\/code><\/p>\n Uygulaman\u0131n \u00e7\u0131kt\u0131s\u0131n\u0131 g\u00f6rmek i\u00e7in port y\u00f6nlendirme yapabilir ve taray\u0131c\u0131n\u0131zdan eri\u015febilirsiniz:<\/p>\n <\/code><\/p>\n Sonra taray\u0131c\u0131n\u0131zda \u015eimdi as\u0131l dinamik g\u00fcncelleme k\u0131sm\u0131na geliyoruz. ConfigMap'i de\u011fi\u015ftirelim ve pod'un nas\u0131l tepki verdi\u011fini g\u00f6zlemleyelim. ConfigMap'i do\u011frudan d\u00fczenlemek i\u00e7in <\/code><\/p>\n A\u00e7\u0131lan edit\u00f6rde <\/code><\/p>\n De\u011fi\u015fiklikleri kaydedip edit\u00f6rden \u00e7\u0131k\u0131n. Kubernetes, ConfigMap'teki bu de\u011fi\u015fikli\u011fi alg\u0131layacak ve yakla\u015f\u0131k 60 saniye i\u00e7inde (kubelet'in varsay\u0131lan polling s\u00fcresi) ba\u011fl\u0131 oldu\u011fu podun dosya sistemindeki ilgili dosyalar\u0131 g\u00fcncelleyecektir.<\/p>\n Pod'un loglar\u0131n\u0131 izlemeye devam edin:<\/p>\n <\/code><\/p>\n Bir s\u00fcre sonra, uygulaman\u0131z\u0131n \"Konfig\u00fcrasyon g\u00fcncellendi\" mesaj\u0131n\u0131 yeni de\u011ferlerle birlikte yazd\u0131rd\u0131\u011f\u0131n\u0131 g\u00f6rmelisiniz:<\/p>\n <\/code><\/p>\n Taray\u0131c\u0131n\u0131zdaki Dinamik ConfigMap g\u00fcncellemelerinin g\u00fcc\u00fc, \u00f6zellikle mikroservis mimarileri ve h\u0131zl\u0131 de\u011fi\u015fen i\u015f ihtiya\u00e7lar\u0131na sahip modern uygulamalar i\u00e7in kendini g\u00f6sterir. \u0130\u015fte bu tekni\u011fin ger\u00e7ek d\u00fcnyada kullan\u0131ld\u0131\u011f\u0131 baz\u0131 \u00f6nemli senaryolar ve potansiyel vaka analizleri:<\/p>\n Vaka Analizi:<\/strong> B\u00fcy\u00fck bir e-ticaret \u015firketi, yeni bir \u00f6deme y\u00f6ntemini belirli bir kullan\u0131c\u0131 grubuna (\u00f6rne\u011fin, t\u00fcm trafi\u011fin %10'una) sunmak istiyor. Geleneksel yakla\u015f\u0131mla, yeni \u00f6deme y\u00f6nteminin kodu ayr\u0131 bir da\u011f\u0131t\u0131m olarak devreye al\u0131n\u0131r ve eski s\u00fcr\u00fcmle de\u011fi\u015ftirilir, bu da riskli ve zaman al\u0131c\u0131d\u0131r. Dinamik ConfigMap'ler sayesinde, uygulaman\u0131n konfig\u00fcrasyonunda basit bir \"feature flag\" (\u00f6zellik bayra\u011f\u0131) tutulabilir ( Vaka Analizi:<\/strong> \u00dcretimde \u00e7al\u0131\u015fan bir mikroservis, bazen belirli bir hatay\u0131 gidermek i\u00e7in daha detayl\u0131 loglara ihtiya\u00e7 duyabilir. Normalde log seviyesini (\u00f6rne\u011fin INFO'dan DEBUG'a) de\u011fi\u015ftirmek i\u00e7in uygulaman\u0131n yeniden da\u011f\u0131t\u0131lmas\u0131 veya podun yeniden ba\u015flat\u0131lmas\u0131 gerekir. Bu, \u00f6zellikle kritik bir \u00fcretim hatas\u0131n\u0131 ara\u015ft\u0131r\u0131rken de\u011ferli zaman kayb\u0131na neden olabilir. Dinamik ConfigMap'ler ile, uygulaman\u0131n loglama \u00e7er\u00e7evesinin konfig\u00fcrasyonu (\u00f6rne\u011fin Log4j, Logback veya Python'\u0131n Vaka Analizi:<\/strong> Bir uygulaman\u0131n kulland\u0131\u011f\u0131 bir veritaban\u0131n\u0131n salt okunur (read-only) kopyas\u0131na veya bir yedekleme veritaban\u0131na ge\u00e7i\u015f yap\u0131lmas\u0131 gerekebilir. Veritaban\u0131 URL'si veya portu gibi hassas olmayan ba\u011flant\u0131 ayarlar\u0131 bir ConfigMap'te tutulabilir. Diyelim ki, birincil veritaban\u0131nda bir bak\u0131m \u00e7al\u0131\u015fmas\u0131 var ve uygulaman\u0131n ge\u00e7ici olarak salt okunur bir replikaya y\u00f6nlendirilmesi gerekiyor. Geleneksel olarak, bu bir da\u011f\u0131t\u0131m veya pod yeniden ba\u015flatma gerektirir. Ancak dinamik g\u00fcncellemelerle, ConfigMap'teki Vaka Analizi:<\/strong> Bir mikroservis, \u00e7e\u015fitli d\u0131\u015f API'lerle entegre olabilir ve bu API'lerin u\u00e7 nokta URL'leri veya zaman a\u015f\u0131m\u0131 (timeout) ayarlar\u0131 gibi parametreleri farkl\u0131 ortamlarda veya belirli durumlarda de\u011fi\u015febilir. \u00d6rne\u011fin, bir test API'sinden bir \u00fcretim API'sine ge\u00e7i\u015f yap\u0131lmas\u0131 gerekti\u011finde. ConfigMap'ler arac\u0131l\u0131\u011f\u0131yla bu API u\u00e7 noktalar\u0131n\u0131 dinamik olarak y\u00f6netebiliriz. Bir uygulama, entegre oldu\u011fu bir \u00f6deme sa\u011flay\u0131c\u0131n\u0131n API URL'sini bir ConfigMap'ten okuyabilir. Sa\u011flay\u0131c\u0131 URL'sini de\u011fi\u015ftirdi\u011finde veya test ortam\u0131ndan canl\u0131ya ge\u00e7i\u015f yap\u0131ld\u0131\u011f\u0131nda, ConfigMap'teki ilgili anahtar g\u00fcncellenir. Uygulama, bu de\u011fi\u015fikli\u011fi yakalayarak yeni API u\u00e7 noktas\u0131na otomatik olarak istek g\u00f6ndermeye ba\u015flar. Bu yakla\u015f\u0131m, \u00f6zellikle \u00e7oklu d\u0131\u015f entegrasyonu olan karma\u015f\u0131k sistemlerde, her bir entegrasyon de\u011fi\u015fikli\u011fi i\u00e7in tam bir da\u011f\u0131t\u0131m veya pod yeniden ba\u015flatma d\u00f6ng\u00fcs\u00fcnden ka\u00e7\u0131narak operasyonel y\u00fck\u00fc ve hata olas\u0131l\u0131\u011f\u0131n\u0131 azalt\u0131r.<\/p>\n Bu senaryolar, dinamik ConfigMap g\u00fcncellemelerinin yaln\u0131zca teknik bir \u00f6zellik olmad\u0131\u011f\u0131n\u0131, ayn\u0131 zamanda i\u015f \u00e7evikli\u011fi, operasyonel verimlilik ve m\u00fc\u015fteri memnuniyeti \u00fczerinde do\u011frudan olumlu bir etkisi oldu\u011funu g\u00f6stermektedir. Uygulama mimarilerini bu yetene\u011fi g\u00f6z \u00f6n\u00fcnde bulundurarak tasarlamak, DevOps pratiklerini bir sonraki seviyeye ta\u015f\u0131r.<\/p>\n ConfigMap'leri podlar\u0131 yeniden ba\u015flatmadan g\u00fcncelleme yetene\u011fi, operasyonel esneklik a\u00e7\u0131s\u0131ndan b\u00fcy\u00fck bir avantaj sa\u011flar. Ancak bu g\u00fcc\u00fc en verimli \u015fekilde kullanmak ve olas\u0131 sorunlardan ka\u00e7\u0131nmak i\u00e7in baz\u0131 ipu\u00e7lar\u0131 ve en iyi uygulamalar\u0131 g\u00f6z \u00f6n\u00fcnde bulundurmak \u00f6nemlidir.<\/p>\n Yukar\u0131daki \u00f6rnekte, konfig\u00fcrasyon de\u011fi\u015fikliklerini basit bir Bu izleyiciler, dosya i\u00e7eri\u011fi de\u011fi\u015fti\u011finde uygulaman\u0131za an\u0131nda bir olay (event) tetikleyerek konfig\u00fcrasyonu yeniden y\u00fcklemesini sa\u011flar. Ancak konfig\u00fcrasyonu yeniden y\u00fcklerken dikkat edilmesi gereken en \u00f6nemli nokta, graceful reload<\/strong> (hatas\u0131z yeniden y\u00fckleme) stratejisidir. Uygulaman\u0131z\u0131n aktif olarak i\u015fledi\u011fi istekleri kesintiye u\u011fratmadan yeni konfig\u00fcrasyonu devreye almas\u0131 gerekir. Bu genellikle, yeni konfig\u00fcrasyonla yeni bir i\u015f par\u00e7ac\u0131\u011f\u0131 (thread) veya ba\u011flant\u0131 havuzu olu\u015fturmak ve mevcut i\u015flemleri tamamlad\u0131ktan sonra eskilerini sonland\u0131rmak anlam\u0131na gelir. \u00d6rne\u011fin, bir veritaban\u0131 ba\u011flant\u0131 havuzunun konfig\u00fcrasyonu de\u011fi\u015fti\u011finde, mevcut ba\u011flant\u0131lar\u0131n i\u015flerini bitirmesine izin verilirken, yeni istekler g\u00fcncellenmi\u015f ba\u011flant\u0131 havuzuna y\u00f6nlendirilir.<\/p>\n ConfigMap'ler hassas olmayan konfig\u00fcrasyon verileri i\u00e7in tasarlanm\u0131\u015ft\u0131r. Parolalar, API anahtarlar\u0131 veya veritaban\u0131 kimlik bilgileri gibi hassas veriler asla ConfigMap'lerde saklanmamal\u0131d\u0131r. Bunun yerine, Kubernetes Secret'lar\u0131 kullan\u0131lmal\u0131d\u0131r. Secret'lar da benzer \u015fekilde podlara volume olarak ba\u011flanabilir, ancak hassas do\u011falar\u0131 gere\u011fi otomatik olarak g\u00fcncellenmezler. Bir Secret g\u00fcncellendi\u011finde, bu Secret'\u0131 kullanan podlar\u0131n yeniden ba\u015flat\u0131lmas\u0131 gerekir (veya yeniden olu\u015fturulmas\u0131), aksi takdirde eski Secret de\u011ferleri kullan\u0131lmaya devam eder. Bu, hassas verilerin g\u00fcvenli\u011fi i\u00e7in bilin\u00e7li bir tasar\u0131m karar\u0131d\u0131r.<\/p>\n Kubelet'in ConfigMap de\u011fi\u015fikliklerini yoklama (polling) aral\u0131\u011f\u0131 varsay\u0131lan olarak 60 saniyedir. Bu, en k\u00f6t\u00fc durumda, bir konfig\u00fcrasyon de\u011fi\u015fikli\u011finin uygulaman\u0131z taraf\u0131ndan alg\u0131lanmas\u0131n\u0131n bir dakikaya kadar s\u00fcrebilece\u011fi anlam\u0131na gelir. \u00c7o\u011fu senaryo i\u00e7in bu kabul edilebilir bir gecikmedir, ancak anl\u0131k tepki gerektiren durumlar i\u00e7in (\u00f6rne\u011fin DDoS sald\u0131r\u0131lar\u0131n\u0131 engellemek i\u00e7in an\u0131nda bir kara liste g\u00fcncellemesi) bu gecikme yeterli olmayabilir. Bu gibi durumlarda, daha geli\u015fmi\u015f konfig\u00fcrasyon y\u00f6netim sistemleri (\u00f6rne\u011fin Consul, etcd veya \u00f6zel operat\u00f6rler) veya do\u011frudan uygulama katman\u0131ndan API sunucusunu dinleyen \u00e7\u00f6z\u00fcmler de\u011ferlendirilebilir. Ayr\u0131ca, \u00e7ok say\u0131da ConfigMap'i s\u0131k s\u0131k g\u00fcncellemek, kubelet \u00fczerinde belirli bir y\u00fck olu\u015fturabilir; bu nedenle, yaln\u0131zca ger\u00e7ekten dinamik olmas\u0131 gereken konfig\u00fcrasyonlar\u0131 bu \u015fekilde y\u00f6netmek ak\u0131ll\u0131ca olacakt\u0131r.<\/p>\n Dinamik ConfigMap'ler harika olsa da, konfig\u00fcrasyon y\u00f6netimi i\u00e7in tek \u00e7\u00f6z\u00fcm de\u011fildir. Di\u011fer yakla\u015f\u0131mlar\u0131 da bilmek \u00f6nemlidir:<\/p>\n Her yakla\u015f\u0131m\u0131n kendi avantajlar\u0131 ve dezavantajlar\u0131 vard\u0131r. En iyi uygulama, uygulaman\u0131z\u0131n \u00f6zel ihtiya\u00e7lar\u0131na ve operasyonel karma\u015f\u0131kl\u0131\u011f\u0131na en uygun olan\u0131 se\u00e7mektir. \u00c7o\u011fu durumda, dinamik ConfigMap'ler basit ve etkili bir \u00e7\u00f6z\u00fcm sunar, ancak daha karma\u015f\u0131k senaryolar i\u00e7in di\u011fer ara\u00e7lar\u0131 ve stratejileri de\u011ferlendirmek gerekebilir.<\/p>\n Kubernetes'te podlar\u0131 yeniden ba\u015flatmadan ConfigMap'ler arac\u0131l\u0131\u011f\u0131yla konfig\u00fcrasyonlar\u0131 dinamik olarak g\u00fcncelleme yetene\u011fi, modern bulut yerel uygulama geli\u015ftirme ve da\u011f\u0131t\u0131m\u0131nda \u00f6nemli bir ad\u0131md\u0131r. Bu rehber boyunca, ConfigMap'lerin ve volume mount mekanizmas\u0131n\u0131n temel prensiplerini, kubelet'in arka planda nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ve uygulamalar\u0131n bu de\u011fi\u015fiklikleri nas\u0131l alg\u0131lay\u0131p tepki verebilece\u011fini ad\u0131m ad\u0131m ele ald\u0131k. Ayr\u0131ca, ger\u00e7ek d\u00fcnya senaryolar\u0131yla bu tekni\u011fin pratik de\u011ferini g\u00f6sterdik ve en iyi uygulamalar, g\u00fcvenlik hususlar\u0131 ve alternatif yakla\u015f\u0131mlar hakk\u0131nda \u00f6nemli ipu\u00e7lar\u0131 payla\u015ft\u0131k.<\/p>\n Bu dinamik konfig\u00fcrasyon y\u00f6netimi yakla\u015f\u0131m\u0131, \u00f6zellikle A\/B testleri, feature flag y\u00f6netimi, loglama seviyesi ayarlamalar\u0131 ve API u\u00e7 nokta de\u011fi\u015fiklikleri gibi anl\u0131k m\u00fcdahale veya esneklik gerektiren durumlar i\u00e7in vazge\u00e7ilmezdir. Uygulaman\u0131z\u0131n kesintisiz \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flarken, operasyonel y\u00fck\u00fc azalt\u0131r ve geli\u015ftirme ekiplerinin daha h\u0131zl\u0131 ve g\u00fcvenli bir \u015fekilde de\u011fi\u015fiklik yapmas\u0131na olanak tan\u0131r. Unutmay\u0131n, bu teknikten tam olarak faydalanmak i\u00e7in uygulaman\u0131z\u0131n konfig\u00fcrasyon de\u011fi\u015fikliklerini alg\u0131lay\u0131p sorunsuz bir \u015fekilde yeniden y\u00fckleyebilecek \u015fekilde tasarlanmas\u0131 kritik \u00f6neme sahiptir. Do\u011fru ara\u00e7lar ve stratejilerle, Kubernetes ortam\u0131n\u0131zda tam anlam\u0131yla dinamik ve esnek bir konfig\u00fcrasyon y\u00f6netimi elde edebilirsiniz.<\/p>\n 1. ConfigMap g\u00fcncellemeleri ne kadar s\u00fcrede pod'a yans\u0131r?<\/strong><\/p>\n Kubernetes, ConfigMap de\u011fi\u015fikliklerini varsay\u0131lan olarak yakla\u015f\u0131k 60 saniyede bir kontrol eder (kubelet'in varsay\u0131lan polling aral\u0131\u011f\u0131). Bu nedenle, bir ConfigMap de\u011fi\u015fikli\u011finin pod'a yans\u0131mas\u0131 genellikle birka\u00e7 saniye ile bir dakika aras\u0131nda s\u00fcrebilir. Uygulaman\u0131z\u0131n bu de\u011fi\u015fikli\u011fi alg\u0131lamas\u0131 ise sizin uygulama i\u00e7i dosya izleme veya periyodik kontrol mekanizman\u0131z\u0131n h\u0131z\u0131na ba\u011fl\u0131d\u0131r.<\/p>\n 2. ConfigMap'ler yerine neden Secret'lar\u0131 kullanam\u0131yorum?<\/strong><\/p>\n ConfigMap'ler hassas olmayan konfig\u00fcrasyon verileri i\u00e7in tasarlanm\u0131\u015ft\u0131r. Secret'lar ise parolalar, API anahtarlar\u0131 gibi hassas veriler i\u00e7in kullan\u0131l\u0131r ve daha g\u00fcvenli bir \u015fekilde saklan\u0131r. Ayr\u0131ca, Secret'lar volume olarak ba\u011fland\u0131\u011f\u0131nda ConfigMap'ler gibi otomatik olarak g\u00fcncellenmezler; bir Secret g\u00fcncellendi\u011finde, onu kullanan podun yeniden ba\u015flat\u0131lmas\u0131 (veya yeniden olu\u015fturulmas\u0131) gerekir. Bu, hassas verilerin yanl\u0131\u015fl\u0131kla a\u00e7\u0131\u011fa \u00e7\u0131kmas\u0131n\u0131 \u00f6nlemek i\u00e7in bilin\u00e7li bir g\u00fcvenlik tasar\u0131m\u0131d\u0131r.<\/p>\n 3. Uygulamam\u0131n ConfigMap de\u011fi\u015fikliklerini nas\u0131l alg\u0131lad\u0131\u011f\u0131ndan emin olabilirim?<\/strong><\/p>\n Uygulaman\u0131z\u0131n ConfigMap de\u011fi\u015fikliklerini alg\u0131lad\u0131\u011f\u0131ndan emin olmak i\u00e7in iki temel y\u00f6ntem vard\u0131r: Birincisi, dosya sistemi izleyicileri (\u00f6rne\u011fin Node.js'te 4. Kubernetes 1.11'den itibaren, 5. T\u00fcm konfig\u00fcrasyonlar\u0131m\u0131 ConfigMap'ler arac\u0131l\u0131\u011f\u0131yla m\u0131 y\u00f6netmeliyim?<\/strong><\/p>\n Hay\u0131r, t\u00fcm konfig\u00fcrasyonlar ConfigMap'ler arac\u0131l\u0131\u011f\u0131yla y\u00f6netilmek zorunda de\u011fildir. Hassas veriler i\u00e7in Secret'lar, pod'un kendi meta verileri veya kaynak limitleri i\u00e7in Downward API ve basit, nadiren de\u011fi\u015fen konfig\u00fcrasyonlar i\u00e7in ortam de\u011fi\u015fkenleri hala ge\u00e7erli se\u00e7eneklerdir. ConfigMap'ler, \u00f6zellikle uygulaman\u0131n yeniden ba\u015flat\u0131lmas\u0131n\u0131 gerektirmeden canl\u0131 olarak g\u00fcncellenmesi gereken, hassas olmayan ve uygulama davran\u0131\u015f\u0131n\u0131 dinamik olarak de\u011fi\u015ftiren konfig\u00fcrasyonlar i\u00e7in en uygun \u00e7\u00f6z\u00fcmd\u00fcr.<\/p>\n <\/body><\/p>\n","protected":false},"excerpt":{"rendered":"Kubernetes ortamlar\u0131nda uygulama konfig\u00fcrasyonlar\u0131n\u0131 y\u00f6netmek, \u00f6zellikle dinamik ve s\u00fcrekli de\u011fi\u015fen ihtiya\u00e7lar s\u00f6z konusu oldu\u011funda \u00f6nemli bir zorluktur. Geleneksel…","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1491],"tags":[],"class_list":{"0":"post-33962","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-kubernetes","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nTemel Kavramlar: ConfigMap ve Volume Mount Nedir ve Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h2>\n
ConfigMap Nedir? Konfig\u00fcrasyon Verilerinin Kalbi<\/h3>\n
\n
kubectl<\/code> komutlar\u0131yla kolayca olu\u015fturulabilir, g\u00fcncellenebilir ve silinebilirler.<\/li>\n<\/ul>\n\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: benim-uygulamam-config\ndata:\n uygulama.url: \"http:\/\/localhost:8080\"\n log.level: \"INFO\"\n timeout.saniye: \"30\"\n ozel.mesaj: |\n Bu, birden fazla sat\u0131r i\u00e7eren\n \u00f6zel bir konfig\u00fcrasyon mesaj\u0131d\u0131r.\n ayarlar.properties: |\n server.port=80\n debug.mode=true\n database.name=production_db\n ayarlar.json: |\n {\n \"api_key\": \"abc123xyz\",\n \"feature_x_enabled\": true\n }\n <\/pre>\nVolume Mount Nedir ve ConfigMap ile Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h3>\n
benim-uygulamam-config<\/code> ConfigMap'ini \/app\/config<\/code> yoluna ba\u011flarsan\u0131z:<\/p>\n\n
\/app\/config\/uygulama.url<\/code> dosyas\u0131 \"http:\/\/localhost:8080\" i\u00e7eri\u011fini bar\u0131nd\u0131r\u0131r.<\/li>\n\/app\/config\/log.level<\/code> dosyas\u0131 \"INFO\" i\u00e7eri\u011fini bar\u0131nd\u0131r\u0131r.<\/li>\n\/app\/config\/ayarlar.properties<\/code> dosyas\u0131, ConfigMap'teki \u00e7ok sat\u0131rl\u0131 properties i\u00e7eri\u011fini bar\u0131nd\u0131r\u0131r.<\/li>\n<\/ul>\nsubPath<\/code> \u00f6zelli\u011fini kullanarak sadece belirli bir ConfigMap anahtar\u0131n\u0131 (yani bir dosyay\u0131) mount edebilir ve b\u00f6ylece olas\u0131 dosya \u00e7ak\u0131\u015fmalar\u0131n\u0131 \u00f6nleyebilirsiniz.\n <\/div>\nConfigMap'i Dinamik Olarak G\u00fcncellemenin Mekanizmas\u0131 Nas\u0131l \u0130\u015fler?<\/h2>\n
\/var\/lib\/kubelet\/pods\/kubelet --sync-frequency<\/code> parametresiyle ayarlanabilir) API sunucusunu yoklayarak (polling) ba\u011flam\u0131\u015f oldu\u011fu ConfigMap'lerde herhangi bir de\u011fi\u015fiklik olup olmad\u0131\u011f\u0131n\u0131 kontrol eder. E\u011fer bir ConfigMap'te de\u011fi\u015fiklik tespit ederse, kubelet otomatik olarak bu de\u011fi\u015fiklikleri d\u00fc\u011f\u00fcmdeki ilgili dizine yans\u0131t\u0131r. Yani, ConfigMap g\u00fcncellendi\u011finde, kubelet bu g\u00fcncellemeyi alg\u0131lar ve ilgili dosya i\u00e7eri\u011fini disk \u00fczerinde g\u00fcnceller. Bu, uygulamam\u0131z\u0131n i\u00e7indeki dosya sisteminde, daha \u00f6nce ba\u011flanan ConfigMap verilerini i\u00e7eren dosyalar\u0131n i\u00e7eri\u011finin otomatik olarak de\u011fi\u015fti\u011fi anlam\u0131na gelir.<\/p>\nUygulama \u0130\u00e7inde Dosya \u0130zleme veya Periyodik Kontrol Stratejileri<\/h3>\n
\n
inotify<\/code>) kullan\u0131r. Bir dosya de\u011fi\u015fikli\u011fi alg\u0131land\u0131\u011f\u0131nda, uygulama hemen konfig\u00fcrasyonu yeniden y\u00fckler. Bu y\u00f6ntem, de\u011fi\u015fikliklere an\u0131nda tepki vermek isteyen uygulamalar i\u00e7in idealdir ve minimum gecikme sa\u011flar.<\/li>\nsubPath<\/code> \u00f6zelli\u011fini ConfigMap volume mount'lar\u0131nda kullanmaktan ka\u00e7\u0131n\u0131n, \u00e7\u00fcnk\u00fc subPath<\/code> ile ba\u011flanan volume'ler Kubernetes 1.11'den itibaren otomatik olarak g\u00fcncellenmez. T\u00fcm ConfigMap'i bir dizine ba\u011flay\u0131p i\u00e7indeki dosyalar\u0131 izlemek, dinamik g\u00fcncelleme i\u00e7in en g\u00fcvenilir yakla\u015f\u0131md\u0131r.\n <\/div>\nfs.watch()<\/code>, Python'da watchdog<\/code> k\u00fct\u00fcphanesi veya Java'da NIO.2 API'si bu t\u00fcr i\u015flevsellikleri sa\u011flar. Uygulaman\u0131z\u0131n bu de\u011fi\u015fiklikleri alg\u0131lamas\u0131 ve sorunsuz bir \u015fekilde yeni konfig\u00fcrasyonu uygulamas\u0131 i\u00e7in, \"graceful reload\" (hatas\u0131z yeniden y\u00fckleme) mekanizmalar\u0131n\u0131 do\u011fru bir \u015fekilde tasarlamak kritik \u00f6nem ta\u015f\u0131r. Bu, \u00f6rne\u011fin, mevcut isteklere hizmet vermeye devam ederken yeni gelen istekler i\u00e7in g\u00fcncellenmi\u015f konfig\u00fcrasyonu kullanmak anlam\u0131na gelebilir.<\/p>\nAd\u0131m Ad\u0131m Uygulama: Dinamik ConfigMap G\u00fcncellemesi Nas\u0131l Yap\u0131l\u0131r?<\/h2>\n
Ad\u0131m 1: ConfigMap Olu\u015fturma<\/h3>\n
\n# configmap.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: my-app-config\ndata:\n message: \"Merhaba Kubernetes D\u00fcnyas\u0131!\"\n version: \"1.0.0\"\n <\/pre>\n\nkubectl apply -f configmap.yaml\n <\/pre>\nAd\u0131m 2: Pod'u ConfigMap ile Konfig\u00fcre Etme<\/h3>\n
app.js<\/code>):<\/p>\n\n\/\/ app.js\nconst http = require('http');\nconst fs = require('fs');\nconst path = require('path');\n\nconst configDir = '\/etc\/config'; \/\/ ConfigMap'in ba\u011flanaca\u011f\u0131 dizin\nlet config = {};\n\nfunction loadConfig() {\n try {\n const messagePath = path.join(configDir, 'message');\n const versionPath = path.join(configDir, 'version');\n\n const message = fs.readFileSync(messagePath, 'utf8').trim();\n const version = fs.readFileSync(versionPath, 'utf8').trim();\n\n config = { message, version };\n console.log([${new Date().toISOString()}] Konfig\u00fcrasyon g\u00fcncellendi:<\/code>, config);\n } catch (err) {\n console.error([${new Date().toISOString()}] Konfig\u00fcrasyon y\u00fcklenirken hata olu\u015ftu:<\/code>, err.message);\n config = { message: 'Hata: Konfig\u00fcrasyon y\u00fcklenemedi', version: 'unknown' };\n }\n}\n\n\/\/ Ba\u015flang\u0131\u00e7ta konfig\u00fcrasyonu y\u00fckle\nloadConfig();\n\n\/\/ Her 5 saniyede bir konfig\u00fcrasyonu kontrol et (dosya i\u00e7eri\u011fini okuyarak)\n\/\/ Ger\u00e7ek uygulamalarda inotify gibi dosya izleyiciler daha efektif olabilir.\nsetInterval(loadConfig, 5000); \n\nconst server = http.createServer((req, res) => {\n res.writeHead(200, { 'Content-Type': 'text\/plain; charset=utf-8' });\n res.end(${config.message} (Versiyon: ${config.version})\\n<\/code>);\n});\n\nconst PORT = 8080;\nserver.listen(PORT, () => {\n console.log([${new Date().toISOString()}] Uygulama ${PORT} portunda \u00e7al\u0131\u015f\u0131yor.<\/code>);\n});\n <\/pre>\n\n# Dockerfile\nFROM node:18-alpine\nWORKDIR \/app\nCOPY package.json .\nRUN npm install\nCOPY app.js .\nEXPOSE 8080\nCMD [\"node\", \"app.js\"]\n <\/pre>\ndocker build -t yourusername\/my-dynamic-app:1.0 .<\/code> ve docker push yourusername\/my-dynamic-app:1.0<\/code>.<\/p>\n\n# pod.yaml\napiVersion: v1\nkind: Pod\nmetadata:\n name: dynamic-config-pod\n labels:\n app: my-dynamic-app\nspec:\n containers:\n - name: my-app-container\n image: yourusername\/my-dynamic-app:1.0 # Kendi Docker imaj\u0131n\u0131z\u0131n ad\u0131\n ports:\n - containerPort: 8080\n volumeMounts:\n - name: config-volume\n mountPath: \/etc\/config # ConfigMap'in ba\u011flanaca\u011f\u0131 dizin\n volumes:\n - name: config-volume\n configMap:\n name: my-app-config\n <\/pre>\n\nkubectl apply -f pod.yaml\n <\/pre>\n\nkubectl get pod dynamic-config-pod\n <\/pre>\n\nkubectl logs -f dynamic-config-pod\n <\/pre>\n\nkubectl port-forward dynamic-config-pod 8080:8080\n <\/pre>\nhttp:\/\/localhost:8080<\/code> adresine gidin. \"Merhaba Kubernetes D\u00fcnyas\u0131! (Versiyon: 1.0.0)\" \u00e7\u0131kt\u0131s\u0131n\u0131 g\u00f6rmelisiniz.<\/p>\nAd\u0131m 3: ConfigMap'i G\u00fcncelleme ve Sonucu G\u00f6zlemleme<\/h3>\n
kubectl edit<\/code> kullanabiliriz:<\/p>\n\nkubectl edit configmap my-app-config\n <\/pre>\nmessage<\/code> ve version<\/code> de\u011ferlerini g\u00fcncelleyin:<\/p>\n\n# configmap.yaml (G\u00fcncellenmi\u015f hali)\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: my-app-config\ndata:\n message: \"Merhaba Dinamik D\u00fcnya!\" # Mesaj g\u00fcncellendi\n version: \"1.1.0\" # Versiyon g\u00fcncellendi\n <\/pre>\n\nkubectl logs -f dynamic-config-pod\n <\/pre>\n\n...\n[2023-10-27T10:30:15.123Z] Uygulama 8080 portunda \u00e7al\u0131\u015f\u0131yor.\n[2023-10-27T10:30:20.123Z] Konfig\u00fcrasyon g\u00fcncellendi: { message: 'Merhaba Kubernetes D\u00fcnyas\u0131!', version: '1.0.0' }\n[2023-10-27T10:30:25.123Z] Konfig\u00fcrasyon g\u00fcncellendi: { message: 'Merhaba Kubernetes D\u00fcnyas\u0131!', version: '1.0.0' }\n... (yakla\u015f\u0131k 60 saniye sonra ConfigMap g\u00fcncellendikten sonra) ...\n[2023-10-27T10:31:05.123Z] Konfig\u00fcrasyon g\u00fcncellendi: { message: 'Merhaba Dinamik D\u00fcnya!', version: '1.1.0' }\n <\/pre>\nhttp:\/\/localhost:8080<\/code> adresini yeniledi\u011finizde ise \"Merhaba Dinamik D\u00fcnya! (Versiyon: 1.1.0)\" \u00e7\u0131kt\u0131s\u0131n\u0131 g\u00f6rmelisiniz. G\u00f6rd\u00fc\u011f\u00fcn\u00fcz gibi, podu yeniden ba\u015flatmadan konfig\u00fcrasyon ba\u015far\u0131yla g\u00fcncellendi! Bu, uygulamalar\u0131n\u0131z\u0131n kesintisiz bir \u015fekilde \u00e7al\u0131\u015fmaya devam ederken dinamik olarak ayarlanabilece\u011fi anlam\u0131na gelir.<\/p>\nGer\u00e7ek D\u00fcnya Senaryolar\u0131 ve Vaka Analizleri: Hangi Durumlarda Kullan\u0131l\u0131r?<\/h2>\n
A\/B Testi ve Feature Flag Y\u00f6netimi<\/h3>\n
payment.newMethod.enabled: \"false\"<\/code>). Canl\u0131 sistem \u00fczerinde, ConfigMap g\u00fcncellenerek bu bayrak \"true\"<\/code> yap\u0131l\u0131r ve trafik y\u00f6nlendirme mekanizmalar\u0131yla (\u00f6rne\u011fin bir servis mesh veya uygulama i\u00e7i mant\u0131k) %10'luk trafi\u011fe yeni \u00f6deme y\u00f6ntemi g\u00f6sterilir. Herhangi bir sorun olu\u015ftu\u011funda, bayrak an\u0131nda \"false\"<\/code> yap\u0131larak eski duruma geri d\u00f6n\u00fclebilir. Bu sayede, \u015firketin m\u00fchendislik ekibi podlar\u0131 yeniden ba\u015flatmaya gerek kalmadan, m\u00fc\u015fteri deneyiminde herhangi bir kesintiye yol a\u00e7madan yeni \u00f6zellikleri g\u00fcvenli bir \u015fekilde test edebilir ve devreye alabilir.<\/p>\nLog Seviyesi Ayarlamalar\u0131<\/h3>\n
logging<\/code> mod\u00fcl\u00fc) bir ConfigMap'ten okunacak \u015fekilde ayarlan\u0131r. Bir sorun an\u0131nda, bir DevOps m\u00fchendisi ConfigMap'teki log.level: \"INFO\"<\/code> anahtar\u0131n\u0131 log.level: \"DEBUG\"<\/code> olarak g\u00fcnceller. Uygulama, dosya sistemi izleyici veya periyodik kontrol mekanizmas\u0131 sayesinde bu de\u011fi\u015fikli\u011fi alg\u0131lar ve \u00e7al\u0131\u015fma zaman\u0131nda log seviyesini de\u011fi\u015ftirir. Hata ay\u0131klama tamamland\u0131\u011f\u0131nda, seviye tekrar INFO'ya \u00e7ekilerek disk ve performans y\u00fck\u00fc minimize edilir. Bu, kritik durumlarda sorun giderme s\u00fcresini \u00f6nemli \u00f6l\u00e7\u00fcde k\u0131salt\u0131r.<\/p>\nVeritaban\u0131 Ba\u011flant\u0131 Ayarlar\u0131 (Hassas Olmayanlar)<\/h3>\n
database.url<\/code> de\u011feri, yedek veritaban\u0131n\u0131n URL'si ile g\u00fcncellenebilir. Uygulama, bu de\u011fi\u015fikli\u011fi alg\u0131layarak yeni URL ile ba\u011flant\u0131 kurmaya ba\u015flar. B\u00f6ylece, kullan\u0131c\u0131lar kesinti ya\u015famadan hizmet almaya devam ederken, altyap\u0131 ekibi g\u00fcvenli bir \u015fekilde bak\u0131m \u00e7al\u0131\u015fmas\u0131n\u0131 ger\u00e7ekle\u015ftirebilir. Elbette, bu senaryo i\u00e7in hassas veritaban\u0131 kimlik bilgilerinin Secret'larda saklanmas\u0131 ve bu Secret'lar\u0131n do\u011frudan g\u00fcncellenmedi\u011fi unutulmamal\u0131d\u0131r.<\/p>\n\u00c7evresel De\u011fi\u015fkenlerin ve API U\u00e7 Noktalar\u0131n\u0131n Y\u00f6netimi<\/h3>\n
\u0130pu\u00e7lar\u0131 ve En \u0130yi Uygulamalar: Dinamik Konfig\u00fcrasyonu Daha Verimli Kullanma<\/h2>\n
Dosya \u0130zleyici K\u00fct\u00fcphaneleri ve Graceful Reload<\/h3>\n
setInterval<\/code> ile periyodik olarak kontrol ettik. Ancak ger\u00e7ek d\u00fcnya uygulamalar\u0131nda, daha reaktif ve verimli bir y\u00f6ntem olan dosya sistemi izleyicileri (file watchers) kullanmak tercih edilir. \u00c7o\u011fu programlama dili ve i\u015fletim sistemi, dosya de\u011fi\u015fikliklerini an\u0131nda bildiren API'ler veya k\u00fct\u00fcphaneler sunar:<\/p>\n\n
fs.watch()<\/code> veya chokidar<\/code> gibi k\u00fct\u00fcphaneler.<\/li>\nwatchdog<\/code> k\u00fct\u00fcphanesi.<\/li>\nWatchService<\/code>.<\/li>\nfsnotify<\/code> k\u00fct\u00fcphanesi.<\/li>\n<\/ul>\nG\u00fcvenlik Endi\u015feleri ve ConfigMap Hassasiyeti<\/h3>\n
Performans Etkileri ve S\u0131n\u0131rlamalar<\/h3>\n
Alternatif Konfig\u00fcrasyon Y\u00f6netimi Yakla\u015f\u0131mlar\u0131<\/h3>\n
\n
Sonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular<\/h3>\n
fs.watch<\/code>, Python'da watchdog<\/code>) kullanarak konfig\u00fcrasyon dosyalar\u0131ndaki de\u011fi\u015fiklikleri an\u0131nda yakalamak. \u0130kincisi, uygulaman\u0131z\u0131n belirli aral\u0131klarla (\u00f6rne\u011fin her 5-10 saniyede bir) konfig\u00fcrasyon dosyas\u0131n\u0131 okuyarak veya dosyan\u0131n son de\u011fi\u015ftirilme zaman\u0131n\u0131 kontrol ederek de\u011fi\u015fiklikleri alg\u0131lamas\u0131d\u0131r. Uygulama loglar\u0131na yans\u0131yan konfig\u00fcrasyon y\u00fckleme mesajlar\u0131n\u0131 takip etmek de do\u011frulama i\u00e7in iyi bir y\u00f6ntemdir.<\/p>\nsubPath<\/code> ile ConfigMap ba\u011flad\u0131\u011f\u0131mda dinamik g\u00fcncelleme neden \u00e7al\u0131\u015fm\u0131yor?<\/strong><\/p>\nsubPath<\/code> kullan\u0131larak bir ConfigMap'ten tek bir dosya olarak ba\u011flanan volume'ler, ConfigMap g\u00fcncellendi\u011finde otomatik olarak g\u00fcncellenmez. Bu, bir s\u0131n\u0131rlamad\u0131r. Dinamik g\u00fcncelleme yetene\u011finden yararlanmak i\u00e7in, ConfigMap'in tamam\u0131n\u0131 bir dizine volume olarak ba\u011flamal\u0131 ve uygulaman\u0131z\u0131n o dizindeki dosyalara do\u011frudan eri\u015fmesini sa\u011flamal\u0131s\u0131n\u0131z.<\/p>\n