Kubernetes ve Docker Swarm Karşılaştırması

Tek sunucuda Docker Compose ile mutlu mesut çalışan bir yığının var, sonra ikinci sunucu geliyor ve soru ortaya çıkıyor: konteynerleri birden fazla makineye nasıl dağıtacaksın? Bu noktada karşına iki isim çıkar — Kubernetes ve Docker Swarm. İnternette "Swarm öldü" diyen de var, "Kubernetes gereksiz karmaşık" diyen de. İkisi de kısmen doğru, ikisi de tek başına yanıltıcı.

Bu yazıda Kubernetes ve Docker Swarm karşılaştırmasını pazarlama diliyle değil, gerçekten karar verirken bakman gereken başlıklarla yapacağım: kurulum ve işletme maliyeti, ağ ve servis keşfi, kalıcı depolama, ölçekleme davranışı, ekosistem ve uzun vadeli risk. Sonunda da hangi durumda hangisini seçmen gerektiğini net bir tabloya bağlayacağım. İkisini de kurup üretimde çalıştırmış biri olarak söyleyebilirim ki doğru cevap projenin büyüklüğüne değil, ekibin büyüklüğüne bağlı.

İkisi de Aynı Problemi Çözüyor, Yaklaşımları Ayrılıyor#

Her iki araç da temelde şunu yapar: birden fazla sunucuyu tek bir kaynak havuzu gibi gösterir, konteynerleri bu havuza dağıtır, çöken konteyneri yeniden başlatır, servisleri birbirine bulduran bir DNS sağlar ve gelen trafiği örneklere dağıtır. Buraya kadar ikisi de aynı sözü veriyor.

Ayrım felsefede başlıyor. Docker Swarm, Docker'ın kendi içine gömülü bir moddur; zaten bildiğin docker komutlarının üstüne birkaç yeni alt komut ekler ve Compose dosyanı neredeyse olduğu gibi kabul eder. Öğrenme eğrisi neredeyse yatay. Kubernetes ise ayrı bir sistemdir: kendi API'si, kendi nesne modeli, kendi istemcisi ve kendi kavram sözlüğü vardır. Karşılığında sana Swarm'ın hiç sunmadığı bir esneklik verir — istediğin davranışı bir denetleyici (controller) yazarak sisteme ekleyebilirsin.

Bir cümlede özetlersem: Swarm mevcut bilgini genişletir, Kubernetes yeni bir sistem öğretir. Docker Compose'la nasıl çalıştığını hatırlamıyorsan önce Docker Compose kullanımı yazısına bakman, buradaki karşılaştırmayı çok daha somut hâle getirir.

Kurulum ve İşletme Maliyeti#

Aradaki en büyük pratik fark burada. Swarm'ı başlatmak tek komuttur, çünkü Docker Engine'in içindedir:

# Yönetici düğümde küme başlat
docker swarm init --advertise-addr 185.12.34.56

# Çıktı sana işçi düğümlerin çalıştıracağı katılma komutunu verir:
# docker swarm join --token SWMTKN-1-xxxx 185.12.34.56:2377

# Düğümleri listele
docker node ls

Bir Compose dosyasını kümeye yaymak da aynı ölçüde kısa:

# Mevcut compose dosyanı stack olarak dağıt
docker stack deploy -c docker-compose.yml uygulama

# Servisleri gör
docker stack services uygulama

# Bir servisi ölçekle
docker service scale uygulama_web=5

Kubernetes tarafında ise önce kümeyi kurman gerekir. kubeadm ile üç düğümlü bir küme kurmak, konteyner çalışma zamanını hazırlamak, bir CNI eklentisi seçip kurmak, sertifikaları yönetmek ve etcd'yi yedeklemek demektir. Tek düğümlük bir başlangıç için k3s gibi hafif dağıtımlar bu yükü ciddi biçimde azaltıyor:

# k3s ile tek komutta küme (hafif Kubernetes dağıtımı)
curl -sfL https://get.k3s.io | sh -

# kubeconfig'i kullanılabilir hâle getir
sudo cat /var/lib/rancher/k3s/server/node-token
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml
kubectl get nodes

