Gece çalışan raporun sabah hazır olmaması, yalnızca bir zamanlayıcı sorunu değildir. Aynı raporun iki kez gönderilmesi, stok aktarımının üst üste çalışması veya gecikmiş bir görevin mesai içinde veritabanını zorlaması da aynı operasyonun parçalarıdır. Kubernetes CronJob kullanırken başarı ölçütü, manifestin kümeye uygulanması değil; doğru işin doğru zaman aralığında, güvenli tekrar davranışıyla tamamlanmasıdır.

Bu rehber, Kubernetes’e giriş anlatmak yerine zamanlanmış işlerde üç karara odaklanır: önceki çalışma bitmeden yenisi başlayabilir mi, geciken işin hâlâ değeri var mı ve tamamlanma nasıl kanıtlanır? Yaklaşım; SaaS raporları, ERP entegrasyonları, bakım görevleri ve düzenli veri aktarımları hazırlayan ekipler içindir. Küme yönetimiyle uygulama iş mantığını birbirinden ayırır.

Kubernetes CronJob çakışması neden iş riski yaratır?

Bir görevin normalde kısa sürmesi, her zaman kısa süreceği anlamına gelmez. Harici API yavaşladığında, veritabanında kilit oluştuğunda veya işlenecek kayıt sayısı arttığında çalışma bir sonraki zaman aralığına taşabilir. Yeni Job aynı kayıtları seçerse çift bildirim, yinelenen sipariş aktarımı ve bağlantı havuzunda baskı oluşabilir. Daha fazla CPU eklemek bu mantıksal çakışmayı kendiliğinden çözmez.

Önce her işin sahibini, tetikleme sıklığını, kabul edilebilir gecikmesini ve yan etkilerini kaydedin. Salt okunur rapor üretmekle ödeme talimatı göndermek aynı risk seviyesinde değildir. İşletme ekibine “bir çalışma atlanabilir mi?” sorusunu sorun. Yanıt hayırsa, yalnızca cron zamanlaması yerine kalıcı kuyruk veya iş tablosuyla eksik dönemlerin takip edilmesi gerekebilir.

Allow, Forbid ve Replace arasında karar verin

concurrencyPolicy: Allow varsayılan davranıştır; önceki çalışma devam ederken yenisi oluşturulabilir. İşler farklı veri dilimleri üzerinde çalışıyorsa ve bağımlı servislerin kapasitesi yeterliyse anlamlıdır. Ancak her çalışma aynı “işlenmedi” kayıtlarını okuyorsa uygulama tarafında sahiplenme ve tekilleştirme gerekir. Varsayılanın güvenli olduğunu varsaymayın.

Forbid, aynı CronJob’un önceki Job’u sürerken yeni eşzamanlı çalışmayı engeller. Bu, her planlanan çalışmanın mutlaka yürütüleceği anlamına gelmez; arada kaçırılan zamanlar oluşabilir. Önceki çalışma bittiğinde başlangıç gecikmesi sınırı da değerlendirilir. Ayrıca politika, başka CronJob’ları veya operatörün elle başlattığı bağımsız işleri tek bir küresel kilit altında toplamaz.

Replace, yeni çalışma zamanı geldiğinde mevcut çalışmayı değiştirir. Her yeni rapor eskisini geçersiz kılıyorsa düşünülebilir; fakat yarıda kesilen aktarımın ne bıraktığı bilinmiyorsa tehlikelidir. Bir dosyayı kısmen yazmış, uzak sisteme isteği göndermiş veya veritabanı dışındaki bir kaynağı değiştirmiş olabilir. Yerine koyma politikasını bir işlem geri alma mekanizması gibi yorumlamayın.

Başlangıç gecikmesi ile çalışma süresini ayırın

startingDeadlineSeconds, planlanan zaman kaçırıldıysa Job’un ne kadar geç oluşturulabileceğini belirler. İş başladıktan sonra ne kadar çalışacağını sınırlamaz. Bu ikinci ihtiyaç için Job seviyesindeki activeDeadlineSeconds değerlendirilir. İki alanı aynı amaçla kullanmak, geç kalan işi durdurduğunuzu sanarken uzun süren bir işlemi açık bırakmanıza yol açabilir.

Örneğin sabah toplantısından sonra değeri kalmayan bir raporla, gecikse de mutlaka aktarılması gereken hareket kaydı farklı davranmalıdır. Rapor için eski çalışmayı atlamak kabul edilebilirken hareket kaydı için eksik dönemlerin uygulama tarafından bulunması gerekir. Süreleri ezbere kopyalamak yerine gerçek çalışma dağılımından ve işin son teslim zamanından türetin. Çok düşük başlangıç toleransı da controller kontrol aralığı nedeniyle beklenmedik atlamalar doğurabilir.

Saat dilimini ve bakım sonrası davranışı açık yazın

İşletme takvimi Türkiye saatine göre ilerliyorsa spec.timeZone: Europe/Istanbul değerini açıkça tanımlayın ve kullanılan Kubernetes sürümünde desteğini doğrulayın. Saat dilimini cron ifadesinin içine eklemek yerine ilgili API alanını kullanın. Ekip içindeki çalışma kaydında hem yerel zaman hem UTC bulunması, logları farklı servisler arasında karşılaştırmayı kolaylaştırır.

