Kubernetes projelerinizde klas\u00f6r karma\u015fas\u0131ndan s\u0131k\u0131ld\u0131n\u0131z m\u0131? \u00d6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k yap\u0131larla u\u011fra\u015f\u0131rken, manifest dosyalar\u0131n\u0131n kayboldu\u011fu, ortamlar aras\u0131 konfig\u00fcrasyonlar\u0131n kar\u0131\u015ft\u0131\u011f\u0131 anlar ya\u015fanabilir. Bu detayl\u0131 rehberde, en iyi uygulamalar\u0131 takip ederek d\u00fczenli, s\u00fcrd\u00fcr\u00fclebilir ve y\u00f6netilebilir bir Kubernetes proje klas\u00f6r yap\u0131s\u0131 olu\u015fturmay\u0131 ad\u0131m ad\u0131m \u00f6\u011frenecek, karma\u015f\u0131kl\u0131\u011f\u0131 ortadan kald\u0131rarak verimlili\u011finizi art\u0131racaks\u0131n\u0131z. Haydi, projelerinizi d\u00fczene sokmaya ba\u015flayal\u0131m!<\/p>\n
Modern uygulama geli\u015ftirme s\u00fcre\u00e7lerinde, mikroservis mimarileri ve DevOps prensipleriyle birlikte Kubernetes, da\u011f\u0131t\u0131k sistemlerin y\u00f6netiminde vazge\u00e7ilmez bir ara\u00e7 haline geldi. Ancak Kubernetes’in g\u00fcc\u00fc, do\u011fru bir yap\u0131land\u0131rma ve y\u00f6netim stratejisi olmadan kolayca bir karma\u015faya d\u00f6n\u00fc\u015febilir. \u0130\u015fte tam da bu noktada, iyi d\u00fc\u015f\u00fcn\u00fclm\u00fc\u015f bir proje klas\u00f6r yap\u0131s\u0131 devreye girer. Bir d\u00fc\u015f\u00fcn\u00fcn, yeni bir ekip \u00fcyesi projenize kat\u0131ld\u0131\u011f\u0131nda veya siz acil bir hatay\u0131 d\u00fczeltmek i\u00e7in h\u0131zl\u0131ca ilgili manifest dosyas\u0131na ula\u015fman\u0131z gerekti\u011finde, arad\u0131\u011f\u0131n\u0131z\u0131 an\u0131nda bulabilmek ne kadar de\u011ferli olurdu? Klas\u00f6r yap\u0131s\u0131, projenin okunabilirli\u011fini, y\u00f6netilebilirli\u011fini ve en \u00f6nemlisi \u00f6l\u00e7eklenebilirli\u011fini do\u011frudan etkileyen temel bir unsurdur.<\/p>\n
D\u00fczenli bir yap\u0131, farkl\u0131 ortamlar (geli\u015ftirme, test, \u00fcretim) i\u00e7in ayr\u0131lm\u0131\u015f konfig\u00fcrasyonlar\u0131 kolayca ay\u0131rt etmenizi sa\u011flar. Bu, yanl\u0131\u015f bir manifest dosyas\u0131n\u0131 yanl\u0131\u015f bir ortama da\u011f\u0131tma riskini minimize ederken, g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 ve sistem kesintilerini \u00f6nlemeye yard\u0131mc\u0131 olur. Ayr\u0131ca, bir projenin ya\u015fam d\u00f6ng\u00fcs\u00fc boyunca bir\u00e7ok de\u011fi\u015fiklikten ge\u00e7ti\u011fi d\u00fc\u015f\u00fcn\u00fcld\u00fc\u011f\u00fcnde, iyi bir klas\u00f6rleme stratejisi, versiyon kontrol sistemleriyle (Git gibi) daha uyumlu \u00e7al\u0131\u015f\u0131r ve de\u011fi\u015fiklikleri takip etmeyi basitle\u015ftirir. \u00d6rne\u011fin, bir Helm chart kullan\u0131yorsan\u0131z, chart’\u0131n \u015fablonlar\u0131n\u0131, de\u011ferlerini ve ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 belirli bir d\u00fczende tutmak, hem chart’\u0131n bak\u0131m\u0131n\u0131 kolayla\u015ft\u0131r\u0131r hem de ba\u015fkalar\u0131n\u0131n onu kullanmas\u0131n\u0131 anla\u015f\u0131l\u0131r hale getirir. K\u0131sacas\u0131, Kubernetes projelerinizdeki d\u00fczen, sadece estetik bir tercih de\u011fil, ayn\u0131 zamanda operasyonel m\u00fckemmelli\u011fin ve h\u0131zl\u0131 teslimat\u0131n temel ta\u015f\u0131d\u0131r. Karma\u015f\u0131k yap\u0131lar genellikle hatalara, gecikmelere ve y\u00fcksek bak\u0131m maliyetlerine yol a\u00e7arken, basit ve anla\u015f\u0131l\u0131r bir yap\u0131, ekibin daha verimli \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayarak inovasyona odaklanmas\u0131na olanak tan\u0131r. Unutmay\u0131n, iyi bir yap\u0131land\u0131rma, projenizin gelecekteki b\u00fcy\u00fcmesini ve adaptasyonunu destekler.<\/p>\n
Peki, bu d\u00fczeni nas\u0131l sa\u011flamal\u0131y\u0131z? Kubernetes d\u00fcnyas\u0131nda standart bir klas\u00f6r yap\u0131s\u0131 olmamakla birlikte, sekt\u00f6rde kabul g\u00f6rm\u00fc\u015f “en iyi uygulamalar” bulunmaktad\u0131r. Bu uygulamalar, \u00e7o\u011fu projenin ihtiya\u00e7lar\u0131na uyacak esneklikte tasarlanm\u0131\u015ft\u0131r ve projenizin \u00f6l\u00e7e\u011fi veya karma\u015f\u0131kl\u0131\u011f\u0131 ne olursa olsun size yol g\u00f6sterebilir. A\u015fa\u011f\u0131daki b\u00f6l\u00fcmlerde, bu pratik yakla\u015f\u0131mlar\u0131 ad\u0131m ad\u0131m inceleyece\u011fiz. Amac\u0131m\u0131z, sadece d\u00fczeni sa\u011flamak de\u011fil, ayn\u0131 zamanda CI\/CD s\u00fcre\u00e7leriyle entegrasyonu kolayla\u015ft\u0131rmak ve tak\u0131m i\u00e7i i\u015fbirli\u011fini g\u00fc\u00e7lendirmektir. Unutulmamal\u0131d\u0131r ki, iyi bir ba\u015flang\u0131\u00e7, uzun vadede zaman ve kaynak tasarrufu demektir.<\/p>\n
Her b\u00fcy\u00fck yolculuk gibi, Kubernetes proje klas\u00f6r yap\u0131n\u0131z\u0131 olu\u015fturmaya ba\u015flamak da temel ad\u0131mlarla ba\u015flar. Genellikle, bir Kubernetes projesi, birden fazla uygulamay\u0131 veya tek bir mikroservisi bar\u0131nd\u0131rabilir. Bu ilk a\u015famada, projenizin genel mimarisini g\u00f6z \u00f6n\u00fcnde bulundurarak, manifest dosyalar\u0131n\u0131z\u0131 ve ilgili konfig\u00fcrasyonlar\u0131n\u0131z\u0131 nas\u0131l grupland\u0131raca\u011f\u0131n\u0131z\u0131 d\u00fc\u015f\u00fcnmelisiniz. En yayg\u0131n ve anla\u015f\u0131l\u0131r yakla\u015f\u0131mlardan biri, her uygulama veya mikroservis i\u00e7in ayr\u0131 bir k\u00f6k klas\u00f6r olu\u015fturmak ve bu klas\u00f6rlerin alt\u0131nda Kubernetes kaynaklar\u0131n\u0131 organize etmektir.<\/p>\n
\u00d6ncelikle, projenizin ana dizininde bir <\/code><\/p>\n Bu temel yap\u0131land\u0131rmada, her servis kendi klas\u00f6r\u00fc alt\u0131nda bar\u0131nd\u0131r\u0131l\u0131r. Bu ilk d\u00fczenleme, projenizin ba\u015flang\u0131c\u0131nda bile b\u00fcy\u00fck bir fark yaratacakt\u0131r. Ekip \u00fcyeleri, belirli bir servisin da\u011f\u0131t\u0131m manifestlerine h\u0131zla ula\u015fabilir ve de\u011fi\u015fiklik yapabilir. Ayr\u0131ca, bu yap\u0131, daha sonra Kustomize veya Helm gibi ara\u00e7larla dinamik konfig\u00fcrasyon y\u00f6netimine ge\u00e7i\u015f yaparken size sa\u011flam bir zemin sunar. Manifest dosyalar\u0131n\u0131za ad verirken de tutarl\u0131 olmak \u00f6nemlidir; \u00f6rne\u011fin, Unutmay\u0131n, iyi bir klas\u00f6r yap\u0131s\u0131 ayn\u0131 zamanda iyi bir dok\u00fcmantasyonla birle\u015fmelidir. Kubernetes projelerinde manifest dosyalar\u0131n\u0131n d\u00fczenlenmesi, projenin genel sa\u011fl\u0131\u011f\u0131 ve s\u00fcrd\u00fcr\u00fclebilirli\u011fi i\u00e7in kritik bir \u00f6neme sahiptir. Her bir uygulama veya mikroservis i\u00e7in ayr\u0131 bir dizin olu\u015fturmak, mant\u0131ksal bir ayr\u0131m sa\u011flar ve ilgili kaynaklar\u0131n bir arada bulunmas\u0131n\u0131 garanti eder. Bu yakla\u015f\u0131m, \u00f6zellikle \u00e7ok say\u0131da servisi olan b\u00fcy\u00fck monorepo projelerinde veya birden fazla mikroservisi y\u00f6netirken i\u015f ak\u0131\u015f\u0131n\u0131 basitle\u015ftirir. \u00d6rne\u011fin, Bu dizinin i\u00e7inde, Bu dosyalar\u0131n her biri, ilgili Kubernetes kayna\u011f\u0131n\u0131n amac\u0131n\u0131 a\u00e7\u0131k\u00e7a belirtmeli ve m\u00fcmk\u00fcn oldu\u011funca jenerik olmal\u0131d\u0131r. Yani, bu Ayr\u0131ca, her bir manifest dosyas\u0131, okunabilirli\u011fi art\u0131rmak ve bak\u0131m\u0131 kolayla\u015ft\u0131rmak i\u00e7in yorumlarla desteklenmelidir. \u00d6zellikle karma\u015f\u0131k veya al\u0131\u015f\u0131lmad\u0131k konfig\u00fcrasyonlar i\u00e7in k\u0131sa a\u00e7\u0131klamalar eklemek, gelecekteki kendinize veya ekip arkada\u015flar\u0131n\u0131za b\u00fcy\u00fck kolayl\u0131k sa\u011flayacakt\u0131r. \u00d6rne\u011fin:<\/p>\n <\/code><\/p>\n Bu yap\u0131, uygulaman\u0131n temel ihtiya\u00e7lar\u0131n\u0131 net bir \u015fekilde ortaya koyar ve geli\u015ftiricilerin, operasyon ekiplerinin ve otomasyon ara\u00e7lar\u0131n\u0131n projeyi anlamas\u0131n\u0131 ve y\u00f6netmesini kolayla\u015ft\u0131r\u0131r. Tekrar eden konfig\u00fcrasyonlar\u0131 \u00f6nlemek i\u00e7in Kubernetes projelerinde ortama \u00f6zel konfig\u00fcrasyonlar\u0131 y\u00f6netmek, ba\u015far\u0131l\u0131 bir da\u011f\u0131t\u0131m stratejisinin temel direklerinden biridir. Geli\u015ftirme, test (staging) ve \u00fcretim (production) gibi farkl\u0131 ortamlar\u0131n kendine \u00f6zg\u00fc gereksinimleri vard\u0131r; bu, genellikle farkl\u0131 kopya say\u0131lar\u0131, kaynak limitleri, etiketler, Ingress kurallar\u0131 veya ConfigMap de\u011ferleri anlam\u0131na gelir. Bu farkl\u0131l\u0131klar\u0131 y\u00f6netmek i\u00e7in en etkili yol, temel (base) manifest dosyalar\u0131n\u0131z\u0131n \u00fczerine \"overlays\" (kaplamalar) olu\u015fturmakt\u0131r.<\/p>\n Bu yakla\u015f\u0131m\u0131 uygulamak i\u00e7in, her uygulama dizininin alt\u0131nda, Bir \u00f6rnekle a\u00e7\u0131klayal\u0131m:<\/p>\n <\/code><\/p>\n Bu yap\u0131da, Her bir <\/code><\/p>\n Bu y\u00f6ntem, manifest dosyas\u0131nda tekrar eden kod miktar\u0131n\u0131 en aza indirir ve ortamlar aras\u0131 tutarl\u0131l\u0131\u011f\u0131 garanti eder. Ayr\u0131ca, bir de\u011fi\u015fiklik yap\u0131ld\u0131\u011f\u0131nda, bu de\u011fi\u015fikli\u011fin sadece belirli bir ortam\u0131 m\u0131 yoksa t\u00fcm ortamlar\u0131 m\u0131 etkileyece\u011fini anlamak kolayla\u015f\u0131r. \u00d6rne\u011fin, bir servisin genel bir \u00f6zelli\u011fi de\u011fi\u015fti\u011finde sadece Son olarak, hassas verileri (\u015fifreler, API anahtarlar\u0131) do\u011frudan Git deposunda saklamaktan kesinlikle ka\u00e7\u0131n\u0131lmal\u0131d\u0131r. Bunun yerine, Kubernetes Secret'lar\u0131, HashiCorp Vault veya s\u0131zd\u0131rmazl\u0131k ara\u00e7lar\u0131 (Sealed Secrets gibi) kullan\u0131lmal\u0131d\u0131r. Manifestlerde Secret referanslar\u0131 bulunabilir, ancak Secret'\u0131n kendisi asla depoya commit edilmemelidir. Bu, g\u00fcvenlik a\u00e7\u0131s\u0131ndan kritik bir uygulamad\u0131r ve her zaman \u00f6ncelikli olarak de\u011ferlendirilmelidir. Ortama \u00f6zel konfig\u00fcrasyonlar\u0131n do\u011fru bir \u015fekilde y\u00f6netilmesi, projenizin olgunlu\u011funu ve profesyonelli\u011fini g\u00f6steren \u00f6nemli bir i\u015farettir.<\/p>\n Modern yaz\u0131l\u0131m geli\u015ftirmede, projenizin b\u00fcy\u00fckl\u00fc\u011f\u00fcne ve tak\u0131m\u0131n\u0131z\u0131n yap\u0131s\u0131na ba\u011fl\u0131 olarak iki ana kod y\u00f6netimi stratejisi \u00f6ne \u00e7\u0131kar: polirepo (her mikroservis\/uygulama i\u00e7in ayr\u0131 bir depo) ve monorepo (t\u00fcm mikroservisler\/uygulamalar tek bir depoda). Kubernetes ortam\u0131nda, monorepo yakla\u015f\u0131m\u0131n\u0131n kendine \u00f6zg\u00fc avantajlar\u0131 ve iyi d\u00fc\u015f\u00fcn\u00fclm\u00fc\u015f bir klas\u00f6r yap\u0131s\u0131yla birle\u015fti\u011finde sundu\u011fu faydalar bulunmaktad\u0131r.<\/p>\n Monorepo, ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 gibi, birden fazla projenin veya uygulaman\u0131n tek bir Git deposunda bar\u0131nd\u0131r\u0131ld\u0131\u011f\u0131 bir yakla\u015f\u0131md\u0131r. Kubernetes ba\u011flam\u0131nda, bu, hem uygulama kaynak kodunu hem de ilgili Kubernetes manifestlerini ayn\u0131 depoda tutmak anlam\u0131na gelir. Klasik bir monorepo yap\u0131s\u0131 \u015fu \u015fekilde g\u00f6r\u00fcnebilir:<\/p>\n <\/code><\/p>\n Bu yap\u0131da, Peki, bu yakla\u015f\u0131m\u0131n avantajlar\u0131 nelerdir? \u00d6ncelikle, ba\u011f\u0131ml\u0131l\u0131k y\u00f6netimi<\/strong> basitle\u015fir. Uygulamalar aras\u0131 kod payla\u015f\u0131m\u0131 daha kolay hale gelir, \u00e7\u00fcnk\u00fc t\u00fcm kod ayn\u0131 depoda bulunur. Bir k\u00fct\u00fcphanede yap\u0131lan de\u011fi\u015fiklikler, ba\u011f\u0131ml\u0131 olan t\u00fcm uygulamalarda an\u0131nda g\u00f6r\u00fcn\u00fcr hale gelir ve CI\/CD s\u00fcre\u00e7leri bu de\u011fi\u015fikliklerin t\u00fcm sistemi nas\u0131l etkiledi\u011fini daha kolay test edebilir. \u0130kinci olarak, atomik de\u011fi\u015fiklikler<\/strong> (atomic changes) yapma yetene\u011fi b\u00fcy\u00fck bir avantajd\u0131r. Bir \u00f6zellik, birden fazla mikroserviste de\u011fi\u015fiklik gerektirdi\u011finde, bu de\u011fi\u015fiklikler tek bir Git commit'i i\u00e7inde yap\u0131labilir ve t\u00fcm ilgili servisler ayn\u0131 anda da\u011f\u0131t\u0131labilir. Bu, da\u011f\u0131t\u0131m koordinasyonunu b\u00fcy\u00fck \u00f6l\u00e7\u00fcde basitle\u015ftirir ve \"deploy hell\" sendromunu azalt\u0131r.<\/p>\n \u00dc\u00e7\u00fcnc\u00fc olarak, tutarl\u0131l\u0131k ve kod tekrar\u0131<\/strong> azal\u0131r. Ortak Kubernetes manifest \u015fablonlar\u0131, CI\/CD boru hatlar\u0131 ve geli\u015ftirme ortam\u0131 konfig\u00fcrasyonlar\u0131 merkezi bir \u015fekilde y\u00f6netilebilir. Bu, farkl\u0131 mikroservislerde ayn\u0131 veya benzer konfig\u00fcrasyonlar\u0131 tekrar tekrar yazma ihtiyac\u0131n\u0131 ortadan kald\u0131r\u0131r. D\u00f6rd\u00fcnc\u00fc olarak, CI\/CD s\u00fcre\u00e7leri<\/strong> daha entegre ve verimli hale gelebilir. T\u00fcm kodun tek bir yerde olmas\u0131, tek bir boru hatt\u0131n\u0131n birden fazla uygulamay\u0131 derlemesini, test etmesini ve da\u011f\u0131tmas\u0131n\u0131 sa\u011flar. Ak\u0131ll\u0131 CI\/CD sistemleri, sadece de\u011fi\u015fen uygulamalar\u0131 tespit edip onlar\u0131 da\u011f\u0131tabilir, bu da kaynak kullan\u0131m\u0131n\u0131 optimize eder.<\/p>\n Elbette, monorepo'nun da zorluklar\u0131 vard\u0131r; \u00f6rne\u011fin, depo boyutu b\u00fcy\u00fcyebilir, klonlama s\u00fcreleri uzayabilir ve tek bir depoda \u00e7ok fazla geli\u015ftiricinin \u00e7al\u0131\u015fmas\u0131 merge \u00e7ak\u0131\u015fmalar\u0131na yol a\u00e7abilir. Ancak, iyi bir klas\u00f6r yap\u0131s\u0131, g\u00fc\u00e7l\u00fc bir versiyon kontrol stratejisi (\u00f6rne\u011fin, trunk-based development) ve ak\u0131ll\u0131 CI\/CD ara\u00e7lar\u0131yla bu zorluklar\u0131n \u00fcstesinden gelinebilir. \u00d6zellikle k\u00fc\u00e7\u00fck ve orta \u00f6l\u00e7ekli tak\u0131mlar i\u00e7in, monorepo, Kubernetes projelerinde verimlili\u011fi ve koordinasyonu art\u0131ran g\u00fc\u00e7l\u00fc bir yakla\u015f\u0131md\u0131r. Karma\u015f\u0131k da\u011f\u0131t\u0131k sistemlerin y\u00f6netimini basitle\u015ftirme potansiyeli g\u00f6z ard\u0131 edilmemelidir.<\/p>\n Kubernetes manifest dosyalar\u0131n\u0131n manuel olarak d\u00fczenlenmesi ve s\u00fcrd\u00fcr\u00fclmesi, projenizin boyutu artt\u0131k\u00e7a giderek daha zahmetli ve hata yapmaya a\u00e7\u0131k hale gelir. \u0130\u015fte bu noktada Helm ve Kustomize gibi ara\u00e7lar devreye girerek dinamik konfig\u00fcrasyon y\u00f6netimi i\u00e7in g\u00fc\u00e7l\u00fc \u00e7\u00f6z\u00fcmler sunar. Bu ara\u00e7lar, temel klas\u00f6r yap\u0131m\u0131z\u0131 tamamlayarak, ortama \u00f6zel de\u011fi\u015fiklikleri, \u015fablonlamay\u0131 ve paketlemeyi kolayla\u015ft\u0131r\u0131r. Her ikisinin de kendi kullan\u0131m senaryolar\u0131 ve avantajlar\u0131 bulunmaktad\u0131r.<\/p>\n Helm, Kubernetes i\u00e7in bir paket y\u00f6neticisi olarak \u00f6ne \u00e7\u0131kar. Uygulamalar\u0131 \"chart\" ad\u0131 verilen \u00f6nceden yap\u0131land\u0131r\u0131lm\u0131\u015f paketler halinde tan\u0131mlaman\u0131z\u0131, kurman\u0131z\u0131 ve y\u00f6netmenizi sa\u011flar. Bir Helm chart'\u0131, bir uygulaman\u0131n t\u00fcm Kubernetes kaynaklar\u0131n\u0131 (Deployment, Service, Ingress vb.) i\u00e7erir ve bu kaynaklar\u0131 Go \u015fablonlama diliyle dinamik hale getirir. Klas\u00f6r yap\u0131m\u0131z i\u00e7inde Helm'i kullanmak istedi\u011fimizde, her bir uygulamam\u0131z i\u00e7in ayr\u0131 bir Helm chart'\u0131 olu\u015fturabiliriz:<\/p>\n <\/code><\/p>\n Bu yap\u0131da, <\/code><\/p>\n Helm, bir uygulaman\u0131n t\u00fcm ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 ve ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc y\u00f6netmek i\u00e7in idealdir. Bir veritaban\u0131 veya kuyruk sistemi gibi karma\u015f\u0131k ba\u011f\u0131ml\u0131l\u0131klar\u0131 olan uygulamalar\u0131 tek bir Helm chart'\u0131 arac\u0131l\u0131\u011f\u0131yla kolayca da\u011f\u0131tabilirsiniz.<\/p>\n Kustomize, Helm'den farkl\u0131 olarak \u015fablonlama motoru kullanmaz. Bunun yerine, mevcut, jenerik Kubernetes manifestlerini \"yamalar\" (patches) kullanarak \u00f6zelle\u015ftirmenizi sa\u011flar. Bu, \"template-free\" (\u015fablonsuz) yakla\u015f\u0131m olarak bilinir ve genellikle daha basit ve anla\u015f\u0131l\u0131r bir yap\u0131 sunar. Kustomize, \u00f6zellikle <\/code><\/p>\n Her <\/code><\/p>\n <\/code> Kustomize'\u0131n ana g\u00fcc\u00fc, \"diff\" tabanl\u0131 bir yakla\u015f\u0131m sunarak sadece de\u011fi\u015fen k\u0131s\u0131mlar\u0131 y\u00f6netmesidir. Bu, \u015fablonlamaya g\u00f6re daha az karma\u015f\u0131k olabilir ve mevcut manifestleri d\u00fczenlemeniz gerekti\u011finde daha do\u011frudan bir kontrol sa\u011flar. Hem Helm hem de Kustomize, CI\/CD boru hatlar\u0131n\u0131zla entegre edilebilir ve Kubernetes da\u011f\u0131t\u0131mlar\u0131n\u0131z\u0131 otomatikle\u015ftirmek i\u00e7in kullan\u0131labilir. Se\u00e7iminiz, projenizin karma\u015f\u0131kl\u0131\u011f\u0131na, ekibinizin al\u0131\u015fkanl\u0131klar\u0131na ve belirli gereksinimlerinize ba\u011fl\u0131 olacakt\u0131r. Baz\u0131 projelerde her iki arac\u0131n bir kombinasyonu bile kullan\u0131labilir; \u00f6rne\u011fin, Helm chart'lar\u0131 Kustomize ile \u00f6zelle\u015ftirilebilir. Bu ara\u00e7lar, iyi bir klas\u00f6r yap\u0131s\u0131yla birle\u015fti\u011finde, Kubernetes konfig\u00fcrasyon y\u00f6netimini bamba\u015fka bir seviyeye ta\u015f\u0131r.<\/p>\n Modern DevOps d\u00fcnyas\u0131nda, GitOps ve S\u00fcrekli Entegrasyon\/S\u00fcrekli Da\u011f\u0131t\u0131m (CI\/CD) kavramlar\u0131 Kubernetes ile el ele gider. GitOps, operasyonel altyap\u0131n\u0131n durumunu y\u00f6netmek i\u00e7in Git depolar\u0131n\u0131 tek do\u011fru kaynak (single source of truth) olarak kullan\u0131r. Bu yakla\u015f\u0131m, altyap\u0131y\u0131 kod olarak ele al\u0131r ve Git'in versiyon kontrol, de\u011fi\u015fiklik izleme ve i\u015fbirli\u011fi \u00f6zelliklerini altyap\u0131 y\u00f6netimine ta\u015f\u0131r. CI\/CD boru hatlar\u0131 ise, kod de\u011fi\u015fikliklerinin otomatik olarak derlenmesini, test edilmesini ve da\u011f\u0131t\u0131lmas\u0131n\u0131 sa\u011flar. Bu g\u00fc\u00e7l\u00fc entegrasyonun temelinde, iyi d\u00fc\u015f\u00fcn\u00fclm\u00fc\u015f ve sistematik bir klas\u00f6r yap\u0131s\u0131 yatar.<\/p>\n Klas\u00f6r yap\u0131n\u0131z, GitOps ve CI\/CD s\u00fcre\u00e7lerinizin verimlili\u011fini ve g\u00fcvenilirli\u011fini do\u011frudan etkiler. E\u011fer manifest dosyalar\u0131n\u0131z da\u011f\u0131n\u0131k, tutars\u0131z veya ortama \u00f6zel de\u011fi\u015fiklikleri y\u00f6netmekte zorlan\u0131yorsa, otomasyon s\u00fcre\u00e7lerinizde hatalar meydana gelmesi ka\u00e7\u0131n\u0131lmazd\u0131r. \u0130yi bir klas\u00f6r yap\u0131s\u0131, CI\/CD ara\u00e7lar\u0131n\u0131n do\u011fru manifestleri bulmas\u0131n\u0131, ortamlar aras\u0131 farkl\u0131l\u0131klar\u0131 uygulamas\u0131n\u0131 ve da\u011f\u0131t\u0131m\u0131n g\u00fcvenli bir \u015fekilde ger\u00e7ekle\u015fmesini sa\u011flar.<\/p>\n GitOps'ta, Kubernetes k\u00fcmenizin mevcut durumu (beklenen durum) Git deposundaki manifest dosyalar\u0131yla temsil edilir. Git deposunda yap\u0131lan her de\u011fi\u015fiklik (commit), k\u00fcme \u00fczerinde bir de\u011fi\u015fime yol a\u00e7ar. Bu modelde, klas\u00f6r yap\u0131n\u0131z\u0131n a\u015fa\u011f\u0131daki \u00f6zellikleri ta\u015f\u0131mas\u0131 kritik \u00f6nemdedir:<\/p>\n Bir GitOps ak\u0131\u015f\u0131nda, geli\u015ftirici bir kod de\u011fi\u015fikli\u011fi yapar, bu de\u011fi\u015fiklik testlerden ge\u00e7er ve bir Pull Request (PR) ile Git deposuna merge edilir. Kubernetes manifest dosyalar\u0131 da ayn\u0131 \u015fekilde (veya ayr\u0131 bir depoda) y\u00f6netilir. GitOps operat\u00f6r\u00fc, Git deposundaki manifest de\u011fi\u015fikliklerini s\u00fcrekli olarak izler ve k\u00fcmenin durumunu bu de\u011fi\u015fikliklere g\u00f6re g\u00fcnceller. E\u011fer klas\u00f6r yap\u0131s\u0131 karma\u015f\u0131ksa, bu izleme ve senkronizasyon s\u00fcre\u00e7leri ba\u015far\u0131s\u0131z olabilir veya yanl\u0131\u015f kaynaklar\u0131 g\u00fcncelleyebilir.<\/p>\n CI\/CD boru hatlar\u0131, kod ve konfig\u00fcrasyon de\u011fi\u015fikliklerinin h\u0131zl\u0131 ve g\u00fcvenilir bir \u015fekilde da\u011f\u0131t\u0131m\u0131n\u0131 sa\u011flamak i\u00e7in tasarlanm\u0131\u015ft\u0131r. Klas\u00f6r yap\u0131n\u0131z, CI\/CD ad\u0131mlar\u0131n\u0131z\u0131n mant\u0131ksal olarak d\u00fczenlenmesine ve optimize edilmesine yard\u0131mc\u0131 olur:<\/p>\n <\/code><\/p>\n Yukar\u0131daki \u00f6rnekte, GitHub Actions'\u0131n Teorik bilgilerin \u00f6tesine ge\u00e7erek, ger\u00e7ek d\u00fcnya senaryolar\u0131nda iyi bir Kubernetes klas\u00f6r yap\u0131s\u0131n\u0131n nas\u0131l bir fark yaratt\u0131\u011f\u0131n\u0131 anlamak \u00f6nemlidir. Hayal edelim ki, \"GlobalConnect\" ad\u0131nda, d\u00fcnya genelinde milyonlarca kullan\u0131c\u0131ya hizmet veren bir e-ticaret platformu geli\u015ftiriyorsunuz. Bu platform, mikroservis mimarisinde tasarlanm\u0131\u015f olup, 50'den fazla farkl\u0131 mikroservis, \u00e7e\u015fitli \u00fc\u00e7\u00fcnc\u00fc taraf entegrasyonlar\u0131 ve farkl\u0131 co\u011frafi b\u00f6lgelerde konu\u015fland\u0131r\u0131lm\u0131\u015f Kubernetes k\u00fcmeleri i\u00e7ermektedir. Proje ba\u015flang\u0131c\u0131nda, ekip k\u00fc\u00e7\u00fckken manifestler tek bir dizinde tutulmu\u015f, ancak b\u00fcy\u00fcme ile birlikte kontrol edilemez bir karma\u015fa ortaya \u00e7\u0131km\u0131\u015ft\u0131r.<\/p>\n GlobalConnect'in ilk a\u015famalar\u0131nda, t\u00fcm Bu sorunlar\u0131 \u00e7\u00f6zmek i\u00e7in GlobalConnect ekibi, kapsaml\u0131 bir yeniden yap\u0131land\u0131rma projesi ba\u015flatt\u0131 ve a\u015fa\u011f\u0131daki klas\u00f6r yap\u0131s\u0131n\u0131 benimsedi:<\/p>\n <\/code><\/p>\n Bu yeni yap\u0131land\u0131rma ile birlikte a\u015fa\u011f\u0131daki iyile\u015ftirmeler yap\u0131ld\u0131:<\/p>\n Bu yeniden yap\u0131land\u0131rma sayesinde GlobalConnect ekibi \u00f6nemli kazan\u0131mlar elde etti:<\/p>\n Bu vaka analizi, iyi bir Kubernetes proje klas\u00f6r yap\u0131s\u0131n\u0131n, ara\u00e7 entegrasyonlar\u0131 (Kustomize, Helm, Argo CD) ve otomatize CI\/CD s\u00fcre\u00e7leriyle birle\u015fti\u011finde, b\u00fcy\u00fck \u00f6l\u00e7ekli ve karma\u015f\u0131k projelerde dahi y\u00f6netilebilirli\u011fi, verimlili\u011fi ve g\u00fcvenilirli\u011fi nas\u0131l art\u0131rabilece\u011fini a\u00e7\u0131k\u00e7a g\u00f6stermektedir. Ba\u015far\u0131l\u0131 bir yap\u0131, sadece kodun de\u011fil, t\u00fcm operasyonel ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fcn temelini olu\u015fturur.<\/p>\n Kubernetes ekosisteminde proje klas\u00f6r yap\u0131s\u0131n\u0131n \u00f6nemi, \u00e7o\u011fu zaman g\u00f6z ard\u0131 edilen ancak projenizin uzun vadeli ba\u015far\u0131s\u0131 ve s\u00fcrd\u00fcr\u00fclebilirli\u011fi i\u00e7in kritik bir fakt\u00f6rd\u00fcr. Bu rehber boyunca ele ald\u0131\u011f\u0131m\u0131z gibi, iyi d\u00fc\u015f\u00fcn\u00fclm\u00fc\u015f bir yap\u0131land\u0131rma, sadece ba\u015flang\u0131\u00e7taki d\u00fczeni sa\u011flamakla kalmaz, ayn\u0131 zamanda projenizin b\u00fcy\u00fcmesiyle ortaya \u00e7\u0131kabilecek karma\u015f\u0131kl\u0131klar\u0131 y\u00f6netme yetene\u011finizi de art\u0131r\u0131r. Geli\u015ftirme s\u00fcrecinin h\u0131z\u0131ndan, operasyonel verimlili\u011fe, hata oranlar\u0131n\u0131n d\u00fc\u015f\u00fcr\u00fclmesinden ekip i\u00e7i i\u015fbirli\u011finin g\u00fc\u00e7lendirilmesine kadar bir\u00e7ok alanda olumlu etkiler yarat\u0131r.<\/p>\n Ba\u015flang\u0131\u00e7ta basit bir Herhangi bir projenin \"tek do\u011fru\" klas\u00f6r yap\u0131s\u0131 olmasa da, bu rehberde sunulan \"en iyi uygulamalar\", deneyimlerden dam\u0131t\u0131lm\u0131\u015f ve sekt\u00f6rde geni\u015f kabul g\u00f6rm\u00fc\u015f prensiplere dayan\u0131r. Bu prensipleri kendi projenize uygulayarak, Kubernetes kaynaklar\u0131n\u0131z\u0131n okunabilirli\u011fini, bak\u0131m\u0131n\u0131 ve \u00f6l\u00e7eklenebilirli\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde geli\u015ftirebilirsiniz. Temiz, mod\u00fcler ve iyi organize edilmi\u015f bir klas\u00f6r yap\u0131s\u0131, projenizin sadece bug\u00fcn\u00fcn\u00fc de\u011fil, gelecekteki b\u00fcy\u00fcmesini ve adaptasyonunu da destekleyen g\u00fc\u00e7l\u00fc bir temel olu\u015fturur. B\u00f6ylece, karma\u015f\u0131kl\u0131\u011f\u0131 y\u00f6netilebilir hale getirirken, ekipleriniz inovasyona ve de\u011fer yaratmaya odaklanabilirler. Hadi, projelerinizi bug\u00fcn d\u00fczenlemeye ba\u015flay\u0131n ve Kubernetes'in t\u00fcm potansiyelini ortaya \u00e7\u0131kar\u0131n!<\/p>\nk8s\/<\/code> veya kubernetes\/<\/code> klas\u00f6r\u00fc olu\u015fturmak iyi bir ba\u015flang\u0131\u00e7t\u0131r. Bu klas\u00f6r, t\u00fcm Kubernetes ile ilgili manifest ve konfig\u00fcrasyon dosyalar\u0131n\u0131 i\u00e7erecektir. Ard\u0131ndan, bu ana klas\u00f6r\u00fcn alt\u0131nda, projenizin servislerini veya uygulamalar\u0131n\u0131 temsil eden alt klas\u00f6rler olu\u015fturun. \u00d6rne\u011fin, bir “api-gateway” ve bir “user-service” mikroservisleriniz varsa, yap\u0131 a\u015fa\u011f\u0131daki gibi g\u00f6r\u00fcnebilir:<\/p>\n\nmy-kubernetes-project\/\n\u251c\u2500\u2500 k8s\/\n\u2502 \u251c\u2500\u2500 api-gateway\/\n\u2502 \u2502 \u2514\u2500\u2500 base\/\n\u2502 \u2502 \u251c\u2500\u2500 deployment.yaml\n\u2502 \u2502 \u251c\u2500\u2500 service.yaml\n\u2502 \u2502 \u2514\u2500\u2500 ingress.yaml\n\u2502 \u251c\u2500\u2500 user-service\/\n\u2502 \u2502 \u2514\u2500\u2500 base\/\n\u2502 \u2502 \u251c\u2500\u2500 deployment.yaml\n\u2502 \u2502 \u251c\u2500\u2500 service.yaml\n\u2502 \u2502 \u2514\u2500\u2500 configmap.yaml\n\u2502 \u2514\u2500\u2500 common\/\n\u2502 \u251c\u2500\u2500 namespace.yaml\n\u2502 \u2514\u2500\u2500 rbac.yaml\n\u251c\u2500\u2500 src\/\n\u2502 \u251c\u2500\u2500 api-gateway\/\n\u2502 \u2502 \u2514\u2500\u2500 ... (uygulama kodlar\u0131)\n\u2502 \u2514\u2500\u2500 user-service\/\n\u2502 \u2514\u2500\u2500 ... (uygulama kodlar\u0131)\n\u2514\u2500\u2500 README.md\n<\/pre>\nbase\/<\/code> klas\u00f6r\u00fc, uygulaman\u0131n temel, ortamlardan ba\u011f\u0131ms\u0131z Kubernetes manifest dosyalar\u0131n\u0131 i\u00e7erir. Bu yakla\u015f\u0131m, manifest dosyalar\u0131n\u0131n mant\u0131ksal olarak ayr\u0131lmas\u0131n\u0131 ve her bir servisin kendi ya\u015fam d\u00f6ng\u00fcs\u00fcne sahip olmas\u0131n\u0131 kolayla\u015ft\u0131r\u0131r. common\/<\/code> klas\u00f6r\u00fc ise, t\u00fcm proje veya birden fazla servis taraf\u0131ndan kullan\u0131lan ortak kaynaklar\u0131 (\u00f6rne\u011fin, namespace tan\u0131mlar\u0131, RBAC rolleri) bar\u0131nd\u0131rabilir. Bu, tekrar\u0131 \u00f6nler ve ortak konfig\u00fcrasyonlar\u0131 tek bir yerden y\u00f6netmenize olanak tan\u0131r.<\/p>\ndeployment.yaml<\/code>, service.yaml<\/code> gibi standart isimlendirmeler kullanmak, okunabilirli\u011fi art\u0131r\u0131r.<\/p>\nREADME.md<\/code> dosyas\u0131, projenin genel yap\u0131s\u0131n\u0131, hangi servisin nerede bulundu\u011funu ve nas\u0131l da\u011f\u0131t\u0131laca\u011f\u0131n\u0131 a\u00e7\u0131klamal\u0131d\u0131r. Bu, \u00f6zellikle yeni ekip \u00fcyeleri i\u00e7in \u00f6\u011frenme e\u011frisini \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r. Projeniz b\u00fcy\u00fcd\u00fck\u00e7e bu temel yap\u0131n\u0131n \u00fczerine in\u015fa edilecek \u00e7ok \u015fey olacakt\u0131r, ancak sa\u011flam bir temel her zaman en \u00f6nemli ad\u0131md\u0131r. \u015eimdilik, bu basit ve etkili ba\u015flang\u0131\u00e7 noktas\u0131n\u0131 benimseyerek, Kubernetes projenizin d\u00fczenini sa\u011flam bir \u015fekilde kurmu\u015f olacaks\u0131n\u0131z. Bu sayede, gelecekteki de\u011fi\u015fiklikler ve geni\u015flemeler i\u00e7in haz\u0131rl\u0131kl\u0131 olursunuz.<\/p>\nUygulama Katman\u0131 ve Manifest Dosyalar\u0131 Nas\u0131l D\u00fczenlenir?<\/h3>\n
api-gateway<\/code> ad\u0131nda bir servisiniz varsa, t\u00fcm Kubernetes manifestleri k8s\/api-gateway\/<\/code> alt\u0131nda yer almal\u0131d\u0131r.<\/p>\nbase\/<\/code> ad\u0131nda bir alt dizin olu\u015fturmak, ortama \u00f6zel de\u011fi\u015fiklikler yapmadan \u00f6nce varsay\u0131lan, temel konfig\u00fcrasyonlar\u0131 saklamak i\u00e7in harika bir yoldur. base\/<\/code> dizini tipik olarak a\u015fa\u011f\u0131daki manifest t\u00fcrlerini i\u00e7erir:<\/p>\n\n
deployment.yaml<\/code>: Uygulaman\u0131z\u0131n pod'lar\u0131n\u0131 nas\u0131l \u00e7al\u0131\u015ft\u0131raca\u011f\u0131n\u0131z\u0131 tan\u0131mlar.<\/li>\nservice.yaml<\/code>: Uygulaman\u0131z\u0131n pod'lar\u0131na nas\u0131l eri\u015filece\u011fini belirler.<\/li>\ningress.yaml<\/code> (iste\u011fe ba\u011fl\u0131): D\u0131\u015f d\u00fcnyadan gelen trafi\u011fi uygulaman\u0131za y\u00f6nlendirmek i\u00e7in kullan\u0131l\u0131r.<\/li>\nconfigmap.yaml<\/code>: Uygulaman\u0131z\u0131n yap\u0131land\u0131rma verilerini (ortam de\u011fi\u015fkenleri, ayar dosyalar\u0131) i\u00e7erir.<\/li>\nsecret.yaml<\/code> (g\u00fcvenlik nedeniyle genellikle ba\u015fka bir y\u00f6ntemle y\u00f6netilir, ancak bazen burada placeholder olarak bulunabilir): Hassas verileri bar\u0131nd\u0131r\u0131r.<\/li>\npvc.yaml<\/code> (kal\u0131c\u0131 depolama gerekiyorsa): Pod'lar i\u00e7in kal\u0131c\u0131 depolama talebini tan\u0131mlar.<\/li>\n<\/ul>\nbase\/<\/code> manifestleri, farkl\u0131 da\u011f\u0131t\u0131m ortamlar\u0131nda (dev, staging, prod) herhangi bir de\u011fi\u015fiklik yap\u0131lmadan do\u011frudan da\u011f\u0131t\u0131labilecek \u015fekilde tasarlanmal\u0131d\u0131r. \u00d6rne\u011fin, bir deployment.yaml dosyas\u0131, resim etiketi olarak my-app:latest<\/code> yerine, daha esnek bir \u015fablonlama de\u011fi\u015fkeni (\u00f6rne\u011fin Helm'de {{ .Values.image.tag }}<\/code> veya Kustomize'da yamay\u0131 kolayla\u015ft\u0131racak bir placeholder) kullanabilir. Bu, base\/<\/code> konfig\u00fcrasyonunun genel ge\u00e7erlili\u011fini korur.<\/p>\n\n# deployment.yaml\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: my-app-deployment\n labels:\n app: my-app\nspec:\n replicas: 3 # \u00dcretim ortam\u0131 i\u00e7in varsay\u0131lan kopya say\u0131s\u0131\n selector:\n matchLabels:\n app: my-app\n template:\n metadata:\n labels:\n app: my-app\n spec:\n containers:\n - name: my-app-container\n image: my-registry\/my-app:1.0.0 # Temel imaj etiketi\n ports:\n - containerPort: 8080\n envFrom:\n - configMapRef:\n name: my-app-config\n resources:\n requests:\n cpu: \"100m\"\n memory: \"128Mi\"\n limits:\n cpu: \"200m\"\n memory: \"256Mi\"\n<\/pre>\ncommon\/<\/code> gibi payla\u015f\u0131lan kaynak klas\u00f6rleri kullanmak da ak\u0131ll\u0131ca bir yakla\u015f\u0131md\u0131r. Bu sayede, \u00f6rne\u011fin t\u00fcm servislerinizin kullanaca\u011f\u0131 bir Kubernetes namespace'ini veya genel RBAC politikalar\u0131n\u0131 tek bir yerden y\u00f6netebilirsiniz. Bu d\u00fczenleme, projenizin b\u00fcy\u00fckl\u00fc\u011f\u00fcnden ba\u011f\u0131ms\u0131z olarak, s\u00fcrekli bir d\u00fczen ve verimlilik art\u0131\u015f\u0131 sa\u011flayacakt\u0131r.<\/p>\nOrtama \u00d6zel Konfig\u00fcrasyonlar\u0131 Y\u00f6netmek \u0130\u00e7in En \u0130yi Uygulamalar Nelerdir?<\/h3>\n
environments\/<\/code> veya overlays\/<\/code> ad\u0131nda bir klas\u00f6r olu\u015fturmak yayg\u0131n bir uygulamad\u0131r. Bu klas\u00f6r\u00fcn i\u00e7inde, her ortam i\u00e7in ayr\u0131 bir alt klas\u00f6r bulunur (\u00f6rne\u011fin, dev\/<\/code>, staging\/<\/code>, prod\/<\/code>). Bu alt klas\u00f6rler, base\/<\/code> klas\u00f6r\u00fcndeki manifestleri hedef alan ve ortama \u00f6zel de\u011fi\u015fiklikleri i\u00e7eren manifest dosyalar\u0131n\u0131 bar\u0131nd\u0131r\u0131r.<\/p>\n\nmy-kubernetes-project\/\n\u251c\u2500\u2500 k8s\/\n\u2502 \u251c\u2500\u2500 api-gateway\/\n\u2502 \u2502 \u251c\u2500\u2500 base\/\n\u2502 \u2502 \u2502 \u251c\u2500\u2500 deployment.yaml\n\u2502 \u2502 \u2502 \u251c\u2500\u2500 service.yaml\n\u2502 \u2502 \u2502 \u2514\u2500\u2500 ingress.yaml\n\u2502 \u2502 \u2514\u2500\u2500 overlays\/\n\u2502 \u2502 \u251c\u2500\u2500 dev\/\n\u2502 \u2502 \u2502 \u251c\u2500\u2500 kustomization.yaml\n\u2502 \u2502 \u2502 \u2514\u2500\u2500 replica-patch.yaml\n\u2502 \u2502 \u251c\u2500\u2500 staging\/\n\u2502 \u2502 \u2502 \u251c\u2500\u2500 kustomization.yaml\n\u2502 \u2502 \u2502 \u2514\u2500\u2500 ingress-host.yaml\n\u2502 \u2502 \u2514\u2500\u2500 prod\/\n\u2502 \u2502 \u251c\u2500\u2500 kustomization.yaml\n\u2502 \u2502 \u2514\u2500\u2500 resource-limits.yaml\n\u2502 \u2514\u2500\u2500 user-service\/\n\u2502 \u2514\u2500\u2500 ...\n\u2514\u2500\u2500 ...\n<\/pre>\napi-gateway\/base\/<\/code> dizininde uygulaman\u0131n varsay\u0131lan, jenerik manifestleri yer al\u0131r. Daha sonra overlays\/<\/code> i\u00e7indeki her ortam klas\u00f6r\u00fc, base\/<\/code> manifestlerini al\u0131p \u00fczerine o ortama \u00f6zel yamalar\u0131 (patches) uygular. Bu yamalar genellikle k\u00fc\u00e7\u00fck YAML dosyalar\u0131d\u0131r ve sadece de\u011fi\u015ftirilmesi gereken alanlar\u0131 i\u00e7erir. \u00d6rne\u011fin, prod\/replica-patch.yaml<\/code> dosyas\u0131 sadece \u00fcretim ortam\u0131 i\u00e7in replika say\u0131s\u0131n\u0131 art\u0131rabilir.<\/p>\noverlays\/kustomization.yaml<\/code> dosyas\u0131, Kustomize'\u0131n hangi base\/<\/code> manifestlerini kullanaca\u011f\u0131n\u0131 ve hangi yamalar\u0131 uygulayaca\u011f\u0131n\u0131 belirler. Bu sayede, tek bir komutla ilgili ortama \u00f6zel manifestler olu\u015fturulabilir:<\/p>\n\n# Geli\u015ftirme ortam\u0131 manifestlerini olu\u015fturmak i\u00e7in:\nkubectl apply -k k8s\/api-gateway\/overlays\/dev\/\n\n# \u00dcretim ortam\u0131 manifestlerini olu\u015fturmak i\u00e7in:\nkubectl apply -k k8s\/api-gateway\/overlays\/prod\/\n<\/pre>\nbase\/<\/code> dosyas\u0131 g\u00fcncellenirken, bir ortam\u0131n kaynak limitleri de\u011fi\u015fti\u011finde sadece o ortam\u0131n yamas\u0131 g\u00fcncellenir. Bu, da\u011f\u0131t\u0131m s\u00fcre\u00e7lerini basitle\u015ftirir, hata olas\u0131l\u0131\u011f\u0131n\u0131 azalt\u0131r ve CI\/CD (S\u00fcrekli Entegrasyon\/S\u00fcrekli Da\u011f\u0131t\u0131m) boru hatlar\u0131n\u0131n daha g\u00fcvenilir \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar. Her ortam i\u00e7in ayr\u0131 bir Git branch veya tag kullanmak yerine, ayn\u0131 branch \u00fczerinde farkl\u0131 ortam konfig\u00fcrasyonlar\u0131n\u0131 y\u00f6netebilmek, GitOps prensipleriyle de daha uyumlu bir yakla\u015f\u0131m sunar.<\/p>\nMonorepo Yakla\u015f\u0131m\u0131 ile \u00c7oklu Uygulamalar\u0131 Y\u00f6netmek: Avantajlar\u0131 Nelerdir?<\/h2>\n
\nmy-monorepo-project\/\n\u251c\u2500\u2500 apps\/\n\u2502 \u251c\u2500\u2500 api-gateway\/\n\u2502 \u2502 \u251c\u2500\u2500 src\/\n\u2502 \u2502 \u2514\u2500\u2500 k8s\/\n\u2502 \u2502 \u251c\u2500\u2500 base\/\n\u2502 \u2502 \u2514\u2500\u2500 overlays\/\n\u2502 \u251c\u2500\u2500 user-service\/\n\u2502 \u2502 \u251c\u2500\u2500 src\/\n\u2502 \u2502 \u2514\u2500\u2500 k8s\/\n\u2502 \u2502 \u251c\u2500\u2500 base\/\n\u2502 \u2502 \u2514\u2500\u2500 overlays\/\n\u2502 \u2514\u2500\u2500 ... (di\u011fer uygulamalar)\n\u251c\u2500\u2500 libs\/\n\u2502 \u251c\u2500\u2500 common-utils\/\n\u2502 \u2514\u2500\u2500 ... (payla\u015f\u0131lan k\u00fct\u00fcphaneler)\n\u251c\u2500\u2500 k8s-infra\/\n\u2502 \u251c\u2500\u2500 common\/\n\u2502 \u2502 \u251c\u2500\u2500 namespace.yaml\n\u2502 \u2502 \u2514\u2500\u2500 rbac.yaml\n\u2502 \u2514\u2500\u2500 environments\/\n\u2502 \u251c\u2500\u2500 dev\/\n\u2502 \u2502 \u2514\u2500\u2500 kustomization.yaml\n\u2502 \u2514\u2500\u2500 prod\/\n\u2502 \u2514\u2500\u2500 kustomization.yaml\n\u2514\u2500\u2500 README.md\n<\/pre>\napps\/<\/code> dizini alt\u0131nda her uygulama kendi kaynak kodunu (src\/<\/code>) ve Kubernetes konfig\u00fcrasyonlar\u0131n\u0131 (k8s\/<\/code>) bar\u0131nd\u0131r\u0131r. libs\/<\/code> ise uygulamalar aras\u0131nda payla\u015f\u0131lan kod k\u00fct\u00fcphanelerini i\u00e7erir. En dikkat \u00e7ekici k\u0131s\u0131m ise k8s-infra\/<\/code> dizinidir. Bu dizin, t\u00fcm monorepo genelinde kullan\u0131lan ortak Kubernetes kaynaklar\u0131n\u0131 veya \u00fcst d\u00fczey ortam tan\u0131mlar\u0131n\u0131 bar\u0131nd\u0131rabilir. \u00d6rne\u011fin, t\u00fcm uygulamalar\u0131n konu\u015fland\u0131\u011f\u0131 namespace'ler, genel a\u011f politikalar\u0131 veya k\u00fcme genelindeki rol tan\u0131mlar\u0131 burada yer alabilir.<\/p>\nsrc\/<\/code> veya k8s\/<\/code> dizinleri) tarayarak ilgili uygulamalar\u0131 yeniden da\u011f\u0131tmas\u0131n\u0131 sa\u011flayacak ak\u0131ll\u0131 trigger'lar kurmak, da\u011f\u0131t\u0131m s\u00fcrelerini k\u0131salt\u0131r ve gereksiz kaynak t\u00fcketimini \u00f6nler. Bu, \u00f6zellikle b\u00fcy\u00fck repolarda \u00e7ok \u00f6nemlidir.\n<\/div>\nHelm ve Kustomize ile Dinamik Konfig\u00fcrasyon Y\u00f6netimi Nas\u0131l Yap\u0131l\u0131r?<\/h2>\n
Helm: Kubernetes Paket Y\u00f6neticisi ve \u015eablonlama G\u00fcc\u00fc<\/h3>\n
\nmy-kubernetes-project\/\n\u251c\u2500\u2500 charts\/\n\u2502 \u251c\u2500\u2500 api-gateway\/\n\u2502 \u2502 \u251c\u2500\u2500 Chart.yaml\n\u2502 \u2502 \u251c\u2500\u2500 values.yaml\n\u2502 \u2502 \u251c\u2500\u2500 templates\/\n\u2502 \u2502 \u2502 \u251c\u2500\u2500 deployment.yaml\n\u2502 \u2502 \u2502 \u251c\u2500\u2500 service.yaml\n\u2502 \u2502 \u2502 \u2514\u2500\u2500 _helpers.tpl\n\u2502 \u2502 \u2514\u2500\u2500 README.md\n\u2502 \u251c\u2500\u2500 user-service\/\n\u2502 \u2502 \u2514\u2500\u2500 ... (Helm chart yap\u0131s\u0131)\n\u251c\u2500\u2500 k8s\/\n\u2502 \u2514\u2500\u2500 ... (varsa Kustomize overlays veya di\u011fer manifestler)\n\u2514\u2500\u2500 ...\n<\/pre>\ncharts\/<\/code> dizini alt\u0131nda her uygulama i\u00e7in bir Helm chart bulunur. values.yaml<\/code> dosyas\u0131, chart'\u0131n varsay\u0131lan yap\u0131land\u0131rma de\u011ferlerini i\u00e7erir ve bu de\u011ferler da\u011f\u0131t\u0131m s\u0131ras\u0131nda ortam baz\u0131nda ge\u00e7ersiz k\u0131l\u0131nabilir. templates\/<\/code> dizini ise uygulaman\u0131n Kubernetes manifest \u015fablonlar\u0131n\u0131 bar\u0131nd\u0131r\u0131r. Helm'in \u015fablonlama yetenekleri sayesinde, bir kez \u015fablonlad\u0131\u011f\u0131n\u0131z bir manifest dosyas\u0131n\u0131 farkl\u0131 ortamlar i\u00e7in farkl\u0131 de\u011ferlerle (\u00f6rne\u011fin, replika say\u0131lar\u0131, imaj etiketleri, kaynak limitleri) da\u011f\u0131tabilirsiniz:<\/p>\n\n# charts\/api-gateway\/templates\/deployment.yaml\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: {{ include \"api-gateway.fullname\" . }}\n labels:\n {{- include \"api-gateway.labels\" . | nindent 4 }}\nspec:\n replicas: {{ .Values.replicaCount }} # replicaCount de\u011feri values.yaml'dan gelir\n selector:\n matchLabels:\n {{- include \"api-gateway.selectorLabels\" . | nindent 6 }}\n template:\n metadata:\n {{- with .Values.podAnnotations }}\n annotations:\n {{- toYaml . | nindent 8 }}\n {{- end }}\n labels:\n {{- include \"api-gateway.selectorLabels\" . | nindent 8 }}\n spec:\n containers:\n - name: {{ .Chart.Name }}\n image: \"{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}\"\n imagePullPolicy: {{ .Values.image.pullPolicy }}\n ports:\n - name: http\n containerPort: 8080\n protocol: TCP\n resources:\n {{- toYaml .Values.resources | nindent 12 }}\n<\/pre>\nKustomize: Yamalarla Manifestleri \u00d6zelle\u015ftirme<\/h3>\n
base\/<\/code> ve overlays\/<\/code> klas\u00f6r yap\u0131m\u0131zla m\u00fckemmel bir uyum i\u00e7indedir:<\/p>\n\nmy-kubernetes-project\/\n\u251c\u2500\u2500 k8s\/\n\u2502 \u251c\u2500\u2500 api-gateway\/\n\u2502 \u2502 \u251c\u2500\u2500 base\/\n\u2502 \u2502 \u2502 \u251c\u2500\u2500 deployment.yaml\n\u2502 \u2502 \u2502 \u251c\u2500\u2500 service.yaml\n\u2502 \u2502 \u2502 \u2514\u2500\u2500 kustomization.yaml # Base i\u00e7in kustomization.yaml\n\u2502 \u2502 \u2514\u2500\u2500 overlays\/\n\u2502 \u2502 \u251c\u2500\u2500 dev\/\n\u2502 \u2502 \u2502 \u251c\u2500\u2500 kustomization.yaml\n\u2502 \u2502 \u2502 \u2514\u2500\u2500 dev-replica-patch.yaml\n\u2502 \u2502 \u251c\u2500\u2500 prod\/\n\u2502 \u2502 \u2502 \u251c\u2500\u2500 kustomization.yaml\n\u2502 \u2502 \u2502 \u2514\u2500\u2500 prod-resource-limits.yaml\n\u2502 \u2514\u2500\u2500 user-service\/\n\u2502 \u2514\u2500\u2500 ...\n\u2514\u2500\u2500 ...\n<\/pre>\noverlays\/kustomization.yaml<\/code> dosyas\u0131n\u0131 i\u00e7erir. Bu dosya, base\/<\/code> dizinini referans al\u0131r ve bu temel manifestler \u00fczerine uygulanacak yamalar\u0131, configMap ve Secret jenerat\u00f6rlerini veya di\u011fer \u00f6zelle\u015ftirmeleri tan\u0131mlar. \u00d6rne\u011fin, prod-resource-limits.yaml<\/code> sadece \u00fcretim ortam\u0131na \u00f6zg\u00fc CPU\/bellek limitlerini g\u00fcncelleyen k\u00fc\u00e7\u00fck bir yama olabilir.<\/p>\n\n# k8s\/api-gateway\/overlays\/prod\/kustomization.yaml\napiVersion: kustomize.config.k8s.io\/v1beta1\nkind: Kustomization\nresources:\n - ..\/..\/base # base klas\u00f6r\u00fcndeki kaynaklar\u0131 kullan\npatches:\n - path: prod-resource-limits.yaml # Bu yamay\u0131 uygula\n target:\n kind: Deployment\n name: api-gateway-deployment # Hedef deployment\n# Ortam baz\u0131nda etiket ekleme\ncommonLabels:\n env: prod\n<\/pre>\n<\/pre>\n
\n# k8s\/api-gateway\/overlays\/prod\/prod-resource-limits.yaml
\napiVersion: apps\/v1
\nkind: Deployment
\nmetadata:
\n name: api-gateway-deployment
\nspec:
\n template:
\n spec:
\n containers:
\n - name: api-gateway-container
\n resources:
\n requests:
\n cpu: \"250m\"
\n memory: \"512Mi\"
\n limits:
\n cpu: \"500m\"
\n memory: \"1024Mi\"
\n<\/code><\/p>\nGitOps ve CI\/CD Entegrasyonu \u0130\u00e7in Klas\u00f6r Yap\u0131s\u0131n\u0131n Rol\u00fc Nedir?<\/h2>\n
GitOps \u0130\u00e7in Klas\u00f6r Yap\u0131s\u0131n\u0131n \u00d6nemi<\/h3>\n
\n
k8s\/overlays\/prod<\/code> dizini, \u00fcretim ortam\u0131 i\u00e7in beklenen durumu i\u00e7erir.<\/li>\nbase\/<\/code> ile overlays\/<\/code> yap\u0131lar\u0131, GitOps ara\u00e7lar\u0131n\u0131n sadece de\u011fi\u015fen bile\u015fenleri hedef almas\u0131na olanak tan\u0131r. Bu, gereksiz yeniden da\u011f\u0131t\u0131mlar\u0131 \u00f6nler ve da\u011f\u0131t\u0131m s\u00fcre\u00e7lerini h\u0131zland\u0131r\u0131r.<\/li>\nCI\/CD Entegrasyonu \u0130\u00e7in Klas\u00f6r Yap\u0131s\u0131n\u0131n Rol\u00fc<\/h3>\n
\n
kubectl apply -f k8s\/my-app\/base\/<\/code> veya kustomize build k8s\/my-app\/overlays\/prod | kubectl apply -f -<\/code> gibi komutlar, iyi bir klas\u00f6r yap\u0131s\u0131yla \u00e7ok daha okunabilir ve y\u00f6netilebilir hale gelir.<\/li>\nk8s\/user-service\/<\/code> klas\u00f6r\u00fcnde bir de\u011fi\u015fiklik alg\u0131lad\u0131\u011f\u0131nda user-service<\/code>'i yeniden da\u011f\u0131tabilir.<\/li>\n<\/ul>\n\n# .github\/workflows\/deploy.yml\nname: Kubernetes Deploy\n\non:\n push:\n branches:\n - main\n paths:\n - 'k8s\/api-gateway\/**' # Sadece api-gateway manifestleri de\u011fi\u015fti\u011finde tetikle\n - 'k8s\/user-service\/**' # Sadece user-service manifestleri de\u011fi\u015fti\u011finde tetikle\n\njobs:\n deploy:\n runs-on: ubuntu-latest\n steps:\n - name: Checkout code\n uses: actions\/checkout@v3\n\n - name: Deploy API Gateway to Production\n if: contains(github.event.commits[0].message, '[deploy-api-gateway]')\n run: |\n # Ortama \u00f6zel kustomize build ve kubectl apply\n kustomize build k8s\/api-gateway\/overlays\/prod | kubectl apply -f -\n\n - name: Deploy User Service to Production\n if: contains(github.event.commits[0].message, '[deploy-user-service]')\n run: |\n kustomize build k8s\/user-service\/overlays\/prod | kubectl apply -f -\n<\/pre>\npaths<\/code> anahtar kelimesi ve commit mesaj\u0131 kontrol\u00fc ile sadece ilgili servislerin da\u011f\u0131t\u0131lmas\u0131 sa\u011flanm\u0131\u015ft\u0131r. Bu t\u00fcr ak\u0131ll\u0131 CI\/CD yap\u0131lar\u0131, d\u00fczg\u00fcn bir klas\u00f6rleme olmasa uygulanamazd\u0131. \u00d6zetle, iyi bir Kubernetes proje klas\u00f6r yap\u0131s\u0131, sadece geli\u015ftiricilerin i\u015fini kolayla\u015ft\u0131rmakla kalmaz, ayn\u0131 zamanda GitOps prensiplerinin ve CI\/CD otomasyonunun tam potansiyelini ortaya \u00e7\u0131kararak daha h\u0131zl\u0131, daha g\u00fcvenilir ve daha s\u00fcrd\u00fcr\u00fclebilir bir yaz\u0131l\u0131m teslimat\u0131 sa\u011flar. Bu, modern DevOps k\u00fclt\u00fcr\u00fcn\u00fcn temel bir par\u00e7as\u0131d\u0131r.<\/p>\nVaka Analizi: B\u00fcy\u00fck \u00d6l\u00e7ekli Bir Projede Ba\u015far\u0131l\u0131 Klas\u00f6r Yap\u0131s\u0131 Uygulamas\u0131<\/h2>\n
Sorun: Y\u00f6netilemez Karma\u015fa ve Hata Oranlar\u0131<\/h3>\n
deployment.yaml<\/code>, service.yaml<\/code> ve di\u011fer manifest dosyalar\u0131 tek bir kubernetes\/<\/code> dizini alt\u0131nda d\u00fcz bir \u015fekilde duruyordu. Farkl\u0131 ortamlar i\u00e7in (dev, test, staging, prod) manuel kopyala-yap\u0131\u015ft\u0131r ile konfig\u00fcrasyonlar \u00e7o\u011falt\u0131lm\u0131\u015ft\u0131. Bu durum, a\u015fa\u011f\u0131daki sorunlara yol a\u00e7t\u0131:<\/p>\n\n
\u00c7\u00f6z\u00fcm: Yeniden Yap\u0131land\u0131r\u0131lm\u0131\u015f Klas\u00f6r ve Ara\u00e7 Entegrasyonu<\/h3>\n
\nglobalconnect-monorepo\/\n\u251c\u2500\u2500 services\/\n\u2502 \u251c\u2500\u2500 order-service\/\n\u2502 \u2502 \u251c\u2500\u2500 src\/\n\u2502 \u2502 \u2514\u2500\u2500 k8s\/\n\u2502 \u2502 \u251c\u2500\u2500 base\/\n\u2502 \u2502 \u2502 \u251c\u2500\u2500 deployment.yaml\n\u2502 \u2502 \u2502 \u251c\u2500\u2500 service.yaml\n\u2502 \u2502 \u2502 \u2514\u2500\u2500 kustomization.yaml\n\u2502 \u2502 \u2514\u2500\u2500 overlays\/\n\u2502 \u2502 \u251c\u2500\u2500 dev\/\n\u2502 \u2502 \u2502 \u2514\u2500\u2500 kustomization.yaml\n\u2502 \u2502 \u251c\u2500\u2500 staging\/\n\u2502 \u2502 \u2502 \u2514\u2500\u2500 kustomization.yaml\n\u2502 \u2502 \u2514\u2500\u2500 prod\/\n\u2502 \u2502 \u2514\u2500\u2500 kustomization.yaml\n\u2502 \u251c\u2500\u2500 payment-service\/\n\u2502 \u2502 \u2514\u2500\u2500 ... (ayn\u0131 yap\u0131)\n\u2502 \u2514\u2500\u2500 ... (di\u011fer 48 servis)\n\u251c\u2500\u2500 shared-libs\/\n\u2502 \u2514\u2500\u2500 ...\n\u251c\u2500\u2500 infrastructure\/ # K\u00fcme genelindeki altyap\u0131 manifestleri\n\u2502 \u251c\u2500\u2500 cluster-roles\/\n\u2502 \u251c\u2500\u2500 namespaces\/\n\u2502 \u2514\u2500\u2500 network-policies\/\n\u251c\u2500\u2500 helm-charts\/ # Baz\u0131 karma\u015f\u0131k uygulamalar i\u00e7in Helm\n\u2502 \u2514\u2500\u2500 analytics-dashboard\/\n\u2502 \u251c\u2500\u2500 Chart.yaml\n\u2502 \u251c\u2500\u2500 values.yaml\n\u2502 \u2514\u2500\u2500 templates\/\n\u251c\u2500\u2500 ci-cd\/\n\u2502 \u251c\u2500\u2500 argocd-applications\/ # Argo CD uygulama tan\u0131mlar\u0131\n\u2502 \u2502 \u251c\u2500\u2500 dev.yaml\n\u2502 \u2502 \u251c\u2500\u2500 staging.yaml\n\u2502 \u2502 \u2514\u2500\u2500 prod.yaml\n\u2502 \u2514\u2500\u2500 pipelines\/ # Jenkins\/GitHub Actions pipeline tan\u0131mlar\u0131\n\u2514\u2500\u2500 README.md\n<\/pre>\n\n
base\/<\/code> manifestlerini ve ortama \u00f6zel overlays\/<\/code> klas\u00f6rlerini kullanan bir Kustomize yap\u0131s\u0131na ge\u00e7ti. Bu, manuel kopyala-yap\u0131\u015ft\u0131r hatas\u0131n\u0131 tamamen ortadan kald\u0131rd\u0131 ve ortamlar aras\u0131 tutarl\u0131l\u0131\u011f\u0131 sa\u011flad\u0131.<\/li>\nci-cd\/argocd-applications\/<\/code> dizininde, her ortam i\u00e7in Argo CD'nin izleyece\u011fi uygulamalar\u0131n tan\u0131mlar\u0131 olu\u015fturuldu. Argo CD, Git deposundaki de\u011fi\u015fiklikleri otomatik olarak alg\u0131lay\u0131p Kubernetes k\u00fcmelerine senkronize etmeye ba\u015flad\u0131. Bu, da\u011f\u0131t\u0131m s\u00fcrecini tamamen otomatik ve g\u00f6zlemlenebilir hale getirdi.<\/li>\ninfrastructure\/<\/code> dizini, t\u00fcm k\u00fcmeler veya birden fazla servis i\u00e7in ge\u00e7erli olan RBAC kurallar\u0131, Namespace tan\u0131mlar\u0131 ve a\u011f politikalar\u0131 gibi ortak altyap\u0131 konfig\u00fcrasyonlar\u0131n\u0131 i\u00e7eriyordu. Bu, tekrar\u0131 \u00f6nledi ve merkezi y\u00f6netim sa\u011flad\u0131.<\/li>\nhelm-charts\/<\/code> dizininde y\u00f6netildi. Bu, bu uygulamalar\u0131n da\u011f\u0131t\u0131m\u0131n\u0131 ve konfig\u00fcrasyonunu basitle\u015ftirdi.<\/li>\nci-cd\/pipelines\/<\/code> dizininde Jenkinsfile'lar veya GitHub Actions workflow'lar\u0131, sadece de\u011fi\u015fen servislerin Kubernetes manifestlerinin Kustomize ile derlenmesini ve Argo CD'ye senkronizasyon tetiklemesini sa\u011flayacak \u015fekilde optimize edildi.<\/li>\n<\/ol>\nSonu\u00e7lar ve Kazan\u0131mlar<\/h3>\n
\n
Sonu\u00e7: Temiz Bir Yap\u0131 ile Kubernetes Projelerinizi \u00d6l\u00e7eklendirin<\/h2>\n
base\/<\/code> ve overlays\/<\/code> yap\u0131s\u0131 ile manifestlerinizi d\u00fczenleyerek temel bir d\u00fczen kurabilir, ard\u0131ndan Kustomize'\u0131n yama tabanl\u0131 yakla\u015f\u0131m\u0131 veya Helm'in \u015fablonlama ve paketleme g\u00fcc\u00fcyle dinamik konfig\u00fcrasyon y\u00f6netimine ge\u00e7ebilirsiniz. Monorepo yakla\u015f\u0131m\u0131, birden fazla mikroservisi tek bir \u00e7at\u0131 alt\u0131nda y\u00f6netme esnekli\u011fi sunarken, GitOps prensipleri ve entegre CI\/CD boru hatlar\u0131, da\u011f\u0131t\u0131mlar\u0131n\u0131z\u0131 otomatikle\u015ftirerek g\u00fcvenilirli\u011fi ve h\u0131z\u0131 art\u0131r\u0131r. Unutmay\u0131n, bu yakla\u015f\u0131mlar\u0131n tamam\u0131 veya bir k\u0131sm\u0131, projenizin \u00f6zel ihtiya\u00e7lar\u0131na ve ekibinizin yetkinliklerine g\u00f6re uyarlanabilir.<\/p>\n