Ama kurulumun kolay olması işletmenin kolay olduğu anlamına gelmiyor. Kubernetes'te sürüm yükseltmeleri, etcd yedeği, sertifika yenilemeleri ve API kullanımdan kaldırma (deprecation) döngüsü sürekli ilgi ister. Swarm'da bu bakım yükünün büyük kısmı yoktur; Docker Engine'i güncellersin, iş biter.

Kavram Karşılıkları#

İki sistem arasında geçiş yaparken en çok zaman kaybettiren şey, aynı işi yapan nesnelerin farklı adlarla anılmasıdır. Karşılık tablosu bu kafa karışıklığını büyük ölçüde çözer:

Bu tablodaki iki boşluk özellikle önemli. Swarm'da yerleşik otomatik ölçekleme yoktur: replika sayısını sen belirlersin, yük artınca kendiliğinden büyümez. Kubernetes'te ise bu iş HPA ile otomatik ölçekleme mekanizmasına düşer ve metrik tabanlı çalışır. İkinci boşluk zamanlanmış görevlerdir; Swarm'da bunun için ya konteyner içinde bir zamanlayıcı çalıştırırsın ya da düğümde sistem seviyesinde bir görev tanımlarsın — Linux cron görevleri yazısındaki yöntemler burada devreye girer.

Ağ, Servis Keşfi ve Yük Dengeleme#

Swarm'ın en beğendiğim tarafı ağ modelinin sadeliği. Bir overlay ağ oluşturursun, servisleri ona bağlarsın ve servisler birbirini doğrudan adıyla bulur. Yayınlanan bir port, kümedeki her düğümden erişilebilir hâle gelir; hangi düğüme istek gelirse gelsin routing mesh onu doğru konteynere iletir.

# Overlay ağ oluştur
docker network create --driver overlay --attachable uygulama-agi

# Servisi ağa bağlayarak çalıştır
docker service create --name api --network uygulama-agi \
  --replicas 3 --publish 8080:8080 firmaniz/api:1.4

Kubernetes'te aynı işi yapmak daha çok parçadan oluşur: pod'lar bir Service ile gruplanır, Service küme içi sanal bir IP alır, dış dünyaya açmak içinse ya NodePort ya LoadBalancer ya da bir Ingress denetleyicisi kurman gerekir. Karşılığında Swarm'da olmayan yönlendirme yeteneklerini elde edersin: yola göre yönlendirme, ana makine adına göre ayrıştırma, TLS sonlandırma, yeniden yazma kuralları ve trafik ağırlıklandırma.

Yani Swarm'da bir ters vekil (Traefik ya da Nginx) kurmak neredeyse zorunlu hâle gelir. Bu aslında kötü bir şey değil; Nginx ve Apache'nin karşılaştırmasını Apache ve Nginx yazısında ele almıştım, aynı mantık burada ön kapı seçimi için geçerli.

Kalıcı Depolama#

Konteyner orkestrasyonunda en çok can yakan konu veridir ve iki sistem burada ciddi biçimde ayrışır. Swarm'da kalıcı depolama için yerleşik bir soyutlama yoktur: bir volume tanımlarsın ama o volume, konteynerin çalıştığı düğümde yaşar. Konteyner başka bir düğüme taşınırsa verisi orada değildir. Pratik çözümler NFS gibi paylaşımlı bir dosya sistemi bağlamak veya veritabanı servisini bir düğüme sabitlemektir:

# docker-compose.yml içinde — servisi tek düğüme sabitle
services:
  db:
    image: postgres:16
    volumes:
      - db-veri:/var/lib/postgresql/data
    deploy:
      replicas: 1
      placement:
        constraints:
          - node.labels.rol == veritabani   # sadece bu etiketli düğümde çalış
volumes:
  db-veri:

Kubernetes'te ise PersistentVolumeClaim ve StorageClass soyutlamaları vardır; depolama sağlayıcısı (bulut diski, Ceph, NFS, yerel disk) bir eklenti tarafından yönetilir ve pod başka bir düğüme taşındığında disk de takip eder — sağlayıcı destekliyorsa. StatefulSet ise her kopyaya sabit bir isim ve kendi diskini vererek veritabanı kümelerini çalıştırılabilir hâle getirir.

