ตั้ง CronJob แล้ว ทำไมงานยังรันซ้อนหรือข้ามรอบ

งานตามเวลาอย่างสร้างรายงานหรือดึงข้อมูลเป็นรอบ มักเริ่มจากคำถามง่ายๆ ว่าอยากให้รันกี่โมง พอตั้งตารางแล้วก็ปล่อยให้ระบบสร้างงานตามนั้น แต่เมื่อระยะทำงานไม่เท่ากันทุกครั้ง ตารางเพียงอย่างเดียวก็ยังไม่ตอบว่าจะทำอย่างไรถ้ารอบเก่ายังไม่จบตอนรอบใหม่มาถึง

ตัวอย่างสมมติคือกำหนดทุกห้านาที แต่งานบางรอบใช้เจ็ดนาที หากเปิดให้เริ่มตามตารางทุกครั้ง เราอาจมีงานสองรอบแตะข้อมูลชุดเดียวกันอยู่พร้อมกัน โดยที่ไม่มีส่วนใดทำผิดตารางเลย ปัญหาอยู่ที่กติกาการซ้อนของงานซึ่งยังไม่ได้กำหนด

สำหรับ Kubernetes CronJob จึงควรอ่านทั้ง schedule นโยบายการรันซ้อนและข้อจำกัดการสร้าง Job ร่วมกันครับ แล้วให้ตัวงานมีรหัสรอบกับทางตรวจผลของตัวเองด้วย

Schedule บอกจังหวะที่คาดว่าจะเริ่ม ไม่ใช่เวลาที่ทำเสร็จ

CronJob ใช้ตารางเพื่อสร้าง Job สำหรับการทำงานแต่ละครั้ง จากนั้นยังมีขั้นที่ Job กับ Pod ต้องเริ่มและประมวลผลต่อ เวลาที่กำหนดไว้ในตารางจึงไม่ควรถูกใช้แทนเวลาจบหรือเวลาที่ผลพร้อมให้ผู้ใช้เรียกอ่าน

เอกสาร Kubernetes ยังระบุว่าการสร้างตามตารางเป็นการประมาณ มีเงื่อนไขที่อาจสร้างสอง Job หรือไม่สร้างในบางรอบได้ จึงแนะนำให้งานมีคุณสมบัติรองรับการทำซ้ำ ไม่ถือว่าระบบตั้งเวลาให้แล้วคำสั่งธุรกิจจะเกิดผลครั้งเดียวแน่นอน

ควรบันทึกเวลาที่ตั้งใจประมวลผลกับเวลาที่เริ่มจริงแยกกัน เช่น งานสรุปข้อมูลของช่วงหนึ่งไม่ควรเปลี่ยนไปสรุปช่วงปัจจุบันเงียบๆ เพียงเพราะมันเริ่มช้า การรับช่วงข้อมูลเป็น input ที่ชัดช่วยให้ทั้ง retry และการตรวจย้อนหลังอ้างงานเดียวกันได้

Allow Forbid และ Replace เลือกพฤติกรรมคนละแบบ

concurrencyPolicy แบบ Allow เปิดให้ Job จาก CronJob นั้นรันพร้อมกันได้ ส่วน Forbid ใช้หลีกเลี่ยงการซ้อนจาก CronJob เดียวกัน หากรอบก่อนยังไม่จบ รอบใหม่อาจถูกข้ามตามเงื่อนไข และรายละเอียดการเริ่มภายหลังก็ต้องดู deadline ประกอบ

Replace ใช้แทนที่ Job ที่กำลังรันด้วยรอบใหม่ แต่การแทนที่ไม่ได้ย้อนผลภายนอกที่งานก่อนทำไปแล้ว เช่น ไฟล์ที่ส่งหรือคำสั่งที่บริการอื่นรับไปแล้ว จึงต้องดูว่างานรองรับการหยุดกลางทางกับการเริ่มรอบใหม่ได้แค่ไหน

ไม่มีตัวเลือกใดเหมาะกับทุกงาน งานตรวจสถานะล่าสุดอาจยอมข้ามรอบได้ต่างจากงานที่ต้องประมวลผลทุกช่วงเวลา หากเลือก Forbid แต่ตัวงานนานกว่าช่วงห่างเป็นประจำ ก็ควรอธิบายว่าจะรักษาข้อมูลของรอบที่ไม่ได้เริ่มอย่างไร ไม่ตั้งค่าแล้วถือว่าความครบถ้วนตามมาเอง

นโยบายนี้ไม่ได้ล็อกข้อมูลร่วมทั้งระบบ

ขอบเขต concurrencyPolicy อยู่ที่ Job ที่สร้างจาก CronJob เดียวกัน ไม่ได้ทำให้ CronJob อีกตัวหรือการกดรันด้วยเส้นทางอื่นหยุดรอด้วย หากหลายงานแก้ข้อมูลชุดเดียวกัน ก็ยังต้องมีกติกาที่ระดับข้อมูลหรือเจ้าของงานเพิ่มเติม

ตัวอย่างเช่น งานที่รันทุกคืนกับเครื่องมือสั่งประมวลผลซ่อมย้อนหลังอาจมาถึงช่วงข้อมูลเดียวกันได้ การมีชื่อรอบงานที่แน่นอนและเงื่อนไขว่าใครรับผิดชอบรอบนั้นช่วยให้ตัดสินซ้ำได้ตามขอบเขต ไม่อาศัยเพียงชื่อ Pod ที่ต่างกันทุกครั้ง

