Da\u011f\u0131t\u0131k sistemlerde performans ve \u00f6l\u00e7eklenebilirlik i\u00e7in \u00f6nbellekleme hayati \u00f6neme sahiptir. Ancak, \u00f6nbellek tutars\u0131zl\u0131\u011f\u0131n\u0131 \u00f6nlemek, yani ‘\u00f6nbellek ge\u00e7ersiz k\u0131lma’ sorunu, her zaman zorlu olmu\u015ftur. Kubernetes gibi dinamik ortamlarda bu problem daha da karma\u015f\u0131kla\u015f\u0131r. Bu makalede, Kubernetes’in headless servislerini kullanarak \u00f6nbellek ge\u00e7ersiz k\u0131lma sorununa getirdi\u011fimiz yenilik\u00e7i ve etkili \u00e7\u00f6z\u00fcm\u00fc detayland\u0131raca\u011f\u0131z.<\/p>\n
\u00d6nbellekleme, veritaban\u0131 veya uzak servis \u00e7a\u011fr\u0131lar\u0131 gibi pahal\u0131 i\u015flemleri tekrarlamaktan ka\u00e7\u0131narak uygulamalar\u0131n yan\u0131t s\u00fcrelerini k\u0131salt\u0131r ve arka u\u00e7 sistemlerin y\u00fck\u00fcn\u00fc azalt\u0131r. Ancak, \u00f6nbelle\u011fe al\u0131nan verinin orijinal veri kayna\u011f\u0131ndan farkl\u0131la\u015fmas\u0131, yani ‘eski’ veya ‘ge\u00e7ersiz’ hale gelmesi durumuyla s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131l\u0131r. Bu durum, kullan\u0131c\u0131lara yanl\u0131\u015f bilgi sunulmas\u0131na, i\u015f mant\u0131\u011f\u0131nda hatalara ve genel sistem g\u00fcvenilirli\u011finin d\u00fc\u015fmesine yol a\u00e7abilir.<\/p>\n
\u00d6nbellek tutars\u0131zl\u0131\u011f\u0131, \u00f6nbellekteki verinin ana veri kayna\u011f\u0131ndaki g\u00fcncel veriden farkl\u0131 olmas\u0131 durumudur. Bu durum, \u00f6zellikle y\u00fcksek frekansl\u0131 veri g\u00fcncellemeleri olan sistemlerde kritik sorunlara yol a\u00e7abilir. \u00d6rne\u011fin, bir e-ticaret sitesinde \u00fcr\u00fcn fiyat\u0131n\u0131n g\u00fcncellenmesine ra\u011fmen \u00f6nbellekte eski fiyat\u0131n g\u00f6sterilmesi, m\u00fc\u015fteri memnuniyetsizli\u011fine ve finansal kay\u0131plara neden olabilir.<\/p>\n
Geleneksel olarak, \u00f6nbellek ge\u00e7ersiz k\u0131lma i\u00e7in \u00e7e\u015fitli stratejiler kullan\u0131l\u0131r:<\/p>\n
Kubernetes, uygulamalar\u0131n da\u011f\u0131t\u0131m\u0131n\u0131, \u00f6l\u00e7eklendirilmesini ve y\u00f6netimini otomatikle\u015ftiren g\u00fc\u00e7l\u00fc bir platformdur. Ancak dinamik do\u011fas\u0131, \u00f6nbellek y\u00f6netimi ve \u00f6zellikle ge\u00e7ersiz k\u0131lma konusunda kendine \u00f6zg\u00fc zorluklar yarat\u0131r.<\/p>\n
Kubernetes’te Pod’lar efemeraldir; yani herhangi bir zamanda olu\u015fturulabilir, silinebilir veya yeniden planlanabilirler. Bir \u00f6nbellek sunucusu olarak \u00e7al\u0131\u015fan Pod’lar da bu durumdan etkilenir. Geleneksel yakla\u015f\u0131mlar, sabit IP adreslerine veya statik konfig\u00fcrasyonlara dayan\u0131rken, Kubernetes’in dinamik yap\u0131s\u0131 bu t\u00fcr yakla\u015f\u0131mlar\u0131 i\u015flevsiz k\u0131lar. Bir \u00f6nbellek Pod’u yeniden ba\u015flat\u0131ld\u0131\u011f\u0131nda veya \u00f6l\u00e7eklendirildi\u011finde, di\u011fer servislerin bu yeni veya de\u011fi\u015fen Pod’lar\u0131 ke\u015ffetmesi gerekir.<\/p>\n
Kubernetes, servis ke\u015ffi i\u00e7in dahili DNS mekanizmalar\u0131n\u0131 kullan\u0131r. Standart bir Kubernetes Service, arkas\u0131ndaki Pod’lar aras\u0131nda y\u00fck dengeleme yapar ve tek bir sanal IP adresi (Cluster IP) sunar. Ancak, \u00f6nbellek ge\u00e7ersiz k\u0131lma senaryolar\u0131nda, bazen belirli bir \u00f6nbellek Pod’una do\u011frudan eri\u015fmek veya t\u00fcm \u00f6nbellek Pod’lar\u0131na ayn\u0131 anda bir mesaj g\u00f6ndermek isteyebiliriz. Standart servisler bu do\u011frudan eri\u015fimi sa\u011flamaz.<\/p>\n
\u00d6nbellek sunucular\u0131n\u0131n birden fazla Pod’a da\u011f\u0131t\u0131ld\u0131\u011f\u0131 durumlarda, bir veri g\u00fcncellemesi oldu\u011funda t\u00fcm ilgili \u00f6nbellek Pod’lar\u0131n\u0131 do\u011fru ve tutarl\u0131 bir \u015fekilde ge\u00e7ersiz k\u0131lmak zorla\u015f\u0131r. Her bir \u00f6nbellek \u00f6rne\u011finin bireysel olarak hedef al\u0131nmas\u0131 veya bir yay\u0131n (broadcast) mekanizmas\u0131 ile ula\u015f\u0131lmas\u0131 gereklili\u011fi, Kubernetes’in dinamik yap\u0131s\u0131yla birle\u015fti\u011finde karma\u015f\u0131kl\u0131\u011f\u0131 art\u0131r\u0131r.<\/p>\n
Kubernetes servisleri, Pod’lara eri\u015fimi kolayla\u015ft\u0131ran soyutlamalard\u0131r. \u00c7o\u011fu servis, Cluster IP ad\u0131 verilen sanal bir IP adresi \u00fczerinden y\u00fck dengeleme sa\u011flarken, headless servisler farkl\u0131 bir amaca hizmet eder.<\/p>\n
Standart bir Kubernetes Service (ClusterIP, NodePort, LoadBalancer), istemcilere tek bir sanal IP adresi sunar ve gelen trafi\u011fi arkas\u0131ndaki Pod’lar aras\u0131nda da\u011f\u0131t\u0131r. Bu, istemcilerin Pod’lar\u0131n bireysel IP adreslerini bilmesine gerek kalmadan servise eri\u015fmesini sa\u011flar. Ancak, bu soyutlama, Pod’lar\u0131n bireysel adreslerine do\u011frudan eri\u015fmek isteyen durumlar i\u00e7in bir engel te\u015fkil edebilir.<\/p>\n
Headless servisler ise bir Cluster IP adresine sahip de\u011fildir. Bunun yerine, Kubernetes DNS sistemi, headless servisin arkas\u0131ndaki her Pod i\u00e7in do\u011frudan bir DNS kayd\u0131 olu\u015fturur. Bu, istemcilerin DNS sorgusu yaparak ilgili Pod’lar\u0131n IP adreslerini do\u011frudan elde etmesini ve onlarla do\u011frudan ileti\u015fim kurmas\u0131n\u0131 sa\u011flar.<\/p>\n
Bir headless servis tan\u0131mland\u0131\u011f\u0131nda, Kubernetes DNS (genellikle CoreDNS), servisin ad\u0131 alt\u0131nda her Pod i\u00e7in A kayd\u0131 (veya StatefulSet durumunda PTR kayd\u0131) olu\u015fturur. \u00d6rne\u011fin, Bu mekanizma, istemci uygulamalar\u0131n\u0131n Pod’lar\u0131n bireysel IP adreslerini dinamik olarak ke\u015ffetmesini ve do\u011frudan onlarla ba\u011flant\u0131 kurmas\u0131n\u0131 sa\u011flar. Bu, \u00f6zellikle da\u011f\u0131t\u0131k \u00f6nbellekler, veritabanlar\u0131 veya mesaj kuyruklar\u0131 gibi durum bilgili (stateful) uygulamalar i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n Headless servisler, her bir Pod’un kendi durumunu korudu\u011fu ve di\u011fer Pod’larla do\u011frudan ileti\u015fim kurmas\u0131 gereken durum bilgili uygulamalar i\u00e7in idealdir. \u00d6rne\u011fin, bir Redis k\u00fcmesi veya Apache Kafka k\u00fcmesi, her d\u00fc\u011f\u00fcm\u00fcn belirli bir rol\u00fc oldu\u011fu ve di\u011fer d\u00fc\u011f\u00fcmlerle do\u011frudan konu\u015fmas\u0131 gerekti\u011fi durumlarda headless servislerden faydalan\u0131r. \u00d6nbellek ge\u00e7ersiz k\u0131lma senaryomuzda da, her \u00f6nbellek Pod’unun ba\u011f\u0131ms\u0131z bir birim olarak ele al\u0131nmas\u0131 ve do\u011frudan ge\u00e7ersiz k\u0131lma komutlar\u0131n\u0131 almas\u0131 gerekti\u011fi i\u00e7in bu yap\u0131 \u00e7ok uygundur.<\/p>\n Kubernetes’in dinamik do\u011fas\u0131na uyum sa\u011flayan ve \u00f6nbellek tutars\u0131zl\u0131\u011f\u0131 sorununu \u00e7\u00f6zen yakla\u015f\u0131m\u0131m\u0131z, headless servislerin sundu\u011fu do\u011frudan Pod ke\u015ffi yetene\u011fini kullanmaya dayan\u0131r.<\/p>\n Temel fikir \u015fudur: \u00d6nbelle\u011fi ge\u00e7ersiz k\u0131lmak isteyen bir servis (\u00f6rne\u011fin, bir veri g\u00fcncelleme servisi), \u00f6nbellek sunucular\u0131n\u0131 bar\u0131nd\u0131ran headless servisi sorgulayarak t\u00fcm \u00f6nbellek Pod’lar\u0131n\u0131n IP adreslerini dinamik olarak elde eder. Ard\u0131ndan, elde etti\u011fi her bir IP adresine do\u011frudan bir ge\u00e7ersiz k\u0131lma iste\u011fi g\u00f6nderir. Bu sayede, \u00f6nbellek Pod’lar\u0131 \u00f6l\u00e7eklense de, yeniden ba\u015flat\u0131lsa da veya IP adresleri de\u011fi\u015fse de, ge\u00e7ersiz k\u0131lma i\u015flemi her zaman g\u00fcncel Pod listesine ula\u015farak tutarl\u0131l\u0131\u011f\u0131 sa\u011flar.<\/p>\n Ge\u00e7ersiz k\u0131lma i\u015flemini tetikleyen servis, Kubernetes DNS’i kullanarak headless servisin ad\u0131n\u0131 sorgular. Bu sorgu, o an aktif olan t\u00fcm \u00f6nbellek Pod’lar\u0131n\u0131n IP adreslerini d\u00f6nd\u00fcr\u00fcr. Uygulama katman\u0131nda bu i\u015flem, genellikle bir DNS istemci k\u00fct\u00fcphanesi (\u00f6rne\u011fin, Go’da \u00d6rnek bir DNS sorgusu ve beklenen \u00e7\u0131kt\u0131:<\/p>\n <\/code><\/p>\n Bu \u00e7\u0131kt\u0131da, IP adresleri elde edildikten sonra, ge\u00e7ersiz k\u0131lma servisi her bir \u00f6nbellek Pod'una do\u011frudan bir HTTP iste\u011fi, gRPC \u00e7a\u011fr\u0131s\u0131 veya ba\u015fka bir protokol \u00fczerinden ge\u00e7ersiz k\u0131lma komutunu g\u00f6nderir. Her \u00f6nbellek Pod'u, bu komutu ald\u0131\u011f\u0131nda kendi i\u00e7indeki ilgili \u00f6nbellek \u00f6\u011felerini temizler veya g\u00fcnceller.<\/p>\n Bu \u00e7\u00f6z\u00fcm\u00fcn uygulanmas\u0131 i\u00e7in hem Kubernetes kaynaklar\u0131n\u0131n do\u011fru yap\u0131land\u0131r\u0131lmas\u0131 hem de uygulama kodunda belirli de\u011fi\u015fikliklerin yap\u0131lmas\u0131 gerekmektedir.<\/p>\n \u00d6ncelikle, \u00f6nbellek sunucular\u0131m\u0131z\u0131 bir Deployment (veya StatefulSet, duruma g\u00f6re) ile \u00e7al\u0131\u015ft\u0131r\u0131r\u0131z. Ard\u0131ndan, bu Deployment'\u0131 hedefleyen bir headless servis tan\u0131mlar\u0131z.<\/p>\n <\/code><\/p>\n <\/code><\/p>\n \u00d6nbellek sunucusu uygulamam\u0131z ( Ge\u00e7ersiz k\u0131lma i\u015flemini tetikleyen servis ise (\u00f6rne\u011fin, bir API servisi veya veri i\u015fleme servisi), Kubernetes DNS'i kullanarak A\u015fa\u011f\u0131da, Go dilinde bir uygulaman\u0131n headless servis \u00fczerinden \u00f6nbellek Pod'lar\u0131n\u0131 nas\u0131l ke\u015ffedip ge\u00e7ersiz k\u0131lma iste\u011fi g\u00f6nderebilece\u011fine dair basit bir \u00f6rnek bulunmaktad\u0131r:<\/p>\n <\/code><\/p>\n Ge\u00e7ersiz k\u0131lma mesajlar\u0131 i\u00e7in HTTP en basit ve yayg\u0131n kullan\u0131lan y\u00f6ntemdir. Ancak, daha performansl\u0131 veya karma\u015f\u0131k senaryolar i\u00e7in gRPC veya Redis PUBLISH\/SUBSCRIBE gibi daha geli\u015fmi\u015f protokoller de kullan\u0131labilir. Se\u00e7im, uygulaman\u0131n gereksinimlerine ve mevcut altyap\u0131ya ba\u011fl\u0131d\u0131r.<\/p>\n Bu yakla\u015f\u0131m\u0131n kendine \u00f6zg\u00fc avantajlar\u0131 ve baz\u0131 dikkat edilmesi gereken noktalar\u0131 bulunmaktad\u0131r.<\/p>\n B\u00fcy\u00fck \u00f6l\u00e7ekli sistemlerde, binlerce \u00f6nbellek Pod'u olmas\u0131 durumunda, t\u00fcm\u00fcne ayn\u0131 anda istek g\u00f6ndermek a\u011fda yo\u011funlu\u011fa neden olabilir. Bu durumda, istekleri e\u015f zamanl\u0131 (concurrent) olarak g\u00f6ndermek veya daha geli\u015fmi\u015f bir da\u011f\u0131t\u0131k mesajla\u015fma sistemi (\u00f6rne\u011fin Kafka veya RabbitMQ) kullanmak d\u00fc\u015f\u00fcn\u00fclebilir. G\u00fcvenlik a\u00e7\u0131s\u0131ndan, Kubernetes Network Policy'leri ile sadece belirli servislerin \u00f6nbellek Pod'lar\u0131na ge\u00e7ersiz k\u0131lma iste\u011fi g\u00f6ndermesine izin verilmelidir.<\/p>\n Kubernetes'in dinamik ve da\u011f\u0131t\u0131k yap\u0131s\u0131nda \u00f6nbellek ge\u00e7ersiz k\u0131lma, karma\u015f\u0131k bir problem olmaya devam etmektedir. Ancak, headless servislerin sa\u011flad\u0131\u011f\u0131 do\u011frudan Pod ke\u015fif yetene\u011fini kullanarak, bu soruna zarif, etkili ve Kubernetes'in do\u011fas\u0131yla uyumlu bir \u00e7\u00f6z\u00fcm getirdik. Bu yakla\u015f\u0131m, ek karma\u015f\u0131k altyap\u0131 gerektirmeden, uygulamalar\u0131n her zaman g\u00fcncel verilere eri\u015fmesini sa\u011flayarak performans ve g\u00fcvenilirli\u011fi art\u0131r\u0131r. Geli\u015ftiriciler, bu basit ama g\u00fc\u00e7l\u00fc mekanizmay\u0131 kendi Kubernetes tabanl\u0131 uygulamalar\u0131na entegre ederek \u00f6nbellek tutars\u0131zl\u0131\u011f\u0131 kabusuna son verebilirler.<\/p>\n Redis Pub\/Sub veya Kafka gibi \u00e7\u00f6z\u00fcmler de ge\u00e7erli yakla\u015f\u0131mlard\u0131r ve daha b\u00fcy\u00fck \u00f6l\u00e7ekli, olay tabanl\u0131 sistemler i\u00e7in uygun olabilir. Ancak, bu \u00e7\u00f6z\u00fcmler ek bir altyap\u0131 bile\u015feni (Redis sunucusu, Kafka k\u00fcmesi) kurma ve y\u00f6netme maliyeti getirir. Headless servis yakla\u015f\u0131m\u0131m\u0131z, Kubernetes'in yerle\u015fik \u00f6zelliklerini kullanarak bu ek maliyetten ka\u00e7\u0131n\u0131r ve daha hafif bir \u00e7\u00f6z\u00fcm sunar. Basit ve do\u011frudan bir ge\u00e7ersiz k\u0131lma ihtiyac\u0131 i\u00e7in gereksiz karma\u015f\u0131kl\u0131\u011f\u0131 ortadan kald\u0131r\u0131r.<\/p>\n Bu \u00e7\u00f6z\u00fcm, belirli bir anahtar veya anahtar grubu i\u00e7in \u00f6nbellek ge\u00e7ersiz k\u0131lma ihtiyac\u0131 olan senaryolar i\u00e7in olduk\u00e7a uygundur. Ancak, t\u00fcm \u00f6nbelle\u011fin toptan temizlenmesi (flush all) gibi daha geni\u015f kapsaml\u0131 operasyonlar veya \u00e7ok y\u00fcksek frekansta, anl\u0131k ge\u00e7ersiz k\u0131lma gerektiren durumlar i\u00e7in ek optimizasyonlar veya farkl\u0131 yakla\u015f\u0131mlar gerekebilir. Her bir \u00f6nbellek Pod'una ayr\u0131 ayr\u0131 istek g\u00f6nderme maliyeti, senaryoya g\u00f6re de\u011ferlendirilmelidir.<\/p>\n Do\u011frudan Pod IP'lerine eri\u015fim, Kubernetes'in Network Policy'leri ile s\u0131k\u0131 bir \u015fekilde kontrol edilmelidir. Yaln\u0131zca belirli servislerin (\u00f6rne\u011fin, veri g\u00fcncelleme servisleri) \u00f6nbellek Pod'lar\u0131na ge\u00e7ersiz k\u0131lma iste\u011fi g\u00f6ndermesine izin verilmelidir. Aksi takdirde, yetkisiz servisler veya d\u0131\u015far\u0131dan gelen sald\u0131r\u0131lar \u00f6nbelleklerinizi manip\u00fcle edebilir. Ayr\u0131ca, ge\u00e7ersiz k\u0131lma endpoint'leri i\u00e7in kimlik do\u011frulama ve yetkilendirme mekanizmalar\u0131 da d\u00fc\u015f\u00fcn\u00fclmelidir.<\/p>\n Kubernetes'in dahili DNS \u00e7\u00f6z\u00fcc\u00fcs\u00fc (CoreDNS) ve istemci taraf\u0131ndaki DNS \u00f6nbellekleri, Pod IP adreslerinin g\u00fcncel kalmas\u0131nda rol oynar. Genellikle CoreDNS, servis kay\u0131tlar\u0131 i\u00e7in k\u0131sa TTL de\u011ferleri kullan\u0131r, bu da de\u011fi\u015fikliklerin h\u0131zl\u0131 yay\u0131lmas\u0131n\u0131 sa\u011flar. Uygulama taraf\u0131nda, DNS \u00e7\u00f6z\u00fcmleme sonu\u00e7lar\u0131n\u0131 \u00e7ok uzun s\u00fcre \u00f6nbelle\u011fe almaktan ka\u00e7\u0131nmak \u00f6nemlidir. Gerekirse, belirli aral\u0131klarla DNS sorgusu tekrarlanarak g\u00fcncel Pod listesinin al\u0131nd\u0131\u011f\u0131ndan emin olunabilir.<\/p>\n","protected":false},"excerpt":{"rendered":"Da\u011f\u0131t\u0131k sistemlerde performans ve \u00f6l\u00e7eklenebilirlik i\u00e7in \u00f6nbellekleme hayati \u00f6neme sahiptir. Ancak, \u00f6nbellek tutars\u0131zl\u0131\u011f\u0131n\u0131 \u00f6nlemek, yani ‘\u00f6n…","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-37239","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-kubernetes","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nmy-cache-service<\/code> ad\u0131nda bir headless servisimiz varsa ve bu servis cache-pod-1<\/code>, cache-pod-2<\/code> Pod’lar\u0131n\u0131 hedefliyorsa, DNS sorgular\u0131 \u015fu \u015fekilde sonu\u00e7lanabilir:<\/p>\n\n
my-cache-service.my-namespace.svc.cluster.local<\/code> sorgusu, cache-pod-1<\/code> ve cache-pod-2<\/code>‘nin IP adreslerini d\u00f6nd\u00fcr\u00fcr.<\/li>\ncache-pod-0.my-cache-service.my-namespace.svc.cluster.local<\/code> gibi \u00f6zel DNS kay\u0131tlar\u0131 da olu\u015fur.<\/li>\n<\/ul>\nDurum Bilgili Uygulamalar \u0130\u00e7in Kullan\u0131m\u0131<\/h4>\n
\u00c7\u00f6z\u00fcm Yakla\u015f\u0131m\u0131m\u0131z: Headless Servis ile \u00d6nbellek Ge\u00e7ersiz K\u0131lma Mekanizmas\u0131<\/h3>\n
Mekanizman\u0131n Temel Fikri<\/h4>\n
\u00d6nbellek Sunucular\u0131n\u0131n Ke\u015ffi<\/h4>\n
net.LookupHost<\/code>, Python’da socket.gethostbyname_ex<\/code>) arac\u0131l\u0131\u011f\u0131yla yap\u0131l\u0131r.<\/p>\n$ kubectl exec -it my-cache-service<\/code> headless servisinin arkas\u0131nda \u00e7al\u0131\u015fan \u00fc\u00e7 \u00f6nbellek Pod'unun IP adresleri g\u00f6r\u00fcnmektedir.<\/p>\nGe\u00e7ersiz K\u0131lma Mesajlar\u0131n\u0131n G\u00f6nderilmesi<\/h4>\n
Uygulama Detaylar\u0131 ve Mimari<\/h3>\n
Kubernetes Kaynaklar\u0131 (Deployment, Headless Service)<\/h4>\n
\u00d6rnek Headless Servis Tan\u0131m\u0131:<\/h5>\n
apiVersion: v1\nkind: Service\nmetadata:\n name: my-cache-service\n namespace: my-namespace\nspec:\n clusterIP: None # Buras\u0131 headless oldu\u011funu belirtir\n selector:\n app: my-cache-app # Bu selector ile \u00f6nbellek Pod'lar\u0131n\u0131 hedefliyoruz\n ports:\n - protocol: TCP\n port: 8080\n targetPort: 8080\n<\/pre>\n\u00d6rnek \u00d6nbellek Uygulamas\u0131 Deployment Tan\u0131m\u0131:<\/h5>\n
apiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: my-cache-deployment\n namespace: my-namespace\nspec:\n replicas: 3\n selector:\n matchLabels:\n app: my-cache-app\n template:\n metadata:\n labels:\n app: my-cache-app\n spec:\n containers:\n - name: cache-server\n image: my-custom-cache-image:latest\n ports:\n - containerPort: 8080\n<\/pre>\nUygulama Katman\u0131nda Yap\u0131lan De\u011fi\u015fiklikler<\/h4>\n
my-custom-cache-image<\/code>), 8080 portunda bir HTTP endpoint'i a\u00e7mal\u0131 ve bu endpoint'e gelen isteklere g\u00f6re \u00f6nbelle\u011fi ge\u00e7ersiz k\u0131labilmelidir. \u00d6rne\u011fin, \/invalidate?key=my_data<\/code> gibi bir endpoint.<\/p>\nmy-cache-service<\/code>'in IP adreslerini dinamik olarak sorgulamal\u0131 ve her birine HTTP iste\u011fi g\u00f6ndermelidir.<\/p>\n\u00d6rnek Kod Par\u00e7ac\u0131klar\u0131 (Go Dili)<\/h4>\n
package main\n\nimport (\n\t\"fmt\"\n\t\"io\/ioutil\"\n\t\"log\"\n\t\"net\"\n\t\"net\/http\"\n\t\"time\"\n)\n\nfunc main() {\n\tcacheServiceDNS := \"my-cache-service.my-namespace.svc.cluster.local\"\n\tinvalidationEndpoint := \"\/invalidate?key=product_data\"\n\n\t\/\/ DNS \u00fczerinden cache Pod'lar\u0131n\u0131n IP adreslerini bul\n\tips, err := net.LookupHost(cacheServiceDNS)\n\tif err != nil {\n\t\tlog.Fatalf(\"Cache servis IP adresleri bulunamad\u0131: %v\", err)\n\t}\n\n\tfmt.Printf(\"Ke\u015ffedilen \u00f6nbellek Pod IP'leri: %v\\n\", ips)\n\n\t\/\/ Her bir Pod'a ge\u00e7ersiz k\u0131lma iste\u011fi g\u00f6nder\n\tfor _, ip := range ips {\n\t\tcacheURL := fmt.Sprintf(\"http:\/\/%s:8080%s\", ip, invalidationEndpoint)\n\t\tfmt.Printf(\"G\u00f6nderilen ge\u00e7ersiz k\u0131lma iste\u011fi: %s\\n\", cacheURL)\n\n\t\tresp, err := http.Get(cacheURL)\n\t\tif err != nil {\n\t\t\tlog.Printf(\"\u00d6nbellek ge\u00e7ersiz k\u0131lma iste\u011fi ba\u015far\u0131s\u0131z oldu %s: %v\", ip, err)\n\t\t\tcontinue\n\t\t}\n\t\tdefer resp.Body.Close()\n\n\t\tbody, _ := ioutil.ReadAll(resp.Body)\n\t\tfmt.Printf(\"\u00d6nbellek Pod %s yan\u0131t\u0131: %s\\n\", ip, string(body))\n\t}\n\n\tfmt.Println(\"T\u00fcm \u00f6nbellek Pod'lar\u0131na ge\u00e7ersiz k\u0131lma iste\u011fi g\u00f6nderildi.\")\n}\n<\/pre>\nMesajla\u015fma Protokol\u00fc<\/h4>\n
Avantajlar, Dezavantajlar ve Dikkat Edilmesi Gerekenler<\/h3>\n
\u00c7\u00f6z\u00fcm\u00fcn Faydalar\u0131<\/h4>\n
\n
Potansiyel Zorluklar ve S\u0131n\u0131rlamalar<\/h4>\n
\n
\u00d6l\u00e7eklenebilirlik ve G\u00fcvenlik Konular\u0131<\/h4>\n
Sonu\u00e7<\/h3>\n
SSS (S\u0131k Sorulan Sorular)<\/h3>\n
1. Neden headless servis kullanmak yerine Redis Pub\/Sub gibi bir y\u00f6ntem tercih etmedik?<\/h4>\n
2. Bu \u00e7\u00f6z\u00fcm, t\u00fcm \u00f6nbellek ge\u00e7ersiz k\u0131lma senaryolar\u0131 i\u00e7in uygun mudur?<\/h4>\n
3. Ge\u00e7ersiz k\u0131lma iste\u011fi g\u00f6nderilirken bir Pod'un kapand\u0131\u011f\u0131 veya yeni bir Pod'un ba\u015flad\u0131\u011f\u0131 durumda ne olur?<\/h4>\n
net.LookupHost<\/code> \u00e7a\u011fr\u0131s\u0131 anl\u0131k olarak o anki aktif Pod'lar\u0131n IP adreslerini d\u00f6nd\u00fcr\u00fcr. E\u011fer bir Pod tam da istek g\u00f6nderilirken kapan\u0131rsa, o Pod'a yap\u0131lan istek ba\u015far\u0131s\u0131z olur ve istemci uygulamas\u0131n\u0131n bu hatay\u0131 ele almas\u0131 gerekir (\u00f6rne\u011fin, loglama veya yeniden deneme). E\u011fer yeni bir Pod ba\u015flarsa, bir sonraki net.LookupHost<\/code> \u00e7a\u011fr\u0131s\u0131nda bu yeni Pod'un IP adresi de listeye dahil edilecektir. DNS TTL de\u011ferleri, bu dinamikli\u011fi etkileyebilir; genellikle k\u0131sa TTL de\u011ferleri tercih edilir.<\/p>\n4. Bu yakla\u015f\u0131m\u0131n g\u00fcvenlik etkileri nelerdir?<\/h4>\n
5. Bu \u00e7\u00f6z\u00fcmde DNS \u00f6nbelleklemesi bir sorun te\u015fkil eder mi?<\/h4>\n