Bu farkın pratik sonucu şu: durum tutan iş yükleri Swarm'da elle çözülür, Kubernetes'te modellenmiştir. Veri stratejisini hangi sistemde olursan ol düşünmen gerekiyor; yaklaşım için Docker uygulama yedekleme ve geri yükleme yazısındaki yöntemler ikisinde de geçerli.

Ekosistem ve Uzun Vadeli Risk#

Burada dürüst olmak gerekiyor. Kubernetes bugün konteyner orkestrasyonunun fiili standardı; CI/CD araçları, izleme yığınları, servis mesh'ler, operatörler ve neredeyse her ticari ürün önce Kubernetes'i destekliyor. İş ilanlarında da aranan beceri bu. Docker Swarm ise hâlâ Docker Engine ile birlikte geliyor ve çalışıyor, ama etrafında büyüyen bir ekosistem yok; yeni araçların çoğu Swarm desteği yazmıyor.

Bu, Swarm'ın yarın kaybolacağı anlamına gelmiyor — Docker Engine'in parçası olduğu sürece kullanılabilir kalacak. Ama şu iki soruyu kendine sorman lazım: bir yıl sonra ihtiyaç duyacağın bir aracın Swarm desteği olacak mı, ve ekibe katılacak yeni bir mühendisin Swarm bilme ihtimali nedir? İkisinin de cevabı zamanla Kubernetes lehine ağırlaşıyor.

Buna karşılık Swarm'ın hâlâ güçlü olduğu bir alan var: küçük ekipler ve az sayıda sunucu. Üç sunucuda on beş servis çalıştıran iki kişilik bir ekip için Kubernetes'in getirdiği kavramsal yük, sağladığı faydadan büyük olabilir. Bu senaryoda Swarm bir gecede kurulur, Compose dosyaların olduğu gibi çalışır ve ekip yeni bir sistem öğrenmeden ikinci sunucuya geçmiş olur.

Hangisini Seçmelisin#

Karar tablosu, tartışmayı somuta indirir:

Son satır özellikle önemli: Swarm ile başlamak Kubernetes'e geçişi imkânsızlaştırmaz. Konteynerleştirdiğin uygulama zaten taşınabilir — imajlar aynı kalır, değişen sadece manifest biçimidir. Uygulamayı doğru imajlamak ise ikisinde de aynı derece kritik; Dockerfile en iyi pratikler ve Docker imaj boyutu optimizasyonu yazılarındaki alışkanlıklar her iki yolda da kazanç sağlar.

Sık Yapılan Hatalar#

Tek sunucuda orkestrasyona geçmek. Tek makinede Swarm ya da Kubernetes kurmak, çözdüğünden fazla sorun yaratır. Tek sunucuda Compose ile restart: unless-stopped kullanmak çoğu ihtiyacı zaten karşılar.

Swarm'da veritabanını replikalı çalıştırmak. replicas: 3 yazıp PostgreSQL'i üç kopya çalıştırmak veri bozulmasına giden en kısa yoldur; her kopya kendi diskine yazar. Durum tutan servisleri tek replika ve düğüm kısıtıyla çalıştır ya da veritabanını orkestrasyonun dışına al.

Kubernetes'i "kurdum, bitti" sanmak. Küme kurulduktan sonra sertifika yenileme, sürüm yükseltme ve etcd yedeği düzenli işlerdir. Yedeği olmayan bir etcd, kümenin tamamının tek noktadan kaybı demektir.

İki sistemi aynı sunucuda çalıştırmak. Aynı makinede hem Swarm modunu hem k3s'i açık bırakmak, port ve iptables kuralı çakışmalarına yol açar. Geçiş yapıyorsan eskisini önce düzgün biçimde kapat.

Manifestleri sürüm kontrolüne almamak. Hangi sistemde olursan ol, kümenin durumu dosyalardan doğmalı. docker service update veya kubectl edit ile elle yapılan değişiklikler bir sonraki dağıtımda kaybolur.

Sıkça Sorulan Sorular#

Docker Swarm öldü mü, hâlâ kullanılıyor mu#

