Docker Swarm vs Kubernetes (k3s) vs Coolify: Konteyner Orkestrasyon Rehberi (2026)

Bulut servis sağlayıcılarının (AWS ECS, Google Cloud Run, Vercel) kullanım bazlı yüksek faturaları nedeniyle 2026 yılında geliştiriciler ve KOBİ'ler hızla kendi kiraladıkları VPS, VDS veya Dedicated sunucular üzerinde konteyner mimarilerine dönmektedir.

Ancak sunucu kiralandıktan sonra en kritik mimari soru ortaya çıkar: Tek bir VPS veya 2-5 sunuculuk küçük bir kümede Docker iş yükleri nasıl yönetilmelidir?

• Büyük işletmelerin standardı olan tam teşekküllü Kubernetes (k8s) küçük sunucularda aşırı kaynak tüketir (yalnızca kontrol düzlemi 2-4 GB RAM harcar).
• Hafifletilmiş Kubernetes dağıtımı k3s, kaynak kullanımını dramatik biçimde düşürür; ancak Kubernetes YAML ve CRD karmaşıklığını sürdürür.
• Docker'ın dahili kümeleme çözümü Docker Swarm, sıfır ek kurulumla birkaç megabayt bellek kullanarak çoklu sunucu orkestrasyonu sağlar.
• Yeni nesil PaaS çözümü Coolify, web arayüzü ve Git entegrasyonuyla kendi kendine barındırılan (self-hosted) modern bir alternatif sunar.

Bu rehberde; 1 ile 5 sunucu arasındaki altyapılarda kaynak tüketimi, yüksek erişilebilirlik (HA), Traefik reverse proxy ve sıfır kesintili dağıtım (zero-downtime rolling update) açısından en doğru orkestrasyon seçimini inceliyoruz.

1. Mimari Karşılaştırma Tablosu

2. Hangi Senaryoda Hangi Orkestrasyon Seçilmeli?

Senaryo A: Tek Bir VPS/VDS (1-2 Uygulama, Veritabanı ve Redis)

Eğer 1 adet sunucunuz varsa ve Next.js, Node.js, Go veya PHP uygulamaları barındırıyorsanız:

• Öneri: Coolify veya saf Docker Compose.
• Neden: Tek sunucuda Kubernetes veya k3s çalıştırmak hem RAM kaynaklarınızın en az 1 GB'ını boşa harcar hem de gereksiz ağ katmanı (CNI/iptables) yükü bindirir. Coolify, web arayüzü üzerinden Git push anında otomatik build, SSL ve veritabanı kurulumu sağlayarak Vercel deneyimini 150-200 TL'lik bir VPS üzerinde yaşatır.

Senaryo B: 2 ile 5 Arasında VPS/VDS (Küçük Küme, Yüksek Erişilebilirlik)

Eğer sunuculardan biri çöktüğünde sistemin ayakta kalmasını (High Availability) ve yükün dağıtılmasını istiyorsanız, ancak tam zamanlı bir DevOps/SRE ekibiniz yoksa:

• Öneri: Docker Swarm.
• Neden: Docker Swarm, Docker motorunun içine yerleşiktir (docker swarm init). Harici bir agent, etcd kurulumu veya karmaşık YAML konfigürasyonu istemez. Sunucular arasındaki overlay ağ trafiğini IPsec ile şifreler, Raft konsensüsüyle lider seçer ve bir sunucu kapandığında konteynerleri saniyeler içinde diğer sunucuda ayağa kaldırır. Kontrol düzlemi bellek tüketimi 50 MB'ın altındadır.

Senaryo C: GitOps, Helm Paketleri ve Kubernetes Ekosistemi Zorunluluğu

Eğer ekibiniz Kubernetes araçlarına (Helm charts, ArgoCD, Prometheus Operator, Cert-Manager) alışkınsa veya ileride AWS EKS / Google GKE'ye geçiş planlanıyorsa:

• Öneri: k3s (Rancher Lightweight Kubernetes).
• Neden: k3s, CNCF sertifikalı tam bir Kubernetes dağıtımıdır; ancak etcd yerine dahili SQLite/Kine kullanır, gereksiz bulut sürücülerini dışarıda bırakır ve tek bir ikili dosya (binary) halinde çalışır. 4 GB RAM'e sahip 3 adet VDS üzerinde eksiksiz ve hafif bir Kubernetes kümesi kurabilirsiniz.

3. Docker Swarm ile 2 Dakikada Yüksek Erişilebilir Küme Kurulumu

Docker Swarm'ın en büyük gücü sadeliğidir. İki adet Ubuntu/Debian VDS sunucunuz olduğunu varsayalım:

1. Ana Düğümde (Manager Node) Swarm Başlatma

# Birinci sunucunun statik IP adresiyle başlatın
docker swarm init --advertise-addr 192.168.1.10

Bu komut size işçi düğümleri (worker node) kümeye bağlamak için bir token verir.

2. İkinci Sunucuyu (Worker Node) Kümeye Ekleme

İkinci sunucunuza SSH ile bağlanıp verilen token komutunu çalıştırın:

docker swarm join --token SWMTKN-1-xxx 192.168.1.10:2377

3. Sıfır Kesintili Stack Dağıtımı (docker-compose.yml)

