Container soyutlama merdiveni
"Kubernetes kullanmalı mıyız" sorusu mutlak olarak sorulur. Pratikte bir merdiven ve çoğu ekip mimari diagramların önerdiğinden bir-iki rung daha aşağıda mutlu.Rung 1: Tek host'ta Docker Compose
Ne: tek makine, compose stack'leri çalıştıran Docker (veya Podman).Uyduğu yer: küçük-orta dahili uygulamalar, dev ortamları, downtime kabul edilebilir tek-node üretim.
Bırakma zamanı: birden fazla node olduğunda.
Yıllarca üretim tek-node Docker Compose stack'leri çalıştıran müşterilerimiz var, mutlu. "Kubernetes kullanmalısın" baskısı genelde yanlış.
Rung 2: Docker Swarm veya Nomad
Ne: basit multi-node orkestrasyon. Swarm "birden çok node'a Docker Compose" gibidir. Nomad benzer ama daha parlatılmış.Uyduğu yer: 3-10 node, basit servis desenleri.
Bırakma zamanı: ekosistem hız tutmayı bırakırsa.
Çoğu ekibin atladığı rung. Compose'tan k8s'ye atlarlar.
Rung 3: managed Kubernetes (EKS, AKS, GKE, k3s)
Ne: tam Kubernetes. Managed control plane.Uyduğu yer: onlarca-binlerce servis, karmaşık ağ, polyglot stack'ler, multi-tenancy, dev/stage/prod parity, büyük ekip.
Rung 4: self-hosted Kubernetes
Ne: kendi donanımınızda/VM'lerinizde tam k8s. Control plane'i siz çalıştırırsınız.Uyduğu yer: regülatif veya maliyet sebepleri, on-prem gereksinimi, adanmış platform mühendisleri için yeterince büyük ekip.
Docker vs Podman
- Docker — varsayılan. Olgun, her yerde.
- Podman — daemonless, rootless-by-default, drop-in uyumlu CLI.
- containerd / nerdctl — altta çalışan.
Karşılığını veren image disiplini
- Multi-stage build'ler.
- Distroless veya alpine base image'leri.
- Sadece tag değil, base image digest'i pin'le.
- BuildKit ile build.
- Build zamanında SBOM üret.
- Build zamanı + registry pull zamanında zafiyet tarama.
Kimsenin planlamadığı şey
Image storage maliyeti. Image lifecycle politikaları olmayan ekip registry'sinde GB'larca tarihsel build biriktirir.Kubernetes işletme — acıyan kısımlar
- Yükseltmeler — cluster + node'lar + iş yükleri, farklı sıklıkta.
- Depolama — Kubernetes'te stateful iş yükleri gerçek mühendislik yatırımı.
- Ağ — CNI seçimi (Calico, Cilium) sonuçlu.
- Secret'lar — base k8s secret'ları varsayılan olarak at rest şifreli değil.
- RBAC — "herkes admin" yanlış yapılandırması kolay.
Uyaracağımız bir desen
Kubernetes adoption'ın ilk yılında service mesh benimsemek.Karşılığını veren bir desen
Şirketin servisleri için standart Helm chart'ları.Container yığınınız nedir?
The container abstraction ladder
The "should we use Kubernetes" question gets asked in absolutes. In practice, it's a ladder.Rung 1: Docker Compose on a single host
Where it fits: small to medium internal applications, dev environments, single-node production where downtime is acceptable.We have customers running production single-node Docker Compose stacks for years, happily.
Rung 2: Docker Swarm or Nomad
Where it fits: 3-10 nodes, simple service patterns.This rung is the one most teams skip.
Rung 3: managed Kubernetes (EKS, AKS, GKE, k3s)
Where it fits: dozens to thousands of services, complex networking, polyglot stacks, multi-tenancy.Rung 4: self-hosted Kubernetes
Where it fits: regulatory or cost reasons, on-prem requirement, large enough team.Docker vs Podman
- Docker — the default.
- Podman — daemonless, rootless-by-default.
- containerd / nerdctl — what runs underneath.
Image discipline that pays off
- Multi-stage builds.
- Distroless or alpine base images.
- Pin base image digest, not just tag.
- Build with BuildKit.
- SBOM at build time.
- Vulnerability scanning at build + at registry pull.
The thing nobody plans
Image storage cost.Operating Kubernetes — the parts that hurt
- Upgrades — cluster + nodes + workloads.
- Storage — stateful workloads on Kubernetes is real engineering.
- Networking — CNI choice (Calico, Cilium) is consequential.
- Secrets — base k8s secrets not encrypted at rest by default.
- RBAC — easy to misconfigure.
One pattern we'd warn about
Adopting service mesh in the first year of Kubernetes adoption.One pattern that pays off
Standard Helm charts for the company's services.What's your container stack?