ส่วนการป้องกันผลซ้ำควรครอบคลุมขั้นที่มีผลจริง ไม่ใช่ตรวจว่าเคยเริ่มรอบนี้หรือยังแล้วตั้งว่าสำเร็จล่วงหน้า เพราะถ้าหยุดกลางทาง รอบถัดไปจะไม่รู้ว่าควรทำต่อหรือหลีกเลี่ยงส่วนใด

รอบที่พลาดต้องมีขอบเขตว่าจะเริ่มช้าได้แค่ไหน

startingDeadlineSeconds ใช้กำหนดขอบเขตการเริ่ม Job ที่พลาดจากจังหวะตามตาราง โดยไม่ใช่ระยะเวลาสูงสุดที่ปล่อยให้ตัวงานรันจนจบ ทั้งสองคำถามจึงต้องแยกกันเมื่อออกแบบการจัดการงานช้าหรือค้าง

การเลือก deadline ต้องสัมพันธ์กับประโยชน์ของข้อมูล เช่น งานที่ยังต้องปิดยอดของช่วงก่อนอาจยอมให้เริ่มภายหลังได้ ขณะที่งานบางชนิดหากเริ่มช้ามากก็ไม่ตอบคำถามเดิมแล้ว ค่าที่ใช้จึงควรมีเหตุผลของงาน ไม่คัดลอกตัวเลขจากตัวอย่างโดยไม่ดูช่วงตาราง

การ suspend CronJob ก็ไม่ได้หยุด Job ที่เริ่มไปแล้ว และเมื่อเปิดกลับ การจัดการรอบที่พลาดต้องดูการตั้งค่าร่วมด้วย จึงควรตรวจสถานะงานจริงก่อนเปลี่ยนการตั้งเวลา ไม่คิดว่าการพักตารางเท่ากับระบบหยุดทำงานทุกส่วนแล้ว

Timezone ของตารางกับขอบเขตข้อมูลต้องตรงกัน

CronJob รองรับการระบุ timeZone ตามรุ่น Kubernetes ที่มีความสามารถนี้ เช่น Asia/Bangkok แทนการฝากความหมายไว้กับ timezone ของ controller โดยไม่บันทึก และไม่ใส่ TZ หรือ CRON_TZ ลงในข้อความ schedule เพื่อหวังให้แทน field ที่รองรับ

แต่การกำหนด timezone ของตารางไม่ได้ทำให้ timestamp ในแอปหรือ session ฐานข้อมูลเปลี่ยนตามเอง หากงานสรุปรายวันต้องเลือกขอบเขตวัน ก็ควรกำหนด timezone ของวันนั้นและช่วงข้อมูลที่นำมาอ่านให้ชัดด้วย

ในระบบที่มี timezone ซึ่งปรับเวลาออมแสง ต้องตรวจพฤติกรรมของตารางกับช่วงข้อมูลตามระบบที่ใช้ ไม่อนุมานว่าทุกวันมีขอบเขตเวลาที่เลื่อนด้วยจำนวนชั่วโมงเดียวกันเสมอ หากงานผูกกับวันที่ปฏิทินก็ต้องรักษาความหมายนี้ตลอดทาง

เมื่อแก้ template ของ CronJob ต้องจำด้วยว่าการเปลี่ยนใช้กับ Job ที่สร้างใหม่หลังจากนั้น งานที่เริ่มไปแล้วไม่ได้ถูกแก้ตามทันที จึงควรติดตามรุ่นของงานที่รันจริงร่วมกับค่าปัจจุบันในตาราง ไม่อ่าน manifest ล่าสุดแล้วอนุมานว่าทุก Pod ใช้ค่าชุดนั้นอยู่

ตรวจผลธุรกิจคู่กับสถานะของ Job

ควรติดตามทั้งรอบที่คาดว่าต้องมี Job ที่สร้างจริง เวลารอเริ่ม เวลาทำงาน และผลที่ต้องใช้ต่อ เช่น รายงานของช่วงนั้นถูกสร้างครบหรือไม่ สถานะของตัวรันเป็นหลักฐานส่วนหนึ่ง แต่ไม่ควรใช้แทนการตรวจว่าข้อมูลปลายทางตรงตามขอบเขตงานทั้งหมดแล้ว

ชุดทดลองควรมีงานที่นานกว่าช่วงห่าง งานที่หยุดกลางทางและการเริ่มรอบเดิมซ้ำ พร้อมตรวจการข้ามหรือแทนที่ตาม policy บทนี้อ้างหลักการจากเอกสาร Kubernetes1.33 และยังไม่ได้เปลี่ยน CronJob หรือเก็บผลตารางงานจริงของผู้ใช้

CronJob ที่ดูแลง่ายต้องมีทั้งความหมายของรอบเวลา นโยบายซ้อนและทางจัดการงานที่พลาด เมื่อแยกขอบเขตของ controller ออกจากผลธุรกิจ พร้อมตามรหัสรอบและช่วงข้อมูลได้ เราจะเลือก Allow Forbid หรือ Replace ตามงานจริง และรู้ว่าการตั้งเวลาให้เริ่มยังต้องเดินต่อไปถึงหลักฐานของผลที่ต้องการ