Swarm ortamında servisleri ayağa kaldırmak için standart docker-compose.yml sözdizimine deploy bloğu eklenir:

version: '3.8'

services:
  web-api:
    image: myregistry.com/app:v2
    deploy:
      replicas: 4
      update_config:
        parallelism: 1
        delay: 5s
        order: start-first
        failure_action: rollback
      restart_policy:
        condition: on-failure
    ports:
      - "3000:3000"
    networks:
      - app-net

networks:
  app-net:
    driver: overlay

Stack'i tek bir komutla yayınlayın:

docker stack deploy -c docker-compose.yml prod-app

order: start-first kuralı sayesinde, Swarm önce yeni sürüm konteynerini başlatıp sağlık kontrolünden (healthcheck) geçirir; başarılı olursa eski konteyneri kapatır. Böylece güncelleme sırasında kullanıcılar sıfır kesinti (zero downtime) yaşar.

4. Kaynak Tüketimi ve Donanım Gereksinimleri

Küçük ölçekli sunucu kiralamada en pahalı kaynak genellikle RAM'dir. Orkestrasyon katmanının arka planda tükettiği boşta (idle) bellek miktarı, uygulamanıza ne kadar kaynak kalacağını doğrudan belirler:

[Standart K8s Control Plane] ████████████████████ (~2500 MB RAM)
[k3s Lightweight K8s]        ████ (~600 MB RAM)
[Coolify PaaS Engine]        ███ (~400 MB RAM)
[Docker Swarm Engine]        █ (~50 MB RAM)

• 1 GB - 2 GB RAM'li Giriş Seviyesi VPS: Kesinlikle Kubernetes kurulmamalıdır. Swarm veya standart Docker Compose tercih edilmelidir; aksi halde Linux OOM Killer (Out of Memory) işlemlerinizi zorla sonlandırır.
• 4 GB - 8 GB RAM'li VDS: k3s veya Coolify rahatlıkla barındırılabilir.
• 16 GB+ RAM'li Dedicated Sunucular: Kubernetes veya birden çok k3s worker düğümü yüksek verimlilikle çalıştırılabilir.

5. Konteyner Ağ Güvenliği ve Tersine Proxy (Reverse Proxy)

Konteyner kümenizi internete açarken her servisin portunu doğrudan dışarıya açmak ciddi bir güvenlik açığıdır. Tüm HTTP/HTTPS trafiği tek bir tersine proxy üzerinden yönlendirilmelidir:

1. Traefik Proxy Kullanımı:
   Traefik, Docker API soketini veya Swarm olaylarını (docker.sock) otomatik olarak dinler. Yeni bir servis ayağa kalktığında etiketlerini (labels) okuyarak anında Let's Encrypt SSL sertifikası üretir ve yönlendirmeyi yapar:

   labels:
     - "traefik.enable=true"
     - "traefik.http.routers.api.rule=Host(`api.sirketiniz.com`)"
     - "traefik.http.routers.api.entrypoints=websecure"
     - "traefik.http.routers.api.tls.certresolver=letsencrypt"
   

2. Dahili Overlay Ağ İzolasyonu:
   Veritabanı (PostgreSQL/MySQL) ve Redis servisleri dış ağa (public) kapalı, yalnızca dahili overlay ağına bağlı tutulmalıdır. Böylece internetten gelen port taramaları veritabanınıza asla ulaşamaz.
3. UFW & Docker Çakışmasına Dikkat:
   Docker varsayılan olarak Linux iptables kurallarını manipüle eder ve standart ufw deny kurallarını atlayarak portları dışarı açabilir. Sunucunuzda ufw-docker yardımcı aracını kullanarak güvenlik duvarı bütünlüğünü koruyun.

6. Sıkça Yapılan 4 Orkestrasyon Hatası

1. 2-3 Sunuculuk Sistemde Kubernetes'e Boğulmak: 3 adet 2 vCPU'lu VPS kiralayıp Kubernetes kurmak, sunucuların CPU ve RAM gücünün neredeyse yarısını sadece k8s'in kendi bileşenlerine (etcd, kubelet, kube-proxy, CoreDNS) harcamak anlamına gelir.
2. Konteyner İçinde Durumlu (Stateful) Veritabanı Kümeleme: PostgreSQL veya MySQL gibi veritabanlarını kalıcı disk hacimleri (persistent volumes) olmadan veya kontrolsüz replication ile çoklu düğümlü konteyner kümesinde gezdirmek, veri bozulması (split-brain) riskini doğurur. Veritabanını ayrı bir adanmış VDS'te barındırmak veya yönetilen veritabanı kullanmak çok daha güvenlidir.
3. Dahili Kaynak Limitleri Koymamak: Bir konteynerde bellek sızıntısı (memory leak) olduğunda tüm sunucunun RAM'ini tüketip komşu konteynerleri ve Docker daemon'ı kilitlemesini engellemek için limits.memory: 512M ve cpus: '0.5' parametreleri zorunlu tutulmalıdır.
4. Healthcheck Tanımlamamak: Sıfır kesintili güncelleme için HEALTHCHECK CMD curl -f http://localhost:3000/api/health || exit 1 tanımı yapılmazsa, konteyner henüz açılmadan trafik oraya yönlendirilir ve kullanıcılar 502 Bad Gateway hatası alır.