Kubernetes'te Job ve CronJob ile zamanlanmış işler nasıl kurulur

Job ve CronJob: biri bir kez, öteki zamanlanmış

Deployment, sürekli çalışması gereken uygulamalar içindir. Bir veri aktarımı, raporun üretilmesi, veritabanı yedeği ya da temizlik betiği gibi bir işi bitirip kapanan uygulamalar için Kubernetes ayrı nesneler sunar. Job, bir ya da birden çok pod'u başarıyla tamamlanana kadar çalıştırır; iş bitince pod'lar durur. CronJob ise Job'ları bir zaman çizelgesine göre tekrar tekrar oluşturur.

İlişki şöyledir: CronJob doğrudan pod çalıştırmaz, her tetiklemede bir Job nesnesi üretir ve Job pod'ları çalıştırır. Bu yüzden CronJob'ı anlamak için önce Job'ı anlamak gerekir. Klasik cron'dan farkı, işin tek bir makinede değil kümede, kapsayıcı olarak ve Kubernetes'in sağlık, kaynak ve günlük altyapısıyla çalışmasıdır.

Job yazmak: temel alanlar

Basit bir Job şu biçimdedir. Örnek kurguseldir, imaj ve komut size göre değişir:

apiVersion: batch/v1 kind: Job metadata: name: veri-aktarimi spec: backoffLimit: <deneme hakkı> template: spec: containers: - name: aktarici image: kayit.ornek.com/aktarici:etiket command: ["/bin/aktar"] restartPolicy: Never

Dikkat edilecek alanlar: • restartPolicy: Bir Job için Never ya da OnFailure olmalıdır; Always kabul edilmez. Never seçilirse hata durumunda yeni bir pod açılır ve eskisinin günlükleri incelenebilir kalır. OnFailure ise aynı pod içinde konteyneri yeniden başlatır. • backoffLimit: Job başarısız sayılmadan önce kaç yeniden deneme yapılacağını sınırlar. Belge örneğinde bu alan açıkça yazılmıştır; varsayılanı belgeden kontrol edin. • completions ve parallelism: Kaç başarılı tamamlanma gerektiğini ve aynı anda kaç pod çalışacağını belirler. Belgedeki örnek çıktıda varsayılan değerlerle görünür, yani tek pod tek seferlik iş. • activeDeadlineSeconds: İşin toplam süresine üst sınır koyar; takılan bir işin sonsuza dek sürmesini engeller. • ttlSecondsAfterFinished: Biten Job nesnesinin ne zaman otomatik temizleneceğini söyler. Aksi halde tamamlanmış Job'lar birikir.

Çalıştırdıktan sonra kubectl get job ile durumu, kubectl logs ile çıktıyı izlersiniz.

Paralel işler ve tamamlanma modları

Büyük bir iş parçalara bölünebiliyorsa Job paralel çalışabilir. Belge, bunun için paralel yürütme ve tamamlanma modunu ayrı başlıklar altında anlatır. Genel fikir şudur: bir iş kuyruğu varsa birkaç pod aynı kuyruktan çekebilir, her pod bitirdiğinde sayaç ilerler ve gereken tamamlanma sayısına ulaşılınca Job biter.

Sabit sayıda bağımsız parça varsa Indexed modu işe yarar: her pod kendi sıra numarasını bilir ve ona göre bir veri dilimini işler. Belgedeki örnek çıktıda görülen NonIndexed modunda ise pod'lar birbirinden ayırt edilmez. Hangi modun uygun olduğu, işi parçalama biçiminize bağlıdır.

Paralel işlerde kritik kural, işin tekrar çalıştırılmaya dayanıklı olmasıdır. Kubernetes bir pod'u yeniden denediğinde iş yarım kalmış olabilir; yarım yazılmış çıktı veya tekrarlanan e-posta gibi etkiler oluşmaması için iş, aynı girdiyle yeniden çalışınca aynı sonucu üretmelidir. Buna idempotent tasarım denir.

CronJob yazmak: zamanlama ve politikalar

CronJob, Job şablonunu bir zamanlamayla sarar. Zamanlama alanı klasik cron biçimini izler: dakika, saat, ayın günü, ay ve haftanın günü sırasıyla yazılır. Belge, adımlı ifadelerin de desteklendiğini ve sık kullanılan kısayolların bulunduğunu belirtir: saatlik, günlük, haftalık, aylık ve yıllık için yazılan makrolar bunlardır. Soru işareti de yıldızla aynı anlamı taşır.

Örnek kurgusal bir yapı:

apiVersion: batch/v1 kind: CronJob metadata: name: gunluk-rapor spec: schedule: "@daily" concurrencyPolicy: Forbid startingDeadlineSeconds: <saniye> jobTemplate: spec: template: spec: containers: - name: rapor image: kayit.ornek.com/rapor:etiket restartPolicy: OnFailure

