Özet: Kubernetes (K8s), Google Borg deneyiminden doğan ve 2015'ten beri CNCF çatısı altında geliştirilen, konteyner orkestrasyonunda fiili endüstri standardı haline gelen açık kaynaklı platformdur. Konteynerlerin zamanlanmasını, kendi kendini iyileştirmesini, otomatik ölçeklemeyi, servis keşfini ve sürüm dağıtımını tek bir deklaratif API üzerinden yönetir.
Ana noktalar:
- Kubernetes; Pod, Service, Deployment, Namespace gibi temel objelerle deklaratif altyapı sunar.
- Control plane (API Server, etcd, scheduler, controller manager) ve worker node (kubelet, kube-proxy, container runtime) iki ana katmandır.
- Docker Swarm geri çekilmiştir; OpenShift ve Nomad belirli senaryolarda alternatiftir.
- KaaS modeli, küçük ve orta ekipler için 3 yıllık TCO'da self-hosted'a göre belirgin tasarruf sağlar.
- Üretime hazır küme için Prometheus, Loki, RBAC, NetworkPolicy, Velero ve görüntü güvenlik taraması standarttır.
Mikroservis mimarisine geçen herhangi bir ekip kısa süre içinde aynı sorunla yüzleşir: onlarca konteyner, yüzlerce örnek, sürekli güncellenen sürümler ve farklı sunuculara dağılmış iş yükleri arasında düzeni nasıl kuracaksınız? 2026 itibarıyla bu sorunun endüstri standardı yanıtı kesindir: Kubernetes. CNCF (Cloud Native Computing Foundation) yıllık anketleri, üretim ortamlarının büyük çoğunluğunun Kubernetes ile konteyner orkestrasyonu yaptığını ve cloud-native ekosistemin Kubernetes etrafında konsolide olduğunu göstermektedir.
Bu rehber; DevOps mühendislerine, platform ekibi liderlerine, mikroservis mimarisi tasarlayan yazılım ekiplerine ve teknik karar vericilere yöneliktir. Kubernetes'in ne olduğunu, mimarisini, temel objelerini, gerçek bir Pod ve Service dağıtımının nasıl göründüğünü, hangi iş yükleri için uygun olduğunu, alternatiflerle karşılaştırmasını ve üretime taşırken kontrol etmeniz gereken hususları ele alacağız. Hedef; ezbere bilgi yerine üretim kararı verirken kullanabileceğiniz bir çerçeve sunmak.
İster ilk kümeni kurmaya hazırlanıyor ol, ister mevcut self-hosted ortamından yönetilen bir hizmete (KaaS) geçmeyi değerlendiriyor ol, aşağıdaki bölümler bu kararı netleştirecektir.
Kubernetes nedir? Kısa bir tanım
Konteyner orkestrasyonu kavramı
Konteynerler (özellikle Docker), uygulamayı tüm bağımlılıklarıyla birlikte paketleyen hafif, taşınabilir birimlerdir. Bir konteyneri tek başına çalıştırmak basittir; ancak yüzlerce konteyneri farklı sunucularda dağıtık, hatalara dayanıklı, dinamik ölçeklenebilir biçimde yönetmek başka bir disiplindir. İşte bu disipline konteyner orkestrasyonu denir.
Kubernetes (yaygın kısaltması K8s), Google tarafından geliştirilip 2014'te açık kaynak olarak yayınlanan, bugün CNCF (Cloud Native Computing Foundation) çatısı altında ilerleyen orkestrasyon platformudur. Konteynerlerin nereye yerleştirileceğine karar verir, hata anında yeniden başlatır, ölçeklemeyi yönetir ve servisler arası ağ trafiğini düzenler.
Kubernetes ne işe yarar?
Kubernetes beş temel sorunu çözer. Birincisi, konteyner zamanlama: hangi node'da hangi konteyner çalışacak? İkincisi, kendi kendini iyileştirme: çöken konteyner otomatik yeniden başlatılır. Üçüncüsü, ölçekleme: yük arttığında otomatik replika eklenir. Dördüncüsü, hizmet keşfi ve yük dengeleme: konteyner adresleri sürekli değişirken servisler birbirini bulur. Beşincisi, sürüm dağıtımı: yeni sürüm aşamalı, geri alınabilir biçimde yayılır.
Bu yetenekler tek tek bakıldığında alternatifleriyle çözülebilir; ancak Kubernetes hepsini tek bir deklaratif API ve aynı operasyonel modelin altında birleştirir. Bu birleştirme, ekiplerin platform üzerine standart araçlar, eğitim materyalleri ve operasyonel bilgi üretmesini mümkün kılar.
Kubernetes kısa tarihi
Google Borg'dan CNCF'ye geçiş
Kubernetes'in kökeni, Google'ın 2003'ten beri iç kullanımda olan Borg sistemine dayanır. Google milyarlarca konteyneri Borg üzerinde çalıştırma deneyimini, 2014'te Kubernetes olarak açık kaynağa açtı. 2015'te CNCF kurulduğunda Kubernetes ilk projeydi ve yönetimi tek bir şirketten bağımsız bir vakfa devredildi.
Endüstri standartı haline gelişi
Açık kaynak yapısı, geniş ekosistemi ve bulut sağlayıcılarının destekli hizmetler (EKS, AKS, GKE) sunmasıyla Kubernetes 2026 itibarıyla konteyner orkestrasyonunun fiili standardı haline gelmiştir. Rakipleri (Docker Swarm, Apache Mesos) büyük ölçüde geri çekilmiş, ekosistem Kubernetes etrafında konsolide olmuştur.
Kubernetes mimarisi ve temel kavramlar
Control plane (master) bileşenleri: API server, etcd, scheduler, controller manager
Control plane, kümenin beynidir ve dört temel bileşenden oluşur. API Server, tüm istekleri kabul eden REST API katmanıdır; kubectl, controller'lar ve operatörler buraya bağlanır. etcd, kümenin tüm durum bilgisini tutan, yüksek tutarlılığa sahip dağıtık anahtar-değer deposudur. Scheduler, yeni Pod'ları uygun node'lara yerleştirir; kaynak gereksinimleri, taints/tolerations ve affinity kurallarına göre karar verir. Controller Manager, kontrol döngülerini çalıştırır; desired state ile actual state arasındaki farkı kapatır.
Worker node bileşenleri: kubelet, kube-proxy, container runtime
Worker node'lar iş yükünü çalıştıran sunuculardır. Kubelet, node üzerinde çalışan ajan; Pod'ları başlatır, sağlık durumunu izler ve control plane'e raporlar. Kube-proxy, ağ trafiği yönlendirmesini yapar. Container runtime (containerd veya CRI-O), konteynerleri fiilen çalıştıran motordur. Docker, 1.20 sürümünden itibaren resmi olarak kaldırılmıştır; modern kümeler containerd ile çalışır.
Temel objeler: Pod, Service, Deployment, Namespace, ConfigMap, Secret
Pod, Kubernetes'in en küçük dağıtım birimidir ve bir veya birden fazla konteyner barındırır. Service, Pod'lara stabil bir ağ adresi sağlar. Deployment, Pod'ların istenen sayıda replikasının çalışmasını ve yeni sürümlerin dağıtımını yönetir. Namespace, kümeyi mantıksal bölümlere ayırır. ConfigMap yapılandırma verisi, Secret hassas veri (şifre, anahtar) saklar. Ingress, dış HTTP trafiğini kümeye yönlendirir; PersistentVolume kalıcı depolama sağlar. Bu objelerin tam referansı ve manifest örnekleri resmi Kubernetes belgelerinde sunulmaktadır.
Networking modeli (CNI)
Kubernetes ağ modeli, her Pod'un benzersiz bir IP adresine sahip olmasını ve NAT olmadan diğer Pod'larla iletişim kurabilmesini öngörür. Bu modeli uygulayan eklentilere Container Network Interface (CNI) denir; Calico, Cilium, Flannel popüler seçeneklerdir. Cilium, eBPF tabanlı yaklaşımıyla son dönemde özellikle ağ güvenliği ve gözlemlenebilirlik açısından öne çıkıyor.
Basit bir örnek: ilk Pod ve Service'i nasıl dağıtırız?
YAML manifest yapısı
Kubernetes'te kaynaklar YAML manifest dosyaları ile tanımlanır. Tipik bir Deployment manifesti üç ana bölüm içerir: apiVersion ve kind (kaynak türü), metadata (isim, label) ve spec (istenen durum). Replikasyon sayısı, kullanılan imaj, kaynak limitleri ve port tanımları spec içinde belirtilir. YAML deklaratif yapıyı destekler; "ne istediğinizi" söylersiniz, Kubernetes nasıl yapılacağıyla ilgilenir.
kubectl ile dağıtım
kubectl apply -f deployment.yaml komutu manifesti kümeye uygular. Kubernetes mevcut durumu istenen durumla karşılaştırır ve farkı kapatır. kubectl get pods ile çalışan Pod'ları, kubectl logs ile loglarını, kubectl describe ile detaylı durum bilgisini görürsünüz. Üretim ekiplerinde manifest'ler Git deposunda tutulur ve CI/CD pipeline'ı tarafından kümeye uygulanır (GitOps yaklaşımı, Argo CD veya Flux ile).
Kubernetes ile ne tür iş yükleri çalıştırılır?
Mikroservisler
Mikroservis mimarisinin doğal yuvası Kubernetes'tir. Her servis ayrı Pod'da çalışır, bağımsız ölçeklenir, ayrı CI/CD pipeline'ı ile yayınlanır. Service mesh (Istio, Linkerd, Cilium) servisler arası iletişimi, gözlemlenebilirliği ve güvenlik politikalarını yönetir.
CI/CD pipeline'ları
Jenkins, GitLab Runner, Tekton, Argo Workflows gibi CI/CD araçları Kubernetes üzerinde dinamik Pod'lar olarak çalıştırılır. Build worker'ları gerektiğinde başlatılır, iş bitince temizlenir; sabit altyapı maliyeti minimuma iner.
GitOps yaklaşımı bu kullanıma çok yakındır: Git deposundaki manifest değişiklikleri Argo CD veya Flux tarafından otomatik kümeye uygulanır. Üretim ortamına manuel kubectl müdahalesi kalkar, tüm değişiklikler izlenebilir hale gelir.
Veri işleme job'ları (CronJob, batch)
Periyodik raporlama, ETL süreçleri, yedekleme görevleri CronJob ile zamanlanır. Tek seferlik veri işleme Job kaynağıyla çalıştırılır. Apache Spark ve Flink gibi büyük veri çerçeveleri de Kubernetes üzerinde dağıtık olarak çalışır.
GPU iş yükleri ve ML training
NVIDIA GPU Operator ile küme node'larındaki GPU'lar Pod'lara tahsis edilebilir. PyTorch ve TensorFlow eğitim job'ları Kubernetes üzerinde dağıtık olarak yürütülür. Kubeflow ve KServe gibi ML platformları Kubernetes üzerine kurulur.
Veritabanları ve stateful uygulamalar
StatefulSet kaynak türü ve PersistentVolume yetenekleri ile veritabanları, Kafka kümeleri ve diğer stateful uygulamalar Kubernetes üzerinde çalıştırılabilir. Bununla birlikte yönetilen veritabanı hizmetleri (DBaaS) operasyonel basitlik açısından çoğunlukla daha tercih edilir; Kubernetes uygulamaları DBaaS'a bağlanır.
Kubernetes ile Docker Swarm, Nomad ve OpenShift karşılaştırması
| Platform | Olgunluk | Karmaşıklık | Tipik kullanım |
|---|---|---|---|
| Kubernetes | Çok yüksek | Yüksek | Üretim mikroservis, kurumsal platformlar |
| Docker Swarm | Düşük (geriye gitti) | Düşük | Küçük ekipler, basit dağıtımlar |
| HashiCorp Nomad | Orta-yüksek | Orta | Karma iş yükü (konteyner + VM + batch) |
| Red Hat OpenShift | Çok yüksek (K8s tabanlı) | Yüksek | Kurumsal, regüle sektör |
OpenShift, Kubernetes'in üzerine inşa edilmiş ticari bir dağıtımdır; geliştirici deneyimi, güvenlik ve destek hizmetleri içerir. Nomad, Kubernetes'e göre daha hafif ve karma iş yükü için tasarlanmıştır. Docker Swarm pratikte yeni projelerde tercih edilmemektedir.
Yönetilen Kubernetes (KaaS) vs kendi kümeni kurma
Operasyonel yük (yamalama, sürüm yükseltme, etcd backup)
Self-hosted Kubernetes kümesinde control plane'in işletilmesi, sürüm yükseltmeleri (3-6 ayda bir minor), etcd yedekleme, CNI ve CSI eklentileri yönetimi, güvenlik yamaları ve sertifika rotasyonu tamamen sizin sorumluluğunuzdadır. KaaS modelinde control plane sağlayıcı tarafından yönetilir; siz yalnızca worker node'larınız ve uygulama katmanı ile ilgilenirsiniz.
3 yıllık TCO karşılaştırması
| Kalem | Self-hosted (örnek) | KaaS (örnek) |
|---|---|---|
| Donanım/kira (3 worker + 3 master) | 540.000 TL | 360.000 TL (worker'lar) |
| Platform mühendisi (yıllık 0,5 FTE) | 600.000 TL | 200.000 TL (azaltılmış) |
| Eğitim ve sertifikalar | 60.000 TL | dahil |
| Toplam (36 ay) | ~1.200.000 TL | ~560.000 TL |
Hangi durumda KaaS, hangi durumda self-hosted?
KaaS modeli; küçük ve orta ölçekli ekipler, platform ekibi olmayan veya hızlı pazara çıkış hedefleyen kuruluşlar için neredeyse her zaman doğru seçimdir. Self-hosted; çok büyük ölçek, özel donanım entegrasyonu, hava-boşluklu (air-gapped) ortam veya regülatif zorunluluk olduğunda anlamlıdır.
Karar verirken sorulması gereken üç pratik soru vardır. Birincisi, ekibinizde tam zamanlı bir platform mühendisi var mı veya istihdam etme imkânı var mı? İkincisi, ürün ekibinin altyapıya değil uygulamaya odaklanması ne kadar değerli? Üçüncüsü, sürüm yükseltme ve etcd bakımı gibi rutin görevler için kim sorumlu olacak? Bu soruların yanıtları çoğu zaman KaaS'ı işaret eder.
Production'a hazır bir Kubernetes kümesi için kontrol listesi
Monitoring (Prometheus + Grafana)
Prometheus küme ve uygulama metriklerini toplar, Grafana ile görselleştirir. kube-state-metrics, node-exporter ve uygulama exporter'ları standart kurulumdur. Alarm kuralları Alertmanager üzerinden ekiplere iletilir.
Logging (Loki / ELK)
Pod logları geçicidir; kalıcı log altyapısı kritiktir. Loki + Grafana, hafif ve ekonomik bir kombinasyondur. ELK (Elasticsearch + Logstash + Kibana) daha zengin sorgu yetenekleri sunar ama daha ağırdır. Fluent Bit ya da Vector log collection için kullanılır.
RBAC ve network policies
Role-Based Access Control (RBAC), kümeye erişimi rol bazında yönetir. Her servis hesabı yalnızca ihtiyacı olan kaynaklara erişebilmelidir. NetworkPolicy ile Pod'lar arası trafik kısıtlanır; varsayılan deny politikası ile başlayıp ihtiyaç bazında izin verilmesi en güvenli yaklaşımdır.
Backup (Velero)
Velero, küme kaynaklarını ve PersistentVolume'leri yedekler. Felaket kurtarma senaryolarında tüm kümeyi yeni bir bölgede ayağa kaldırmak Velero ile mümkün hale gelir. Düzenli zamanlı yedekleme ve geri yükleme testi vazgeçilmezdir.
Disaster recovery
İki bölge arasında pasif-aktif veya aktif-aktif konfigürasyon kurulabilir. DNS tabanlı failover, Velero geri yükleme ve veritabanı replikasyonu birleştirildiğinde RTO'nun 30 dakikanın altına çekilmesi mümkündür.
Güvenlik tarama ve policy enforcement
Imaj güvenlik taraması (Trivy, Grype), runtime güvenlik (Falco), policy enforcement (OPA Gatekeeper, Kyverno) üretim kümeleri için standart hale gelmiştir. Bu araçlar zayıflıkları erken aşamada yakalar ve uyum politikalarının ihlal edilmesini engeller.
Sıkça sorulan sorular
Küçük ekipler için Kubernetes aşırı mı?
Evet, tek mikroservisi olan ve sabit yüklü basit uygulamalar için Kubernetes aşırıdır; bu senaryoda basit bir VM veya PaaS daha verimlidir. Birden fazla servis, dinamik ölçek ve CI/CD otomasyonu ihtiyacı doğduğunda Kubernetes belirleyici avantaj sağlar. Küçük ekipler için yönetilen KaaS, öğrenme eğrisini düşürür ve operasyonel yükü sağlayıcıya devreder.
KVKK uyumlu Kubernetes mümkün mü?
Evet, kümenin Türkiye'de barındırılması, Secret'larda hassas veri saklanması, RBAC ile erişim sınırlandırması ve audit log'ların etkinleştirilmesi ile KVKK uyumlu bir Kubernetes ortamı kurulabilir. İstanbul veri merkezi konumlu yönetilen Kubernetes hizmetleri bu süreci basitleştirir; veri yurt içinde kalır ve denetim izleri merkezi tutulur.
GPU iş yükleri için ne gerekir?
NVIDIA GPU Operator kurulduğunda node'lardaki GPU'lar Pod manifest'lerinde kaynak isteği olarak belirtilebilir hale gelir. PyTorch ve TensorFlow imajları NVIDIA NGC üzerinden hazır gelir. Multi-GPU eğitimi için NCCL kütüphanesi ve doğru ağ topolojisi (InfiniBand veya yüksek hızlı Ethernet) gerekir.
Cloud4U Türkiye Yönetilen Kubernetes ile başlayın
Kendi Kubernetes kümenizi kurup yönetmek yerine, uygulamalarınızı üretim ortamına taşımaya odaklanmak istiyorsanız, yönetilen Kubernetes (KaaS) en hızlı yoldur. Cloud4U Türkiye Kubernetes-as-a-Service, 2026 ekosisteminin gerektirdiği olgunluk seviyesinde bir hizmet sunar.
Türkiye veri merkezinde yönetilen küme
Tüm kümeniz İstanbul'daki sertifikalı veri merkezimizde barındırılır. Veri KVKK kapsamında yurt içinde kalır; düzenleyici denetimler için belgelendirme avantajı sağlanır.
Otomatik yedekleme ve sürüm yükseltme
- Kümenin otomatik Kubernetes sürüm yükseltmesi (planlı bakım pencerelerinde)
- etcd ve uygulama yedekleri Velero entegrasyonu ile
- Yerel kayıt defteri (registry), monitoring ve logging hazır şekilde
- 7/24 Türkçe konuşan platform mühendisliği desteği
Fiyatlandırma ve demo isteği
Kontrol düzlemi ücretsiz, yalnızca worker node'lar için saatlik veya aylık faturalandırma. Pilot projelerde ücretsiz mimari danışmanlık ve göç desteği sunuyoruz.
Detaylı Kubernetes yapılandırma seçenekleri ve demo talebi için Cloud4U Türkiye Kubernetes-as-a-Service sayfasını ziyaret edin ve yönetilen kümeniz ile bu hafta üretime alın.