Bakım sırasında suspend: true yapılması daha önce başlayan Job’ları durdurmaz. Askı kaldırıldığında kaçırılan zamanların değerlendirilmesi başlangıç toleransına bağlıdır. Bu nedenle bakım öncesinde çalışan işleri ayrıca görün; bakım sonrasında da beklenmedik iş yükü doğup doğmadığını kontrol edin. Geçmişe yönelik toplu telafi gerekiyorsa bunu açık bir veri aralığıyla, kontrollü ayrı operasyon olarak yürütün.

Tek çalıştırma varsayımı yerine idempotency tasarlayın

Kubernetes zamanlaması, iş düzeyinde “tam olarak bir kez” teslim garantisi değildir. Bazı koşullarda aynı dönem için birden fazla Job oluşabilir veya bir çalışma hiç oluşturulmayabilir. Bu yüzden uygulama, aynı iş tekrarlandığında zararlı yan etki üretmeyecek şekilde tasarlanmalıdır. İş kimliği yalnızca Pod adına bağlı olmamalı; müşteri, rapor dönemi ve görev türü gibi anlamlı bileşenlere dayanmalıdır.

Veritabanında benzersiz iş anahtarı, atomik sahiplenme ve tamamlanma kaydı kullanılabilir. Harici servis destekliyorsa idempotency anahtarı da gönderilebilir. Ancak zaman aşımında yanıt alınmaması, karşı tarafın isteği işlemediğini kanıtlamaz. Yeniden denemeden önce işlem durumunu sorgulama veya mutabakat mekanizması düşünün. Kilit kullanıyorsanız süresi, yenilenmesi ve iş çöktüğünde nasıl bırakılacağı da tasarımın parçasıdır.

Pod tamamlandı mı, iş sonucu gerçekten oluştu mu?

Bir konteynerin sıfır çıkış koduyla kapanması gerekli ama her zaman yeterli değildir. Boş sorgu sonucu, yanlış tarih aralığı veya sessizce atlanan API cevabı da teknik olarak başarılı görünebilir. İş kaydında planlanan dönem, başlama ve bitiş zamanı, işlenen kayıt sayısı ve çıktı konumu bulunmalıdır. Hassas müşteri verilerini loga taşımadan bu kanıtı üretin.

Alarmı yalnız hata veren Pod’a bağlamayın. Beklenen saatte son başarılı sonuç oluşmaması da alarm sebebidir. Ayrı olarak çalışma süresinin uzamasını, artan retry sayısını ve hedef sisteme erişim sorunlarını izleyin. Job geçmişi temizlendiğinde kanıt kaybolmasın diye iş sonuçlarını uygun saklama süresine sahip merkezi bir kayıtta tutun.

Canlıya geçiş öncesi kontrollü test listesi

• Normal çalışmada beklenen çıktı, doğru dönem ve kayıt sayısı doğrulandı mı?
• Önceki iş uzadığında seçilen concurrency politikası beklendiği gibi davranıyor mu?
• Aynı iş anahtarı iki kez verildiğinde çift yan etki engelleniyor mu?
• Geç başlangıç, bakım sonrası askı kaldırma ve bağımlı servis kesintisi denendi mi?
• Kaynak talepleri, Secret erişimi ve servis hesabı yalnız gerekli kapsamda mı?
• Son başarılı iş zamanı için bir sorumluya ulaşan alarm var mı?
• Elle telafi komutu, yetki sınırı ve olay kaydı runbook’ta bulunuyor mu?

Bu testleri gerçek ödeme, müşteri bildirimi veya silme işlemleri üzerinde ilk kez yapmayın. İzole test verisi ve etkisiz hedefler kullanın. Üretime geçerken önce düşük riskli bir görev seçin; ölçülen sonuçları iş sahibine gösterdikten sonra daha kritik aktarım akışlarına ilerleyin. Birden fazla ekibin kullandığı işlerde telafi yetkisini tek bir sorumlu akışta toplamak çakışmaları azaltır.

Altyapı ile uygulama sorumluluğunu birlikte planlayın

Kubernetes Cluster Hosting değerlendirmesinde yalnız worker kapasitesini değil, zamanlanmış işlerin bağımlılıklarını ve bakım takvimini de paylaşın. İzleme, erişim ve işletim işlerinin kapsamı için DevOps hizmeti ayrı değerlendirilmelidir. Küme erişilebilirliği; uygulama idempotency’sinin, dış API davranışının veya her raporun zamanında tesliminin otomatik garantisi değildir.

CTA: Zamanlanmış işlerinizin sıklığını, normal ve en uzun çalışma süresini, gecikme toleransını ve kritik yan etkilerini paylaşın. CronJob kapasite ve operasyon planınızı birlikte değerlendirelim. İnceleme, ölçülebilir kabul kriterleriyle başlayan bir altyapı görüşmesi olmalıdır; uygulama geliştirme ve özel entegrasyon kapsamı ayrıca netleştirilir.

Teknik kaynak: Kubernetes resmî CronJob dokümantasyonu.