Kubernetes'te n8n: Helm Chart, Queue Mode ve Ne Zaman Buna Değer

n8n, genellikle Docker Compose ile tek bir sunucuda birkaç dakika içinde çalıştırılabilir ve küçük ve orta ölçekli işletmelerin büyük çoğunluğu için bu yaklaşım tamamen yeterlidir. Resmi Helm Chart ile Kubernetes, ancak iş akışlarının birden fazla düğüme dağıtılması, otomatik olarak ölçeklendirilmesi veya arızalarda kendiliğinden yeniden başlatılması gerektiğinde, örneğin çok yüksek webhook hacminde veya şirkette diğer uygulamalar için zaten bir Kubernetes platformu çalışıyorsa önemli hale gelir. Resmi chart, n8n tarafından bizzat n8n-io/n8n-hosting deposunda bakımı yapılır ve bir OCI kayıt defteri üzerinden yayınlanır. Chart README dosyasına göre iki çalışma modunu destekler: harici bağımlılıklar olmadan SQLite ile bağımsız (standalone) mod ve PostgreSQL ile Redis gerektiren ve iş yükünü ayrı worker pod'larına dağıtan Queue Mode. Durum: Ağustos 2026.

Resmi n8n Helm Chart'ı Somut Olarak Neleri Kapsar?

Chart, n8n'i oci://ghcr.io/n8n-io/n8n-helm-chart/n8n OCI referansı ile helm install komutu üzerinden ve yapılandırma için özel bir values.yaml dosyası kullanarak kurar. Belgelere göre en az Helm 3.12 ve 1.25 sürümünden itibaren bir Kubernetes kümesi gereklidir. Chart'ın varsayılan ayarı olan Queue Mode'da mimari üç pod türünü ayırt eder: arayüz, API ve üretim dışı webhook'lar için main pod'lar, Redis kuyruğundan iş akışlarını işleyen ve genellikle birden fazla kopya halinde çalışan worker pod'lar ve üretim webhook trafiği için isteğe bağlı özel webhook pod'ları. Chart ayrıca hem worker'lar hem de webhook işleyicileri için HPA ve KEDA üzerinden yatay otomatik ölçeklendirme desteği de sunar.

Queue Mode ve Redis Nasıl İlişkilidir?

Queue Mode, birden fazla n8n worker'ının iş akışlarını paralel olarak işleyebilmesinin ön koşuludur ve bunun için n8n'in kuyruk olarak Redis'e ihtiyacı vardır. Queue Mode olmadan, tek bir n8n örneği iş akışlarını arayüzü de sunan aynı süreçte sıralı olarak işler; bu, az sayıda iş akışında sorun yaratmaz ancak yüksek yükte darboğaza dönüşür. Queue Mode etkinleştirildiğinde n8n, yürütülecek iş akışlarını bir Redis kuyruğuna yerleştirir ve worker pod'lar bunları buradan alarak birbirinden bağımsız olarak işler. Barındırma deposundaki bilgilere göre, üretim ortamında kullanım için Redis 7 veya üzeri önerilir; bir Redis kullanıcı adı yapılandırıldığında ise en az sürüm 6 gereklidir. Bu yapılandırmada PostgreSQL birincil veritabanı olarak eklenir, SQLite Queue Mode için öngörülmemiştir.

Gerçekçi Olarak Hangi Ön Koşulları ve Emeği Planlamalısınız?

Helm Chart'ı üretimde kullanan herkesin, çalışan bir Kubernetes kümesinin yanı sıra PostgreSQL, Redis ve ingress yapılandırması konusunda deneyime de ihtiyacı vardır, çünkü chart n8n bileşenlerinin orkestrasyonunu üstlenir, ancak harici bağımlılıkların işletilmesini üstlenmez. Chart belgelerine göre, yüksek erişilebilirlik için birden fazla main örneği ayrıca bir Enterprise lisansı ile yük dengeleyici düzeyinde oturum tabanlı yük dağıtımı gerektirir. Kod yürütmenin izolasyonu için chart, kendi kimlik doğrulamasını gerektiren ayrı sidecar'lar olarak sözde task runner'lar sunar. Pratikte bu şu anlama gelir: Docker Compose kurulumuna kıyasla operasyonel ek yük, küme bakımından izlemeye ve Redis ile PostgreSQL için yedekleme stratejilerine kadar belirgindir. Kuyrukta birkaç saniye daha bekleyebilecek bir avuç otomasyonu olan bir KOBİ için bu genellikle gereğinden fazladır. Bu emek, özellikle BT ekipleri zaten Kubernetes uzmanlığına sahipse veya n8n zaten Kubernetes üzerinde çalışan daha büyük bir platformun parçası haline geliyorsa anlamlıdır. Kendi otomasyon yüküne hangi barındırma modelinin uyduğundan emin olmayanlar, bu soruyu uygulamadan önce netleştirmelidir, örneğin bir n8n danışmanlığı kapsamında, sonradan aşırı büyük bir altyapıyla uğraşmak yerine. Ayrıca ROI hesaplayıcısına bir göz atmak da bir Kubernetes çözümünün ek operasyonel eforunun beklenen otomasyon faydasıyla orantılı olup olmadığını değerlendirmeye yardımcı olur.

n8n ve Kubernetes Hakkında Sıkça Sorulan Sorular

n8n İçin Kesinlikle Kubernetes'e İhtiyacım Var mı?

Hayır, çoğu KOBİ için tek bir sunucuda Docker Compose kurulumu tamamen yeterlidir. Kubernetes ancak birden fazla düğüm üzerinden ölçeklendirme, otomatik hata toleransı veya şirkette zaten var olan bir Kubernetes platformu söz konusu olduğunda önemli hale gelir. Başlangıç veya daha küçük otomasyon projeleri için bir kümenin operasyonel ek yükü genellikle haklı gösterilemez.

Helm Chart İçin Mutlaka Queue Mode Kullanmam Gerekir mi?

Hayır, resmi chart aynı zamanda SQLite ile ve Redis veya PostgreSQL gibi harici bağımlılıklar olmadan bağımsız bir modu da destekler. Queue Mode ancak birden fazla worker'ın iş akışlarını paralel olarak işlemesi gerektiğinde değerli hale gelir, çünkü o zaman dağıtımı bir Redis kuyruğu üstlenir. Tek ve yönetilebilir bir iş akışı hacmi için bağımsız mod çalıştırılması çok daha kolaydır.

Resmi Chart İçin Hangi Kubernetes Sürümüne İhtiyacım Var?

Resmi chart'ın README dosyasına göre en az Helm 3.12 ve Kubernetes 1.25 gereklidir. Daha eski küme sürümleri chart tarafından resmi olarak desteklenmez, bu nedenle kurulumdan önce bir küme yükseltmesi kontrol edilmelidir. Bu minimum gereksinimler gelecekteki chart sürümleriyle değişebilir.

Resmi Chart Üretim Kullanımı İçin mi Yoksa Yalnızca Test İçin mi Uygundur?

Chart, üretim kullanımı için tasarlanmıştır ve HPA ile KEDA üzerinden yatay otomatik ölçeklendirme ile üretim trafiği için özel webhook pod'ları gibi özellikler sunar. Ancak ön koşul, PostgreSQL ve Redis gibi harici bağımlılıkların kendilerinin üretime hazır şekilde işletilmesidir; chart yalnızca n8n'in kendisinin orkestrasyonunu üstlenir. Bu operasyonel deneyime şirket içinde sahip olmayanlar, karar vermeden önce emeği gerçekçi bir şekilde değerlendirmelidir.