Ölmedi; Docker Engine'in içinde gelmeye devam ediyor ve çalışıyor. Ancak etrafındaki ekosistem büyümüyor, yeni araçların çoğu Swarm desteği yazmıyor ve topluluk enerjisinin neredeyse tamamı Kubernetes tarafında. Küçük ekipler ve az sunuculu kurulumlar için hâlâ makul bir tercih, ama uzun vadeli bir platform kararı veriyorsan bu asimetriyi hesaba katmalısın.

Docker Compose dosyam Swarm'da olduğu gibi çalışır mı#

Büyük ölçüde evet, ama birebir değil. docker stack deploy Compose dosyasını kabul eder; build yönergesi çalışmaz (imajı önceden derleyip bir kayıt defterine göndermen gerekir), depends_on sıralama garantisi vermez ve deploy bloğu yalnızca Swarm'da anlamlıdır. Yani dosya aynı kalır, birkaç yönergeyi Swarm'a uygun hâle getirirsin.

Kubernetes küçük bir proje için fazla mı gelir#

Genellikle evet. Üç servis ve iki sunucu için Kubernetes'in getirdiği kavram sayısı, kazandırdığı esneklikten fazladır. Ancak k3s gibi hafif dağıtımlar bu dengeyi değiştiriyor: tek komutla kurulup az kaynak tüketiyorlar ve ilerideki büyümeye hazır bir zemin bırakıyorlar. Ekipte konuyu öğrenmeye zaman ayırabilecek biri varsa küçük projede de mantıklı olabilir.

Swarm'dan Kubernetes'e geçiş zor mu#

Konteyner imajların değişmediği için işin ağır kısmı zaten bitmiş demektir. Geçiş, manifestleri yeniden yazmaktan ibarettir: her Swarm servisi bir Deployment ve bir Service'e, her docker config bir ConfigMap'e, her docker secret bir Secret'a dönüşür. Asıl zorluk kalıcı depolama ve dış erişim katmanındadır; bunları yeniden tasarlaman gerekir.

Hangisi daha az kaynak tüketir#

Docker Swarm belirgin biçimde daha hafiftir, çünkü ayrı bir kontrol düzlemi çalıştırmaz; işi Docker Engine'in kendisi yapar. Kubernetes'te api-server, etcd, scheduler ve controller-manager sürekli bellek ve CPU tüketir. k3s bu farkı önemli ölçüde kapatır ama yine de Swarm'ın üzerindedir. Sunucu kaynağın çok kısıtlıysa bu fark karar verirken gerçek bir kriter olur.

İkisini birlikte kullanabilir miyim#

Aynı sunucuda çalıştırmak önerilmez; ağ kuralları ve port kullanımı çakışabilir. Ancak farklı sunucu gruplarında farklı sistemler çalıştırmak mümkündür — örneğin eski yığın Swarm'da kalırken yeni servisleri Kubernetes'te başlatabilir ve trafiği ön kapıdaki ters vekil üzerinden kademeli olarak taşıyabilirsin. Geçiş dönemlerinde en az riskli yöntem budur.

Kapanış#

Kubernetes ve Docker Swarm arasındaki seçim, teknik üstünlükten çok bağlamla ilgili. Swarm mevcut Docker bilgini birkaç saatte kümeye taşır ve küçük ekiplerde işletme yükünü düşük tutar; Kubernetes ise otomatik ölçekleme, durum tutan iş yükleri, namespace bazlı yetkilendirme ve devasa bir ekosistem karşılığında öğrenme ve bakım maliyeti ister. Kararı verirken şu üçüne bak: kaç sunucun var, kaç kişi bakacak ve önümüzdeki bir yılda hangi yeteneklere ihtiyacın olacak.

Hangi yolu seçersen seç altında öngörülebilir kaynaklı makineler gerekiyor. Küme düğümleri için tam root erişimli VDS ve sanal sunucu paketlerimizi, ihtiyaca göre büyüyen bir yapı istiyorsan bulut sunucu seçeneğimizi değerlendirebilirsin. Kurulum ve bakım yükünü üstlenmek istemiyorsan sunucu yönetimi hizmetimiz küme kurulumundan güncellemelere kadar bu işi sizin yerinize yürütür.