Kestra 2.0 motorunu baştan yazıyor, control ve data plane'i ayrıştırıyor, Apache 2.0'da kalıyor

Kestra, açık kaynak orchestration platformunun 2.0 sürümünü yayımladı; bu sürüm, execution motorunun büyük bölümünü değiştiriyor ve sistemi bir control plane ile bir data plane olarak yeniden yapılandırıyor. dev.to'daki duyuru yazısına göre motor, arayüz ve pluginler Apache 2.0 altında kalmaya devam ediyor ve 2.0, uzun süreli destek (long-term support) sürümü olarak geliyor.

Yazı, 2.0'ı Kestra'nın 2022'deki özgün tasarımına yönelik eleştirilere verilen yanıt olarak sunuyor; o tasarım, işleri planlamak için bile bir Kafka cluster'ı ve bir Elasticsearch cluster'ı gerektiriyordu — ilk dev.to yazısının okuyucuları bunu denemeye bile değmeyecek kadar ağır bir kurulum olarak nitelemişti. Dört ay sonra proje bir JDBC backend'i ekledi; böylece tek bir Postgres veya MySQL hem kuyruk hem de durum deposu olarak çalışabildi ve sürüm 1.0, Eylül 2025'te geldi.

Worker'lar artık veritabanı erişimine ihtiyaç duymuyor

1.x mimarisinde her worker doğrudan merkezi veritabanına bağlanıyordu. Bu tek kısıtlama, görevlerin nerede çalışabileceğini belirliyordu: bir güvenlik ekimi bir ağdan başka bir ağdaki veritabanına giden bir yol açmayı reddettiğinde, ekipler ya her lokasyona tam bir Kestra instance'ı kuruyordu ya da orchestration'dan tamamen vazgeçiyordu. Yazara göre ikinci sonuç yaygındı.

Sürüm 2.0 bu iki kaygıyı ayrıştırıyor. Executor, scheduler, webserver, indexer ve yeni bir worker controller control plane'i oluşturuyor ve kullanıcı kodunu hiç çalıştırmıyor; worker'lar ise data plane. Her worker, worker controller'a tek bir kalıcı gRPC stream'i açıyor; bu bağlantı her zaman worker tarafından başlatılıyor ve işler, sonuçlar, loglar ile metrikler aynı kanaldan taşınıyor. Stream TLS ile şifrelenebiliyor ve herhangi bir iş gönderilmeden önce worker'lardan bir client certificate veya bir JWT sunmaları istenebiliyor.

Yazıya göre pratik sonuç şu: bir worker hiçbir veritabanı kimlik bilgisi taşımıyor ve gelen bağlantı kabul etmiyor; dolayısıyla başka bir bulutta, başka bir bölgede, verinin yanında on-premises olarak ya da yalnızca giden trafiğe izin veren bir ağın içinde çalışabiliyor.

İki motor yerine tek motor

Yeniden yazım ayrıca iç teknik borcu da azaltıyor. Önceki sürümlerde kuyruk ve repository sabit bir çift olarak geliyordu — ikisi için de JDBC ya da Kafka yanında Elasticsearch — bu da iki motor uygulaması, her hatanın iki kez düzeltilmesi ve iki yol arasındaki davranış farklılıkları anlamına geliyordu. Kestra 2.0'da tek bir executor, tek bir scheduler ve tek bir worker var; kuyruk ve repository bağımsız olarak seçiliyor. Kafka Streams motoru tamamen silindi.

Flow düzeyindeki değişiklikler

Yeniden yazımla birlikte bir dizi workflow düzeyi özellik de geliyor:

• Loop, ForEach ve ForEachItem yapılarının yerini alıyor; her iterasyon kendi sub-execution'ı olarak çalıştığı için kontrolden çıkan bir döngü artık executor'ı deviremiyor — yazar bunun daha önce yaşandığını itiraf ediyor.
• Trigger koşulları, CI yapılandırmasına benzer biçimde tek bir "when" ifadesinde birleşiyor.
• Kotalar flow veya namespace başına execution'ları sınırlayabiliyor, böylece bir ekibin hatası herkesin olayına dönüşmüyor.
• Herhangi bir flow bir MCP aracı olarak açığa çıkarılabiliyor. Onu çağıran bir agent, Run düğmesine tıklayan bir kişiyle aynı izinlerle normal bir execution tetikliyor; execution system.from: mcp etiketiyle işaretleniyor ve geri alınamaz adımlar insan onayına bırakılabiliyor.
• Yapay zeka isteğe bağlı: AI Agent görevi yerel donanımdaki Ollama'yı gösterebiliyor ve kestra.ai.enabled: false ayarı sunucudaki her yapay zeka endpoint'ini kaldırıyor.
• Arayüze bir canvas editörü ve taslaklar geliyor; canvas ile YAML senkron tutuluyor, bir Git repository'sindeki YAML temel doğruluk kaynağı olarak kalıyor ve kullanıcı kodu Kestra'dan hiçbir şey içe aktarmıyor.

Lisans sınırı

Yazı, open-core çizgisinin nerede olduğunu açıkça belirtiyor: RBAC, SSO, audit logları, multi-tenancy, worker group'lar, Policies, Cases ve bulut VM task runner'ları ücretli; flow'ları production'da çalıştırmak için gereken her şey ise değil. Yazar, büyük sürümlerin projelerin genellikle lisansını değiştirdiği yer olduğunu, Kestra'nın bunu yapmadığını ve yapmayı planlamadığını belirtiyor. Kestra'da ilk yayımdan bu yana dört milyardan fazla execution çalıştı; bunların çoğu, projenin hiç görmediği donanımdaki açık kaynak sürümde.

Neden önemli

Orchestration araçları çoğu zaman compute'un merkezi bir veritabanına erişebildiğini varsayıyor; bu varsayım regüle edilmiş veya bölümlenmiş ağlarda çöküyor. Kestra'nın yeni modeli — worker'ların depolanmış kimlik bilgisi olmadan gRPC üzerinden dışarı bağlanması — projenin kendi ifadesiyle ekipleri yeniden cron'a iten bir kısıtlamayı ortadan kaldırıyor ve multi-cloud ile on-prem hibrit dağıtımları çok daha gerçekçi hale getiriyor. Motorun tekilleştirilmesi, kendi kendine barındıranların akıl yürütmesi gerekenleri basitleştiriyor ve MCP trigger'ı mevcut flow'ları yapay zeka agent'ları için çağrılabilir araçlara dönüştürüyor. Ve yazının da kabul ettiği gibi, büyük sürümler açık kaynak projelerin genellikle yeniden lisanslandığı yerlerdir; burada bilinçli bir karar olarak sunulan Apache 2.0'da kalış, bir orchestrator'u yıllar ölçeğinde seçen herkes için önemli.