G\u00fcn\u00fcm\u00fcz\u00fcn h\u0131zla de\u011fi\u015fen teknoloji d\u00fcnyas\u0131nda, yaz\u0131l\u0131m geli\u015ftirme ve da\u011f\u0131t\u0131m s\u00fcre\u00e7lerinin vazge\u00e7ilmez bir par\u00e7as\u0131 haline gelen Docker ve Kubernetes, DevOps m\u00fchendislerinin g\u00fcnl\u00fck operasyonlar\u0131nda kilit rol oynamaktad\u0131r. Ancak, \u00e7o\u011fu zaman bu g\u00fc\u00e7l\u00fc ara\u00e7lar\u0131n potansiyeli tam olarak ke\u015ffedilemez; m\u00fchendisler genellikle temel komutlar ve y\u00fczeysel bilgilerle yetinirler. Peki, bu durum neden bu kadar yayg\u0131n ve derinlemesine bilgiye ula\u015fmak asl\u0131nda ne anlama geliyor? Bu makale, DevOps m\u00fchendislerinin Docker ve Kubernetes’i neden sadece y\u00fczeyden kulland\u0131klar\u0131n\u0131, bu durumun getirdi\u011fi zorluklar\u0131 ve bu kritik teknolojilerde nas\u0131l daha derin bir uzmanl\u0131k kazan\u0131laca\u011f\u0131n\u0131 detayl\u0131 bir \u015fekilde inceleyecektir. Amac\u0131m\u0131z, sizi sadece “kullanan” olmaktan \u00e7\u0131kar\u0131p, “anlayan ve optimize eden” bir m\u00fchendis seviyesine ta\u015f\u0131makt\u0131r. E\u011fer konteynerizasyon ve orkestrasyonun ger\u00e7ek g\u00fcc\u00fcn\u00fc ke\u015ffetmek istiyorsan\u0131z, do\u011fru yerdesiniz.<\/p>\n
Docker ve Kubernetes’in modern yaz\u0131l\u0131m d\u00fcnyas\u0131ndaki y\u00fckseli\u015fi, mikroservis mimarileri ve bulut tabanl\u0131 uygulamalar\u0131n yayg\u0131nla\u015fmas\u0131yla do\u011frudan ili\u015fkilidir. Bu teknolojiler, uygulama da\u011f\u0131t\u0131m\u0131n\u0131, \u00f6l\u00e7eklendirmeyi ve y\u00f6netimini k\u00f6kten de\u011fi\u015ftirerek DevOps pratiklerinin merkezine yerle\u015fmi\u015ftir. Ancak bu pop\u00fclerli\u011fe ra\u011fmen, bir\u00e7ok DevOps m\u00fchendisi i\u00e7in temel kavramlar\u0131n \u00f6tesine ge\u00e7mek zorlu bir s\u00fcre\u00e7 olabilir. Gelin, bu temel ta\u015flar\u0131n\u0131 ve neden basit\u00e7e kullanman\u0131n yeterli olmad\u0131\u011f\u0131n\u0131 yak\u0131ndan inceleyelim.<\/p>\n
Docker, uygulamalar\u0131n ve ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131n bir araya getirilerek “konteyner” ad\u0131 verilen ta\u015f\u0131nabilir, izole edilmi\u015f birimlerde \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131n\u0131 sa\u011flayan bir platformdur. Geli\u015ftirme ortam\u0131nda \u00e7al\u0131\u015fan bir uygulaman\u0131n \u00fcretimde de ayn\u0131 \u015fekilde \u00e7al\u0131\u015faca\u011f\u0131n\u0131n garantisini vermesi, Docker’\u0131n en b\u00fcy\u00fck avantajlar\u0131ndan biridir. Bu, “benim makinemde \u00e7al\u0131\u015f\u0131yor” sorununu ortadan kald\u0131r\u0131r. Temelde Docker’da iki ana kavram vard\u0131r: Docker Image<\/strong> ve Docker Container<\/strong>. Image’lar, uygulaman\u0131z\u0131n ve t\u00fcm ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131n statik bir anl\u0131k g\u00f6r\u00fcnt\u00fcs\u00fcd\u00fcr; container’lar ise bu image’lardan olu\u015fturulan \u00e7al\u0131\u015fan \u00f6rneklerdir. Bir Dockerfile ile image’lar\u0131n\u0131z\u0131 tan\u0131mlars\u0131n\u0131z ve Docker Compose ile birden fazla servisi (uygulamay\u0131) i\u00e7eren karma\u015f\u0131k uygulamalar\u0131 kolayca y\u00f6netebilirsiniz. Bir\u00e7ok m\u00fchendis, bir uygulamay\u0131 konteynerize etmek i\u00e7in temel bir Dockerfile yazabilir veya birka\u00e7 Docker komutu \u00e7al\u0131\u015ft\u0131rabilir. Ancak, bu sadece buzda\u011f\u0131n\u0131n g\u00f6r\u00fcnen k\u0131sm\u0131d\u0131r. Performans optimizasyonu, g\u00fcvenlik pratikleri ve a\u011f yap\u0131land\u0131rmalar\u0131 gibi derinlemesine konular, \u00e7o\u011fu zaman atlan\u0131r. \u00d6rne\u011fin, yanl\u0131\u015f yap\u0131land\u0131r\u0131lm\u0131\u015f bir Dockerfile, devasa boyutlarda image’lar olu\u015fturabilir veya g\u00fcvenlik a\u00e7\u0131klar\u0131na yol a\u00e7abilir. Dockerfile’daki her bir katman\u0131n nas\u0131l olu\u015ftu\u011funu ve image boyutunu nas\u0131l etkiledi\u011fini anlamak, ger\u00e7ekten optimize edilmi\u015f ve g\u00fcvenli konteynerler olu\u015fturman\u0131n anahtar\u0131d\u0131r. Dahas\u0131, Docker a\u011f\u0131n\u0131n ve depolama mekanizmalar\u0131n\u0131n i\u00e7 i\u015fleyi\u015fini bilmek, karma\u015f\u0131k mikroservis mimarilerinde performans darbo\u011fazlar\u0131n\u0131 veya veri kal\u0131c\u0131l\u0131\u011f\u0131 sorunlar\u0131n\u0131 \u00e7\u00f6zmek i\u00e7in hayati \u00f6neme sahiptir. Bu temel bilgilerle y\u00fczeyde kalmak, ileride daha b\u00fcy\u00fck ve daha maliyetli sorunlara yol a\u00e7abilir.<\/p>\n Docker’\u0131n konteynerle\u015ftirme devrimiyle birlikte, tek bir makinede birden fazla konteyneri y\u00f6netmek nispeten kolay olsa da, y\u00fczlerce konteyneri onlarca sunucu \u00fczerinde otomatik olarak da\u011f\u0131tmak, \u00f6l\u00e7eklendirmek, dengelemek ve sa\u011fl\u0131\u011f\u0131n\u0131 izlemek ciddi bir zorluk haline gelmi\u015ftir. \u0130\u015fte bu noktada Kubernetes (K8s)<\/strong> devreye girer. Kubernetes, konteynerle\u015ftirilmi\u015f i\u015f y\u00fcklerini ve hizmetleri y\u00f6netmek i\u00e7in a\u00e7\u0131k kaynakl\u0131 bir platformdur ve konteyner orkestrasyonunun fiili standard\u0131 olmu\u015ftur. Temel amac\u0131, da\u011f\u0131t\u0131lm\u0131\u015f sistemlerin karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 basitle\u015ftirmektir. Kubernetes’te Pod’lar<\/strong> (\u00e7al\u0131\u015fan uygulamalar\u0131n en k\u00fc\u00e7\u00fck birimi), Deployment’lar<\/strong> (Pod’lar\u0131n durumunu ve s\u00fcr\u00fcm\u00fcn\u00fc y\u00f6netir), Service’ler<\/strong> (Pod’lara eri\u015fimi sa\u011flar) ve ReplicaSet’ler<\/strong> (belirli say\u0131da Pod’u her zaman \u00e7al\u0131\u015f\u0131r durumda tutar) gibi temel kavramlar bulunur. \u00c7o\u011fu DevOps m\u00fchendisi, basit bir YAML dosyas\u0131 ile bir uygulamay\u0131 Kubernetes’e da\u011f\u0131tabilir ve bir servis olu\u015fturabilir. Ancak, Kubernetes’in ger\u00e7ek g\u00fcc\u00fc, sadece bir da\u011f\u0131t\u0131m arac\u0131 olmaktan \u00f6teye ge\u00e7er. Kaynak y\u00f6netimi (CPU\/Bellek limitleri), a\u011f politikalar\u0131, depolama s\u0131n\u0131flar\u0131, otomatik \u00f6l\u00e7eklendirme (HPA\/VPA), hizmet ke\u015ffi, g\u00fcvenlik ve felaket kurtarma gibi ileri d\u00fczey \u00f6zellikler, platformun derinliklerine inildi\u011finde ortaya \u00e7\u0131kar. \u00d6rne\u011fin, sadece bir Deployment olu\u015fturup uygulaman\u0131z\u0131 \u00e7al\u0131\u015ft\u0131rmak, uygulaman\u0131z\u0131n beklenmedik y\u00fck art\u0131\u015flar\u0131nda \u00e7\u00f6kmesini veya gereksiz kaynak t\u00fcketimi yapmas\u0131n\u0131 engelleyemez. Kubernetes’in i\u00e7 yap\u0131s\u0131n\u0131, kontrol d\u00f6ng\u00fcs\u00fcn\u00fc, scheduler’\u0131n\u0131 ve etcd gibi bile\u015fenlerini anlamak, kar\u015f\u0131la\u015f\u0131lan sorunlar\u0131 h\u0131zl\u0131ca te\u015fhis etmek ve optimize edilmi\u015f, dayan\u0131kl\u0131 sistemler kurmak i\u00e7in vazge\u00e7ilmezdir. Y\u00fczeyde kalan bir anlay\u0131\u015f, sizi yaln\u0131zca haz\u0131r \u00e7\u00f6z\u00fcmleri kopyalay\u0131p yap\u0131\u015ft\u0131rmaya iterken, derinlemesine bilgi, kendi \u00f6zg\u00fcn ve robust \u00e7\u00f6z\u00fcmlerinizi tasarlaman\u0131z\u0131 sa\u011flar.<\/p>\n Docker ve Kubernetes’in temellerini anlamak \u015f\u00fcphesiz \u00f6nemlidir, ancak genellikle kar\u015f\u0131la\u015f\u0131lan problem, bu temel bilgilerin \u00f6tesine ge\u00e7mekte ya\u015fanan zorluktur. Bir\u00e7ok DevOps m\u00fchendisi, bu teknolojileri g\u00fcnl\u00fck i\u015flerinde “kullan\u0131r”, ancak “anlamaz”. Bu durum, genellikle zaman k\u0131s\u0131tlamalar\u0131, \u00f6\u011frenme e\u011frisinin dikli\u011fi veya anl\u0131k proje ihtiya\u00e7lar\u0131na odaklanma gibi nedenlerle ortaya \u00e7\u0131kar. Sonu\u00e7 olarak, potansiyeli tam olarak de\u011ferlendirilemeyen sistemler, performans sorunlar\u0131 ve g\u00fcvenlik a\u00e7\u0131klar\u0131yla dolu ortamlar ortaya \u00e7\u0131kar. Peki, bu s\u0131\u011f bilginin arkas\u0131ndaki ana nedenler ve bunun ger\u00e7ek d\u00fcnyadaki yans\u0131malar\u0131 nelerdir?<\/p>\n DevOps m\u00fchendisleri aras\u0131nda yayg\u0131n olan baz\u0131 yan\u0131lg\u0131lar, Docker ve Kubernetes’i derinlemesine \u00f6\u011frenmenin \u00f6n\u00fcnde engel te\u015fkil eder:<\/p>\n Bir e-ticaret \u015firketinin DevOps ekibi, Docker ve Kubernetes’i kullanarak mikroservis tabanl\u0131 uygulamalar\u0131n\u0131 da\u011f\u0131t\u0131yordu. \u0130lk ba\u015flarda her \u015fey yolundayd\u0131, ancak kara cuma gibi yo\u011fun d\u00f6nemlerde sistemlerinde beklenmedik performans d\u00fc\u015f\u00fc\u015fleri ve \u00e7\u00f6k\u00fc\u015fler ya\u015famaya ba\u015flad\u0131lar. Uygulaman\u0131n anl\u0131k olarak y\u00fczlerce pod’a \u00f6l\u00e7eklenmesine ra\u011fmen, yan\u0131t s\u00fcreleri kabul edilemez seviyelere y\u00fckseliyordu.<\/p>\n Sorunun temelinde, m\u00fchendislerin Kubernetes kaynak y\u00f6netimi konusunda yeterince derin bilgiye sahip olmamalar\u0131 yat\u0131yordu. Uygulamalar\u0131n Kubernetes manifest’lerinde sadece \u00c7\u00f6z\u00fcm olarak, DevOps ekibi a\u015fa\u011f\u0131daki ad\u0131mlar\u0131 att\u0131:<\/p>\n Bu de\u011fi\u015fiklikler sayesinde, \u015firket yo\u011fun d\u00f6nemlerde bile stabil ve performansl\u0131 bir sistemle \u00e7al\u0131\u015fmaya devam etti. Bu vaka, temel komutlar\u0131 bilmenin \u00f6tesine ge\u00e7ip, detaylara inmenin ne kadar kritik oldu\u011funu a\u00e7\u0131k\u00e7a g\u00f6stermektedir. Kaynak limitlerinin basit bir \u015fekilde yap\u0131land\u0131r\u0131lmas\u0131 veya Docker imajlar\u0131n\u0131n optimize edilmesi gibi “derinlemesine” g\u00f6r\u00fcnen ad\u0131mlar, ger\u00e7ek d\u00fcnyada b\u00fcy\u00fck farklar yaratabilir.<\/p>\n Docker, sadece uygulamalar\u0131 paketlemekten \u00e7ok daha fazlas\u0131n\u0131 sunar. Konteynerlerinizin performans\u0131n\u0131, g\u00fcvenli\u011fini ve verimlili\u011fini art\u0131rmak i\u00e7in kullanabilece\u011finiz bir\u00e7ok ileri d\u00fczey teknik ve en iyi pratik vard\u0131r. Y\u00fczeyde kalmak yerine, Docker’\u0131n i\u00e7 mekanizmalar\u0131n\u0131 anlamak, daha sa\u011flam, g\u00fcvenli ve maliyet-etkin \u00e7\u00f6z\u00fcmler geli\u015ftirmenize olanak tan\u0131r. \u0130\u015fte bu derinlemesine konulara bir g\u00f6z atal\u0131m.<\/p>\n Bir Docker imaj\u0131n\u0131n boyutu ve i\u00e7erdi\u011fi katman say\u0131s\u0131, hem da\u011f\u0131t\u0131m h\u0131z\u0131n\u0131 hem de olas\u0131 g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 do\u011frudan etkiler. Tek bir a\u015famada t\u00fcm ba\u011f\u0131ml\u0131l\u0131klar\u0131 y\u00fckleyip uygulamay\u0131 derlemek, genellikle b\u00fcy\u00fck ve gereksiz dosya i\u00e7eren imajlar olu\u015fturur. \u00c7ok a\u015famal\u0131 Dockerfile’lar (Multi-stage builds)<\/strong>, bu sorunu \u00e7\u00f6zmek i\u00e7in m\u00fckemmel bir yakla\u015f\u0131md\u0131r. Geli\u015ftirme ve derleme a\u015famas\u0131n\u0131, nihai \u00fcretim imaj\u0131ndan ay\u0131rarak sadece gerekli dosyalar\u0131n nihai imaja eklenmesini sa\u011flarlar. Bu sayede, \u00fcretim imajlar\u0131 \u00e7ok daha k\u00fc\u00e7\u00fck ve daha g\u00fcvenli hale gelir.<\/p>\n G\u00fcvenlik, Docker kullan\u0131m\u0131n\u0131n en kritik y\u00f6nlerinden biridir. \u0130\u015fte baz\u0131 en iyi g\u00fcvenlik pratikleri:<\/p>\n A\u015fa\u011f\u0131da basit bir \u00e7ok a\u015famal\u0131 Dockerfile \u00f6rne\u011fi yer almaktad\u0131r:<\/p>\n <\/code><\/p>\n Yukar\u0131daki \u00f6rnekte, ilk a\u015famada uygulaman\u0131n derlenmesi i\u00e7in gerekli t\u00fcm ara\u00e7lar (Node.js ve NPM) kullan\u0131l\u0131rken, ikinci a\u015famada sadece uygulaman\u0131n \u00e7al\u0131\u015fmas\u0131 i\u00e7in minimum d\u00fczeyde gerekli olanlar nihai imaja dahil edilir. Bu, imaj boyutunu \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r.<\/p>\n Uygulamalar\u0131n\u0131z\u0131n konteynerler i\u00e7inde verimli bir \u015fekilde \u00e7al\u0131\u015fmas\u0131 i\u00e7in, Docker'\u0131n a\u011f ve depolama mekanizmalar\u0131n\u0131 anlamak kritik \u00f6neme sahiptir. Yanl\u0131\u015f a\u011f yap\u0131land\u0131rmas\u0131, mikroservisler aras\u0131nda ileti\u015fim sorunlar\u0131na yol a\u00e7arken, uygun olmayan depolama se\u00e7imi veri kayb\u0131 veya performans darbo\u011fazlar\u0131na neden olabilir.<\/p>\n Bir e-ticaret uygulamas\u0131nda, bir web aray\u00fcz\u00fc konteynerinin bir veritaban\u0131 konteyneriyle ileti\u015fim kurmas\u0131 ve \u00fcr\u00fcn resimlerini kal\u0131c\u0131 olarak depolamas\u0131 gerekebilir. Bunu Docker Compose ile nas\u0131l yap\u0131land\u0131rabiliriz?<\/p>\n <\/code><\/p>\n Bu \u00f6rnekte, Kubernetes, konteyner orkestrasyonunda basit da\u011f\u0131t\u0131m ve \u00f6l\u00e7eklendirmeden \u00e7ok daha fazlas\u0131n\u0131 sunar. Platformun ger\u00e7ek g\u00fcc\u00fc, ileri d\u00fczey kaynak y\u00f6netimi, a\u011f ve g\u00fcvenlik politikalar\u0131 gibi konularda derinlemesine bilgi sahibi olmakla ortaya \u00e7\u0131kar. Bu konular, \u00f6zellikle b\u00fcy\u00fck \u00f6l\u00e7ekli ve kritik \u00fcretim ortamlar\u0131nda uygulaman\u0131z\u0131n dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131, performans\u0131n\u0131 ve g\u00fcvenli\u011fini sa\u011flamak i\u00e7in vazge\u00e7ilmezdir. Y\u00fczeydeki bilgilerle yetinmek, maliyetli kesintilere ve g\u00fcvenlik ihlallerine davetiye \u00e7\u0131karabilir.<\/p>\n Kubernetes'te kaynak y\u00f6netimi, uygulamalar\u0131n\u0131z\u0131n istikrarl\u0131 \u00e7al\u0131\u015fmas\u0131n\u0131 ve cluster kaynaklar\u0131n\u0131n verimli kullan\u0131lmas\u0131n\u0131 sa\u011flaman\u0131n temelidir. Yanl\u0131\u015f kaynak ayarlar\u0131, performans darbo\u011fazlar\u0131na, hizmet kesintilerine veya gereksiz bulut maliyetlerine yol a\u00e7abilir.<\/p>\n A\u015fa\u011f\u0131da, bir uygulamaya kaynak istekleri ve limitleri tan\u0131mlayan ve HPA ile \u00f6l\u00e7eklendiren bir Kubernetes manifest \u00f6rne\u011fi bulunmaktad\u0131r:<\/p>\n <\/code><\/p>\n Bu yap\u0131land\u0131rma, uygulaman\u0131n minimum 3, maksimum 10 pod ile \u00e7al\u0131\u015fmas\u0131n\u0131 ve CPU kullan\u0131m\u0131 %70'i a\u015ft\u0131\u011f\u0131nda otomatik olarak \u00f6l\u00e7eklenmesini sa\u011flar. Ayr\u0131ca her pod'un kaynak t\u00fcketimi belirli s\u0131n\u0131rlar i\u00e7inde tutularak cluster istikrar\u0131 korunur.<\/p>\n Kubernetes ortamlar\u0131nda a\u011f ve g\u00fcvenlik, uygulaman\u0131n i\u015fleyi\u015fi ve veri b\u00fct\u00fcnl\u00fc\u011f\u00fc i\u00e7in hayati \u00f6neme sahiptir. Varsay\u0131lan ayarlar genellikle yeterli de\u011fildir ve \u00f6zellikle mikroservis mimarilerinde detayl\u0131 kontrol sa\u011flamak gerekir.<\/p>\n Kubernetes Network Policies, pod'lar aras\u0131ndaki ve pod'lardan\/d\u0131\u015f d\u00fcnyaya gelen\/giden trafi\u011fi kontrol etmek i\u00e7in kullan\u0131l\u0131r. Bu, mikroservisler aras\u0131nda \"s\u0131f\u0131r g\u00fcven\" (zero trust) prensibini uygulaman\u0131z\u0131 sa\u011flar. \u00d6rne\u011fin, sadece belirli bir hizmetin veritaban\u0131 pod'una eri\u015fmesine izin vermek gibi kurallar tan\u0131mlayabilirsiniz.<\/p>\n <\/code><\/p>\n Bu politika, Bu geli\u015fmi\u015f a\u011f ve g\u00fcvenlik mekanizmalar\u0131n\u0131 anlamak ve do\u011fru bir \u015fekilde uygulamak, Kubernetes cluster'\u0131n\u0131z\u0131n sadece \u00e7al\u0131\u015fmas\u0131n\u0131 de\u011fil, ayn\u0131 zamanda g\u00fcvenli ve dayan\u0131kl\u0131 bir \u015fekilde \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar. Y\u00fczeyde kalmak, bu kritik g\u00fcvenlik katmanlar\u0131n\u0131 g\u00f6z ard\u0131 etmenize ve potansiyel g\u00fcvenlik a\u00e7\u0131klar\u0131na maruz kalman\u0131za neden olabilir.<\/p>\n Docker ve Kubernetes'i derinlemesine anlamak, sadece bu teknolojilerin kendi i\u00e7indeki mekanizmalar\u0131n\u0131 bilmekle kalmaz, ayn\u0131 zamanda geni\u015fleyen ekosistemlerini ve CI\/CD s\u00fcre\u00e7leriyle nas\u0131l entegre edildiklerini kavramay\u0131 da gerektirir. Otomasyon, izleme, loglama ve uyar\u0131 sistemleri, modern DevOps pratiklerinin vazge\u00e7ilmezidir ve bu alanlarda derinlemesine bilgi sahibi olmak, \u00fcretim ortamlar\u0131n\u0131z\u0131n sa\u011fl\u0131\u011f\u0131n\u0131 ve performans\u0131n\u0131 en \u00fcst d\u00fczeye \u00e7\u0131kar\u0131r. Y\u00fczeyde kalmak, genellikle manuel m\u00fcdahalelere ve reaktif sorun gidermeye yol a\u00e7ar; oysa derinlemesine bir yakla\u015f\u0131mla proaktif ve tamamen otomatikle\u015ftirilmi\u015f bir d\u00f6ng\u00fc kurabilirsiniz.<\/p>\n Kubernetes'e uygulama da\u011f\u0131tmak i\u00e7in YAML manifest'leri yazmak, k\u00fc\u00e7\u00fck projeler i\u00e7in yeterli olabilir. Ancak, mikroservis tabanl\u0131 karma\u015f\u0131k uygulamalar ve birden fazla ortama (dev, staging, prod) da\u011f\u0131t\u0131m yap\u0131lmas\u0131 gerekti\u011finde bu y\u00f6ntem h\u0131zla y\u00f6netilemez hale gelir. \u0130\u015fte bu noktada paket y\u00f6neticileri ve otomasyon ara\u00e7lar\u0131 devreye girer:<\/p>\n A\u015fa\u011f\u0131da basit bir Helm Chart yap\u0131s\u0131 \u00f6rne\u011fi yer almaktad\u0131r:<\/p>\n <\/code><\/p>\n Bu yap\u0131y\u0131 kullanarak, Bir uygulaman\u0131n veya altyap\u0131n\u0131n sa\u011fl\u0131\u011f\u0131n\u0131 ger\u00e7ek zamanl\u0131 olarak anlamak, herhangi bir DevOps ortam\u0131nda en \u00f6nemli yeteneklerden biridir. \u0130zleme (Monitoring), g\u00fcnl\u00fckleme (Logging) ve uyar\u0131lar (Alerting) olmadan, sorunlar ortaya \u00e7\u0131kt\u0131\u011f\u0131nda reaktif olarak hareket etmek zorunda kal\u0131rs\u0131n\u0131z. Derinlemesine bir yakla\u015f\u0131mla, proaktif bir \u015fekilde sorunlar\u0131 tespit edebilir ve hatta \u00f6nleyebilirsiniz.<\/p>\n Bu ara\u00e7lar\u0131 do\u011fru bir \u015fekilde entegre etmek ve yap\u0131land\u0131rmak, DevOps m\u00fchendislerine cluster'lar\u0131n\u0131n ve uygulamalar\u0131n\u0131n \"nabz\u0131n\u0131\" tutma imkan\u0131 verir. Derinlemesine bir bilgi birikimi, sadece ara\u00e7lar\u0131 kurmaktan \u00f6te, hangi metriklerin \u00f6nemli oldu\u011funu, hangi g\u00fcnl\u00fcklerin de\u011ferli oldu\u011funu ve hangi e\u015fiklerin uyar\u0131 tetikleyicisi olmas\u0131 gerekti\u011fini anlamay\u0131 gerektirir.<\/p>\n <\/p>\nKubernetes Neden Ortaya \u00c7\u0131kt\u0131 ve Ne \u00c7\u00f6z\u00fcyor? Orkestrasyonun G\u00fcc\u00fc Nerede Yatar?<\/h3>\n
S\u0131\u011f Bilgiden Derin Uzmanl\u0131\u011fa Ge\u00e7i\u015f: Neden Y\u00fczeyde Kal\u0131yoruz?<\/h2>\n
S\u0131k Kar\u015f\u0131la\u015f\u0131lan Yan\u0131lg\u0131lar Nelerdir? Y\u00fczeyde Kalmak Neden Sorun Te\u015fkil Eder?<\/h3>\n
\n
docker build<\/code>, docker run<\/code>, kubectl apply<\/code> gibi temel komutlar\u0131 bilmenin yeterli oldu\u011funu d\u00fc\u015f\u00fcn\u00fcr. Ancak bu komutlar\u0131n perde arkas\u0131nda neyi tetikledi\u011fini, nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 veya farkl\u0131 parametrelerin etkilerini anlamamak, sorun giderme ve optimizasyon yeteneklerini ciddi \u015fekilde k\u0131s\u0131tlar.<\/li>\nGer\u00e7ek D\u00fcnya Problemleri ve \u00c7\u00f6z\u00fcmleri: Bir Vaka Analizi<\/h3>\n
requests<\/code> tan\u0131mlanm\u0131\u015f, ancak limits<\/code> tan\u0131mlanmam\u0131\u015ft\u0131. Bu durum, baz\u0131 pod’lar\u0131n CPU ve belle\u011fi a\u015f\u0131r\u0131 derecede t\u00fcketmesine ve ayn\u0131 d\u00fc\u011f\u00fcm \u00fczerindeki di\u011fer pod’lar\u0131n kaynak k\u0131tl\u0131\u011f\u0131 \u00e7ekmesine (noisy neighbor sendromu) neden oluyordu. Ayr\u0131ca, uygulaman\u0131n konteyner imajlar\u0131 gereksiz ba\u011f\u0131ml\u0131l\u0131klar i\u00e7erdi\u011fi i\u00e7in olduk\u00e7a b\u00fcy\u00fckt\u00fc, bu da pod’lar\u0131n ba\u015flat\u0131lma s\u00fcresini uzat\u0131yordu.<\/p>\n\n
requests<\/code> ve limits<\/code> de\u011ferleri belirlendi ve manifest’lere eklendi. Bu sayede, kaynaklar\u0131n adil da\u011f\u0131l\u0131m\u0131 sa\u011fland\u0131 ve “noisy neighbor” etkisi azalt\u0131ld\u0131.<\/li>\nDocker Derinlemesine: \u0130leri Konteyner Y\u00f6netimi ve Optimizasyonlar\u0131 Nas\u0131l Yap\u0131l\u0131r?<\/h2>\n
\u00c7ok A\u015famal\u0131 Dockerfile’lar ve G\u00fcvenlik Best Practices Nelerdir?<\/h3>\n
\n
root<\/code> kullan\u0131c\u0131s\u0131 yerine m\u00fcmk\u00fcn oldu\u011funca d\u00fc\u015f\u00fck yetkili bir kullan\u0131c\u0131 ile \u00e7al\u0131\u015ft\u0131r\u0131n.<\/li>\nalpine<\/code> gibi minimal temel imajlar kullan\u0131n. Bu, imaj boyutunu k\u00fc\u00e7\u00fclt\u00fcr ve sald\u0131r\u0131 y\u00fczeyini azalt\u0131r.<\/li>\n.dockerignore<\/code> Kullan\u0131m\u0131:<\/strong> Kaynak kodunuzdaki gereksiz dosyalar\u0131n (\u00f6rne\u011fin .git<\/code> klas\u00f6r\u00fc, node_modules<\/code> \u00f6nbelle\u011fi) imaja dahil edilmesini engellemek i\u00e7in .dockerignore<\/code> dosyas\u0131n\u0131 kullan\u0131n.<\/li>\n<\/ul>\n\n# A\u015fama 1: Uygulamay\u0131 derle\nFROM node:18-alpine AS builder\nWORKDIR \/app\nCOPY package*.json .\/\nRUN npm install\nCOPY . .\nRUN npm run build\n\n# A\u015fama 2: Sadece derlenmi\u015f uygulamay\u0131 i\u00e7eren k\u00fc\u00e7\u00fck bir \u00fcretim imaj\u0131 olu\u015ftur\nFROM node:18-alpine\nWORKDIR \/app\nCOPY --from=builder \/app\/build .\/build\nCOPY --from=builder \/app\/package*.json .\/\nRUN npm install --omit=dev # Sadece \u00fcretim ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131 y\u00fckle\nCMD [\"node\", \"build\/index.js\"]\n<\/pre>\nDocker A\u011f\u0131 ve Depolama Mekanizmalar\u0131: Ger\u00e7ek Bir Uygulama Senaryosu<\/h3>\n
Docker A\u011f Modlar\u0131:<\/h4>\n
\n
Docker Depolama Se\u00e7enekleri:<\/h4>\n
\n
\nversion: '3.8'\nservices:\n webapp:\n build: .\n ports:\n - \"80:80\"\n networks:\n - app-network\n volumes:\n - images-data:\/app\/images # \u00dcr\u00fcn resimlerini kal\u0131c\u0131 olarak sakla\n environment:\n - DATABASE_HOST=db\n\n db:\n image: postgres:13\n environment:\n - POSTGRES_DB=ecommerce\n - POSTGRES_USER=admin\n - POSTGRES_PASSWORD=secret\n networks:\n - app-network\n volumes:\n - db-data:\/var\/lib\/postgresql\/data # Veritaban\u0131 verilerini kal\u0131c\u0131 olarak sakla\n\nnetworks:\n app-network:\n driver: bridge # \u00d6zel bir bridge a\u011f\u0131 olu\u015ftur\n\nvolumes:\n images-data:\n db-data:\n<\/pre>\nwebapp<\/code> ve db<\/code> servisleri app-network<\/code> ad\u0131nda \u00f6zel bir bridge a\u011f\u0131 \u00fczerinden ileti\u015fim kurar. Bu, izole bir ileti\u015fim ortam\u0131 sa\u011flar. Ayr\u0131ca, images-data<\/code> ve db-data<\/code> adl\u0131 Docker Volumes kullan\u0131larak hem uygulama taraf\u0131ndan y\u00fcklenen resimlerin hem de veritaban\u0131 verilerinin kal\u0131c\u0131 olarak saklanmas\u0131 sa\u011flan\u0131r. Bu, konteynerler yeniden ba\u015flat\u0131lsa veya silinse bile verilerin g\u00fcvende kalmas\u0131n\u0131 garantiler. Docker a\u011f ve depolama mekanizmalar\u0131n\u0131 do\u011fru bir \u015fekilde anlamak ve yap\u0131land\u0131rmak, da\u011f\u0131tt\u0131\u011f\u0131n\u0131z uygulamalar\u0131n g\u00fcvenilirli\u011fini ve performans\u0131n\u0131 art\u0131rmak i\u00e7in hayati \u00f6neme sahiptir.<\/p>\nKubernetes Derinlemesine: Orkestrasyonun \u00d6tesindeki G\u00fc\u00e7ler Nas\u0131l Ke\u015ffedilir?<\/h2>\n
Geli\u015fmi\u015f Kaynak Y\u00f6netimi ve Optimizasyon Teknikleri Nelerdir?<\/h3>\n
\n
requests<\/code> ve limits<\/code> tan\u0131mlamak, Kubernetes Scheduler'\u0131n pod'lar\u0131 uygun d\u00fc\u011f\u00fcmlere yerle\u015ftirmesini ve bir pod'un di\u011ferlerini olumsuz etkilemesini (noisy neighbor sendromu) \u00f6nlemesini sa\u011flar.\n\n
requests<\/code>:<\/strong> Pod i\u00e7in minimum garanti edilen kaynak miktar\u0131d\u0131r. Scheduler, pod'u bu kaynaklar\u0131 sa\u011flayabilecek bir d\u00fc\u011f\u00fcme yerle\u015ftirmeye \u00e7al\u0131\u015f\u0131r.<\/li>\nlimits<\/code>:<\/strong> Pod'un kullanabilece\u011fi maksimum kaynak miktar\u0131d\u0131r. CPU limitini a\u015fan pod'lar k\u0131s\u0131labilir (throttling), bellek limitini a\u015fan pod'lar ise do\u011frudan sonland\u0131r\u0131labilir (OOMKilled).<\/li>\n<\/ul>\n<\/li>\n\n
requests<\/code> hem de limits<\/code> e\u015fit ve tan\u0131mlanm\u0131\u015fsa. En y\u00fcksek \u00f6nceli\u011fe sahiptir.<\/li>\nrequests<\/code> tan\u0131mlanm\u0131\u015fsa ve limits<\/code> (e\u011fer tan\u0131mlanm\u0131\u015fsa) requests<\/code>'ten b\u00fcy\u00fckse. Orta \u00f6nceli\u011fe sahiptir.<\/li>\nrequests<\/code> veya limits<\/code> tan\u0131mlanmam\u0131\u015fsa. En d\u00fc\u015f\u00fck \u00f6nceli\u011fe sahiptir ve kaynak s\u0131k\u0131nt\u0131s\u0131 ya\u015fand\u0131\u011f\u0131nda ilk sonland\u0131r\u0131lacak pod'lar aras\u0131ndad\u0131r.<\/li>\n<\/ul>\n<\/li>\n\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: my-app-deployment\nspec:\n replicas: 3\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\n resources:\n requests:\n cpu: \"200m\" # 0.2 CPU \u00e7ekirde\u011fi iste\n memory: \"256Mi\" # 256 MiB bellek iste\n limits:\n cpu: \"500m\" # 0.5 CPU \u00e7ekirde\u011fi ile s\u0131n\u0131rl\u0131\n memory: \"512Mi\" # 512 MiB bellek ile s\u0131n\u0131rl\u0131\n---\napiVersion: autoscaling\/v2\nkind: HorizontalPodAutoscaler\nmetadata:\n name: my-app-hpa\nspec:\n scaleTargetRef:\n apiVersion: apps\/v1\n kind: Deployment\n name: my-app-deployment\n minReplicas: 3\n maxReplicas: 10\n metrics:\n - type: Resource\n resource:\n name: cpu\n target:\n type: Utilization\n averageUtilization: 70 # CPU kullan\u0131m\u0131 %70'in \u00fczerine \u00e7\u0131kt\u0131\u011f\u0131nda \u00f6l\u00e7ekle\n<\/pre>\nGeli\u015fmi\u015f Kubernetes A\u011f ve G\u00fcvenlik Politikalar\u0131 Nas\u0131l Uygulan\u0131r?<\/h3>\n
Kubernetes A\u011f Politikalar\u0131 (Network Policies):<\/h4>\n
\napiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n name: db-access-policy\n namespace: default\nspec:\n podSelector:\n matchLabels:\n app: database # Bu politika sadece 'app: database' etiketine sahip pod'lara uygulan\u0131r\n policyTypes:\n - Ingress # Gelen trafi\u011fi kontrol eder\n ingress:\n - from:\n - podSelector:\n matchLabels:\n app: webapp # Sadece 'app: webapp' etiketine sahip pod'lardan gelen trafi\u011fe izin ver\n ports:\n - protocol: TCP\n port: 5432 # Sadece PostgreSQL portuna izin ver\n<\/pre>\ndefault<\/code> namespace'indeki app: database<\/code> etiketli pod'lara sadece app: webapp<\/code> etiketli pod'lardan ve sadece 5432 (PostgreSQL) portu \u00fczerinden gelen trafi\u011fe izin verir. Di\u011fer t\u00fcm gelen trafik engellenir.<\/p>\nKubernetes G\u00fcvenlik Politikalar\u0131:<\/h4>\n
\n
Ekosistem ve Otomasyon: CI\/CD ile Entegre Derinlemesine DevOps Yakla\u015f\u0131mlar\u0131<\/h2>\n
Helm, Kustomize ve Operat\u00f6rler: Kompleks Uygulamalar\u0131 Y\u00f6netmenin \u0130leri Yollar\u0131<\/h3>\n
\n
\nmy-app-chart\/\n\u251c\u2500\u2500 Chart.yaml # Helm chart'\u0131 hakk\u0131nda bilgiler\n\u251c\u2500\u2500 values.yaml # Varsay\u0131lan konfig\u00fcrasyon de\u011ferleri\n\u251c\u2500\u2500 templates\/ # Kubernetes manifest \u015fablonlar\u0131\n\u2502 \u251c\u2500\u2500 deployment.yaml\n\u2502 \u251c\u2500\u2500 service.yaml\n\u2502 \u2514\u2500\u2500 _helpers.tpl # Yeniden kullan\u0131labilir \u015fablonlar\n\u2514\u2500\u2500 charts\/ # Ba\u011f\u0131ml\u0131 chart'lar (\u00f6rne\u011fin veritaban\u0131)\n<\/pre>\nvalues.yaml<\/code> dosyas\u0131ndaki de\u011ferleri de\u011fi\u015ftirerek veya birden fazla de\u011fer dosyas\u0131 kullanarak ayn\u0131 chart'\u0131 farkl\u0131 ortamlar i\u00e7in kolayca da\u011f\u0131tabilirsiniz.<\/p>\n\u0130zleme, G\u00fcnl\u00fckleme ve Uyar\u0131lar: Uygulama Sa\u011fl\u0131\u011f\u0131n\u0131 Derinlemesine Anlamak<\/h3>\n
\n
\n
\n