Üretimde 10 konteyneriniz var. Biri gece 2’de çöküyor. Bir diğeri fazla trafik alıp yavaşlıyor. Üçüncüsünün güncellenmesi gerekiyor ama tüm uygulamayı devre dışı bırakamıyorsunuz.
Çöken konteyneri kim yeniden başlatacak? Trafiği yavaş olandan kim uzaklaştıracak? Kesinti olmadan güncellemeyi kim yapacak?
Kubernetes bunların hepsini yapıyor. Otomatik olarak.
Konteyner konusuna yeniyseniz önce Docker Nedir? Kapsayıcılara Giriş yazısına göz atın.
Kubernetes’in Çözdüğü Problem
Docker, konteyner çalıştırmak için harika. Ama konteynerleri ölçekte çalıştırmak farklı bir problem.
Bir web uygulamanız olduğunu ve hafta sonları 10 kat daha fazla trafik aldığını düşünün. Sadece Docker ile şunları yapmanız gerekir:
- Yükü karşılamak için manuel olarak daha fazla konteyner başlatmak
- Trafiği aralarında manuel olarak dağıtmak
- Çöken herhangi bir konteyneri manuel olarak yeniden başlatmak
- Kesinti olmadan güncellemeleri manuel olarak yönetmek
Bu pratik değil. Ve ölçeklenmiyor.
Kubernetes bunların tamamını otomatikleştiriyor. Bir konteyner orkestrasyon platformu: birden fazla makine üzerindeki konteynerlerin yaşam döngüsünü yöneten bir sistem.
Kubernetes mi, Docker mu?
Sık sorulan bir soru: Kubernetes, Docker’ın yerini mi alıyor?
Hayır. Farklı işler yapıyorlar.
- Docker, tek bir makinede konteyner oluşturur ve çalıştırır
- Kubernetes, birçok makine üzerinde konteynerleri orkestra eder
Çoğu Kubernetes cluster’ı, konteynerleri gerçekten çalıştırmak için Docker’ı (ya da containerd gibi başka bir konteyner çalışma zamanını) kullanır. Kubernetes bunun üzerinde oturur ve büyük resmi yönetir.
Docker: "Bu konteyneri bu makinede çalıştır"
Kubernetes: "Bu konteynerin 5 kopyasını, 3 makineye dağıtarak çalıştır,
çökenleri yeniden başlat ve aralarında trafiği yönlendir"
Kubernetes Nedir?
Kubernetes (kısaca K8s: 8, K ile s arasındaki 8 harfi temsil ediyor), açık kaynaklı bir konteyner orkestrasyon sistemi. Google’ın Borg adlı iç sistemine dayanarak geliştirildi ve 2014’te açık kaynak olarak yayınlandı.
Bugün konteyner orkestrasyonunun fiili standardı. CNCF’in 2025 yıllık Cloud Native anketine göre, konteyner çalıştıran organizasyonların %82’si üretimde Kubernetes kullanıyor.
Güncel kararlı sürüm, Aralık 2025’te 60 iyileştirmeyle yayınlanan Kubernetes 1.35 “Timbernetes”.
Kubernetes Mimarisi
Bir Kubernetes cluster’ında iki tür makine var: control plane ve worker node’lar.
Kubernetes Cluster
├── Control Plane (beyin)
│ ├── kube-apiserver
│ ├── etcd
│ ├── kube-scheduler
│ └── kube-controller-manager
│
└── Worker Node'lar (uygulamaların çalıştığı yer)
├── Node 1
│ ├── kubelet
│ ├── kube-proxy
│ └── konteyner çalışma zamanı (containerd)
├── Node 2
└── Node 3
Control Plane
Control plane, cluster’ın beyni. Sistemin genel durumunu yönetiyor.
kube-apiserver
Kubernetes’in ön kapısı. kubectl ile çalıştırdığınız her komut API server üzerinden geçiyor. İstekleri doğruluyor ve cluster durumunu güncelliyor.
etcd
Tüm cluster verisini tutan bir key-value store. Kubernetes’in veritabanı gibi düşünün; cluster’daki her nesnenin istenen durumunu ve gerçek durumunu saklıyor.
kube-scheduler
Yeni bir Pod çalıştırılması gerektiğinde, scheduler hangi worker node’a yerleştirileceğine karar veriyor. Kullanılabilir kaynaklara, kısıtlamalara ve politikalara bakıyor.
kube-controller-manager
Cluster durumunu izleyen controller döngülerini çalıştırıyor. Bir Pod çökerse, ReplicaSet controller bunu fark edip yerine yenisini başlatıyor. Kubernetes’in kendi kendini iyileştirmesi (self-healing) bu şekilde çalışıyor.
Worker Node’lar
Worker node’lar, uygulamalarınızın gerçekten çalıştığı makineler.
kubelet
Her node üzerinde çalışan bir ajan. API server ile iletişim kuruyor ve Pod tanımlarında belirtilen konteynerlerin çalıştığından ve sağlıklı olduğundan emin oluyor.
kube-proxy
Her node üzerinde ağ yönlendirmesini yönetiyor. Pod’ların birbiriyle ve dış trafikle iletişim kurabilmesi için ağ kurallarını sürdürüyor.
Konteyner Çalışma Zamanı
Konteynerleri gerçekten çalıştıran yazılım. Kubernetes 1.35, standart çalışma zamanı olarak containerd‘i kullanıyor (Docker’ın çalışma zamanı katmanı). Eski sürümler Docker’ı doğrudan da destekliyordu, ama bu K8s 1.24’te kullanımdan kaldırıldı.
Önemli Kubernetes Nesneleri
Kubernetes, YAML dosyalarında tanımlanan bildirimli (declarative) nesnelerle çalışıyor. En önemlileri:
| Nesne | Ne Yapar |
|---|---|
| Pod | En küçük birim: aynı ağı paylaşan bir ya da daha fazla konteyner |
| Deployment | Aynı Pod’lardan oluşan bir seti yönetir, rolling update’leri yapar |
| Service | Bir grup Pod için sabit bir ağ endpoint’i |
| ConfigMap | Hassas olmayan yapılandırma verisini saklar |
| Secret | Şifre ve API anahtarı gibi hassas verileri saklar |
| Namespace | Kaynakları izole etmek için sanal cluster’lar |
| Ingress / HTTPRoute | Dış HTTP trafiğini Service’lere yönlendirir |
Bildirimli (Declarative) Model
Kubernetes, bildirimli bir yaklaşım kullanıyor. İstediğiniz durumu tanımlıyorsunuz, Kubernetes bunu nasıl gerçekleştireceğini kendisi buluyor.
# Şunu söylüyorsunuz: "Uygulamamın her zaman 3 replikası çalışsın"
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
replicas: 3
...
Kubernetes daha sonra sürekli olarak istenen durumu (deklare ettiğiniz) gerçek durumla (çalışmakta olanla) karşılaştırıyor. Farklılık varsa, aradaki farkı kapatmak için harekete geçiyor.
Bu, “şu konteyneri şimdi başlat” gibi buyurgan (imperative) komutlardan farklı. Bildirimli yaklaşım daha güçlü çünkü sistem, çökmelerden, node arızalarından ya da yeniden başlatmalardan sonra bile istediğiniz durumu korumak için sürekli çalışıyor.
kubectl: Kubernetes CLI’si
Kubernetes ile kubectl üzerinden etkileşim kuruyorsunuz. Komutları kube-apiserver’a gönderiyor.
# Cluster bilgisini kontrol et
kubectl cluster-info
# Tüm node'ları listele
kubectl get nodes
# Tüm namespace'lerdeki tüm pod'ları listele
kubectl get pods -A
# Belirli bir pod hakkında detay al
kubectl describe pod mypod
# Bir YAML manifest uygula
kubectl apply -f deployment.yaml
# Bir kaynağı sil
kubectl delete -f deployment.yaml
Kubernetes Neden Kazanıyor?
Kubernetes karmaşık. Organizasyonlar buna rağmen neden kullanıyor?
Kendi kendini iyileştirme (self-healing) Bir konteyner çökerse, Kubernetes onu otomatik olarak yeniden başlatıyor. Bir node ölürse, Kubernetes Pod’ları başka node’lara yeniden zamanlıyor.
Yatay ölçeklendirme Tek bir komutla 1 replikadan 100’e ölçeklenebilirsiniz; ya da CPU kullanımına göre otomatik olarak.
Rolling update’ler Uygulamanızın yeni sürümünü sıfır kesintiyle deploy edin. Kubernetes, eski Pod’ları yavaşça yenileriyle değiştirir, her adımda sağlığı kontrol eder.
Servis keşfi (service discovery) Pod’lar otomatik olarak sabit bir DNS adı alır. Diğer servisler, Pod’lar değiştirilse bile onları isimle bulabilir.
Kaynak verimliliği Kubernetes, konteynerleri node’lara sığdırarak (bin packing) filonuz genelinde kaynakları verimli kullanıyor.
Ne Zaman Kubernetes Kullanmalısınız?
Kubernetes güçlü ama aynı zamanda karmaşık. Her durum için doğru araç değil.
Kubernetes kullanın, eğer:
- Bağımsız olarak ölçeklenmesi gereken birden fazla servisiniz varsa
- Sıfır kesintili deploy’lara ihtiyacınız varsa
- Uygulamalarınızı birden fazla makinede çalıştırıyorsanız
- Yüksek erişilebilirlik ve self-healing’e ihtiyacınız varsa
Bunun yerine Docker Compose kullanın, eğer:
- 2-3 servisli küçük bir uygulamanız varsa
- Tek bir sunucuda çalışıyorsanız
- Otomatik ölçeklendirme ya da self-healing’e ihtiyacınız yoksa
- Güçten çok sadelik istiyorsanız
İyi bir kural: Docker Compose ihtiyaçlarınızı karşılıyorsa onu kullanın. Ona sığamaz hale gelirseniz, sıradaki adım Kubernetes.
Sık Yapılan Hatalar
Kubernetes’in Docker’ın yerini aldığını düşünmek
Kubernetes konteynerleri orkestra ediyor. Onları gerçekten çalıştırmak için hâlâ bir konteyner çalışma zamanına (Docker’ı da güçlendiren containerd) ihtiyacı var. Docker ve Kubernetes birlikte çalışıyor.
Docker’ı bilmeden Kubernetes öğrenmeye çalışmak
Kubernetes doğrudan konteyner kavramları üzerine kuruluyor. Image, konteyner ve Dockerfile’ları anlamıyorsanız Kubernetes son derece kafa karıştırıcı olacaktır. Önce Docker temellerini öğrenin.
Basit bir uygulama için Kubernetes kullanmak
Veritabanlı basit bir web uygulaması mı çalıştırıyorsunuz? Docker Compose daha basit, kurması daha hızlı ve bakımı daha kolay. İhtiyacınız yoksa Kubernetes’in karmaşıklığını eklemeyin.
Kubernetes, Türkiye’de Gerçekten Kimin İşine Yarıyor?
Türkiye’deki yazılım ekiplerinin büyük çoğunluğu için Kubernetes fazlasıyla erken bir karar. Onlarca mikroservisi, ekipler arası paylaşılan cluster’ları ve bağımsız otomatik ölçeklendirme gerektiren gerçek bir trafik hacmi yoksa, K8s’in getirdiği operasyonel yük (bir control plane işletmek, YAML manifestleri yönetmek, cluster güvenliğini takip etmek) kazandırdığından daha fazlasını götürüyor. Bu yüzden Türkiye’deki küçük ve orta ölçekli startup’ların çoğu, trafik gerçekten onu gerektirene kadar düz Docker Compose’da ya da bir PaaS’ta (Railway, Render, Fly.io gibi) kalıyor; bunlar Kubernetes’in karmaşıklığının çoğunu sizin yerinize soyutluyor.
Kubernetes’in Türkiye’de gerçekten karşılığını bulduğu yer, çok sayıda servisi olan, birden fazla ekibin aynı altyapıyı paylaştığı ve trafiğin gerçekten dalgalı olduğu daha büyük şirketler ve kurumsal ortamlar; bankacılık, e-ticaret devleri ve büyük SaaS şirketleri gibi. Küçük bir ekipteyseniz ve “Kubernetes öğrenmeli miyiz” diye soruyorsanız, muhtemelen henüz değil: önce Docker Compose ile ne kadar ileri gidebildiğinizi görün, cluster yönetmenin getirdiği operasyonel yükü gerçekten ihtiyacınız olduğunda üstlenin.