Önceki yazımızda n8n’i Docker ile kendi bilgisayarınızda nasıl ayağa kaldıracağınızı anlatmıştık. O kurulum kişisel kullanım ve küçük ölçekli otomasyonlar için gayet yeterli. Ama n8n’i bir ekip için, yüksek işlem hacmiyle, kesintisiz çalışacak şekilde production’a taşımak istediğinizde işler değişir. İşte tam bu noktada Kubernetes devreye girer.

Bu yazıda n8n’i Kubernetes’te çalıştırmanın temel mantığını, karşılaşacağınız kritik kararları ve nelere dikkat etmeniz gerektiğini ele alıyoruz. Konunun tamamını değil, doğru zihin haritasını çizmeyi hedefliyoruz.

Neden Docker Compose Değil de Kubernetes?

Docker Compose bir makinede çalışır. Bir sunucunuz çöktüğünde n8n de çöker. Bu gibi durumlarda ek ayarlar, ileri seviye teknik bilgiye başvurulur. Kubernetes ise şunu garanti eder: bir pod (n8n’in çalıştığı birim) çökerse otomatik olarak yeniden başlatılır; trafik arttığında yeni kopyalar (replica) otomatik açılır, güncelleme yaparken kesinti yaşanmaz (rolling update).

Kubernetes dünyasına adım atmak isterseniz Kubernetes Bootcamp‘ine katılmanızı öneririm. Gelelim uygulama kısmına.

Ön Gereksinimler

• kubectl komut satırı aracı kurulu ve cluster’a bağlı
• Çalışan bir Kubernetes cluster’ı (lokalde denemek için Minikube veya Kind yeterli)

Adım 1: Basit Bir n8n Deployment’ı

Kubernetes’te her şey YAML manifestleriyle tanımlanır. En temel haliyle bir n8n Deployment’ı şöyle görünür:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: n8n
spec:
  replicas: 1
  selector:
    matchLabels:
      app: n8n
  template:
    metadata:
      labels:
        app: n8n
    spec:
      containers:
        - name: n8n
          image: n8nio/n8n
          ports:
            - containerPort: 5678
          env:
            - name: N8N_ENCRYPTION_KEY
              valueFrom:
                secretKeyRef:
                  name: n8n-secrets
                  key: encryption-key
          volumeMounts:
            - name: n8n-data
              mountPath: /home/node/.n8n
      volumes:
        - name: n8n-data
          persistentVolumeClaim:
            claimName: n8n-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: n8n
spec:
  selector:
    app: n8n
  ports:
    - port: 5678
      targetPort: 5678

Burada dikkat edilmesi gereken en kritik nokta şu: N8N_ENCRYPTION_KEY‘i asla YAML dosyasının içine düz metin olarak yazmayın. Bu anahtar, n8n’in kaydettiğiniz tüm credential’ları (API key’ler, şifreler) şifrelemek için kullandığı anahtardır. Kubernetes’te bunun doğru yeri bir Secret objesidir:

kubectl create secret generic n8n-secrets \
  --from-literal=encryption-key=$(openssl rand -hex 32)

Adım 2: Kalıcı Depolama

Docker Compose’daki volume mantığının Kubernetes karşılığı PersistentVolumeClaim (PVC). Cluster’ınıza kalıcı disk alanı talep eder:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: n8n-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

Bu olmadan pod her yeniden başladığında (ki Kubernetes’te bu sık olur) tüm workflow’larınızı ve credential’larınızı kaybedersiniz.

Adım 3: Dışarıya Açmak – Ingress

Cluster’ın içindeki bir Service dış dünyaya kapalıdır. n8n’e tarayıcınızdan ve webhook’lar aracılığıyla erişebilmek için bir Ingress tanımlamanız gerekir:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: n8n-ingress
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
    - hosts:
        - n8n.sizin-domaininiz.com
      secretName: n8n-tls
  rules:
    - host: n8n.sizin-domaininiz.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: n8n
                port:
                  number: 5678

Burada tek bir kural aklınızda kalsın: n8n’in domain’i sabit olmalı. Webhook URL’leri ve OAuth redirect URI’ları bu adrese göre kaydedilir; pod yeniden başladığında adres değişirse tüm entegrasyonlarınız (Google, Slack, vb.) bozulur. cert-manager gibi bir araçla HTTPS sertifikasını otomatik yönetmek de OAuth sağlayıcılarının çoğu zaten HTTPS zorunlu tuttuğu için pratikte şart.

Veritabanı Meselesi: Tek Pod Yetmezse?

Yukarıdaki kurulum n8n’in varsayılan SQLite veritabanını kullanır, tek pod için sorun değil. Ama birden fazla n8n kopyası (replica) çalıştırmak istediğinizde her pod kendi SQLite dosyasını görür, veriler tutarsızlaşır. Bu noktada harici bir PostgreSQL veritabanına geçmeniz gerekir.

Burada iki yol var:

1. Yönetilen bir veritabanı servisi (RDS, Cloud SQL, Supabase vb.) – yedekleme, replikasyon, failover sizin için hazır.
2. Cluster içinde kendi Postgres’inizi çalıştırmak – bunu yapıyorsanız elle bir Deployment yazmak yerine CloudNativePG veya Crunchy PGO gibi bir operatör kullanmanızı öneririz; bunlar yedekleme ve failover’ı sizin yerinize otomatikleştirir.

Ölçeklendirme: Queue Mode

Tek n8n pod’u aynı anda hem arayüzü sunar hem workflow’ları çalıştırır hem de webhook’ları dinler. Yoğun kullanımda bu üçü birbirine engel olmaya başlar. n8n’in çözümü queue mode: işler bir kuyruğa (Redis) yazılır, ayrı “worker” pod’ları bu kuyruğu tüketip işleri yürütür. Böylece worker sayısını HorizontalPodAutoscaler ile trafiğe göre otomatik artırıp azaltabilirsiniz.

Bu geçişin doğru yapılması, main/worker/webhook rollerinin ayrılması, hepsinde aynı encryption key’in kullanılması, connection pooling gibi detaylar tek başına bir yazıyı hatta eğitimi hak ediyor. Burada sadece kavramı tanıyoruz.

Umarım sizler için faydalı bir rehber olmuştur. Kubernetes üzerinde n8n çalıştırmak daha ileri seviye bir çözüm elbette. Yeni başlayanlar, cloud ortamda çalışmak isteyenler veya docker ile kendi lokalinde AI agent oluşturmayı deneyimlemeyi isteyenler için n8n AI Agent Developer Bootcamp‘imizde adım adım sıfırdan başlayarak ilerliyoruz. Detaylar için bootcamp sayfamıza göz atabilir ve sorularınız varsa bize ulaşabilirsiniz.