Airflow ile k8s otomasyonu 4: Birkac detay

Bu hususlara dikkat ememiz gerekiyor:

Pod resources
Istenecek resource'lari birer Variable seklinde airflow'a kaydedersek ilerde farkli resourcelar istemek icin dag koduna dokunmamiza gerek kalmaz. Ayni zamanda Variable kullanildiginda default deger de verilebiliyor. 

resources = {
    'request_memory': Variable.get("pod_memory", default_var='128Gi'),
    'limit_memory': Variable.get("pod_memory", default_var='128Gi'),
    'request_cpu': Variable.get("pod_cpu", default_var='128Gi')
}

Seklinde belirtebiliriz. Buradaki birimler enteresan, ben cpu'yu 1 olarak verdim ama, micro-cpu olarak da verebiliyorsunuz. (o da neyse gari)

Podunuz gec mi kalkiyor?
Ortam kosullarina gore bazen pod'a resource allocate edilmesi biraz zaman aliyor. (bkz bir onceki post, 1 gun bekledi gene olmadi ama bu bir edge case). Bu durumda KubernetesPodOperator bir muddet bekliyor (default kac bilmiyorum dokumantasyonda yazar) sonra fail oluyor cunku Pod hala ayaga kalkmamis oluyor. Bunun icin saniye cinsinden soyle bir parametre var:

startup_timeout_seconds=600

Bu sayede sekildeki gibi 10dk gibi bir timeout verilebilir. Veya nebilym. 

Podunuz fail oldu lutfen tekrar deneyiniz
Evet bazen de direk fail oluyor. Benim durumumda memory az verilince, icerde calisan python uygulamasinini memory cosmasi sonucu pod kill ediliyor. (Veya baska bir sebepten tam bilmiyoruz). Bu durumda tekrar podunu kaldirip tekrar denemeye dayali bir strateji izlemek isterseniz, airflow sizin icin yapiyor. 

retries=3

parametresi ile kac kere tekrar denemesi gerektigini belirtebilirsiniz. Burada 3 kere denedikten sonra hepsi fail olursa airflow bu task'u fail etmis sayacak. 

Bu arada arka arkaya da denemek bazen sacma oluyor. K8s clusterinin durumuna gore, eger pod ayaga kaldirmayla alakali gecici bir sorun var, bir fail aldiktan sonra biraz bekleyip tekrar denemek gerekiyor. Aslinda bilinen bir strateji bu, client programciliginda da kullanilir. Eger bir api hata donduruyorsa ikinci kere denersiniz ve her seferinde giderek artan zaman araliklariyla denersiniz. 

retry_exponential_backoff=True

seklindeki parametre ile airflowun da, taski tekrar denerken gittikce daha cok beklemesini saglayabilirsiniz.