Tại sao trong công việc kubernetes cron hai công việc có thể được tạo ra, hoặc không có công việc nào có thể được tạo ra?

Question

Trong k8s Cron Job Limitations nói rằng không có gì bảo đảm rằng một công việc sẽ thực hiện đúng một lần:

Một công việc cron tạo ra một đối tượng công việc khoảng một lần mỗi thời gian thực hiện thời hạn của nó. Chúng tôi nói "về" bởi vì có một số trường hợp trong đó hai công việc có thể được tạo hoặc không thể tạo công việc. Chúng tôi cố gắng để làm cho những điều này hiếm, nhưng không hoàn toàn ngăn chặn chúng. Do đó, việc làm nên được idempotent

bất cứ ai có thể giải thích:

• tại sao điều này có thể xảy ra?
• xác suất/thống kê này có thể xảy ra là gì?
• nó sẽ được sửa trong một số tương lai hợp lý trong k8?
• có cách giải quyết nào để ngăn chặn hành vi đó không (nếu công việc đang chạy không thể được thực hiện như idempotent)?
• làm khác cron liên quan dịch vụ có cùng vấn đề? Có lẽ nó là một vấn đề cron cốt lõi?

Answer 1

Bộ điều khiển:

https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/cronjob/cronjob_controller.go

bắt đầu với một lời nhận xét đó đặt nền tảng cho một lời giải thích:

I did not use watch or expectations. Those add a lot of corner cases, and we aren't expecting a large volume of jobs or scheduledJobs. (We are favoring correctness over scalability.) 

If we find a single controller thread is too slow because there are a lot of Jobs or CronJobs, we we can parallelize by Namespace. If we find the load on the API server is too high, we can use a watch and UndeltaStore.) 

Just periodically list jobs and SJs, and then reconcile them. 

kỳ có nghĩa là mỗi 10 giây:

https://github.com/kubernetes/kubernetes/blob/master/pkg/controller/cronjob/cronjob_controller.go#L105

Các tài liệu sau đây những hạn chế niêm yết cũng có một số màu hữu ích về một số trong các trường hợp theo đó 2 việc làm hoặc không có việc làm có thể được đưa ra theo một lịch trình cụ thể:

If startingDeadlineSeconds is set to a large value or left unset (the default) and if concurrentPolicy is set to AllowConcurrent, the jobs will always run at least once. 

Jobs may fail to run if the CronJob controller is not running or broken for a span of time from before the start time of the CronJob to start time plus startingDeadlineSeconds, or if the span covers multiple start times and concurrencyPolicy does not allow concurrency. For example, suppose a cron job is set to start at exactly 08:30:00 and its startingDeadlineSeconds is set to 10, if the CronJob controller happens to be down from 08:29:00 to 08:42:00, the job will not start. Set a longer startingDeadlineSeconds if starting later is better than not starting at all. 

Một mức cao hơn, giải quyết cho chỉ một lần trong một hệ thống phân phối là cứng:

https://bravenewgeek.com/you-cannot-have-exactly-once-delivery/

Đồng hồ và đồng bộ hóa thời gian trong một hệ thống phân phối cũng cứng:

https://8thlight.com/blog/rylan-dirksen/2013/10/04/synchronization-in-a-distributed-system.html

Để các câu hỏi:

• tại sao điều này có thể xảy ra?

  Ví dụ: nút lưu trữ CronJobController không thành công tại thời điểm công việc được yêu cầu chạy.

• xác suất/thống kê này có thể xảy ra là gì?

  Rất khó cho bất kỳ lần chạy nào đã cho.Đối với một số lượng đủ lớn chạy, rất khó có thể thoát khỏi phải đối mặt với vấn đề này.

• nó sẽ được sửa trong một số tương lai hợp lý trong k8?

  Không có vấn đề liên quan đến idemopotency theo nhãn khu vực/lô hàng trong repo k8, do đó, người ta sẽ không đoán.

  https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Aarea%2Fbatch

• được có bất kỳ cách giải quyết để ngăn chặn một hành vi như vậy (nếu công việc chạy không thể được thực hiện như idempotent)?

  Suy nghĩ thêm về định nghĩa cụ thể về tính ngẫu nhiên và các điểm cụ thể trong công việc có cam kết. Ví dụ, các công việc có thể được thực hiện để hỗ trợ nhiều hơn một lần thực hiện nếu họ lưu trạng thái để dàn khu vực, và sau đó có một quá trình bầu cử để xác định công việc của ai thắng.

• các dịch vụ liên quan đến cron khác có cùng vấn đề không? Có lẽ nó là một vấn đề cron cốt lõi?

  Có, đó là sự cố hệ thống phân tán lõi.

  Đối với hầu hết người dùng, tài liệu k8 có thể cung cấp câu trả lời chính xác và sắc thái hơn là cần thiết. Nếu công việc theo lịch trình của bạn là kiểm soát một số thủ tục y tế quan trọng, nó thực sự quan trọng để lên kế hoạch cho các trường hợp thất bại. Nếu nó chỉ làm một số hệ thống dọn dẹp, thiếu một chạy theo lịch trình không quan trọng nhiều. Theo định nghĩa, gần như tất cả người dùng của k8s CronJobs rơi vào thể loại sau.