Modern uygulama geli\u015ftirmenin ve da\u011f\u0131t\u0131m\u0131n\u0131n merkezinde, yap\u0131land\u0131rma ve hassas veri y\u00f6netimi yer al\u0131r. Peki, bir uygulaman\u0131n veritaban\u0131 ba\u011flant\u0131 bilgilerini, API anahtarlar\u0131n\u0131 veya farkl\u0131 ortamlara \u00f6zg\u00fc ayarlar\u0131n\u0131 g\u00fcvenli ve esnek bir \u015fekilde nas\u0131l y\u00f6netiriz? Bu kritik soru, genellikle geli\u015ftiricilerin ve operasyon ekiplerinin kar\u015f\u0131la\u015ft\u0131\u011f\u0131 en b\u00fcy\u00fck zorluklardan biridir. Yanl\u0131\u015f y\u00f6netim, g\u00fcvenlik a\u00e7\u0131klar\u0131na veya da\u011f\u0131t\u0131m kabuslar\u0131na yol a\u00e7abilir. Bu makalede, Kubernetes’in bu sorunlara getirdi\u011fi g\u00fc\u00e7l\u00fc \u00e7\u00f6z\u00fcmler olan ConfigMaps ve Secrets’\u0131 detayl\u0131 bir \u015fekilde inceleyece\u011fiz. S\u0131f\u0131rdan ba\u015flayarak, temel kavramlardan ger\u00e7ek d\u00fcnya senaryolar\u0131na ve ileri d\u00fczey en iyi pratiklere kadar ad\u0131m ad\u0131m ilerleyecek, uygulamalar\u0131n\u0131z\u0131 daha g\u00fcvenli ve y\u00f6netilebilir hale getirmenin yollar\u0131n\u0131 ke\u015ffedece\u011fiz.<\/p>\n
Uygulama geli\u015ftirme ser\u00fcveninde s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan bir durum, yaz\u0131l\u0131m\u0131n farkl\u0131 ortamlarda (geli\u015ftirme, test, \u00fcretim) farkl\u0131 davran\u0131\u015flar sergilemesini gerektiren yap\u0131land\u0131rma de\u011fi\u015fkenleridir. Bir veritaban\u0131n\u0131n adresi, bir API anahtar\u0131 veya bir hizmetin \u00e7al\u0131\u015fma zaman\u0131 parametreleri gibi bilgiler, uygulaman\u0131n kodundan ayr\u0131 tutulmal\u0131d\u0131r. Geleneksel yakla\u015f\u0131mlar genellikle bu bilgileri do\u011frudan kodun i\u00e7ine g\u00f6mmeyi (hardcoding), s\u00fcr\u00fcm kontrol sistemine yanl\u0131\u015fl\u0131kla y\u00fcklemeyi veya ortam de\u011fi\u015fkenleri olarak elle y\u00f6netmeyi i\u00e7erir. Bu y\u00f6ntemler, hem g\u00fcvenlik riskleri ta\u015f\u0131r hem de \u00f6l\u00e7eklenebilirlik ve s\u00fcrd\u00fcr\u00fclebilirlik a\u00e7\u0131s\u0131ndan ciddi sorunlara yol a\u00e7ar. \u00d6rne\u011fin, bir veritaban\u0131 \u015fifresi hardcode edildi\u011finde, bu \u015fifreyi de\u011fi\u015ftirmek i\u00e7in uygulaman\u0131n yeniden derlenmesi ve yeniden da\u011f\u0131t\u0131lmas\u0131 gerekir ki bu da ciddi bir operasyonel y\u00fck demektir. \u0130\u015fte tam bu noktada Kubernetes’in ConfigMaps ve Secrets devreye girer, bu sorunlara zarif ve g\u00fc\u00e7l\u00fc \u00e7\u00f6z\u00fcmler sunar.<\/p>\n
ConfigMaps: Uygulama Yap\u0131land\u0131rmalar\u0131n\u0131 Ay\u0131rmak \u0130\u00e7in Neden \u00d6nemlidir?<\/strong> ConfigMaps, hassas olmayan yap\u0131land\u0131rma verilerini anahtar-de\u011fer \u00e7iftleri veya yap\u0131land\u0131rma dosyalar\u0131 olarak depolaman\u0131n bir yoludur. Temel amac\u0131, uygulama kodunu ve yap\u0131land\u0131rmay\u0131 birbirinden ay\u0131rmakt\u0131r. Bu ayr\u0131m, uygulaman\u0131n yeniden olu\u015fturulmas\u0131na gerek kalmadan yap\u0131land\u0131rma de\u011fi\u015fikliklerinin yap\u0131labilmesini sa\u011flar. \u00d6rne\u011fin, bir mikroservisin g\u00fcnl\u00fckleme seviyesi, bir sunucunun port numaras\u0131 veya bir \u00f6zelli\u011fin a\u00e7\u0131l\u0131p kapanmas\u0131 gibi parametreler ConfigMaps’te tutulabilir. Kubernetes’teki Pod’lar, bu ConfigMaps’teki verilere ortam de\u011fi\u015fkenleri olarak veya Pod’a ba\u011flanan dosya sistemindeki birimler (volume) arac\u0131l\u0131\u011f\u0131yla eri\u015febilir. Bu esneklik, ayn\u0131 uygulama imaj\u0131n\u0131n farkl\u0131 ortamlarda farkl\u0131 davran\u0131\u015flar sergilemesine olanak tan\u0131r, b\u00f6ylece daha tutarl\u0131 ve g\u00fcvenilir da\u011f\u0131t\u0131m s\u00fcre\u00e7leri elde edilir. ConfigMaps’in i\u00e7eri\u011fi \u015fifrelenmez; bu nedenle hassas veriler asla ConfigMaps’te saklanmamal\u0131d\u0131r.<\/p>\n Secrets: Hassas Verileri G\u00fcvenli Bir \u015eekilde Nas\u0131l Saklar\u0131z?<\/strong> Secrets, ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 gibi, hassas verileri depolamak i\u00e7in tasarlanm\u0131\u015ft\u0131r. Veritaban\u0131 \u015fifreleri, API anahtarlar\u0131, OAuth token’lar\u0131 veya SSH anahtarlar\u0131 gibi bilgiler bu kategoriye girer. ConfigMaps’ten farkl\u0131 olarak Secrets, Kubernetes API sunucusunda depoland\u0131\u011f\u0131nda varsay\u0131lan olarak Base64 ile kodlan\u0131r ve etcd’de \u015fifrelenmi\u015f olarak tutulabilir (e\u011fer etcd \u015fifrelemesi do\u011fru yap\u0131land\u0131r\u0131lm\u0131\u015fsa). Bu, verilerin depoland\u0131\u011f\u0131 yerde belirli bir d\u00fczeyde koruma sa\u011flar. Ancak unutulmamal\u0131d\u0131r ki, Pod’lar bir Secret’a eri\u015fti\u011finde, bu veriler Pod’un belle\u011finde veya dosya sisteminde okunabilir formda bulunur. Bu nedenle Secrets y\u00f6netimi ek g\u00fcvenlik \u00f6nlemleri gerektirir. Pod’lar, t\u0131pk\u0131 ConfigMaps gibi, Secrets’a ortam de\u011fi\u015fkenleri veya birim ba\u011flamalar\u0131 arac\u0131l\u0131\u011f\u0131yla eri\u015febilir. Secrets’\u0131n temel felsefesi, uygulama kodunun veya da\u011f\u0131t\u0131m YAML dosyalar\u0131n\u0131n i\u00e7ine hassas verileri g\u00f6mmek yerine, bu verileri merkezi ve g\u00fcvenli bir \u015fekilde y\u00f6netmektir. Bu sayede, g\u00fcvenlik a\u00e7\u0131klar\u0131 en aza indirilir ve hassas verilerin yanl\u0131\u015f ellere ge\u00e7me riski azal\u0131r. K\u0131sacas\u0131, ConfigMaps ve Secrets, Kubernetes ortam\u0131nda yap\u0131land\u0131rma ve hassas veri y\u00f6netimi i\u00e7in vazge\u00e7ilmez iki ara\u00e7t\u0131r ve do\u011fru kullan\u0131ld\u0131\u011f\u0131nda uygulamalar\u0131n\u0131z\u0131n hem esnekli\u011fini hem de g\u00fcvenli\u011fini art\u0131r\u0131r.<\/p>\n ConfigMaps, Kubernetes k\u00fcmenizde uygulama yap\u0131land\u0131rmalar\u0131n\u0131 d\u0131\u015fsalla\u015ft\u0131rmak i\u00e7in g\u00fc\u00e7l\u00fc ve esnek bir ara\u00e7 sunar. Uygulamalar\u0131n statik veya dinamik olarak de\u011fi\u015febilen ayarlar\u0131n\u0131 koddan ay\u0131rmak, geli\u015ftirme ve operasyon s\u00fcre\u00e7lerini b\u00fcy\u00fck \u00f6l\u00e7\u00fcde basitle\u015ftirir. Hadi, bir ConfigMap’i nas\u0131l olu\u015fturaca\u011f\u0131m\u0131za ve bir Pod i\u00e7inde nas\u0131l kullanaca\u011f\u0131m\u0131za dair ad\u0131m ad\u0131m \u00f6rneklere g\u00f6z atal\u0131m. Bu sayede, uygulaman\u0131z\u0131n farkl\u0131 ortamlara g\u00f6re nas\u0131l kolayca yap\u0131land\u0131r\u0131labilece\u011fini daha net anlayacaks\u0131n\u0131z.<\/p>\n Bir ConfigMap Olu\u015fturma: Basit Bir Senaryo<\/strong><\/p>\n Diyelim ki bir web uygulaman\u0131z var ve bu uygulaman\u0131n g\u00fcnl\u00fckleme seviyesi ile bir kar\u015f\u0131lama mesaj\u0131n\u0131 farkl\u0131 ortamlarda de\u011fi\u015ftirmek istiyorsunuz. \u00d6ncelikle, bu yap\u0131land\u0131rma verilerini i\u00e7eren bir ConfigMap olu\u015ftural\u0131m. Bunun i\u00e7in bir YAML dosyas\u0131 kullanaca\u011f\u0131z:<\/p>\n <\/code><\/p>\n Bu YAML dosyas\u0131n\u0131 <\/code><\/p>\n Art\u0131k ConfigMap Verilerini Pod \u0130\u00e7inde Kullanma: Ortam De\u011fi\u015fkenleri ve Birim Ba\u011flamalar\u0131<\/strong><\/p>\n Olu\u015fturdu\u011fumuz bu ConfigMap'teki verileri bir Pod i\u00e7inde kullanman\u0131n iki temel yolu vard\u0131r: ortam de\u011fi\u015fkenleri olarak veya birim ba\u011flamalar\u0131 (volume mounts) arac\u0131l\u0131\u011f\u0131yla dosya olarak.<\/p>\n <\/code><\/p>\n Bu Pod tan\u0131m\u0131nda, <\/code><\/p>\n Yukar\u0131daki \u00f6rnekte, Ger\u00e7ek D\u00fcnya Senaryosu: Ortamlara G\u00f6re Farkl\u0131 Yap\u0131land\u0131rmalar<\/strong><\/p>\n \u015eirketinizde geli\u015ftirme, test ve \u00fcretim ortamlar\u0131 i\u00e7in ayn\u0131 uygulaman\u0131n farkl\u0131 yap\u0131land\u0131rmalara ihtiya\u00e7 duydu\u011funu varsayal\u0131m. Geli\u015ftirme ortam\u0131nda veritaban\u0131 adresi <\/code><\/p>\n Daha sonra, ilgili Pod'unuzu da\u011f\u0131t\u0131rken, hangi ortama da\u011f\u0131t\u0131m yap\u0131yorsan\u0131z o ortama ait ConfigMap'i kullanacak \u015fekilde Pod tan\u0131m\u0131n\u0131z\u0131 g\u00fcncelleyebilirsiniz. Bu yakla\u015f\u0131m, ayn\u0131 Docker imaj\u0131n\u0131 kullanarak farkl\u0131 ortamlarda farkl\u0131 davran\u0131\u015flar sergileyen uygulamalar da\u011f\u0131tman\u0131za olanak tan\u0131r, bu da CI\/CD s\u00fcre\u00e7lerini \u00f6nemli \u00f6l\u00e7\u00fcde basitle\u015ftirir ve hata potansiyelini azalt\u0131r.<\/p>\n G\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere, ConfigMaps Kubernetes'te yap\u0131land\u0131rma y\u00f6netimini olduk\u00e7a \u015feffaf ve y\u00f6netilebilir hale getiriyor. Uygulamalar\u0131n\u0131z\u0131n esnekli\u011fini art\u0131r\u0131rken, operasyonel y\u00fck\u00fcn\u00fcz\u00fc azaltarak daha verimli bir geli\u015ftirme ve da\u011f\u0131t\u0131m s\u00fcreci sunar.<\/p>\n Uygulamalar\u0131m\u0131z\u0131n d\u00fczg\u00fcn \u00e7al\u0131\u015fmas\u0131 i\u00e7in genellikle veritaban\u0131 \u015fifreleri, API anahtarlar\u0131, TLS sertifikalar\u0131 gibi hassas bilgilere ihtiya\u00e7 duyar\u0131z. Bu t\u00fcr verileri ConfigMaps gibi d\u00fcz metin olarak saklamak ciddi g\u00fcvenlik riskleri ta\u015f\u0131r. Kubernetes'in Secrets mekanizmas\u0131, bu hassas verileri g\u00fcvenli bir \u015fekilde depolamak ve Pod'lara eri\u015fim sa\u011flamak i\u00e7in tasarlanm\u0131\u015ft\u0131r. Ancak, \"g\u00fcvenli\" kavram\u0131n\u0131 do\u011fru anlamak ve Secrets'\u0131 en iyi pratiklerle kullanmak hayati \u00f6neme sahiptir. Hadi, bir Secret'\u0131 nas\u0131l olu\u015fturaca\u011f\u0131m\u0131za, kullanaca\u011f\u0131m\u0131za ve g\u00fcvenlik ipu\u00e7lar\u0131na bakal\u0131m.<\/p>\n Bir Secret Olu\u015fturma: Base64 Kodlamas\u0131 ve YAML Tan\u0131m\u0131<\/strong><\/p>\n Kubernetes Secrets, verileri do\u011frudan YAML i\u00e7inde d\u00fcz metin olarak de\u011fil, Base64 ile kodlanm\u0131\u015f olarak bekler. Bu, veriyi \"\u015fifrelemekten\" ziyade, onu okunaks\u0131z bir formata d\u00f6n\u00fc\u015ft\u00fcrmektir. Ger\u00e7ek \u015fifreleme, Kubernetes'in arka plan\u0131nda etcd depolamas\u0131nda devreye girer (e\u011fer do\u011fru yap\u0131land\u0131r\u0131lm\u0131\u015fsa). Bir \u00f6rnek \u00fczerinden gidelim: bir veritaban\u0131 kullan\u0131c\u0131 ad\u0131 ve \u015fifresi saklamak istiyoruz.<\/p>\n \u00d6ncelikle, hassas verilerimizi Base64 ile kodlayal\u0131m:<\/p>\n <\/code><\/p>\n \u015eimdi bu kodlanm\u0131\u015f de\u011ferleri kullanarak bir Secret YAML dosyas\u0131 olu\u015ftural\u0131m:<\/p>\n <\/code><\/p>\n Bu YAML dosyas\u0131n\u0131 <\/code><\/p>\n Uyar\u0131:<\/strong> Secret Verilerini Pod \u0130\u00e7inde Kullanma: Ortam De\u011fi\u015fkenleri ve Birim Ba\u011flamalar\u0131<\/strong><\/p>\n ConfigMaps'te oldu\u011fu gibi, Secrets da Pod'lar i\u00e7inde ortam de\u011fi\u015fkenleri veya birim ba\u011flamalar\u0131 arac\u0131l\u0131\u011f\u0131yla kullan\u0131labilir. Ancak, hassasiyetleri nedeniyle farkl\u0131 yakla\u015f\u0131mlar ve g\u00fcvenlik \u00f6nlemleri gerektirirler.<\/p>\n <\/code><\/p>\n Bu Pod tan\u0131m\u0131nda, <\/code><\/p>\n Bu \u00f6rnekte, G\u00fcvenlik Hususlar\u0131 ve En \u0130yi Pratikler<\/strong><\/p>\n Secrets, Kubernetes'in sundu\u011fu g\u00fc\u00e7l\u00fc bir g\u00fcvenlik arac\u0131d\u0131r ancak yanl\u0131\u015f kullan\u0131m ciddi risklere yol a\u00e7abilir. Yukar\u0131da bahsedilen en iyi pratikleri uygulayarak, hassas verilerinizi Kubernetes ortam\u0131nda g\u00fcvenli bir \u015fekilde y\u00f6netebilir ve uygulamalar\u0131n\u0131z\u0131n b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc koruyabilirsiniz.<\/p>\n ConfigMaps ve Secrets'\u0131n her birinin kendi ba\u015f\u0131na ne i\u015fe yarad\u0131\u011f\u0131n\u0131 g\u00f6rd\u00fck. Ancak as\u0131l g\u00fc\u00e7leri, karma\u015f\u0131k uygulama mimarilerinde birlikte ve entegre bir \u015fekilde kullan\u0131ld\u0131klar\u0131nda ortaya \u00e7\u0131kar. Ger\u00e7ek d\u00fcnya senaryolar\u0131nda, bu iki Kubernetes objesi genellikle yan yana \u00e7al\u0131\u015farak, uygulamalar\u0131n hem esnekli\u011fini hem de g\u00fcvenli\u011fini sa\u011flamak i\u00e7in kritik bir rol oynar. Bu b\u00f6l\u00fcmde, iki farkl\u0131 vaka analizi \u00fczerinden ConfigMaps ve Secrets'\u0131n ortak kullan\u0131m\u0131na odaklanaca\u011f\u0131z.<\/p>\n Modern uygulama geli\u015ftirmenin temel ta\u015flar\u0131ndan biri olan mikroservis mimarileri, genellikle \u00e7ok say\u0131da ba\u011f\u0131ms\u0131z servisten olu\u015fur. Her servis kendi yap\u0131land\u0131rma ayarlar\u0131n\u0131 ve bazen de hassas verilerini gerektirir. Bir e-ticaret platformunu ele alal\u0131m. Bu platformda \"\u00dcr\u00fcn Katalo\u011fu\", \"Kullan\u0131c\u0131 Y\u00f6netimi\" ve \"\u00d6deme\" gibi mikroservisler bulunur. Her servisin kendine \u00f6zg\u00fc ayarlar\u0131 (\u00f6rne\u011fin, API eri\u015fim limitleri, cache s\u00fcreleri) ve baz\u0131 ortak hassas verileri (\u00f6rne\u011fin, ana veritaban\u0131 ba\u011flant\u0131 bilgileri, d\u0131\u015f \u00f6deme sa\u011flay\u0131c\u0131s\u0131 API anahtarlar\u0131) olabilir.<\/p>\n Senaryo Detaylar\u0131:<\/strong><\/p>\n ConfigMaps ve Secrets Kullan\u0131m\u0131:<\/strong><\/p>\n <\/code><\/p>\n <\/code><\/p>\n <\/code>\n<\/ol>\n Deployment Tan\u0131m\u0131 \u00d6rne\u011fi (\u00dcr\u00fcn Katalo\u011fu Servisi):<\/strong><\/p>\n <\/code><\/p>\n Bu senaryoda, her mikroservis kendi yap\u0131land\u0131rma setini (ConfigMap) kullan\u0131rken, ortak veya servise \u00f6zg\u00fc hassas veriler (Secrets) g\u00fcvenli bir \u015fekilde y\u00f6netilir. Bu ayr\u0131m, her servisin ba\u011f\u0131ms\u0131z olarak g\u00fcncellenebilmesini, farkl\u0131 ortamlarda farkl\u0131 davran\u0131\u015flar sergileyebilmesini ve hassas verilerin yaln\u0131zca ilgili servislere a\u00e7\u0131lmas\u0131n\u0131 sa\u011flar.<\/p>\n S\u00fcrekli Entegrasyon\/S\u00fcrekli Da\u011f\u0131t\u0131m (CI\/CD) s\u00fcre\u00e7leri, yaz\u0131l\u0131m da\u011f\u0131t\u0131m\u0131n\u0131 otomatikle\u015ftirmek i\u00e7in kritik \u00f6neme sahiptir. Bu s\u00fcre\u00e7lerde, Kubernetes kaynaklar\u0131n\u0131 da\u011f\u0131t\u0131rken yap\u0131land\u0131rma ve hassas verilerin g\u00fcvenli bir \u015fekilde enjekte edilmesi gerekir. Bir CI\/CD pipeline'\u0131nda (\u00f6rne\u011fin Jenkins, GitLab CI, Argo CD) ConfigMaps ve Secrets'\u0131n nas\u0131l kullan\u0131ld\u0131\u011f\u0131na dair bir \u00f6rnek inceleyelim.<\/p>\n Senaryo Detaylar\u0131:<\/strong><\/p>\n ConfigMaps ve Secrets Kullan\u0131m\u0131:<\/strong><\/p>\n <\/code><\/p>\n <\/code>\n<\/ol>\n CI\/CD Pipeline Entegrasyonu:<\/strong><\/p>\n CI\/CD pipeline'\u0131nda, da\u011f\u0131t\u0131m a\u015famas\u0131nda, hedef ortama (\u00f6rne\u011fin 'prod') g\u00f6re ilgili ConfigMap ve Secret dosyalar\u0131 se\u00e7ilerek <\/code><\/p>\n Uygulama Pod'lar\u0131, Deployment tan\u0131m\u0131nda bu ConfigMap'leri ve Secrets'\u0131 ortam de\u011fi\u015fkenleri veya birim ba\u011flamalar\u0131 olarak referans g\u00f6sterir. Bu yakla\u015f\u0131m, CI\/CD pipeline'\u0131n\u0131n hassas verileri do\u011frudan i\u015flemesine gerek kalmadan g\u00fcvenli bir da\u011f\u0131t\u0131m yap\u0131lmas\u0131n\u0131 sa\u011flar. Veriler Kubernetes API'si arac\u0131l\u0131\u011f\u0131yla g\u00fcvenli bir \u015fekilde iletilir ve y\u00f6netilir. Bu sayede, g\u00fcvenlik a\u00e7\u0131klar\u0131 en aza indirilir, otomasyon s\u00fcre\u00e7leri h\u0131zlan\u0131r ve hata yapma olas\u0131l\u0131\u011f\u0131 azal\u0131r.<\/p>\n Bu vaka analizleri, ConfigMaps ve Secrets'\u0131n ger\u00e7ek d\u00fcnya senaryolar\u0131nda nas\u0131l tamamlay\u0131c\u0131 roller \u00fcstlendi\u011fini ve modern Kubernetes tabanl\u0131 uygulamalar\u0131n yap\u0131land\u0131rma ve hassas veri y\u00f6netimi ihtiya\u00e7lar\u0131n\u0131 nas\u0131l kar\u015f\u0131lad\u0131\u011f\u0131n\u0131 a\u00e7\u0131k\u00e7a g\u00f6stermektedir. Do\u011fru kullan\u0131ld\u0131klar\u0131nda, hem geli\u015ftirme verimlili\u011fini hem de operasyonel g\u00fcvenli\u011fi \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131rlar.<\/p>\n ConfigMaps ve Secrets'\u0131n temel i\u015flevleri ve kullan\u0131m senaryolar\u0131 olduk\u00e7a net olsa da, Kubernetes ekosisteminin derinliklerinde bu kaynaklar\u0131 daha etkin ve g\u00fcvenli kullanmak i\u00e7in ileri d\u00fczey teknikler ve en iyi pratikler mevcuttur. Uygulamalar\u0131n\u0131z\u0131n karma\u015f\u0131kl\u0131\u011f\u0131 artt\u0131k\u00e7a ve g\u00fcvenlik gereksinimleri y\u00fckseldik\u00e7e, bu konulara hakim olmak hayati \u00f6nem ta\u015f\u0131r. \u0130\u015fte daha deneyimli kullan\u0131c\u0131lar i\u00e7in baz\u0131 ipu\u00e7lar\u0131 ve p\u00fcf noktalar\u0131.<\/p>\n 1. ConfigMaps ve Secrets'\u0131n De\u011fi\u015fmezli\u011fi (Immutability): G\u00fcvenlik ve Tutarl\u0131l\u0131k \u0130\u00e7in Neden \u00d6nemli?<\/strong><\/p>\n Varsay\u0131lan olarak, bir ConfigMap veya Secret'\u0131 olu\u015fturduktan sonra i\u00e7eri\u011fini de\u011fi\u015ftirebilirsiniz. Bu de\u011fi\u015fiklikler, referans verilen Pod'lara otomatik olarak yans\u0131t\u0131lmaz; Pod'lar\u0131n yeniden ba\u015flat\u0131lmas\u0131 veya yeniden olu\u015fturulmas\u0131 gerekir (bu durum, volume mount ile kullan\u0131lan ConfigMaps i\u00e7in farkl\u0131l\u0131k g\u00f6sterebilir, ancak genellikle yeni bir deployment \u00f6nerilir). Yanl\u0131\u015fl\u0131kla yap\u0131lan de\u011fi\u015fiklikleri \u00f6nlemek ve da\u011f\u0131t\u0131mlar\u0131n tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamak i\u00e7in ConfigMaps ve Secrets'\u0131 de\u011fi\u015ftirilemez (immutable) olarak i\u015faretleyebilirsiniz.<\/p>\n <\/code><\/p>\n Bir kez 2. Otomatik G\u00fcncellemeler ve Rolling Updates: De\u011fi\u015fiklikleri Minimum Kesintiyle Uygulama<\/strong><\/p>\n ConfigMap veya Secret'ta yap\u0131lan bir de\u011fi\u015fiklik, varsay\u0131lan olarak ilgili Pod'lara otomatik olarak yans\u0131maz. Ortam de\u011fi\u015fkeni olarak kullan\u0131lan durumlarda Pod'un yeniden ba\u015flat\u0131lmas\u0131 (veya yeni bir Pod'un olu\u015fturulmas\u0131) gerekir. Volume mount olarak kullan\u0131lan ConfigMaps i\u00e7in ise, de\u011fi\u015fiklikler belirli bir gecikmeyle Pod'un i\u00e7indeki dosyalara yans\u0131yabilir (genellikle Bunu yapman\u0131n yayg\u0131n bir yolu, Deployment YAML'\u0131nda Pod \u015fablonunun ( <\/code><\/p>\n Bu \u00f6rnekte, Helm gibi bir \u015fablonlama arac\u0131 kullan\u0131larak ConfigMap veya Secret'\u0131n i\u00e7eri\u011finin SHA256 \u00f6zeti Pod \u015fablonuna bir annotation olarak eklenir. ConfigMap veya Secret de\u011fi\u015fti\u011finde, \u00f6zeti de de\u011fi\u015fir, bu da Pod \u015fablonunun kendisini de\u011fi\u015ftirir ve Kubernetes'in rolling update'i tetiklemesini sa\u011flar. Bu sayede uygulaman\u0131z, yap\u0131land\u0131rma de\u011fi\u015fikliklerini s\u0131f\u0131r kesintiyle alabilir.<\/p>\n 3. Harici Secret Y\u00f6netimi Entegrasyonu: Daha Y\u00fcksek G\u00fcvenlik ve Denetim<\/strong><\/p>\n Kubernetes Secrets, verileri etcd'de \u015fifrelenmi\u015f olarak tutsa da, Pod'lar i\u00e7inde veriler d\u00fcz metin halindedir. Ayr\u0131ca, Secret y\u00f6netimi Kubernetes k\u00fcmesi i\u00e7inde kal\u0131r. Y\u00fcksek g\u00fcvenlikli ortamlarda veya merkezi bir Secret y\u00f6netimi stratejisi gerektiren durumlarda, HashiCorp Vault, AWS Secrets Manager, Azure Key Vault veya Google Secret Manager gibi harici Secret y\u00f6netim \u00e7\u00f6z\u00fcmleriyle entegrasyon tercih edilir.<\/p>\n Bu entegrasyon genellikle Secret Store CSI Driver veya \u00f6zel operat\u00f6rler arac\u0131l\u0131\u011f\u0131yla yap\u0131l\u0131r. Secret Store CSI Driver, harici Secret y\u00f6neticilerinden hassas verileri al\u0131p bunlar\u0131 bir Kubernetes Pod'u i\u00e7inde volume olarak sunar. Bu, Secret'lar\u0131n Kubernetes API'sinde do\u011frudan tutulmas\u0131n\u0131 gerektirmez, b\u00f6ylece sald\u0131r\u0131 y\u00fczeyi azalt\u0131l\u0131r ve harici sistemlerin daha geli\u015fmi\u015f g\u00fcvenlik \u00f6zellikleri (dinamik Secret'lar, kapsaml\u0131 denetim g\u00fcnl\u00fckleri, daha g\u00fc\u00e7l\u00fc \u015fifreleme mekanizmalar\u0131) kullan\u0131labilir.<\/p>\n 4. Kubernetes RBAC ile Eri\u015fim Kontrol\u00fc: Kim Neye Eri\u015febilir?<\/strong><\/p>\n ConfigMaps ve \u00f6zellikle Secrets'a eri\u015fim, Kubernetes'in Rol Tabanl\u0131 Eri\u015fim Kontrol\u00fc (RBAC) mekanizmas\u0131 ile s\u0131k\u0131ca kontrol edilmelidir. Yaln\u0131zca belirli Pod'lara veya ServiceAccount'lara ihtiya\u00e7 duyduklar\u0131 ConfigMaps ve Secrets'\u0131 okuma izni verilmelidir. Geni\u015f yetkilere sahip olmak, g\u00fcvenlik risklerini art\u0131r\u0131r.<\/p>\n <\/code><\/p>\n Bu \u00f6rnek, 5. Mobile Uyumlu HTML \u00d6rnekleri: Teknik \u0130\u00e7eri\u011fi Her Yerde Okunabilir K\u0131lmak<\/strong><\/p>\n Her ne kadar makalenin kendisi Kubernetes konfig\u00fcrasyonu hakk\u0131nda olsa da, bu t\u00fcr teknik i\u00e7eriklerin \u00e7e\u015fitli cihazlarda (mobil dahil) okunabilir olmas\u0131 \u00f6nemlidir. Mobil uyumlu HTML, i\u00e7eri\u011finizin farkl\u0131 ekran boyutlar\u0131na ve \u00e7\u00f6z\u00fcn\u00fcrl\u00fcklerine uyum sa\u011flamas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, kod bloklar\u0131n\u0131 veya tablolar\u0131 mobil cihazlarda daha iyi g\u00f6r\u00fcnt\u00fclemek i\u00e7in CSS medya sorgular\u0131 kullan\u0131labilir:<\/p>\n <\/code><\/p>\n Bu CSS snippet'i, \u00f6zellikle kod bloklar\u0131n\u0131n ve tablolar\u0131n mobil ekranlarda daha d\u00fczenli g\u00f6r\u00fcnmesini sa\u011flar. Kod bloklar\u0131 yatay kayd\u0131rma \u00e7ubu\u011fu ile ta\u015fmay\u0131 \u00f6nlerken, tablolar her sat\u0131r\u0131 ve s\u00fctunu blok olarak g\u00f6stererek dikeyde daha iyi bir okuma deneyimi sunar.<\/p>\n Bu ileri d\u00fczey teknikler ve en iyi pratikler, Kubernetes ortam\u0131n\u0131zda ConfigMaps ve Secrets'\u0131 kullan\u0131rken g\u00fcvenlik, tutarl\u0131l\u0131k ve otomasyon seviyenizi art\u0131rman\u0131za yard\u0131mc\u0131 olacakt\u0131r. Unutmay\u0131n, iyi bir yap\u0131land\u0131rma y\u00f6netimi stratejisi, uygulaman\u0131z\u0131n ba\u015far\u0131s\u0131 i\u00e7in temeldir.<\/p>\n Bu makale boyunca, Kubernetes'in yap\u0131land\u0131rma ve hassas veri y\u00f6netimi i\u00e7in sundu\u011fu ConfigMaps ve Secrets mekanizmalar\u0131n\u0131 derinlemesine inceledik. Uygulama kodundan yap\u0131land\u0131rma ve hassas verileri ay\u0131rman\u0131n ne kadar kritik oldu\u011funu, bunun neden g\u00fcvenlik, esneklik ve s\u00fcrd\u00fcr\u00fclebilirlik a\u00e7\u0131s\u0131ndan vazge\u00e7ilmez bir pratik oldu\u011funu vurgulad\u0131k. ConfigMaps ile hassas olmayan verileri nas\u0131l y\u00f6netece\u011fimizi, Secrets ile ise veritaban\u0131 \u015fifreleri ve API anahtarlar\u0131 gibi kritik bilgileri nas\u0131l g\u00fcvenli bir \u015fekilde depolay\u0131p kullanaca\u011f\u0131m\u0131z\u0131 ad\u0131m ad\u0131m \u00f6rneklerle g\u00f6rd\u00fck. Mikroservis mimarileri ve CI\/CD s\u00fcre\u00e7leri gibi ger\u00e7ek d\u00fcnya senaryolar\u0131nda bu iki arac\u0131n birlikte nas\u0131l g\u00fc\u00e7l\u00fc \u00e7\u00f6z\u00fcmler sundu\u011funu analiz ettik. Ayr\u0131ca, de\u011fi\u015fmezlik, otomatik g\u00fcncellemeler, harici Secret y\u00f6netimi entegrasyonu ve RBAC ile s\u0131k\u0131 eri\u015fim kontrol\u00fc gibi ileri d\u00fczey teknikler ve en iyi pratiklerle uygulamalar\u0131m\u0131z\u0131n g\u00fcvenlik duru\u015funu nas\u0131l g\u00fc\u00e7lendirebilece\u011fimizi ele ald\u0131k.<\/p>\n Kubernetes'in ConfigMaps ve Secrets mekanizmalar\u0131, modern bulut tabanl\u0131 uygulamalar\u0131n gerektirdi\u011fi dinamik ve g\u00fcvenli yap\u0131land\u0131rma y\u00f6netimi ihtiya\u00e7lar\u0131n\u0131 kar\u015f\u0131lamak i\u00e7in tasarlanm\u0131\u015ft\u0131r. Bu ara\u00e7lar\u0131 do\u011fru ve bilin\u00e7li bir \u015fekilde kullanarak, uygulamalar\u0131n\u0131z\u0131n operasyonel y\u00fck\u00fcn\u00fc azaltabilir, g\u00fcvenlik risklerini minimize edebilir ve da\u011f\u0131t\u0131m s\u00fcre\u00e7lerinizi daha tutarl\u0131 ve verimli hale getirebilirsiniz. Unutmay\u0131n, g\u00fcvenlik bir s\u00fcre\u00e7tir, tek seferlik bir kurulum de\u011fil. Bu nedenle, en iyi pratikleri s\u00fcrekli olarak uygulamak ve g\u00fcvenlik stratejilerinizi g\u00fcncel tutmak, Kubernetes ortam\u0131n\u0131z\u0131n sa\u011fl\u0131\u011f\u0131 i\u00e7in hayati \u00f6nem ta\u015f\u0131maktad\u0131r.<\/p>\n 1. ConfigMap'ler \u015fifreleniyor mu? Secrets'lar tamamen g\u00fcvenli mi?<\/strong><\/p>\n Cevap:<\/strong> Hay\u0131r, ConfigMap'ler \u015fifrelenmez; i\u00e7lerindeki veriler d\u00fcz metin olarak depolan\u0131r ve okunur. Bu nedenle hassas veriler ConfigMap'lerde saklanmamal\u0131d\u0131r. Secrets'lar ise Kubernetes API sunucusunda depoland\u0131\u011f\u0131nda varsay\u0131lan olarak Base64 ile kodlan\u0131r ve etcd veri deposunda \u015fifrelenmi\u015f olarak tutulabilir (e\u011fer etcd \u015fifreleme do\u011fru yap\u0131land\u0131r\u0131lm\u0131\u015fsa). Ancak, Pod'un i\u00e7inde bu veriler d\u00fcz metin olarak eri\u015filebilir durumdad\u0131r. Bu nedenle, Secrets'lar tamamen \"g\u00fcvenli\" de\u011fildir; ek g\u00fcvenlik \u00f6nlemleri (RBAC, birim ba\u011flamalar\u0131, harici Secret y\u00f6neticileri) gereklidir.<\/p>\n 2. ConfigMap veya Secret g\u00fcncellendi\u011finde Pod'lar otomatik olarak yeniden ba\u015flat\u0131l\u0131yor mu?<\/strong><\/p>\n Cevap:<\/strong> Hay\u0131r, ConfigMap veya Secret g\u00fcncellendi\u011finde Pod'lar otomatik olarak yeniden ba\u015flat\u0131lmaz. Ortam de\u011fi\u015fkeni olarak kullan\u0131lan durumlarda, de\u011fi\u015fikliklerin uygulanmas\u0131 i\u00e7in Pod'lar\u0131n yeniden olu\u015fturulmas\u0131 veya yeniden ba\u015flat\u0131lmas\u0131 gerekir. Birim ba\u011flamas\u0131 olarak kullan\u0131lan ConfigMap'ler i\u00e7in de\u011fi\u015fiklikler Pod'un i\u00e7indeki dosyalara belirli bir gecikmeyle (genellikle birka\u00e7 dakika i\u00e7inde) yans\u0131yabilir, ancak yine de uygulaman\u0131n bu de\u011fi\u015fiklikleri fark etmesi ve uygulamas\u0131 gerekir. En iyi uygulama, ConfigMap veya Secret'\u0131n hash'ini Deployment \u015fablonuna bir annotation olarak ekleyerek rolling update'i tetiklemektir.<\/p>\n 3. Hangi durumlarda ConfigMap, hangi durumlarda Secret kullanmal\u0131y\u0131m?<\/strong><\/p>\n Cevap:<\/strong> Genel kural \u015fudur: hassas olmayan, uygulama davran\u0131\u015f\u0131n\u0131 etkileyen ayarlar (API URL'leri, loglama seviyeleri, \u00f6zellik anahtarlar\u0131 vb.) i\u00e7in ConfigMaps kullan\u0131n. Hassas, gizli kalmas\u0131 gereken veriler (veritaban\u0131 \u015fifreleri, API anahtarlar\u0131, TLS sertifikalar\u0131, \u00f6zel SSH anahtarlar\u0131 vb.) i\u00e7in Secrets kullan\u0131n. \u0130kisi aras\u0131ndaki temel fark, verilerin hassasiyeti ve dolay\u0131s\u0131yla gereken g\u00fcvenlik seviyesidir.<\/p>\n 4. Kubernetes Secrets, verilerimi tamamen \u015fifreliyor mu, yoksa sadece kodluyor mu?<\/strong><\/p>\n Cevap:<\/strong> Kubernetes Secrets i\u00e7indeki veriler, YAML tan\u0131m\u0131nda Base64 ile \"kodlanm\u0131\u015f\" olarak g\u00f6r\u00fcn\u00fcr. Bu, verinin kolayca okunmas\u0131n\u0131 engeller ancak \u015fifreleme de\u011fildir; Base64 kodlamas\u0131 kolayca tersine \u00e7evrilebilir. Ger\u00e7ek \u015fifreleme, Kubernetes'in arka plan\u0131nda ger\u00e7ekle\u015fir: etcd veri deposunda saklan\u0131rken veriler \u015fifrelenebilir, ancak bunun i\u00e7in Kubernetes k\u00fcmenizin etcd \u015fifrelemesi i\u00e7in do\u011fru \u015fekilde yap\u0131land\u0131r\u0131lmas\u0131 gerekir. Pod'un i\u00e7inde, veriler uygulamaya sunulurken \u015fifresiz hale gelir.<\/p>\n 5. Mevcut ConfigMap'leri veya Secrets'lar\u0131 g\u00fcncellemek yerine neden yeni bir tane olu\u015fturmak daha iyi bir uygulama olabilir?<\/strong><\/p>\n Cevap:<\/strong> \u00d6zellikle <\/body><\/p>\n","protected":false},"excerpt":{"rendered":"Modern uygulama geli\u015ftirmenin ve da\u011f\u0131t\u0131m\u0131n\u0131n merkezinde, yap\u0131land\u0131rma ve hassas veri y\u00f6netimi yer al\u0131r. Peki, bir uygulaman\u0131n veritaban\u0131 ba\u011flant\u0131…","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-30719","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-kubernetes","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nConfigMaps ile Uygulama Yap\u0131land\u0131rmalar\u0131n\u0131 Nas\u0131l Y\u00f6netiriz?<\/h2>\n
\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: benim-uygulama-config\ndata:\n LOG_LEVEL: \"INFO\"\n MESAJ: \"Kubernetes'e Ho\u015f Geldiniz!\"\n # Veya bir dosya i\u00e7eri\u011fi olarak\n uygulama.properties: |\n server.port=8080\n database.name=prod_db\n<\/pre>\nconfigmap.yaml<\/code> olarak kaydedip a\u015fa\u011f\u0131daki komutla Kubernetes k\u00fcmenize uygulayabilirsiniz:<\/p>\n\nkubectl apply -f configmap.yaml\n<\/pre>\nbenim-uygulama-config<\/code> ad\u0131nda bir ConfigMap'iniz var. \u0130\u00e7indeki verilere kubectl describe configmap benim-uygulama-config<\/code> komutuyla bakabilirsiniz.<\/p>\n\n
\napiVersion: v1\nkind: Pod\nmetadata:\n name: configmap-pod-env\nspec:\n containers:\n - name: benim-web-uygulamam\n image: nginx:latest # \u00d6rnek bir uygulama imaj\u0131\n env:\n - name: UYGULAMA_MESAJI\n valueFrom:\n configMapKeyRef:\n name: benim-uygulama-config\n key: MESAJ\n - name: LOGLAMA_SEVIYESI\n valueFrom:\n configMapKeyRef:\n name: benim-uygulama-config\n key: LOG_LEVEL\n<\/pre>\nbenim-uygulama-config<\/code> ConfigMap'indeki MESAJ<\/code> ve LOG_LEVEL<\/code> anahtarlar\u0131, Pod'un i\u00e7indeki kapsay\u0131c\u0131ya UYGULAMA_MESAJI<\/code> ve LOGLAMA_SEVIYESI<\/code> ortam de\u011fi\u015fkenleri olarak aktar\u0131l\u0131r. Uygulama, bu de\u011fi\u015fkenlere do\u011frudan eri\u015febilir.<\/p>\n\n
\napiVersion: v1\nkind: Pod\nmetadata:\n name: configmap-pod-volume\nspec:\n containers:\n - name: benim-web-uygulamam\n image: nginx:latest\n volumeMounts:\n - name: config-volume\n mountPath: \"\/etc\/config\" # ConfigMap verilerinin ba\u011flanaca\u011f\u0131 yol\n volumes:\n - name: config-volume\n configMap:\n name: benim-uygulama-config\n # Opsiyonel: Sadece belirli anahtarlar\u0131 dosya olarak ba\u011flayabiliriz\n # items:\n # - key: uygulama.properties\n # path: app.properties\n<\/pre>\nbenim-uygulama-config<\/code> ConfigMap'indeki t\u00fcm anahtar-de\u011fer \u00e7iftleri (\u00f6rne\u011fin LOG_LEVEL<\/code>, MESAJ<\/code> ve uygulama.properties<\/code>), Pod'un i\u00e7indeki \/etc\/config<\/code> dizinine ayr\u0131 ayr\u0131 dosyalar olarak ba\u011flan\u0131r. LOG_LEVEL<\/code> i\u00e7eri\u011fi \/etc\/config\/LOG_LEVEL<\/code> dosyas\u0131nda, MESAJ<\/code> i\u00e7eri\u011fi \/etc\/config\/MESAJ<\/code> dosyas\u0131nda ve uygulama.properties<\/code> i\u00e7eri\u011fi \/etc\/config\/uygulama.properties<\/code> dosyas\u0131nda bulunacakt\u0131r. Uygulama, bu dosyalardan yap\u0131land\u0131rmay\u0131 okuyabilir.<\/p>\ndev_db<\/code> iken, \u00fcretimde prod_db<\/code> olabilir. Bu durumda, her ortam i\u00e7in ayr\u0131 bir ConfigMap olu\u015fturarak bu esnekli\u011fi sa\u011flayabiliriz:<\/p>\n\n# configmap-dev.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: uygulama-config-dev\ndata:\n DB_HOST: \"dev-db-service\"\n LOG_LEVEL: \"DEBUG\"\n---\n# configmap-prod.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: uygulama-config-prod\ndata:\n DB_HOST: \"prod-db-cluster\"\n LOG_LEVEL: \"INFO\"\n<\/pre>\nimmutable: true<\/code> alan\u0131n\u0131 metadata alt\u0131na ekleyebilirsiniz. Ancak bu, ConfigMap'i g\u00fcncelleyemeyece\u011finiz anlam\u0131na gelir; yeni bir s\u00fcr\u00fcm i\u00e7in yeni bir ConfigMap olu\u015fturman\u0131z gerekir.<\/div>\nSecrets ile Hassas Verileri G\u00fcvenle Nas\u0131l Saklar\u0131z?<\/h2>\n
\necho -n 'dbuser' | base64\n# \u00c7\u0131kt\u0131: ZGJ1c2Vy\necho -n 'supersecretpassword' | base64\n# \u00c7\u0131kt\u0131: c3VwZXJzZWNyZXRwYXNzd29yZA==\n<\/pre>\n\napiVersion: v1\nkind: Secret\nmetadata:\n name: benim-veritabani-secret\ntype: Opaque # Genel kullan\u0131m i\u00e7in tipik olarak Opaque kullan\u0131l\u0131r\ndata:\n username: ZGJ1c2Vy # base64 kodlanm\u0131\u015f 'dbuser'\n password: c3VwZXJzZWNyZXRwYXNzd29yZA== # base64 kodlanm\u0131\u015f 'supersecretpassword'\n<\/pre>\nsecret.yaml<\/code> olarak kaydedip a\u015fa\u011f\u0131daki komutla uygulayabilirsiniz:<\/p>\n\nkubectl apply -f secret.yaml\n<\/pre>\nkubectl get secret benim-veritabani-secret -o yaml<\/code> komutuyla Secret i\u00e7eri\u011fini kontrol etti\u011finizde, data<\/code> alan\u0131ndaki de\u011ferlerin Base64 kodlu oldu\u011funu g\u00f6receksiniz. Bu, hassas verilerin do\u011frudan terminalde g\u00f6r\u00fcnmesini engeller, ancak asl\u0131nda \u015fifreleme de\u011fildir. Verileri d\u00fcz metin olarak g\u00f6rmek i\u00e7in Base64 \u00e7\u00f6z\u00fcmlemesi yapman\u0131z gerekir.<\/p>\n\n
kubectl exec [pod-ad\u0131] -- env<\/code> ile) dikkatli olunmal\u0131d\u0131r.<\/li>\n<\/ol>\n\napiVersion: v1\nkind: Pod\nmetadata:\n name: secret-pod-env\nspec:\n containers:\n - name: veritabani-baglayici\n image: benim-uygulama-imaji:latest\n env:\n - name: DB_USERNAME\n valueFrom:\n secretKeyRef:\n name: benim-veritabani-secret\n key: username\n - name: DB_PASSWORD\n valueFrom:\n secretKeyRef:\n name: benim-veritabani-secret\n key: password\n<\/pre>\nbenim-veritabani-secret<\/code> i\u00e7indeki kullan\u0131c\u0131 ad\u0131 ve \u015fifre, DB_USERNAME<\/code> ve DB_PASSWORD<\/code> ortam de\u011fi\u015fkenleri olarak Pod'a enjekte edilir. Uygulama kodunuz bu de\u011fi\u015fkenleri okuyarak veritaban\u0131na ba\u011flanabilir.<\/p>\n\n
\napiVersion: v1\nkind: Pod\nmetadata:\n name: secret-pod-volume\nspec:\n containers:\n - name: veritabani-baglayici\n image: benim-uygulama-imaji:latest\n volumeMounts:\n - name: secret-volume\n mountPath: \"\/etc\/secrets\"\n readOnly: true # Sadece okunabilir olarak ba\u011flamak \u00f6nemlidir\n volumes:\n - name: secret-volume\n secret:\n secretName: benim-veritabani-secret\n # Opsiyonel: Sadece belirli anahtarlar\u0131 dosya olarak ba\u011flayabiliriz\n # items:\n # - key: username\n # path: db_username.txt\n # - key: password\n # path: db_password.txt\n<\/pre>\nbenim-veritabani-secret<\/code> i\u00e7indeki her bir anahtar (username<\/code>, password<\/code>), Pod'un i\u00e7indeki \/etc\/secrets<\/code> dizinine ayr\u0131 bir dosya olarak ba\u011flan\u0131r. Uygulama, \/etc\/secrets\/username<\/code> ve \/etc\/secrets\/password<\/code> dosyalar\u0131n\u0131 okuyarak verilere eri\u015fir. readOnly: true<\/code> ayar\u0131, bu dosyalar\u0131n yanl\u0131\u015fl\u0131kla de\u011fi\u015ftirilmesini engeller.<\/p>\n\n
items<\/code> alan\u0131n\u0131 kullan\u0131n.<\/li>\nGer\u00e7ek D\u00fcnya Uygulamalar\u0131 ve Senaryolar: ConfigMaps ve Secrets Birlikte Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h2>\n
Vaka Analizi 1: Mikroservis Ortam\u0131nda Dinamik Yap\u0131land\u0131rma Y\u00f6netimi<\/h3>\n
\n
\n
\napiVersion: v1\nkind: Secret\nmetadata:\n name: ana-veritabani-secret\ndata:\n DB_USERNAME: \napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: urun-katalogu-config\ndata:\n CACHE_DURATION_SECONDS: \"3600\"\n ITEMS_PER_PAGE: \"20\"\n FEATURE_TOGGLE_A: \"true\"\n <\/pre>\n\napiVersion: v1\nkind: Secret\nmetadata:\n name: odeme-api-key-secret\ndata:\n PAYMENT_API_KEY: \napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: urun-katalogu-deployment\nspec:\n replicas: 3\n selector:\n matchLabels:\n app: urun-katalogu\n template:\n metadata:\n labels:\n app: urun-katalogu\n spec:\n containers:\n - name: urun-katalogu-servisi\n image: benim-repo\/urun-katalogu:v1.0.0\n ports:\n - containerPort: 8080\n envFrom: # T\u00fcm ConfigMap ve Secret'\u0131 ortam de\u011fi\u015fkeni olarak y\u00fckler\n - configMapRef:\n name: urun-katalogu-config\n volumeMounts:\n - name: db-secret-volume\n mountPath: \"\/etc\/secrets\/db\"\n readOnly: true\n volumes:\n - name: db-secret-volume\n secret:\n secretName: ana-veritabani-secret\n<\/pre>\nVaka Analizi 2: CI\/CD S\u00fcre\u00e7lerinde G\u00fcvenli Da\u011f\u0131t\u0131m ve Otomasyon<\/h3>\n
\n
\n
\n# uygulama-config-prod.yaml\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: uygulama-config-prod\ndata:\n DB_URL: \"jdbc:mysql:\/\/prod-db:3306\/uygulama_prod\"\n CACHE_EXPIRY: \"7200\"\n LOG_LEVEL: \"INFO\"\n <\/pre>\n\n# uygulama-api-secret-prod.yaml\napiVersion: v1\nkind: Secret\nmetadata:\n name: uygulama-api-secret-prod\ndata:\n EXTERNAL_API_KEY: kubectl apply<\/code> komutuyla k\u00fcme \u00fczerine uygulan\u0131r. Bu, genellikle Helm Charts veya Kustomize gibi ara\u00e7lar kullan\u0131larak daha dinamik ve \u015fablon tabanl\u0131 bir \u015fekilde yap\u0131l\u0131r.<\/p>\n\n# GitLab CI veya Jenkinsfile'da bir sahne\ndeploy_to_production:\n stage: deploy\n script:\n - # Helm Chart kullanarak da\u011f\u0131t\u0131m\n - helm upgrade --install benim-uygulama .\/helm-chart \\\n --namespace production \\\n --set configmap.name=uygulama-config-prod \\\n --set secret.name=uygulama-api-secret-prod\n # Veya direkt YAML dosyalar\u0131n\u0131 uygulama\n - kubectl apply -f kubernetes\/prod\/uygulama-config-prod.yaml\n - kubectl apply -f kubernetes\/prod\/uygulama-api-secret-prod.yaml\n - kubectl apply -f kubernetes\/prod\/uygulama-deployment.yaml\n environment:\n name: production\n<\/pre>\n\u0130leri D\u00fczey Kullan\u0131m Teknikleri ve En \u0130yi Pratikler<\/h2>\n
\napiVersion: v1\nkind: ConfigMap\nmetadata:\n name: benim-uygulama-config\nimmutable: true # \u0130\u015fte burada!\ndata:\n MESAJ: \"Bu ConfigMap de\u011fi\u015ftirilemez.\"\n<\/pre>\nimmutable: true<\/code> olarak i\u015faretlendi\u011finde, bu kayna\u011f\u0131 art\u0131k de\u011fi\u015ftiremezsiniz. Bir de\u011fi\u015fiklik yapman\u0131z gerekti\u011finde, yeni bir isimle yeni bir ConfigMap\/Secret olu\u015fturup Deployment'\u0131n\u0131z\u0131 bu yeni kayna\u011fa i\u015faret edecek \u015fekilde g\u00fcncellemeniz gerekir. Bu, bir t\u00fcr s\u00fcr\u00fcm kontrol\u00fc sa\u011flayarak istenmeyen yap\u0131land\u0131rma de\u011fi\u015fikliklerinin \u00f6n\u00fcne ge\u00e7er.<\/p>\nkubelet<\/code>'in ConfigMap'leri senkronize etme s\u0131kl\u0131\u011f\u0131na ba\u011fl\u0131d\u0131r, bu da dakikalar s\u00fcrebilir). En g\u00fcvenli ve tutarl\u0131 yakla\u015f\u0131m, ConfigMap veya Secret g\u00fcncellendi\u011finde, Deployment'\u0131 rolling update mekanizmas\u0131n\u0131 tetikleyecek \u015fekilde yap\u0131land\u0131rmakt\u0131r.<\/p>\nspec.template<\/code>) annotation'lar\u0131na ConfigMap\/Secret'\u0131n hash'ini eklemektir:<\/p>\n\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: benim-uygulama-deployment\nspec:\n template:\n metadata:\n annotations:\n checksum\/config: {{ include (print $.Template.BasePath \"\/configmap.yaml\") . | sha256sum }}\n checksum\/secret: {{ include (print $.Template.BasePath \"\/secret.yaml\") . | sha256sum }}\n # ... di\u011fer Deployment detaylar\u0131\n<\/pre>\n\napiVersion: rbac.authorization.k8s.io\/v1\nkind: Role\nmetadata:\n name: secret-okuyucu-rolu\nrules:\n- apiGroups: [\"\"] # \"\" core API grubunu temsil eder\n resources: [\"secrets\"]\n verbs: [\"get\", \"list\", \"watch\"] # Sadece okuma izni\n resourceNames: [\"benim-veritabani-secret\"] # Sadece bu Secret'a eri\u015fim\n---\napiVersion: rbac.authorization.k8s.io\/v1\nkind: RoleBinding\nmetadata:\n name: secret-okuyucu-rolebinding\nsubjects:\n- kind: ServiceAccount\n name: benim-uygulama-sa # Uygulaman\u0131z\u0131n kulland\u0131\u011f\u0131 ServiceAccount\n namespace: default\nroleRef:\n kind: Role\n name: secret-okuyucu-rolu\n apiGroup: rbac.authorization.k8s.io\n<\/pre>\nbenim-uygulama-sa<\/code> ServiceAccount'\u0131na sadece benim-veritabani-secret<\/code> Secret'\u0131n\u0131 okuma izni verir. Bu, minimum ayr\u0131cal\u0131k prensibini uygulaman\u0131n temel bir yoludur.<\/p>\n\n\/* Genel kod blo\u011fu stilleri *\/\npre {\n white-space: pre-wrap; \/* Uzun sat\u0131rlar\u0131 otomatik sarar *\/\n word-wrap: break-word; \/* Kelimeleri b\u00f6lerek ta\u015fmay\u0131 \u00f6nler *\/\n overflow-x: auto; \/* Yatay kayd\u0131rma \u00e7ubu\u011fu ekler *\/\n background-color: #f5f5f5;\n padding: 15px;\n border-radius: 5px;\n}\n\n\/* Mobil cihazlar i\u00e7in \u00f6zel stiller *\/\n@media (max-width: 768px) {\n pre {\n font-size: 0.9em; \/* Font boyutunu k\u00fc\u00e7\u00fclt *\/\n padding: 10px;\n }\n \/* Tablolar i\u00e7in responsive d\u00fczenleme *\/\n table, thead, tbody, th, td, tr {\n display: block; \/* Her h\u00fccreyi ayr\u0131 bir blok eleman\u0131 gibi g\u00f6ster *\/\n }\n thead tr {\n position: absolute;\n top: -9999px;\n left: -9999px;\n }\n tr { border: 1px solid #ccc; }\n td {\n border: none;\n border-bottom: 1px solid #eee;\n position: relative;\n padding-left: 50%;\n }\n td:before {\n position: absolute;\n top: 6px;\n left: 6px;\n width: 45%;\n padding-right: 10px;\n white-space: nowrap;\n content: attr(data-label); \/* data-label niteli\u011fi ile ba\u015fl\u0131\u011f\u0131 g\u00f6ster *\/\n font-weight: bold;\n }\n}\n<\/pre>\nSonu\u00e7: G\u00fcvenli ve Esnek Yap\u0131land\u0131rma Y\u00f6netiminin Temelleri<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n
immutable: true<\/code> olarak i\u015faretlenmi\u015f kaynaklar i\u00e7in yeni bir ConfigMap veya Secret olu\u015fturmak zorunludur. Ancak genel olarak, yeni bir kaynak olu\u015fturmak (veya s\u00fcr\u00fcmlemek) ve Deployment'\u0131 bu yeni kayna\u011f\u0131 kullanacak \u015fekilde g\u00fcncellemek, de\u011fi\u015fikliklerin daha kontroll\u00fc ve denetlenebilir olmas\u0131n\u0131 sa\u011flar. Bu yakla\u015f\u0131m, yanl\u0131\u015fl\u0131kla yap\u0131lan de\u011fi\u015fikliklerin \u00f6n\u00fcne ge\u00e7er, geri alma (rollback) i\u015flemlerini basitle\u015ftirir ve CI\/CD pipeline'lar\u0131nda daha tutarl\u0131 bir \"tek ger\u00e7ek kaynak\" (single source of truth) prensibi sa\u011flar. Bu, \u00f6zellikle \u00fcretim ortamlar\u0131nda riskleri en aza indirmek i\u00e7in tercih edilen bir y\u00f6ntemdir.<\/p>\n