Bulut altyap\u0131s\u0131 y\u00f6netimi g\u00fcn\u00fcm\u00fczde hi\u00e7 olmad\u0131\u011f\u0131 kadar karma\u015f\u0131k hale geldi. \u00d6zellikle \u00e7ok kirac\u0131l\u0131 (multi-tenant) Kubernetes ortamlar\u0131nda, her bir kirac\u0131n\u0131n kendine \u00f6zg\u00fc ihtiya\u00e7lar\u0131n\u0131 y\u00f6netmek, kaynaklar\u0131 izole etmek ve \u00f6l\u00e7eklenebilirli\u011fi sa\u011flamak b\u00fcy\u00fck bir meydan okumad\u0131r. Bu makalede, altyap\u0131n\u0131n kod olarak y\u00f6netilmesi (IaC) felsefesinin g\u00fc\u00e7l\u00fc temsilcisi Terraform’un, bu senaryolarda neden s\u0131n\u0131rlar\u0131na ula\u015fabilece\u011fini ve veritaban\u0131 odakl\u0131, daha esnek bir yakla\u015f\u0131mla bu zorluklar\u0131n \u00fcstesinden nas\u0131l gelinebilece\u011fini derinlemesine inceleyece\u011fiz.<\/p>\n
Modern bulut altyap\u0131lar\u0131n\u0131n temel ta\u015flar\u0131ndan ikisi \u015f\u00fcphesiz Terraform ve Kubernetes\u2019tir. Terraform, HashiCorp taraf\u0131ndan geli\u015ftirilen, altyap\u0131y\u0131 kod olarak (Infrastructure as Code – IaC) tan\u0131mlaman\u0131za ve y\u00f6netmenize olanak tan\u0131yan a\u00e7\u0131k kaynakl\u0131 bir ara\u00e7t\u0131r. Sunuculardan a\u011f yap\u0131land\u0131rmalar\u0131na, veritabanlar\u0131ndan depolama birimlerine kadar geni\u015f bir yelpazedeki kaynaklar\u0131 deklaratif bir yakla\u015f\u0131mla, yani “olmas\u0131 gereken durumu” tan\u0131mlayarak olu\u015fturabilir, de\u011fi\u015ftirebilir ve silebilirsiniz. Di\u011fer yandan Kubernetes, konteynerize edilmi\u015f uygulamalar\u0131 otomatik olarak da\u011f\u0131tmak, \u00f6l\u00e7eklendirmek ve y\u00f6netmek i\u00e7in tasarlanm\u0131\u015f g\u00fc\u00e7l\u00fc bir orkestrasyon platformudur. Uygulamalar\u0131n\u0131z\u0131 y\u00fcksek eri\u015filebilirlikle \u00e7al\u0131\u015ft\u0131rmak i\u00e7in end\u00fcstri standard\u0131 haline gelmi\u015ftir.<\/p>\n
Peki, bu iki g\u00fc\u00e7l\u00fc ara\u00e7 bir araya geldi\u011finde \u00e7ok kirac\u0131l\u0131 bir ortam i\u00e7in ne anlama gelir? \u00c7ok kirac\u0131l\u0131l\u0131k, temel olarak birden fazla m\u00fc\u015fterinin veya “kirac\u0131n\u0131n” ayn\u0131 altyap\u0131 \u00fczerinde izole edilmi\u015f bir \u015fekilde hizmet ald\u0131\u011f\u0131 bir mimari modelidir. Bu, kaynak verimlili\u011fi sa\u011flar ve maliyetleri d\u00fc\u015f\u00fcr\u00fcr. \u0130lk bak\u0131\u015fta, Terraform\u2019un deklaratif do\u011fas\u0131 ve Kubernetes\u2019in soyutlama yetenekleri, \u00e7ok kirac\u0131l\u0131 bir ortam\u0131 y\u00f6netmek i\u00e7in m\u00fckemmel bir kombinasyon gibi g\u00f6r\u00fcnebilir. Her bir kirac\u0131 i\u00e7in ayr\u0131 Kubernetes namespace’leri olu\u015fturmak, bu namespace’lere \u00f6zg\u00fc kaynak limitleri (CPU, bellek), a\u011f politikalar\u0131 ve servis hesaplar\u0131 tan\u0131mlamak Terraform ile olduk\u00e7a kolayd\u0131r. Hatta her kirac\u0131 i\u00e7in bir Helm grafi\u011fi da\u011f\u0131tmak veya \u00f6zel bir uygulama yap\u0131land\u0131rmas\u0131 sa\u011flamak dahi ba\u015flang\u0131\u00e7ta y\u00f6netilebilir bir s\u00fcre\u00e7 gibi durur.<\/p>\n
\u00d6rne\u011fin, her kirac\u0131 i\u00e7in basit bir Kubernetes namespace’i ve bir kaynak kotas\u0131 tan\u0131mlamak istedi\u011finizde, Terraform HCL (HashiCorp Configuration Language) kodu a\u015fa\u011f\u0131daki gibi g\u00f6r\u00fcnebilir:<\/p>\n
resource \"kubernetes_namespace\" \"tenant_ns\" {\n metadata {\n name = \"tenant-${var.tenant_id}-namespace\"\n }\n}\n\nresource \"kubernetes_resource_quota\" \"tenant_quota\" {\n metadata {\n name = \"tenant-${var.tenant_id}-quota\"\n namespace = kubernetes_namespace.tenant_ns.metadata[0].name\n }\n spec {\n hard = {\n \"requests.cpu\" = \"1\"\n \"requests.memory\" = \"1Gi\"\n \"limits.cpu\" = \"2\"\n \"limits.memory\" = \"2Gi\"\n \"pods\" = \"10\"\n }\n }\n}<\/pre>\n<\/code><\/p>\n
Bu yakla\u015f\u0131m, az say\u0131da kirac\u0131n\u0131z oldu\u011funda sorunsuz \u00e7al\u0131\u015f\u0131r. Yeni bir kirac\u0131 eklendi\u011finde, Terraform dosyas\u0131na birka\u00e7 sat\u0131r ekler, terraform plan<\/code> ile de\u011fi\u015fiklikleri g\u00f6zden ge\u00e7irir ve terraform apply<\/code> ile yeni kaynaklar\u0131 da\u011f\u0131t\u0131rs\u0131n\u0131z. Olduk\u00e7a basit ve etkili! Ancak zamanla, kirac\u0131 say\u0131s\u0131 artt\u0131k\u00e7a, bu basitlik yerini karma\u015f\u0131kl\u0131\u011fa ve performans sorunlar\u0131na b\u0131rakmaya ba\u015flar. Her kirac\u0131n\u0131n kendine \u00f6zg\u00fc gereksinimleri (farkl\u0131 \u00f6zellik setleri, daha fazla kaynak, farkl\u0131 g\u00fcvenlik politikalar\u0131) devreye girdi\u011finde, Terraform state'i \u015fi\u015fer ve y\u00f6netim s\u00fcre\u00e7leri \u00e7\u0131\u011f\u0131r\u0131ndan \u00e7\u0131kar. \u0130\u015fte tam da bu noktada, ba\u015flang\u0131\u00e7ta her \u015feyin g\u00fczel g\u00f6r\u00fcnd\u00fc\u011f\u00fc bu yap\u0131, \u00f6l\u00e7eklenebilirlik s\u0131n\u0131rlar\u0131na ula\u015fmaya ba\u015flar ve yeni bir yakla\u015f\u0131ma ihtiya\u00e7 duyulur.<\/p>\n\u00d6l\u00e7eklenebilirlik Engelleri: Terraform Neden Yetersiz Kal\u0131r?<\/h2>\n
Terraform'un deklaratif g\u00fcc\u00fc tart\u0131\u015f\u0131lmaz olsa da, \u00e7ok kirac\u0131l\u0131 Kubernetes ortamlar\u0131nda belirli bir \u00f6l\u00e7e\u011fin \u00fczerine \u00e7\u0131kt\u0131\u011f\u0131nda ciddi zorluklarla kar\u015f\u0131la\u015fabiliriz. Bu zorluklar\u0131n ba\u015f\u0131nda, Terraform'un \"state\" (durum) y\u00f6netimi gelir. Terraform, y\u00f6netti\u011fi t\u00fcm altyap\u0131 kaynaklar\u0131n\u0131n ger\u00e7ek d\u00fcnyadaki durumunu kaydetti\u011fi bir state dosyas\u0131 tutar. Kirac\u0131 say\u0131s\u0131 artt\u0131k\u00e7a, her bir kirac\u0131ya ait namespace'ler, kotalar, servis hesaplar\u0131, ingress kurallar\u0131 ve hatta bazen spesifik uygulamalar\u0131n yap\u0131land\u0131rmalar\u0131 bu state dosyas\u0131na kaydedilir. Y\u00fczlerce, hatta binlerce kirac\u0131ya ula\u015ft\u0131\u011f\u0131n\u0131zda, bu state dosyas\u0131 devasa boyutlara ula\u015fabilir.<\/p>\n
Bu devasa state dosyas\u0131n\u0131n do\u011frudan performans \u00fczerindeki etkileri olduk\u00e7a belirgindir. \u0130lk olarak, terraform plan<\/code> ve terraform apply<\/code> komutlar\u0131n\u0131n \u00e7al\u0131\u015fma s\u00fcreleri dramatik bir \u015fekilde artar. Her bir i\u015flemde, Terraform t\u00fcm state dosyas\u0131n\u0131 okumak, mevcut altyap\u0131 ile kar\u015f\u0131la\u015ft\u0131rmak ve olas\u0131 de\u011fi\u015fiklikleri belirlemek zorundad\u0131r. Bu, uzun s\u00fcren planlama ve uygulama d\u00f6ng\u00fclerine yol a\u00e7abilir, bu da geli\u015ftirme ve da\u011f\u0131t\u0131m s\u00fcre\u00e7lerini yava\u015flat\u0131r. Kirac\u0131lar i\u00e7in acil bir kaynak art\u0131\u015f\u0131na ihtiya\u00e7 duyuldu\u011funda, mevcut yava\u015fl\u0131k kabul edilemez bir seviyeye ula\u015fabilir.<\/p>\n\u0130kinci olarak, b\u00fcy\u00fck state dosyalar\u0131n\u0131n y\u00f6netimi ba\u015fl\u0131 ba\u015f\u0131na bir sorundur. Yanl\u0131\u015fl\u0131kla yap\u0131lan bir de\u011fi\u015fiklik veya state dosyas\u0131ndaki bir bozulma, t\u00fcm altyap\u0131y\u0131 etkileyebilir. \"Blast radius\" olarak adland\u0131r\u0131lan bu risk, tek bir kirac\u0131 i\u00e7in yap\u0131lan basit bir konfig\u00fcrasyon de\u011fi\u015fikli\u011finin, t\u00fcm kirac\u0131lar\u0131n hizmetlerini etkileme potansiyeli ta\u015f\u0131mas\u0131 anlam\u0131na gelir. Bu durum, \u00f6zellikle canl\u0131 sistemlerde ciddi kesintilere yol a\u00e7abilir ve operasyonel ekipler i\u00e7in b\u00fcy\u00fck bir stres kayna\u011f\u0131d\u0131r. Ayr\u0131ca, state dosyas\u0131n\u0131n b\u00fcy\u00fcmesiyle birlikte e\u015fzamanl\u0131 de\u011fi\u015fiklik yapma yetene\u011fi de k\u0131s\u0131tlan\u0131r; birden fazla ki\u015fi ayn\u0131 anda state \u00fczerinde \u00e7al\u0131\u015fmaya kalkt\u0131\u011f\u0131nda \u00e7ak\u0131\u015fmalar (merge conflicts) ka\u00e7\u0131n\u0131lmaz hale gelir ve bu da s\u00fcre\u00e7leri daha da yava\u015flat\u0131r.<\/p>\n
\n Uzman \u0130pucu: B\u00fcy\u00fck bir Terraform state dosyas\u0131yla \u00e7al\u0131\u015f\u0131rken, terraform refresh=false<\/code> gibi komutlar\u0131 kullanarak planlama s\u00fcresini k\u0131saltmaya \u00e7al\u0131\u015fabilirsiniz, ancak bu, ger\u00e7ek d\u00fcnya durumuyla state dosyan\u0131z aras\u0131ndaki tutars\u0131zl\u0131k riskini art\u0131rabilir. Uzun vadede problem i\u00e7in kal\u0131c\u0131 \u00e7\u00f6z\u00fcm bulmak esast\u0131r.\n <\/div>\nDi\u011fer bir engel ise drift detection ve reconciliation (durum e\u015fitleme) yetenekleridir. Terraform deklaratif bir ara\u00e7t\u0131r, ancak Kubernetes ortam\u0131nda do\u011frudan m\u00fcdahaleler (\u00f6rne\u011fin, manuel kubectl<\/code> komutlar\u0131) veya d\u0131\u015f sistemlerden kaynaklanan de\u011fi\u015fiklikler, Terraform state'i ile ger\u00e7ek durum aras\u0131nda \"drift\" olu\u015fmas\u0131na neden olabilir. B\u00fcy\u00fck bir state dosyas\u0131nda bu drift'i tespit etmek ve d\u00fczeltmek olduk\u00e7a zordur. Her terraform apply<\/code> i\u015flemi, bu t\u00fcr sapmalar\u0131 d\u00fczeltmeye \u00e7al\u0131\u015f\u0131r, ancak s\u00fcre\u00e7 yava\u015f oldu\u011fundan, ger\u00e7ek zamanl\u0131 bir e\u015fitleme sa\u011flamak m\u00fcmk\u00fcn de\u011fildir.<\/p>\nSon olarak, geleneksel GitOps yakla\u015f\u0131mlar\u0131, Terraform'un bu denli b\u00fcy\u00fck ve dinamik state'leri y\u00f6netme konusunda zorlanmas\u0131yla birlikte etkinliklerini kaybeder. GitOps, altyap\u0131 ve uygulama konfig\u00fcrasyonlar\u0131n\u0131 Git deposunda y\u00f6netmeyi ve otomatik olarak da\u011f\u0131tmay\u0131 hedefler. Ancak her bir kirac\u0131 de\u011fi\u015fikli\u011fi i\u00e7in Git deposuna s\u00fcrekli commit atmak ve Terraform'u \u00e7al\u0131\u015ft\u0131rmak, hem repo tarih\u00e7esini \u015fi\u015firir hem de yukar\u0131da bahsedilen performans sorunlar\u0131 nedeniyle pratik olmaktan \u00e7\u0131kar. \u0130\u015fte bu nedenlerle, Terraform \u00e7ok kirac\u0131l\u0131 Kubernetes ortamlar\u0131nda belli bir \u00f6l\u00e7e\u011fin \u00f6tesine ge\u00e7ti\u011finde, altyap\u0131 y\u00f6neticilerini daha esnek, dinamik ve verimli bir \u00e7\u00f6z\u00fcme y\u00f6nlendiren ciddi k\u0131s\u0131tlamalar sunar.<\/p>\n
Veritaban\u0131 Odakl\u0131 Bir Yakla\u015f\u0131m Nas\u0131l \u00c7al\u0131\u015f\u0131r? Mimarisi ve Temel Bile\u015fenleri<\/h2>\n
Terraform'un \u00e7ok kirac\u0131l\u0131 ortamlardaki \u00f6l\u00e7eklenebilirlik k\u0131s\u0131tlamalar\u0131n\u0131 anlad\u0131ktan sonra, \u015fimdi bu sorunlar\u0131 a\u015fmak i\u00e7in veritaban\u0131 odakl\u0131 bir yakla\u015f\u0131m\u0131 nas\u0131l benimseyebilece\u011fimizi inceleyelim. Bu yakla\u015f\u0131m\u0131n temel fikri, dinamik olarak de\u011fi\u015fen ve kirac\u0131ya \u00f6zg\u00fc konfig\u00fcrasyon bilgilerini (\u00f6rne\u011fin, her kirac\u0131n\u0131n kaynak limitleri, aktif \u00f6zellik bayraklar\u0131, entegrasyon ayarlar\u0131 vb.) Terraform state dosyas\u0131ndan ay\u0131rarak merkezi bir veritaban\u0131nda saklamakt\u0131r. Terraform bu senaryoda tamamen devreden \u00e7\u0131kmaz; aksine, rol\u00fc daha stratejik bir hale gelir: Kubernetes k\u00fcmesi gibi temel platform altyap\u0131s\u0131n\u0131 ve t\u00fcm kirac\u0131lar\u0131n payla\u015faca\u011f\u0131 genel bile\u015fenleri (\u00f6rne\u011fin, Ingress Controller, Prometheus, vb.) y\u00f6netmeye devam eder. Kirac\u0131ya \u00f6zel dinamik konfig\u00fcrasyonlar ise veritaban\u0131 taraf\u0131ndan y\u00f6nlendirilir.<\/p>\n
Bu mimariyi olu\u015fturan temel bile\u015fenler \u015funlard\u0131r:<\/p>\n
\n- Terraform (Platform Katman\u0131 \u0130\u00e7in):<\/strong> Kubernetes k\u00fcmesinin kendisini (EKS, GKE, AKS gibi), temel a\u011f ayarlar\u0131n\u0131, depolama s\u0131n\u0131flar\u0131n\u0131 ve t\u00fcm kirac\u0131lar\u0131n kullanaca\u011f\u0131 payla\u015f\u0131ml\u0131 servisleri olu\u015fturmak i\u00e7in kullan\u0131l\u0131r. Bu, Terraform'un state dosyas\u0131n\u0131 \u00e7ok daha k\u00fc\u00e7\u00fck ve y\u00f6netilebilir tutar.<\/li>\n
- Merkezi Veritaban\u0131:<\/strong> Buras\u0131, t\u00fcm kirac\u0131ya \u00f6zg\u00fc konfig\u00fcrasyon verilerinin sakland\u0131\u011f\u0131 yerdir. PostgreSQL, MySQL, Cassandra veya MongoDB gibi bir teknoloji se\u00e7ilebilir. Veritaban\u0131, her kirac\u0131n\u0131n ID'sini, kaynak limitlerini, sahip oldu\u011fu \u00f6zellikleri ve di\u011fer t\u00fcm dinamik yap\u0131land\u0131rmalar\u0131 i\u00e7erir.<\/li>\n
- API Katman\u0131 (Kontrol D\u00fczlemi):<\/strong> Bu katman, kirac\u0131lar veya i\u00e7 sistemler taraf\u0131ndan (\u00f6rne\u011fin bir self-service portal\u0131ndan) gelen kirac\u0131 konfig\u00fcrasyon de\u011fi\u015fiklik isteklerini i\u015fler. Gelen istekleri do\u011frular, i\u015f mant\u0131\u011f\u0131n\u0131 uygular ve bu de\u011fi\u015fiklikleri veritaban\u0131na yazar.<\/li>\n
- Kubernetes Operat\u00f6r\u00fc veya Reconciler (E\u015fitleme Mekanizmas\u0131):<\/strong> Bu, veritaban\u0131 odakl\u0131 yakla\u015f\u0131m\u0131n kalbidir. Kubernetes k\u00fcmesi i\u00e7erisinde \u00e7al\u0131\u015fan bu \u00f6zel uygulama, s\u00fcrekli olarak merkezi veritaban\u0131ndaki kirac\u0131 konfig\u00fcrasyonlar\u0131n\u0131 izler. Veritaban\u0131ndaki de\u011fi\u015fiklikleri alg\u0131lad\u0131\u011f\u0131nda, Kubernetes API'si arac\u0131l\u0131\u011f\u0131yla k\u00fcmede ilgili kaynaklar\u0131 (namespace'ler, resource quotas, network policies, servis hesaplar\u0131 vb.) olu\u015fturur, g\u00fcnceller veya siler.<\/li>\n<\/ol>\n
Bu mimarideki ak\u0131\u015f \u015fu \u015fekilde \u00f6zetlenebilir:<\/p>\n
\n- Yeni bir kirac\u0131 olu\u015fturma iste\u011fi, API katman\u0131na ula\u015f\u0131r.<\/li>\n
- API, iste\u011fi i\u015fler, gerekli do\u011frulamalar\u0131 yapar ve kirac\u0131 bilgilerini merkezi veritaban\u0131na kaydeder.<\/li>\n
- Kubernetes k\u00fcmesinde \u00e7al\u0131\u015fan operat\u00f6r, veritaban\u0131ndaki yeni kirac\u0131 kayd\u0131n\u0131 veya mevcut kay\u0131tlardaki de\u011fi\u015fikli\u011fi alg\u0131lar.<\/li>\n
- Operat\u00f6r, bu bilgilere dayanarak Kubernetes API'si \u00fczerinden ilgili kaynaklar\u0131 (\u00f6rne\u011fin,
tenant-xyz<\/code> ad\u0131nda bir namespace, bu namespace i\u00e7in bir ResourceQuota<\/code> objesi) olu\u015fturur veya g\u00fcnceller.<\/li>\n- Kirac\u0131n\u0131n Kubernetes \u00fczerindeki kaynaklar\u0131, operat\u00f6r taraf\u0131ndan veritaban\u0131ndaki son durumla e\u015fle\u015fecek \u015fekilde s\u00fcrekli olarak izlenir ve g\u00fcncellenir.<\/li>\n<\/ol>\n
\u00d6zetle, bu veritaban\u0131 odakl\u0131 yakla\u015f\u0131m, Terraform'un a\u011f\u0131r state y\u00f6netimi y\u00fck\u00fcn\u00fc ortadan kald\u0131r\u0131rken, Kubernetes'in dinamik yap\u0131s\u0131ndan en iyi \u015fekilde faydalanmam\u0131z\u0131 sa\u011flar. De\u011fi\u015fiklikler \u00e7ok daha h\u0131zl\u0131 yans\u0131t\u0131l\u0131r, \"blast radius\" k\u00fc\u00e7\u00fcl\u00fcr ve operasyonel ekiplerin y\u00fck\u00fc \u00f6nemli \u00f6l\u00e7\u00fcde azal\u0131r.<\/p>\n
Ad\u0131m Ad\u0131m Uygulama: Veritaban\u0131 Destekli Bir Kubernetes Operat\u00f6r\u00fc Nas\u0131l Geli\u015ftirilir?<\/h3>\n
Veritaban\u0131 odakl\u0131 yakla\u015f\u0131m\u0131n mimarisi anla\u015f\u0131ld\u0131ktan sonra, \u015fimdi bu konsepti somutla\u015ft\u0131rmak i\u00e7in \u00f6rnek bir uygulama senaryosu \u00fczerinden ilerleyelim. Amac\u0131m\u0131z, her kirac\u0131 i\u00e7in Kubernetes \u00fczerinde izole bir namespace olu\u015fturmak ve bu namespace'e belirli kaynak limitleri atamak olsun. Bu senaryo, SaaS platformlar\u0131nda s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan temel bir gereksinimdir. Gelin bu s\u00fcreci ad\u0131m ad\u0131m inceleyelim.<\/p>\n
1. Merkezi Veritaban\u0131 Kurulumu ve \u015eemas\u0131<\/h4>\n
\u0130lk ad\u0131m, kirac\u0131 verilerini saklayacak bir veritaban\u0131 se\u00e7mek ve yap\u0131land\u0131rmakt\u0131r. Basit bir PostgreSQL veritaban\u0131 bu i\u015f i\u00e7in olduk\u00e7a uygun olacakt\u0131r. A\u015fa\u011f\u0131da, tenants<\/code> ad\u0131nda \u00f6rnek bir tablo \u015femas\u0131 bulunmaktad\u0131r:<\/p>\nCREATE TABLE tenants (\n id SERIAL PRIMARY KEY,\n tenant_id VARCHAR(255) UNIQUE NOT NULL,\n status VARCHAR(50) NOT NULL DEFAULT 'Active',\n cpu_requests_limit VARCHAR(10) NOT NULL,\n memory_requests_limit VARCHAR(10) NOT NULL,\n pod_limit INT NOT NULL,\n updated_at TIMESTAMP WITH TIME ZONE DEFAULT CURRENT_TIMESTAMP\n);\n\n-- updated_at alan\u0131n\u0131 otomatik g\u00fcncelleyen trigger\nCREATE OR REPLACE FUNCTION update_timestamp()\nRETURNS TRIGGER AS $$\nBEGIN\n NEW.updated_at = NOW();\n RETURN NEW;\nEND;\n$$ LANGUAGE plpgsql;\n\nCREATE TRIGGER update_tenants_timestamp\nBEFORE UPDATE ON tenants\nFOR EACH ROW\nEXECUTE FUNCTION update_timestamp();<\/pre>\n<\/code><\/p>\n
Bu \u015fema, her kirac\u0131 i\u00e7in benzersiz bir tenant_id<\/code>, durumu, CPU ve bellek talep limitleri ve pod s\u0131n\u0131r\u0131 gibi temel bilgileri tutar. updated_at<\/code> s\u00fctunu, bir operat\u00f6r\u00fcn de\u011fi\u015fiklikleri izlemesi i\u00e7in kritik bir rol oynayacakt\u0131r.<\/p>\n2. API Katman\u0131 Geli\u015ftirme (Basit Bir REST API)<\/h4>\n
Kirac\u0131 olu\u015fturma, okuma, g\u00fcncelleme ve silme (CRUD) i\u015flemlerini y\u00f6netecek basit bir REST API'ye ihtiyac\u0131m\u0131z var. Go, Python (FastAPI\/Flask) veya Node.js (Express) gibi dillerle kolayca geli\u015ftirilebilir. A\u015fa\u011f\u0131da, Go ile yaz\u0131lm\u0131\u015f basit bir API endpoint'i (pseudocode) \u00f6rne\u011fi yer almaktad\u0131r:<\/p>\n
\/\/ Go ile bir API endpoint \u00f6rne\u011fi\nfunc createTenantHandler(w http.ResponseWriter, r *http.Request) {\n \/\/ Gelen tenant verilerini parse et\n var tenantData struct { \/* ... alanlar ... *\/ }\n if err := json.NewDecoder(r.Body).Decode(&tenantData); err != nil { \/* ... hata ... *\/ }\n\n \/\/ Veritaban\u0131na kaydet\n _, err := db.Exec(\"INSERT INTO tenants (tenant_id, cpu_requests_limit, ...) VALUES ($1, $2, ...)\",\n tenantData.TenantID, tenantData.CPURequestsLimit \/* ... *\/)\n if err != nil { \/* ... hata ... *\/ }\n\n w.WriteHeader(http.StatusCreated)\n json.NewEncoder(w).Encode(map[string]string{\"message\": \"Kirac\u0131 ba\u015far\u0131yla olu\u015fturuldu\"})\n}<\/pre>\n<\/code><\/p>\n
Bu API, d\u0131\u015far\u0131dan gelen istekleri al\u0131p veritaban\u0131na yazar. Operat\u00f6r\u00fcm\u00fcz, bu veritaban\u0131n\u0131 okuyarak Kubernetes kaynaklar\u0131n\u0131 g\u00fcncelleyecektir.<\/p>\n
3. Kubernetes Operat\u00f6r\u00fc Geli\u015ftirme<\/h4>\n
Bu, veritaban\u0131 odakl\u0131 yakla\u015f\u0131m\u0131n kalbi olan k\u0131s\u0131md\u0131r. Go dili ve client-go<\/code> veya controller-runtime<\/code> k\u00fct\u00fcphaneleri ile bir Kubernetes operat\u00f6r\u00fc geli\u015ftirece\u011fiz. Bu operat\u00f6r, d\u00fczenli aral\u0131klarla veritaban\u0131n\u0131 sorgulayacak, kirac\u0131 verilerindeki de\u011fi\u015fiklikleri tespit edecek ve buna g\u00f6re Kubernetes API'si ile etkile\u015fime ge\u00e7ecektir.<\/p>\n\/\/ Kubernetes Operat\u00f6r\u00fc'n\u00fcn temel \u00e7al\u0131\u015fma mant\u0131\u011f\u0131 (pseudocode)\n\nfunc RunOperator(db *sql.DB, clientset *kubernetes.Clientset) {\n ticker := time.NewTicker(30 * time.Second) \/\/ Her 30 saniyede bir veritaban\u0131n\u0131 kontrol et\n defer ticker.Stop()\n\n for range ticker.C {\n \/\/ Veritaban\u0131ndan aktif kirac\u0131 verilerini \u00e7ek\n rows, err := db.Query(\"SELECT tenant_id, cpu_requests_limit, memory_requests_limit, pod_limit FROM tenants WHERE status = 'Active'\")\n if err != nil { \/* ... hata y\u00f6netimi ... *\/ continue }\n defer rows.Close()\n\n var activeTenants []TenantConfig \/\/ TenantConfig: struct with tenant_id, cpu_limit etc.\n for rows.Next() { \/* ... verileri oku ... *\/ }\n\n \/\/ Her aktif kirac\u0131 i\u00e7in Kubernetes kaynaklar\u0131n\u0131 e\u015fitle\n for _, tenant := range activeTenants {\n desiredNamespaceName := fmt.Sprintf(\"tenant-%s\", tenant.TenantID)\n \n \/\/ Namespace'i olu\u015ftur veya g\u00fcncelle\n _, err := clientset.CoreV1().Namespaces().Get(context.TODO(), desiredNamespaceName, metav1.GetOptions{})\n if err != nil && k8serrors.IsNotFound(err) {\n ns := &v1.Namespace{ \/* ... namespace objesi ... *\/ }\n _, err = clientset.CoreV1().Namespaces().Create(context.TODO(), ns, metav1.CreateOptions{})\n if err != nil { \/* ... hata ... *\/ continue }\n } else if err != nil { \/* ... hata ... *\/ continue }\n\n \/\/ ResourceQuota'y\u0131 olu\u015ftur veya g\u00fcncelle\n resourceQuotaName := fmt.Sprintf(\"tenant-%s-quota\", tenant.TenantID)\n quota, err := clientset.CoreV1().ResourceQuotas(desiredNamespaceName).Get(context.TODO(), resourceQuotaName, metav1.GetOptions{})\n if err != nil && k8serrors.IsNotFound(err) {\n rq := &v1.ResourceQuota{ \/* ... kota objesi ... *\/ }\n _, err = clientset.CoreV1().ResourceQuotas(desiredNamespaceName).Create(context.TODO(), rq, metav1.CreateOptions{})\n if err != nil { \/* ... hata ... *\/ }\n } else if err == nil {\n \/\/ Mevcut kotay\u0131 veritaban\u0131 verisiyle kar\u015f\u0131la\u015ft\u0131r ve g\u00fcncelle (basitle\u015ftirilmi\u015f)\n \/\/ ... kar\u015f\u0131la\u015ft\u0131rma ve g\u00fcncelleme mant\u0131\u011f\u0131 ...\n _, err = clientset.CoreV1().ResourceQuotas(desiredNamespaceName).Update(context.TODO(), quota, metav1.UpdateOptions{})\n if err != nil { \/* ... hata ... *\/ }\n } else { \/* ... hata ... *\/ }\n }\n \/\/ Veritaban\u0131nda olmayan (\u00f6rne\u011fin 'Inactive' durumdaki) kirac\u0131 kaynaklar\u0131n\u0131 Kubernetes'ten temizle\n \/\/ Bu k\u0131s\u0131m i\u00e7in ayr\u0131 bir temizleme mant\u0131\u011f\u0131 implemente edilmeli.\n }\n}<\/pre>\n<\/code><\/p>\n
Bu kod blo\u011fu, operat\u00f6r\u00fcn temel mant\u0131\u011f\u0131n\u0131 g\u00f6stermektedir. Ger\u00e7ek bir operat\u00f6r, daha geli\u015fmi\u015f hata y\u00f6netimi, retry mekanizmalar\u0131, durum de\u011fi\u015fikliklerini izlemek i\u00e7in veritaban\u0131 tetikleyicileri (Change Data Capture - CDC) kullanma veya daha sofistike bir reconciliation d\u00f6ng\u00fcs\u00fc i\u00e7erebilir. Operat\u00f6r, veritaban\u0131ndaki updated_at<\/code> alan\u0131n\u0131 izleyerek sadece de\u011fi\u015fen kirac\u0131lar\u0131 i\u015fleyerek daha verimli hale getirilebilir.<\/p>\nBu \u00fc\u00e7 temel bile\u015fen bir araya geldi\u011finde, Terraform'un performans sorunlar\u0131na tak\u0131lmadan binlerce kirac\u0131y\u0131 dinamik olarak y\u00f6netebilen \u00f6l\u00e7eklenebilir bir sistem elde etmi\u015f oluruz. Terraform, k\u00fcmenin kendisini ve operat\u00f6r\u00fcn da\u011f\u0131t\u0131m\u0131n\u0131 y\u00f6netirken, kirac\u0131 ya\u015fam d\u00f6ng\u00fcs\u00fc API ve operat\u00f6r arac\u0131l\u0131\u011f\u0131yla veritaban\u0131 odakl\u0131 bir yakla\u015f\u0131mla sa\u011flan\u0131r.<\/p>\n
Ger\u00e7ek D\u00fcnya Senaryolar\u0131 ve Vaka Analizleri: B\u00fcy\u00fck \u015eirketler Nas\u0131l Yakla\u015f\u0131yor?<\/h2>\n
Veritaban\u0131 odakl\u0131 bir yakla\u015f\u0131m teoride kula\u011fa ho\u015f gelse de, ger\u00e7ek d\u00fcnyadaki uygulamalar\u0131 ve getirdi\u011fi faydalar olduk\u00e7a \u00f6nemlidir. \u00d6zellikle b\u00fcy\u00fck \u00f6l\u00e7ekli SaaS (Software as a Service) sa\u011flay\u0131c\u0131lar\u0131 ve bulut platformlar\u0131, bu t\u00fcr mimarileri benimseyerek operasyonel verimliliklerini ve \u00f6l\u00e7eklenebilirliklerini art\u0131rm\u0131\u015flard\u0131r. \u0130\u015fte birka\u00e7 vaka analizi senaryosu:<\/p>\n
Vaka Analizi 1: SaaS Platformu Sa\u011flay\u0131c\u0131s\u0131<\/h4>\n
Y\u00fcz binlerce m\u00fc\u015fterisine hizmet veren bir SaaS \u015firketini d\u00fc\u015f\u00fcn\u00fcn. Her m\u00fc\u015fterinin farkl\u0131 kaynak ihtiya\u00e7lar\u0131 ve \u00f6zellik setleri vard\u0131. Ba\u015flang\u0131\u00e7ta her yeni m\u00fc\u015fteri i\u00e7in Terraform ile yeni Kubernetes namespace'leri, kotalar ve politikalar da\u011f\u0131t\u0131l\u0131yordu. Ancak m\u00fc\u015fteri say\u0131s\u0131 artt\u0131k\u00e7a terraform apply<\/code> s\u00fcreleri 45 dakikay\u0131 a\u015ft\u0131 ve kritik bir yama da\u011f\u0131t\u0131m\u0131nda t\u00fcm platformun etkilenebilece\u011fi endi\u015fesi ya\u015fand\u0131. M\u00fc\u015fterilerin self-service portal\u0131ndan kaynak art\u0131\u015f\u0131 talep etmesi g\u00fcnler s\u00fcrebiliyordu.<\/p>\n\u00c7\u00f6z\u00fcm olarak \u015firket, veritaban\u0131 odakl\u0131 bir yakla\u015f\u0131ma ge\u00e7ti. PostgreSQL'de her m\u00fc\u015fterinin konfig\u00fcrasyonu sakland\u0131. Bir Go tabanl\u0131 API, self-service portal\u0131ndan gelen istekleri i\u015fleyerek bu veritaban\u0131n\u0131 g\u00fcncelliyordu. K\u00fcme i\u00e7inde \u00e7al\u0131\u015fan \u00f6zel bir Kubernetes operat\u00f6r\u00fc (m\u00fc\u015fteri operat\u00f6r\u00fc), veritaban\u0131ndaki de\u011fi\u015fiklikleri izleyerek Kubernetes API'si \u00fczerinden m\u00fc\u015fteri namespace'lerini, ResourceQuota'lar\u0131 ve di\u011fer kaynaklar\u0131 otomatik olarak y\u00f6netiyordu. Terraform'un rol\u00fc ise sadece Kubernetes k\u00fcmesinin kendisini ve payla\u015f\u0131ml\u0131 altyap\u0131lar\u0131 y\u00f6netmekle s\u0131n\u0131rl\u0131 kald\u0131.<\/p>\n
Sonu\u00e7lar:<\/strong> Bu ge\u00e7i\u015fle terraform apply<\/code> s\u00fcreleri dakikalardan saniyelere d\u00fc\u015ft\u00fc. M\u00fc\u015fteriye \u00f6zel kaynak provizyonu anl\u0131k hale geldi. Bir kirac\u0131daki hata veya yanl\u0131\u015f konfig\u00fcrasyonun etkisi, o kirac\u0131n\u0131n namespace'iyle s\u0131n\u0131rl\u0131 kalarak \"blast radius\" riskini \u00f6nemli \u00f6l\u00e7\u00fcde azaltt\u0131. Operasyonel verimlilik artt\u0131, m\u00fchendisler m\u00fc\u015fteri taleplerine \u00e7ok daha h\u0131zl\u0131 yan\u0131t verebilir hale geldi.<\/p>\nVaka Analizi 2: B\u00fcy\u00fck Bir Veri Platformu Sa\u011flay\u0131c\u0131s\u0131<\/h4>\n
B\u00fcy\u00fck \u015firketlerin dahili ekipleri i\u00e7in \u00f6zel veri analiz platformlar\u0131 sunan bir ba\u015fka \u015firket, her i\u00e7 ekibe kendi izole edilmi\u015f Spark k\u00fcmelerini ve Kafka topiklerini sa\u011flayarak \u00e7ok kirac\u0131l\u0131 bir model benimsedi. \u0130lk ba\u015fta, her yeni ekip i\u00e7in y\u00fczlerce sat\u0131rl\u0131k Terraform HCL kodlar\u0131 yaz\u0131l\u0131yor, bu da kopyalama hatalar\u0131na ve tutars\u0131zl\u0131klara yol a\u00e7\u0131yordu. K\u00fcme boyutlar\u0131n\u0131n veya topik say\u0131lar\u0131n\u0131n g\u00fcncellenmesi, t\u00fcm Terraform state'ini etkiliyor ve uzun da\u011f\u0131t\u0131m s\u00fcreleri gerektiriyordu.<\/p>\n
\u00c7\u00f6z\u00fcm olarak \u015firket, bir i\u00e7 geli\u015ftirici platformu (IDP) kurdu ve arkas\u0131na veritaban\u0131 odakl\u0131 bir model entegre etti. Ekipler, bir web aray\u00fcz\u00fc veya CLI arac\u0131l\u0131\u011f\u0131yla kendi Spark k\u00fcmelerinin boyutlar\u0131n\u0131, Kafka topik say\u0131lar\u0131n\u0131 ve di\u011fer parametreleri belirleyebiliyordu. Bu istekler, bir API arac\u0131l\u0131\u011f\u0131yla merkezi bir DynamoDB tablosuna kaydediliyordu. Kubernetes k\u00fcmesinde \u00e7al\u0131\u015fan \u00f6zel bir \"Data Platform Operator\", bu DynamoDB tablosunu izleyerek her ekibin Kubernetes \u00fczerinde kendi Spark operat\u00f6r\u00fcn\u00fc, Kafka kaynaklar\u0131n\u0131 ve ilgili depolama birimlerini y\u00f6netiyordu. Terraform yine sadece temel Kubernetes k\u00fcmesi ve operat\u00f6r\u00fcn da\u011f\u0131t\u0131m\u0131 i\u00e7in kullan\u0131ld\u0131.<\/p>\n
Sonu\u00e7lar:<\/strong> Bu ge\u00e7i\u015f sayesinde, yeni ekiplerin veri platformuna onboarding s\u00fcresi saatlerden dakikalara d\u00fc\u015ft\u00fc. Ekipler, self-service yetenekleri sayesinde kendi kaynaklar\u0131n\u0131 ba\u011f\u0131ms\u0131z bir \u015fekilde y\u00f6netebilir hale geldi, bu da merkezi operasyonel ekibin \u00fczerindeki y\u00fck\u00fc azaltt\u0131. Hata oran\u0131 d\u00fc\u015ft\u00fc ve platformun genel g\u00fcvenilirli\u011fi artt\u0131.<\/p>\n\u0130leri D\u00fczey \u0130pu\u00e7lar\u0131 ve En \u0130yi Uygulamalar: Daha Robust Bir Yap\u0131 \u0130\u00e7in Neler Yapmal\u0131s\u0131n\u0131z?<\/h2>\n
Veritaban\u0131 odakl\u0131 Kubernetes y\u00f6netim yakla\u015f\u0131m\u0131n\u0131 benimserken, sisteminizi daha sa\u011flam, g\u00fcvenli ve verimli hale getirmek i\u00e7in baz\u0131 ileri d\u00fczey ipu\u00e7lar\u0131 ve en iyi uygulamalar\u0131 g\u00f6z \u00f6n\u00fcnde bulundurmal\u0131s\u0131n\u0131z:<\/p>\n
G\u00fcvenlik ve \u0130zolasyon Derinli\u011fi<\/h4>\n\n- RBAC:<\/strong> Her kirac\u0131n\u0131n namespace'ine \u00f6zel, en az yetki ilkesine uygun RBAC rolleri ve RoleBinding'ler tan\u0131mlay\u0131n.<\/li>\n
- Network Policies:<\/strong> Kirac\u0131 namespace'leri aras\u0131ndaki ileti\u015fimi kat\u0131 bir \u015fekilde kontrol edin.<\/li>\n
- Pod Security Standards (PSS):<\/strong> Pod'lar\u0131n g\u00fcvenlik ba\u011flamlar\u0131n\u0131 k\u0131s\u0131tlayarak g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131 minimize edin.<\/li>\n
- Secret Y\u00f6netimi:<\/strong> Hassas verileri Kubernetes Secret'lar\u0131 i\u00e7inde saklay\u0131n ve ilgili kirac\u0131 uygulamalar\u0131yla s\u0131n\u0131rl\u0131 eri\u015fim sa\u011flay\u0131n (\u00f6rn. Kube-Vault).<\/li>\n<\/ul>\n
Veritaban\u0131 Yedekleme ve Kurtarma Stratejileri<\/h4>\n
Kirac\u0131 konfig\u00fcrasyonlar\u0131n\u0131z\u0131n kalbi olan veritaban\u0131n\u0131z\u0131n y\u00fcksek eri\u015filebilirli\u011fini ve veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc sa\u011flamak mutlak bir zorunluluktur. D\u00fczenli yedeklemeler al\u0131n ve felaket kurtarma (Disaster Recovery - DR) planlar\u0131 olu\u015fturun. Yedeklemelerinizi farkl\u0131 co\u011frafi b\u00f6lgelerde veya farkl\u0131 bulut sa\u011flay\u0131c\u0131lar\u0131nda saklamay\u0131 d\u00fc\u015f\u00fcn\u00fcn. Bulut sa\u011flay\u0131c\u0131lar\u0131n\u0131n y\u00f6netilen veritaban\u0131 servislerinin otomatik yedekleme ve replikasyon \u00f6zelliklerinden faydalan\u0131n.<\/p>\n
Operat\u00f6r \u0130zleme, Loglama ve Uyar\u0131 Sistemleri<\/h4>\n
Operat\u00f6r\u00fcn\u00fcz\u00fcn sa\u011fl\u0131\u011f\u0131n\u0131 ve performans\u0131n\u0131 s\u00fcrekli olarak izlemek, sorunlar\u0131 proaktif bir \u015fekilde tespit etmek i\u00e7in hayati \u00f6neme sahiptir. Prometheus ile operat\u00f6r metriklerini toplay\u0131n, Grafana ile g\u00f6rselle\u015ftirin. Operat\u00f6r loglar\u0131n\u0131 merkezi bir ELK (Elasticsearch, Logstash, Kibana) veya Loki sistemine g\u00f6nderin. Belirli e\u015fiklerin a\u015f\u0131lmas\u0131 durumunda (\u00f6rne\u011fin, uzun s\u00fcreli reconciliation hatalar\u0131) uyar\u0131lar olu\u015fturun.<\/p>\n
Maliyet Optimizasyonu ve Otomatik \u00d6l\u00e7ekleme<\/h4>\n
Kirac\u0131 ba\u015f\u0131na maliyetler, \u00e7ok kirac\u0131l\u0131 ortamlar\u0131n en hassas noktalar\u0131ndan biridir. Operat\u00f6r\u00fcn\u00fcz, kirac\u0131lar\u0131n kaynak taleplerini (requests ve limits) dinamik olarak ayarlayabilmeli ve Kubernetes'in HPA (Horizontal Pod Autoscaler), VPA (Vertical Pod Autoscaler) ve Cluster Autoscaler gibi otomatik \u00f6l\u00e7ekleme \u00f6zelliklerinden faydalanmal\u0131d\u0131r. Gereksiz kaynak tahsisini \u00f6nlemek i\u00e7in kirac\u0131 kullan\u0131m paternlerini analiz edin ve optimizasyonlar yap\u0131n.<\/p>\n
Veritaban\u0131 Odakl\u0131 GitOps<\/h4>\n
Veritaban\u0131 \u015femas\u0131n\u0131 ve hatta ba\u015flang\u0131\u00e7 kirac\u0131 verilerini Git depolar\u0131nda y\u00f6neterek \"veritaban\u0131 odakl\u0131 GitOps\" prensiplerini uygulay\u0131n. Veritaban\u0131 g\u00f6\u00e7 ara\u00e7lar\u0131 (\u00f6rne\u011fin, Flyway, Liquibase) kullanarak \u015fema de\u011fi\u015fikliklerini otomatikle\u015ftirin ve s\u00fcr\u00fcm kontrol\u00fcne al\u0131n. Bu, veritaban\u0131 de\u011fi\u015fikliklerinin izlenebilirli\u011fini ve geri al\u0131nabilirli\u011fini art\u0131r\u0131r.<\/p>\n
De\u011fi\u015fiklik Verisi Yakalama (Change Data Capture - CDC)<\/h4>\n
Operat\u00f6r\u00fcn veritaban\u0131n\u0131 d\u00fczenli aral\u0131klarla sorgulamas\u0131 yerine, veritaban\u0131ndaki de\u011fi\u015fiklikleri ger\u00e7ek zamanl\u0131 olarak yakalayan CDC teknolojilerini kullanmay\u0131 de\u011ferlendirebilirsiniz (\u00f6rne\u011fin, Debezium ile Kafka). Bu, operat\u00f6r\u00fcn yaln\u0131zca ger\u00e7ekten de\u011fi\u015fen verilerle ilgilenmesini sa\u011flayarak gecikmeyi azalt\u0131r ve verimlili\u011fi art\u0131r\u0131r.<\/p>\n