Önemli politika alanları: • concurrencyPolicy: Allow (varsayılan) eşzamanlı Job'lara izin verir. Forbid, önceki Job bitmediyse yeni çalıştırmayı atlar. Replace ise çalışan Job'ı yenisiyle değiştirir. Bu politika yalnızca aynı CronJob'ın Job'ları arasında geçerlidir; farklı CronJob'ların Job'ları her zaman eşzamanlı çalışabilir. • startingDeadlineSeconds: Bir Job zamanında başlayamazsa, ne kadar süre geç başlayabileceğini belirler. Süre aşılırsa o tetikleme atlanır ama sonraki çalıştırmalar planlanmaya devam eder. • suspend: true yapılırsa sonraki çalıştırmalar durdurulur, zaten başlamış Job'lar etkilenmez. Bakım dönemlerinde işe yarar.

Zaman dilimi davranışı ve başarılı Job geçmişini sınırlama gibi ayarlar için belgeye bakın.

Günlük işler için pratik tasarım

Zamanlanmış görevleri güvenilir kılan, Kubernetes ayarlarından çok işin tasarımıdır.

Önce idempotency. Gece çalışan bir rapor işi aynı gün yeniden tetiklenebilir ya da yarıda kesilip yeniden denenebilir. İşi, "bugünün raporu zaten üretildiyse atla" gibi bir kontrolle yazın.

Sonra çakışma. Önceki çalıştırma bitmeden yenisi başlarsa aynı veriye birden çok iş yazabilir. Veriyi değiştiren işlerde Forbid genellikle güvenli seçimdir; ancak sürekli atlanan çalıştırmaları izlemeniz gerekir.

Kaynaklar. Job pod'larına request ve limit yazın; toplu iş kümenin kaynağını sessizce tüketmesin. Çalışma süresi uzun olan işleri diğer iş yüklerinden ayırmak için ayrı bir düğüm havuzu da düşünülebilir.

Bildirim. Başarısız bir CronJob kimseye haber vermeden günlerce çalışmayabilir. Başarısız Job sayısı için uyarı kurun; en azından kubectl get jobs çıktısını düzenli denetleyen bir süreç olsun.

Temizlik. Tamamlanan Job'ların birikmesi hem ekranı kirletir hem de kaynak tüketir; geçmiş sınırı ve ttl alanlarıyla otomatik temizliği ayarlayın. Ancak sorun giderebilmek için son başarısız çalıştırmaların günlüklerini bir süre tutmak isteyebilirsiniz; günlükleri ayrıca merkezi bir sisteme aktarmak en sağlamıdır.

Sık hatalar ve sorun giderme

• İş çalışmıyor, Job hiç oluşmuyor: Zamanlama ifadesi yanlış olabilir ya da CronJob askıda (suspend) olabilir. kubectl describe cronjob çıktısındaki son zamanlama bilgisine bakın.
• Job oluşuyor ama pod başlamıyor: İmaj çekilemiyor ya da kümede kaynak yok. Pod olaylarına bakın.
• Job tekrar tekrar başarısız: Komut hatalı çıkış kodu veriyor. backoffLimit dolunca Job başarısız sayılır; günlükleri okuyun ve girdiyi kontrol edin.
• Çalıştırmalar atlanıyor: Forbid politikası ve uzun süren önceki iş, ya da startingDeadlineSeconds çok kısa.
• Yinelenen çıktı: İş idempotent değil ve yeniden denendi.
• Beklenmedik saatte çalışıyor: Zaman dilimi varsayımı yanlış. Belgede zaman dilimi ayarını okuyun ve kritik işlerde saati açıkça tanımlayın.
• Biten Job'lar birikiyor: Temizlik alanları ayarlı değil.

Şunu da unutmayın: CronJob zamanlaması "yaklaşık" bir söz verir. Kontrol düzlemi kısa süre erişilemezse tetikleme kaçabilir. Tam zamanlı ya da kesin tek seferlik çalışma gerektiren işler için işin kendi içinde kontrol mantığı kurun.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Job ve CronJob, Kubernetes iş yükü kaynaklarının toplu işlere dönük kısmıdır. Mindset kataloğundaki "Kubernetes ile Orkestrasyon" programı "İş Yükü Kaynakları", "Konfigürasyon ve Gizli Yönetimi" ve "Güvenilirlik ve Sorun Giderme" modülleriyle bu temeli kurar. Veri aktarımı, raporlama ya da bakım betiklerini kümeye taşıyacak geliştirici, veri mühendisi ve DevOps ekipleri için uygundur. Zamanlanmış işlerin kimin sorumluluğunda olduğu ve nasıl izleneceği, kurumsal ekiplerde sık atlanan bir konudur; program bu tartışmayı ortak bir terimle açmak için zemin sağlar.