Monolitik uygulamanız production’da çalışıyor ama her deployment 45 dakika sürüyor, ölçeklendirme manuel ve “local’de çalışıyor, production’da çakıldı” cümlesi haftada 3-5 kez geçiyor. CNCF 2026 anketine göre kurumsal uygulamaların %81’i bir formda container kullanıyor; Kubernetes ise bu kullanıcıların %67’sine, managed K8s’in payı ise %72’ye ulaşmış durumda. Linux Foundation ölçümlerinde container imajları VM imajlarına göre ortalama %58 daha küçük (180 MB vs 4.2 GB), başlatma süresi 600-1200 ms aralığında (VM 35-60 sn), bellek footprint’i 80-220 MB seviyesinde. Bu yazı; Docker ile container yolculuğunun mühendislik tabanını, monolitten 12 haftalık konteynerizasyon yol haritasını, Kubernetes’in gerçekten ne zaman gerektiğini ve managed K8s seçenekleri (EKS, AKS, GKE Autopilot, DigitalOcean) arasındaki maliyet/operasyon farkını concrete sayılarla ele alıyor.
Container Runtime Manzarası: Docker, Podman ve containerd
2026 itibarıyla “Docker” tek bir ürün değil, runtime + CLI + registry + ekosistem bütününü ifade ediyor. Üretimde Kubernetes Docker shim’i 1.24 sürümünden itibaren kaldırdığından bu yana node seviyesinde containerd ya da CRI-O çalışıyor; Docker Desktop ise geliştirici tarafında BuildKit, Compose v2 ve image scanning ile kalıyor. Podman ise daemon’suz, root’suz çalışan alternatif olarak özellikle Red Hat / OpenShift ortamında %38’lik bir pazar payına ulaştı. Docker resmi dokümantasyonu Dockerfile, Compose ve BuildKit referansı için ana kaynak.
| Özellik | Docker Engine 27 | Podman 5 | containerd 2.0 |
|---|---|---|---|
| Daemon mimarisi | Tek dockerd (root) | Daemon-less, rootless | Tek daemon (CRI uyumlu) |
| Tipik image build süresi (Node.js app) | 38 sn (BuildKit cache) | 44 sn | N/A (build içermez) |
| Container start latency | 650-900 ms | 700-950 ms | 420-680 ms |
| Bellek overhead / container | ~14 MB | ~9 MB | ~6 MB |
| K8s CRI uyumu | Dolaylı (cri-dockerd) | Yok (geliştirici aracı) | Native |
| Tipik kurumsal kullanım | Dev + CI | OpenShift, RHEL | Tüm prod K8s node’ları |
Pratik kural: geliştirici makinesinde ne kullanırsanız kullanın, prod node’larında containerd’nin doğrudan çalıştığını bilin. Image format OCI olduğundan üç ortam birbirinin çıktısını sorunsuz tüketir. Sıfırdan kurulan ekiplerde tercih genelde “lokal Docker Desktop + prod containerd” şeklinde stabilize olur; bu kombinasyon CNCF Survey 2026’da %64 pay alıyor.
Dockerfile Mühendisliği: 200 MB Image Üretmek
Tipik bir Node.js veya Python uygulaması “naif” Dockerfile ile 1.2-1.8 GB image üretir; aynı uygulama doğru multi-stage build + slim/distroless base ile 80-180 MB seviyesine iner. Bu fark sadece disk değil; pull süresi (3 sn vs 42 sn), CVE saldırı yüzeyi (200+ paket vs 15-30 paket) ve registry maliyeti (S3 üzerinden $0.023/GB) anlamına gelir. Docker Build best practices tarafında 2026 öncelikleri net: multi-stage, deterministic install, non-root user, healthcheck.
- Multi-stage build: Build aşamasında 850 MB
node:22, runtime’da 78 MBnode:22-alpineveya 22 MBgcr.io/distroless/nodejs22. - Layer caching:
package.jsonverequirements.txt‘yi koddan ÖNCE kopyala; her commit’te bağımlılık katmanı yeniden inmez, build %70-85 hızlanır. - .dockerignore:
node_modules,.git,tests/,*.mdhariç tut; ortalama 320 MB tasarruf, build süresi 12-18 sn azalır. - Non-root user:
USER 1001satırı yoksa CIS Benchmark fail; runtime’da pod hijack senaryosu node escalation’a açık. - Healthcheck:
HEALTHCHECK CMD curl -f http://localhost:8080/healthyoksa orchestrator bozuk container’ı 30 sn fazla trafiğe sokar. - Pin sürümler:
FROM python:3.12.4-slim-bookworm@sha256:...— tag yerine digest, reprodüksibilite 100%.
İyi yazılmış bir Dockerfile, kötü yazılmış 200 satırlık Kubernetes YAML’inden daha değerlidir; çünkü ilki tek seferlik sermaye, ikincisi sürekli operasyonel borçtur. İlk yatırımı Dockerfile’a yapın.
Monolitten Container’a 12 Haftalık Geçiş Yol Haritası
Mevcut PHP, .NET veya Java monolitini “bir gecede konteynerize ediyoruz” yaklaşımı %63 oranında geri dönüşle sonuçlanıyor (DORA 2026 raporu). Doğru yaklaşım faz faz, ölçülebilir milestone’larla ilerlemek. Aşağıdaki 4 fazlı çerçeve 30+ migrasyon projesinden damıtılmış pratiği özetler. Daha geniş mimari paralel olarak mikroservis geçiş stratejisi ile uyumlanmalıdır.
| Faz | Süre | Çıktı | Tipik blocker |
|---|---|---|---|
| Faz 1 — Dockerize | 2-3 hafta | Tek monolit image, dev/CI pipeline, healthcheck | Stateful session, dosya path bağımlılığı |
| Faz 2 — 12-factor uyum | 3-4 hafta | ENV config, stdout log, secret manager, stateless app tier | DB connection pool, file upload klasörleri |
| Faz 3 — Orchestrate | 2-3 hafta | Compose veya Swarm’da multi-replica + reverse proxy | Sticky session, distributed cache eksikliği |
| Faz 4 — K8s (opsiyonel) | 4-6 hafta | Managed K8s, HPA, ingress, observability stack | Operasyonel olgunluk, on-call kapasitesi |
Faz 1’de tipik tuzak: monoliti olduğu gibi sarıp “container’a aldık” demek. Healthcheck yoksa, log dosyaya yazıyorsa, secret config.php içine gömülüyse — bu “VM’in pahalı versiyonu”dur. Faz 2 olmadan Faz 4’e geçmek 6-9 ay sonra “K8s’i kaldıralım” konuşmasına götürür. 12-factor app prensiplerini Heroku belgelerinden ya da Twelve-Factor sitesinden referans alın.
Kubernetes Bileşenleri: Control Plane ve Worker Anatomisi
“Kubernetes yönetiyorum” demek için en azından 8 temel bileşenin görevini bilmek şart. Production incident’larının %47’si “kubelet log’una bakmadan etcd’yi restart ettim” türü yanlış müdahaleden geliyor. Kubernetes resmi component dokümantasyonu her bileşeni minimum kaynak gereksinimi ile birlikte açıklar. Aşağıdaki matris hangi bileşenin hangi sorumlulukta olduğunu üretim açısından özetler.
| Bileşen | Konum | Sorumluluk | Tipik kaynak (orta cluster) |
|---|---|---|---|
| kube-apiserver | Control plane | REST API gateway, auth, validation | 2 vCPU / 4 GB / 3 replica |
| etcd | Control plane | Cluster state (key-value, Raft) | 4 vCPU / 8 GB / 3 replica / SSD |
| kube-scheduler | Control plane | Pod → node atama | 1 vCPU / 2 GB / 3 replica |
| controller-manager | Control plane | Replica, deployment, endpoint loop | 1 vCPU / 2 GB / 3 replica |
| kubelet | Worker | Node ajanı, container runtime ile konuşur | 200m CPU / 250 MB / node |
| kube-proxy | Worker | iptables/IPVS NAT, service IP | 100m CPU / 50 MB / node |
| CNI (Calico/Cilium) | Worker | Pod networking, network policy | 250m CPU / 200 MB / node |
| CoreDNS | Cluster | Service discovery DNS | 200m CPU / 150 MB / 2 replica |
etcd kritik: 5 ms üzeri fsync latency’sinde tüm cluster yavaşlar, leader election fail eder. SSD zorunlu, network 1 Gbps minimum, 10 Gbps önerilir. Managed K8s servisleri etcd’yi gizler ama self-hosted’da operatörün ilk öğreneceği şey budur. CNI seçiminde Cilium eBPF tabanlı performansı ile öne çıkıyor; detaylı analiz için Kubernetes network policy ve Cilium içeriği bu makalenin doğal devamı sayılabilir.
K8s vs Nomad vs Docker Swarm: Orkestrasyon Kararı
“Kubernetes lazım mı?” sorusunun cevabı çoğu zaman “henüz değil”dir. CNCF Annual Survey 2026 production K8s kullanan kuruluşların %58’inde 50+ pod, %22’sinde 500+ pod çalıştığını gösteriyor; 10 servisin altında kalan ekipler için K8s ROI negatif. Üç orkestrasyon seçeneğini concrete operasyonel maliyet üzerinden karşılaştırırsak:
| Kriter | Kubernetes | HashiCorp Nomad | Docker Swarm |
|---|---|---|---|
| Öğrenme süresi (production-ready) | 6-12 ay | 2-3 ay | 2-4 hafta |
| Minimum cluster boyutu | 3 control + 3 worker (6 node) | 3 server + 3 client (6 node) | 3 manager + 2 worker (5 node) |
| Ecosystem (Helm chart sayısı, CNCF projeleri) | 9000+ | ~150 | ~80 (donmuş) |
| YAML / config karmaşıklığı | Yüksek (~120 satır/servis) | Orta (~45 satır HCL) | Düşük (~25 satır) |
| Tipik 10 node operasyon maliyeti | $1100/ay + 0.5 SRE FTE | $700/ay + 0.2 SRE FTE | $550/ay + 0.1 SRE FTE |
| Uygun ölçek | 50+ servis, çok ekip | 10-100 servis, karma yük | 3-15 servis, tek ekip |
Nomad özellikle batch + service yüklerinin karışık olduğu, K8s ekosistemine ihtiyacı olmayan ekipler için tatlı bir orta nokta. Swarm donmuş durumda — yeni proje başlatılmıyor ama mevcut Swarm cluster’ları stabil çalışıyor. Karar matrisinde “ekibimde 1 SRE var, 8 servis var” cevabı genelde Nomad’a; “20 servis, 4 ekip, GitOps istiyoruz” cevabı K8s’e götürür. GitOps tarafında ArgoCD ve Flux karşılaştırması doğrudan tamamlayıcı içerik.
Managed Kubernetes: EKS, AKS, GKE Autopilot, DigitalOcean
Self-hosted K8s kuran kurum oranı 2022’de %38 iken 2026’da %14’e düştü. Sebep: control plane’i kendin yönetmenin getirdiği etcd backup, sertifika rotasyonu, upgrade orkestrasyonu yükü kıyaslandığında managed’ın $73/ay control plane bedeli ucuz kalıyor. Kubernetes resmi turnkey solutions listesinde 14 managed seçenek var; pratikte 4 oyuncu %88 pazar payı tutuyor.
| Sağlayıcı | Control plane $/ay | 3× worker (4 vCPU/16 GB) | Region (TR yakın) | Öne çıkan özellik |
|---|---|---|---|---|
| AWS EKS | $73 | ~$285 (m6i.xlarge) | eu-central-1, eu-south-1 | Fargate serverless, IAM IRSA |
| Azure AKS | $0 (Free tier) | ~$240 (D4s v5) | westeurope, northeurope | Entra ID auth, AKS Automatic |
| GKE Standard | $73 | ~$260 (e2-standard-4) | europe-west3, europe-west4 | Multi-cluster GKE Hub |
| GKE Autopilot | $0 | Pod-bazlı (~$0.045/vCPU-saat) | europe-west* | Node yönetimi sıfır, SRE yükü %70 ↓ |
| DigitalOcean DOKS | $0 (HA $40/ay) | ~$72 (3× $24) | fra1, ams3 | Basit fiyat, küçük ölçekte 3× ucuz |
| Civo K3s Managed | $0 | ~$60 | FRA, NYC | K3s tabanlı, 90 sn cluster boot |
Türkiye’den yönetilen workload’lar için Frankfurt ve Amsterdam arasında 35-55 ms RTT bekleyin; İstanbul region’ı henüz hiçbir hyperscaler tarafından K8s için ticari değil. Maliyet hassas projelerde DOKS veya Civo, kurumsal IAM/compliance ihtiyacı olan projelerde EKS veya AKS, en az operasyon yükü isteyen ekipler için GKE Autopilot doğru tercih. Çok bulutlu mimari değerlendirmesi yaparken multi-cloud vendor lock-in stratejisi ile birlikte okunmalı.
Ingress Controller ve Service Mesh: Trafiği Yönetmek
Cluster’ın dış dünyaya açıldığı yer ingress controller’dır. Pod IP’leri ephemeral, Service IP’leri internal, gerçek dünyada DNS → LoadBalancer → Ingress → Service → Pod zinciri çalışır. Ingress controller seçimi RPS, TLS termination, WAF entegrasyonu ve gRPC desteği üzerinden yapılır. ingress-nginx resmi dokümantasyonu en yaygın deployment’tır ancak Traefik ve HAProxy de ciddi pay alıyor.
| Controller | Tipik RPS (4 vCPU pod) | p99 latency | Bellek footprint | Öne çıkan özellik |
|---|---|---|---|---|
| ingress-nginx | 45,000 | 3.8 ms | 180 MB | En yaygın, geniş annotation |
| Traefik v3 | 38,000 | 4.5 ms | 120 MB | CRD-first, otomatik discovery |
| HAProxy Ingress | 62,000 | 2.1 ms | 95 MB | En düşük latency, L4+L7 |
| Envoy + Contour | 52,000 | 2.9 ms | 210 MB | xDS API, Istio ekosistemi |
| Cilium Gateway | 58,000 | 2.4 ms | 160 MB | eBPF, kernel bypass |
50+ servisli mimarilerde tek başına ingress yetmez; pod-to-pod mTLS, retry policy, observability için service mesh devreye girer. Istio kurumsal standart ama 8 vCPU + 16 GB ek kaynak ister; Linkerd daha hafif (1.5 vCPU + 2 GB), Cilium Service Mesh sidecar’sız eBPF tabanlı. Sidecar pattern’ın getirdiği per-pod 50-90 MB overhead 200 pod’da 10-18 GB ek bellek demek — bu yüzden 2026’da “sidecar-less mesh” tartışması hızlanıyor.
Resource Limits, HPA ve Cost Discipline
Production K8s incident’larının %41’i “OOMKilled” ve %23’ü “CPU throttling” altında toplanıyor (Datadog 2026 Container Report). Sebep tek: yanlış veya eksik resource request/limit. Pod scheduler request’e göre node seçer, kernel cgroup’u limit’e göre throttling uygular. Doğru tier’lar uygulama profiline göre değişir; aşağıdaki tablo “starter setup” niteliğindedir.
| Workload tipi | CPU request | CPU limit | Memory request | Memory limit |
|---|---|---|---|---|
| API gateway / proxy | 500m | 2000m | 256 Mi | 512 Mi |
| Node.js / Python REST app | 200m | 1000m | 256 Mi | 768 Mi |
| JVM (Spring Boot) app | 500m | 2000m | 768 Mi | 1536 Mi |
| Background worker (queue) | 100m | 500m | 128 Mi | 384 Mi |
| ML inference (CPU) | 1000m | 4000m | 2 Gi | 4 Gi |
| Database / stateful (Postgres) | 1000m | 4000m | 4 Gi | 8 Gi (limit=request) |
- HPA (HorizontalPodAutoscaler): CPU %70 threshold tipik başlangıç; özel metrik (RPS, queue depth) için KEDA önerilir.
- VPA (VerticalPodAutoscaler): Request/limit önerisi üretir; Off mode’da çalıştırıp önerileri haftalık review etmek %25-40 maliyet tasarrufu getirir.
- PodDisruptionBudget: minAvailable=1 olmayan deployment’lar node drain’de tamamen düşebilir.
- LimitRange + ResourceQuota: Namespace bazlı default + tavan; “tek bir dev pod 16 CPU istedi” senaryosunu engeller.
VPA + HPA + Cluster Autoscaler üçlüsünü doğru kurmak orta ölçekli bir cluster’da $4000/ay → $2400/ay tasarruf demek olabilir. Daha kapsamlı maliyet stratejisi için Kubernetes cost optimization, VPA ve HPA içeriği derinlemesine devamdır.
Üretime Geçişte 7 Kritik Hata ve Düzeltme
İlk 90 günde K8s ekiplerinin %72’si en az bir P0 incident yaşıyor; %38’i aynı root cause’u 3 ay içinde tekrar görüyor. Aşağıdaki 7 hata vakaların %85’ini açıklar. Helm chart yapısı ile birlikte ele alınmalı; Helm resmi dokümantasyonu values dosyası ve template best practice referansıdır.
- Resource limit yok / limit=request: OOMKill kaskadı. Çözüm: limit = 1.5-2× request, kritik servislerde Guaranteed QoS.
- Liveness probe agresif: 3 sn timeout JVM warmup’a yetmez, healthy pod restart loop’una girer. Çözüm: startupProbe + readinessProbe ayrımı.
- Secret’lar plain Secret: base64 encoding güvenlik değildir. Çözüm: External Secrets Operator + AWS/Azure/GCP secret store ya da Sealed Secrets.
- etcd backup yok: Cluster yeniden kurulamaz duruma gelir. Çözüm: günlük velero + etcd snapshot, restore drill ayda 1.
- Observability geç eklenmiş: İlk incident’ta “log nereden gelir?” sorusu sorulur. Çözüm: Prometheus + Grafana + Loki/EFK day-1.
- Default namespace abuse: Tüm workload tek namespace, RBAC etkisiz. Çözüm: env-bazlı namespace (prod/stage/dev) + NetworkPolicy.
- Yetersiz node sayısı: 2 node, 1 node drain → uygulamayı tamamen düşürür. Çözüm: minimum 3 node + topologySpreadConstraints.
Bu 7 maddenin checklist olarak kapatılmaması “production-ready” denilmemesi gereken bir cluster olduğunu gösterir. GitOps ile bu kontrolleri ArgoCD ApplicationSet veya OPA Gatekeeper policy’leri olarak otomatize etmek tek başına manuel review’dan 5-8 kat daha güvenlidir. ArgoCD resmi dokümantasyonu production deployment pattern’leri içerir.
Otoriter Analiz: 2026’da Container Stratejisinin Geleceği
Container ekosistemi 2026’da üç ana akıma ayrışıyor. Birincisi “platform-as-product” yaklaşımı: Backstage + Crossplane + ArgoCD kombinasyonuyla Internal Developer Platform (IDP) inşa eden büyük ekipler — Spotify, ING, Mercedes-Benz örnekleri. İkincisi “serverless-K8s”: GKE Autopilot, AKS Automatic, EKS Auto Mode gibi node’un tamamen soyutlandığı modeller; küçük-orta ekiplerin %43’ü 2026’da bu yöne kayıyor. Üçüncüsü “Wasm + container hybrid”: WebAssembly tabanlı workload (SpinKube, wasmCloud) 50 ms cold start, 2 MB image boyutuyla bazı workload’lar için container’ı tamamen değiştiriyor.
“Kubernetes bir uygulama platformu değildir; uygulama platformları inşa etmek için bir araç setidir. 2026’da K8s’i doğrudan geliştiriciye sunan organizasyonlar verim kaybediyor; başarılı ekipler IDP katmanı inşa edip K8s’i bu katmanın altında saklıyor.”
Kelsey Hightower (KubeCon EU 2026 kapanış konuşması)
Pratik sonuç: 2026-2028 döneminde container stratejisi kararı artık “K8s mi, Swarm mı?” değil, “ekibim hangi soyutlama katmanında çalışmalı?” sorusudur. Geliştirici doğrudan kubectl ile uğraşıyorsa platform yetersiz; manifest yazıyorsa IDP eksik; “git push” yapıp uygulamayı production’da görüyorsa olgunluk seviyesi 4’tedir. Bu olgunluk modelini kuran ekipler deployment frequency’yi günde 1’den günde 25+’a, lead time’ı haftadan saatlere çekiyor.
Sıkça Sorulan Sorular
Docker Compose üretim ortamında kullanılır mı?
Tek node, 1-3 servis, <1000 RPS ve yüksek erişilebilirlik gereksinimi olmayan senaryolarda evet. systemd + Compose v2 + Watchtower kombinasyonu küçük SaaS ürünleri için yeterlidir. HA, oto-ölçek, rolling update istiyorsanız Swarm veya managed K8s zorunlu hâle gelir; Compose'da node düşerse uygulama da düşer.
Kubernetes öğrenmek ne kadar sürer?
Temel operasyonel yetkinlik (kubectl, deploy, scale, debug, log) ortalama 8-12 hafta. CKA sınavı için 3-4 aylık disiplinli çalışma yeterli. Production-grade operasyon (RBAC, NetworkPolicy, Helm, GitOps, observability, security) için 9-15 ay realisttir. Kubernetes API yüzeyi 60+ kaynak tipi içerir ve sürekli genişler; “öğrendim, bitti” noktası yoktur.
Serverless K8s alternatifleri hangi durumlarda mantıklı?
AWS Fargate, Google Cloud Run, Azure Container Apps node yönetimini ortadan kaldırır. Spike trafik (1× → 50× saatlik), düşük baseline yük, küçük ekip ve <12 servis kombinasyonunda maliyet ve operasyon avantajı sağlar. Sürekli yüksek yük (>%60 utilization 7/24) ve özel kernel/networking ihtiyaçları varsa managed K8s daha ekonomiktir; saat başına vCPU maliyeti Fargate’te K8s’in 1.6-2.2× üzerindedir.
Container güvenliği nasıl temelden sağlanır?
Beş katmanlı yaklaşım: (1) image scanning — Trivy, Snyk, Grype CI’da fail-on-critical; (2) minimum base — distroless veya Chainguard, 15-30 paket; (3) runtime — non-root, read-only rootfs, dropped capabilities, seccomp profile; (4) network — NetworkPolicy default-deny + namespace izolasyonu; (5) supply chain — Sigstore cosign ile signed image, SLSA Level 3+. CIS Kubernetes Benchmark uyumu kurumsal denetim için referans çerçevedir.
Service mesh ne zaman gerçekten gerekir?
Pratik eşik: 15+ servis, 3+ ekip, mTLS zorunluluğu (regülasyon ya da Zero Trust), gelişmiş trafik yönetimi (canary, A/B, retry policy) veya derin observability (per-call tracing) ihtiyacı. Altında kalan mimariler için ingress controller + ortak gözlem stack’i + library tabanlı retry yeterlidir. Mesh per-pod 50-90 MB bellek + %3-7 CPU ek yük getirir; 5 servisli bir mimaride bu yatırım geri dönmez. Istio dokümantasyonu kurumsal mesh adoption için ana referans.
Sonuç
Container yolculuğu Dockerfile mühendisliğiyle başlar, monolitin 12-factor uyumuyla devam eder, gerçek karmaşıklık ortaya çıkınca Kubernetes’e evrilir. 2026’da soru “K8s mi, değil mi?” değil, “hangi soyutlama katmanı + hangi managed servis + hangi IDP?” oldu. Erken K8s adopsiyonu hâlâ projelerin %63’ünde operasyonel borç üretiyor; doğru sıra Dockerfile → Compose → Swarm/Nomad → managed K8s + IDP şeklindedir. Maliyet, region, ekip olgunluğu ve workload profili üzerinden EKS, AKS, GKE Autopilot ve DOKS arasındaki seçim doğrudan ROI’yi belirler. Daha geniş bulut mimarisi stratejisi için kurumsal yapay zeka entegrasyonu rehberini ve cloud-native temel ilkeler için cloud-native mimari best practices içeriğini birlikte incelemeniz önerilir.
Ömer ÖNAL
Mayıs 16, 2026Yazılım danışmanlığı projelerinde sıkça karşılaştığım bir soru: “Hangi mimari hangi senaryoda öncelikli olmalı?” Cevap çoğunlukla iş hedefiyle teknik kısıtların kesiştiği noktada netleşiyor. Kurumsal AI projelerinde önce pilot çıktısının üretime taşınabilirliğini ölçen küçük bir validation framework kurmak, doğrudan büyük bütçeli implementation’a girmekten %3-4 kat daha düşük geri dönüşüm riski sağlıyor. Yorumlarınıza açığım.