Kubernetes: CronJobs harus mendukung zona waktu

@iterion Tidak ada label tanda pada masalah ini. Silakan tambahkan label tanda dengan:
(1) menyebutkan tanda: @kubernetes/sig-<team-name>-misc
(2) menentukan label secara manual: /sig <label>

_Catatan: metode (1) akan memicu pemberitahuan ke tim. Anda dapat menemukan daftar tim di sini dan daftar label di sini _

/ tandatangani aplikasi

Lebih suka opsi kedua karena terlihat lebih alami bagi saya

@soltysh @kubernetes/sig-apps-feature-requests

Saya juga menyukai formulir kedua, tetapi tampaknya cara termudah untuk menerapkannya adalah dengan menghapus waktu itu dan menggunakannya secara terpisah. Juga, argumen dapat dibuat, bahwa, karena kami menggunakan template cron "standar", kami tidak boleh mengacaukannya.

Sepertinya ini harus mudah diterapkan:
Saat ini, kita hanya melewatkan time.Now() ke dalam loop syncOne . Cron lib yang digunakan k8s tampaknya berfungsi hanya dengan menggunakan waktu di zona yang Anda pedulikan. Jadi, kita bisa menarik zona waktu dari CronJob dan melewatkan waktu itu dengan zona ke fungsi syncOne.

//init the loc, needs error handling
//perhaps default to local if Timezone was invalid
loc, _ := time.LoadLocation(cronjob.Spec.Timezone)

//set timezone,  
now := time.Now().In(loc)

Juga, saya senang mencoba menerapkan ini.

Saya bukan orang yang tepat untuk meninjau PR Anda, tetapi saya memiliki beberapa pertanyaan tentang semantik.

• Apa semantik ketika tidak ada zona waktu yang ditentukan?
• Apakah implementasinya bergantung pada zona waktu yang dikonfigurasi dengan benar pada host pengontrol?
• Kapan kami memvalidasi legalitas zona waktu? Pada waktu pembuatan/pembaruan objek, atau lebih baru?
• Apa yang terjadi jika nama zona waktu legal ketika objek API dibuat, tetapi di masa mendatang tidak ada lagi? Ini bisa terjadi karena nama dihapus (mungkin kota atau negara tidak ada lagi), atau karena paket tzdata yang mendasarinya telah berubah ke versi yang lebih lama.

Jika tidak ada zona waktu yang ditentukan, itu akan menjadi default ke perilaku saat ini yang akan menggunakan zona waktu Host. Saya kira dalam banyak kasus ini akan dikonfigurasi sebagai UTC, tetapi pengguna benar-benar dapat memilih zona waktu apa pun. Dengan demikian, tidak ada ketergantungan yang lebih besar pada zona waktu yang dikonfigurasi dengan benar pada host sebagai akibat dari PR ini.

Saat ini saya baru saja menyelamatkan dan menggunakan zona waktu Host jika pengguna menentukan sesuatu yang tidak valid. Di sini, saya bersandar pada metode golang time.LoadLocation(str) . String apa pun yang diterima oleh fungsi itu akan dianggap valid. Saat ini saya tidak memvalidasi ini pada waktu membuat/memperbarui, meskipun tampaknya itu akan menjadi hal yang cukup mudah untuk dilakukan.

Sejauh pertanyaan terakhir, yang itu sedikit lebih tidak terdefinisi. Saat ini, dan mungkin di masa depan, kemungkinan besar akan kembali ke penjadwalan pekerjaan berdasarkan zona waktu default. Saya terbuka untuk saran tentang cara menangani kasus ini.

Apa yang terjadi jika nama zona waktu legal ketika objek API dibuat, tetapi di masa mendatang tidak ada lagi? Ini bisa terjadi karena nama dihapus (mungkin kota atau negara tidak ada lagi), atau karena paket tzdata yang mendasarinya telah berubah ke versi yang lebih lama.

Saran saya untuk itu adalah menggagalkan penciptaan lapangan kerja dengan acara yang sesuai. Tapi terus terang saya ragu ini sering terjadi. Saya akan memastikan untuk menambahkan ini dalam implementasi Anda @iterion.

dan format cron tidak mendukung tahun yang diajukan, bagaimana menjalankan pekerjaan hanya sekali pada waktu yang ditentukan?

:+1:

@iterion Terima kasih atas masalah dan permintaan tariknya. Kami membahasnya sedikit selama seminggu terakhir, baik di Aplikasi SIG dan Arsitektur SIG. Sementara kasus penggunaan ini bisa berguna untuk masuk akal, kami juga harus membahas kerugiannya. Misalnya, setiap distribusi Kubernetes yang patuh harus memiliki basis data zona waktu dan selalu memperbaruinya. Zona waktu, waktu musim panas, dan detail membuat ini berfungsi sementara detail dunia nyata dapat dan melakukan shift sulit. Ini akan menjadi pekerjaan tambahan untuk lebih dari 20 distribusi yang ada saat ini.

Pada saat yang sama telah terjadi pergeseran dalam pengembangan Kubernetes. Saya tidak yakin seberapa luas telah dikomunikasikan (komunikasi adalah poin lain yang dibahas dalam Arsitektur SIG). Pergeseran ini adalah keinginan agar inti Kubernetes fokus pada stabilitas dan bergerak lambat. Orang-orang sekarang didorong untuk berinovasi dan memecahkan masalah semacam ini di ekosistem daripada di inti.

Alih-alih menempatkan ini di Kubernetes, permintaannya adalah:

1. Kembangkan ini dalam ekosistem (misalnya, pengontrol) yang dapat digunakan orang lain. Distribusikan, selesaikan masalah di sana, dan lihat seperti apa pembaruannya
2. Jika solusi diadopsi secara luas dan dapat digunakan oleh semua orang (termasuk skala kecil, multi-cluster, dll) maka solusi tersebut dapat dipertimbangkan untuk Kubernetes inti

Jika ini membantu, ini bukan satu-satunya fitur yang menerima arah yang sama (bahkan dalam pertemuan Arsitektur SIG yang sama). Saya mulai memikirkan hal ini dengan nada yang mirip dengan sesuatu seperti wordpress (saya menggunakan wordpress karena ini adalah contoh yang sangat umum). Ada perbedaan antara itu menjadi plugin atau bagian dari wordpress itu sendiri. Arah saat ini adalah untuk mendorong inovasi dalam plugin, sehingga untuk berbicara.

Jika Anda membuat sesuatu seperti ini, kami ingin mendemokannya di SIG Apps untuk dipamerkan kepada orang-orang. Bisa juga di demo di pertemuan komunitas.

Jika Anda memiliki pertanyaan tentang ini, jangan ragu untuk menghubungi saya.

Mengingat komentar sebelumnya, saya merasa kami dapat menutup masalah ini. Jangan ragu untuk membuka kembali jika Anda tidak setuju.

FWIW, "cara mengatur zona waktu" ditanyakan oleh setiap pengguna saya yang membuat CronJob (pengembang dan admin).

@iterion Apa yang akhirnya Anda lakukan tentang ini? Kami sedang mempertimbangkan berbagai opsi untuk kasus penggunaan kami, termasuk

• berlari dari garpu kubernetes dengan perbaikan Anda
• Menyalin kode pengontrol cron ke pengontrol eksternal, dan menggunakan apiVersion yang berbeda untuk membedakan keduanya.
• Membangun sesuatu yang spesifik untuk proyek kita di Ruby yang mencerminkan implementasi pengontrol cronjob kube tetapi berdasarkan pada file konfigurasi khusus aplikasi daripada sumber daya CronJob.

Jika Anda sudah memiliki sesuatu yang bekerja untuk Anda yang dapat kami gunakan sebagai titik awal, atau jika kami dapat berkolaborasi dalam sesuatu yang dapat mendorong @mattfarina untuk membatalkan keputusannya untuk tidak mengizinkan menyertakan ini (yang secara dramatis merugikan adopsi kube ini fitur), itu akan luar biasa.

Saya sebenarnya telah beralih ke pekerjaan baru, jadi masalah aslinya tidak ada lagi bagi saya secara pribadi. Sejauh yang saya tahu, mantan rekan kerja saya hanya berurusan dengan rasa sakit yang diakibatkannya.

Yang mengatakan, jika saya punya waktu untuk mencurahkan ini, saya mungkin hanya akan menulis pengontrol kecil yang akan menonton dan memodifikasi CronJobs sesuai kebutuhan. Saya mungkin hanya akan menambahkan anotasi ke CronJobs dengan waktu dan zona waktu yang diinginkan dan meminta pengontrol mengirimkan jadwal itu ke UTC dan memodifikasi CronJobs. Anda bisa saja menjalankan loop sinkronisasi ini pada suatu interval untuk menangkap tepi masalah, yaitu ketika penghematan siang hari dimulai atau berakhir. Dengan cara ini, pengontrol hanya akan menjadi pembungkus yang sangat tipis di atas CronJob API yang sudah ada.

mendorong @mattfarina untuk membalikkan keputusannya untuk tidak mengizinkan termasuk ini

Untuk memperjelas, keputusan ini dilakukan secara kolektif dalam salah satu pertemuan arsitektur. Matt adalah satu-satunya orang yang mengungkapkan keputusan itu dalam masalah ini.

Masalah zona waktu dengan semua lonceng dan peluit telah lama diselesaikan di dunia Linux. Mengapa ini merupakan prasyarat untuk penerapan Kubernetes?

Sulit untuk membahas tentang pentingnya kasus penggunaan yang saya akui. Namun (dan menurut pendapat saya), dapat menjadwalkan layanan yang sinkron dengan pengguna layanan tampaknya cukup penting bagi saya untuk memenuhi syarat untuk inti Kubernetes.

Adakah yang mau menulis operator dengan TimezoneAwareCronjobController? Sebagian besar kode yang ditulis oleh @iterion mungkin dapat didaur ulang.
Memindahkan penanganan TZ ke dalam aplikasi paket akan menyelesaikan argumen distribusi yang mematikan dukungan cronjob kelas satu di Kubernetes.

FWIW, https://gopkg.in/robfig/cron.v2 (yang digunakan oleh pengontrol yang ada adalah subset yang lebih lama), mendukung passing di TZ, dan serangkaian definisi waktu yang sedikit lebih kaya.
Kami memiliki pengontrol secara internal yang membuat pekerjaan cron untuk beberapa beban kerja internal kami, dan merupakan permintaan fitur yang luar biasa untuk dapat menentukan zona waktu untuk itu. Saya perlu mencari cara untuk memperbarui definisi cronjob yang ada dengan aman tanpa melewatkan, atau menjalankan kembali pekerjaan secara tidak sengaja. Pada titik ini rasanya mungkin lebih mudah untuk mencuri penjadwalan pekerjaan dari pengontrol yang keluar dan membuat definisi pekerjaan secara langsung (daripada cronjobs).

Sejak saya mulai menggunakan K8, saya kembali ke masalah ini dua kali setahun, ketika saya terpaksa mengubah jadwal di semua CronJobs, berharap akhirnya dibuka kembali. Jika chronos dan crontab memiliki fitur tersebut, bagaimana K8s masih tidak mendukung ini?

masalah jangka panjang (catatan untuk diri sendiri)

Semoga masalah ini dibuka kembali dan agak aneh melihat waktu UTC setiap hari.

Saya memiliki cronjob yang perlu dijalankan pada hari pertama setiap bulan pada waktu setempat, tetapi waktu UTC adalah 16:00 pada hari terakhir bulan lalu. Bagaimana cara menentukan hari terakhir bulan lalu? Cronjob tidak mendukung L.

Tampaknya solusi alternatif tidak ada. Lihat pertanyaan saya di sini dan di sini

Bagi siapa pun yang masih menunggu ini; Saya membuat pengontrol yang berasal dari pengontrol cronjob Kubernetes asli dan PR asli yang ditutup.

https://github.com/hiddeco/cronjobber

Sunting (2019-05-12): berkat @mterron , Cronjobber sekarang mendukung basis data zona waktu host independen menggunakan sespan.

@hiddeco apakah lebih baik memiliki pengontrol kontrol pengontrol CJ standar daripada memodifikasi yang sudah ada? Dengan pendekatan yang terakhir, seseorang perlu mengikuti perubahan pengontrol CJ yang sebenarnya, yang mungkin tidak selalu layak. Terima kasih atas kerjamu.

@andrewsav itu lebih disukai tetapi tidak bisa dilakukan. Satu-satunya cara saya melihat untuk 'mengendalikan' pengontrol CJ yang ada adalah dengan memodifikasi jadwal CronJob ke offset zona waktu. Anda tidak dapat melakukannya untuk semua kemungkinan kombinasi jadwal.

Saya tidak berharap banyak perubahan pada pengontrol CJ, ditambah kami tidak berkewajiban untuk tetap sinkron dengannya agar tetap berjalan karena mandiri (kecuali untuk dependensi pada klien dan spesifikasi Job ) .

@hiddeco

Anda tidak dapat melakukannya untuk semua kemungkinan kombinasi jadwal.

Bisakah Anda menjelaskan ini?

@AndrewSav contoh sederhana: 0 0 1 * * berjalan di NZDT (UTC+13) berarti Anda perlu menghitung ulang setiap bulan karena Anda harus menjalankannya pada hari terakhir bulan sebelumnya pukul 11:00 di UTC.

Jika kompleksitas jadwal Anda meningkat, jumlah perubahan yang perlu Anda buat agar tetap sinkron juga meningkat. Plus, Anda perlu mengubahnya setiap kali area zona waktu berubah dari DST ke ST.

Ini membuatnya sangat kompleks dan membuka banyak ruang untuk menjalankannya pada waktu yang salah atau bahkan mungkin lebih buruk; tidak semuanya.

Solusinya adalah menjalankan cron setiap jam "mungkin" tergantung pada zona waktu Anda dan lewati jika waktu saat ini bukan yang diharapkan. Saya berharap saya bisa melakukannya di level kubernetes.

Untuk DST ini berarti akan berjalan dua kali sehari daripada sekali dan melewatkan yang pertama atau yang kedua tergantung pada DST.

Misalnya, setiap distribusi Kubernetes yang patuh harus memiliki basis data zona waktu dan selalu memperbaruinya. Zona waktu, waktu musim panas, dan detail membuat ini berfungsi sementara detail dunia nyata dapat dan melakukan shift sulit. Ini akan menjadi pekerjaan tambahan untuk lebih dari 20 distribusi yang ada saat ini.

Basis data zona waktu, DST, dikelola dengan sangat baik oleh distribusi OS, yang harus diandalkan oleh distribusi kubernetes. Alasan "kerja keras untuk distribusi" bukanlah IMO yang valid.

Saya tidak akan membantah jika konsep itu disebut PeriodicJob atau RepeatingJob . Tetapi sebaliknya, ini disebut CronJob . Itu diikat dengan kalender dan jam. Tidak dapat disangkal bahwa kesadaran zona waktu adalah persyaratan penting untuk ini.

Solusi lain; mungkin masalahnya bisa diselesaikan dengan menghapus CronJob sepenuhnya dari kubernetes. Bukan berarti itu akan membantu siapa pun.

Solusi lain; mungkin masalahnya bisa diselesaikan dengan menghapus CronJob sepenuhnya dari kubernetes. Bukan berarti itu akan membantu siapa pun.

Setuju, jika mereka tidak dapat menerapkan solusi yang tepat di k8s, mereka tidak boleh menambahkan solusi sama sekali. Cronjob dirancang untuk bekerja dengan zona waktu, juga semua OS saat ini menangani zona waktu secara transparan dengan fungsi OS terkait.

Alasannya tampaknya tidak masuk akal, jika kita akan mengikuti logika ini maka harus ada banyak fitur yang ada di K8 yang seharusnya tidak ada.

Ini memang bug. Nama Cronjob itu sendiri menyesatkan karena tidak mengikuti spesifikasi Cron. Sebagian besar pengguna kubernetes akan menganggap dukungan Zona Waktu keluar dari kotak. Sangat mengecewakan bahwa pengembang inti memilih untuk tidak memasukkan ini. Masalah ini akan memengaruhi > 90% pengguna yang tidak beroperasi pada waktu UTC.

Saya akan mendorong untuk meninjau kembali ini. Satu masalah yang saya alami adalah saya ingin pekerjaan tertentu berjalan pada jam 1 pagi pada bulan pertama di Jepang - tentu saja kasus penggunaan yang masuk akal/standar. Mengingat bahwa cron didefinisikan dalam UTC, tidak ada cara bagi saya untuk menentukan ini; 0 0 1 * * akan berjalan pada jam 9 pagi waktu Jepang. (Akan lebih baik untuk menambahkan 0 0 L * * untuk hari terakhir bulan yang digunakan dalam beberapa implementasi cron)

@johnnyshields Anda mungkin harus meminta @soltysh untuk membuka kembali.

Meskipun saya ingin ini dipertimbangkan kembali, saya pikir peluangnya kecil. Tim berkumpul, mendiskusikannya dan memutuskan bahwa ini akan menyebabkan terlalu banyak pekerjaan tambahan. Ini bukan sesuatu yang telah berubah sejak saat itu, jadi keputusannya sepertinya juga tidak berubah.

Lihat saja (dan berkontribusi!) ke CronJobber https://github.com/hiddeco/cronjobber. Itu melakukan apa yang diinginkan semua orang.

PR yang didasarkan pada versi terbaru dari pengontrol CronJob akan sangat bagus tetapi berfungsi dengan baik seperti apa adanya.

Meskipun saya ingin ini dipertimbangkan kembali, saya pikir peluangnya kecil. Tim berkumpul, mendiskusikannya dan memutuskan bahwa ini akan menyebabkan terlalu banyak pekerjaan tambahan. Ini bukan sesuatu yang telah berubah sejak saat itu, jadi keputusannya sepertinya juga tidak berubah.

Mereka setidaknya harus konsisten dan menghapus implementasi cronjob saat ini karena itu sangat menyesatkan (untuk sedikitnya).

@mterron masalah dengan yang itu, apakah sudah ditambal hampir setahun yang lalu dan belum diperbarui sejak itu, sementara itu kami memiliki selusin rilis titik kubernet dengan peningkatan dan perbaikan keamanan. Jadi seseorang tidak dapat percaya diri menjalankan pengontrol basi bahwa mereka mendapatkan keuntungan dari semua perubahan dan fitur terbaru di kubernetes di area ini.

@AndrewSav dan itulah mengapa saya meminta bantuan untuk itu. Saya sudah melakukan semua yang saya bisa. Saya tidak yakin ada risiko keamanan dengannya, Kubernetes berubah setiap saat tetapi itu tidak berarti bahwa perubahan itu berarti dalam hal keamanan.

Karena itu, rebase akan keren, jangan ragu untuk berkontribusi dan membantunya.

@mterron Anda adalah penulisnya bukan? Jadi mengingat bahkan Anda tidak dapat menemukan waktu untuk melakukan itu, kecil kemungkinan orang akan berkontribusi pada sesuatu yang tidak lagi aktif. Akan sangat menyenangkan, saya setuju. Ketika proyek itu pertama kali didorong, saya secara singkat mempertimbangkan apakah saya bertaruh dan memasukkannya ke dalam kelompok saya, dan kemudian saya berpikir bahwa kemungkinan itu dipertahankan tidak besar. Sekarang setahun kemudian saya melihat saya tidak salah. Jadi saya berterima kasih atas pekerjaan Anda, tetapi saya khawatir dalam bentuknya yang sekarang ini tidak berkelanjutan.

Jika itu lepas landas dan seseorang terus secara konsisten mengubah dan mempertahankannya, itu akan luar biasa.

Tidak, saya bukan penulisnya. Saya hanya pengguna yang berkontribusi pada proyek yang saya gunakan saat saya bisa.
Saya mengerti dari mana Anda berasal, tetapi saya pikir harapan Anda sedikit tinggi untuk sesuatu yang dilakukan orang di waktu luang mereka untuk kepentingan komunitas.

@mterron Saya pikir saya sesuai dengan harapan saya. Jika ada, mereka rendah. Itulah alasan utama saya menahan diri untuk tidak menggunakan pekerjaan tertaut di kluster saya.

@AndrewSav Anda harus melakukan perbedaan antara cronjobber dan pengontrol cronjob hulu. Terakhir kali saya lakukan (1.17) tidak ada perbedaan. Pengontrol cronjob hulu secara efektif tidak dikelola menurut definisi Anda.

Pengontrol hulu juga memiliki karakteristik kinerja yang mengerikan, yang tentu saja diwariskan oleh cronjobber.

@benlangfeld

anda harus melakukan perbedaan antara cronjobber dan pengontrol cronjob hulu

Ini bukan tentang saya, ini tentang keberlanjutan untuk penggunaan umum. Hampir tidak masuk akal untuk meminta setiap pengguna potensial untuk melakukan diff. Bahkan jika itu adalah fakta bahwa tidak ada perubahan, yang ingin saya periksa lebih lanjut di bawah.

Pengontrol cronjob hulu secara efektif tidak dikelola menurut definisi Anda.

Ini bukan interpretasi yang adil dari apa yang saya katakan.

Tentang perbedaan: apa yang Anda bedakan dengan apa? Ada lebih dari 50 file dalam repo itu, dan tidak semua nama cocok dengan yang berasal dari sumber kubernetes. Bisakah Anda menjelaskan bagaimana kami bisa meyakinkan diri sendiri bahwa tidak ada perubahan? Lebih disukai sedikit lebih detail dari komentar Anda sebelumnya, karena tidak jelas. Khususnya, file mana di cabang/komit mana di setiap sisi yang telah Anda bandingkan, dan tidak mendeteksi adanya perubahan?

Mengingat partisipasi intensif dalam masalah ini, saya pikir wajar untuk meminta pertimbangan ulang untuk fitur inti Kubernetes.

Saya menemukan pernyataan berikut di atas penting: "Jika solusi diadopsi secara luas dan dapat digunakan oleh semua orang (termasuk skala kecil, multi-cluster, dll) maka itu dapat dipertimbangkan untuk Kubernet inti". Tampaknya ada solusi, mungkin belum sepenuhnya siap. Jadi, pernyataan tim inti bahwa use case diakui memenuhi syarat untuk inti K8 akan menjadi sinyal bagus bagi pengembang solusi ini untuk membuat mereka siap menerima permintaan tarik.

@AndrewSav sebagai penulis 'garpu', saya harus dengan hormat tidak setuju dengan apa pun yang Anda nyatakan sejauh ini, dan sebagai pengelola beberapa proyek OSS, saya terkejut dengan sikap Anda.

Pertama, cronjobber diturunkan dari pengontrol CronJob Kubernetes karena ini adalah perbaikan yang paling mudah, membutuhkan waktu paling sedikit untuk solusi yang matang (dan terbukti). Mengingat alasan yang disebutkan di bawah ini, saya tidak berharap hulu banyak berubah (juga tidak).

Kedua, pekerjaan spawning X pada waktu Y dengan memperhitungkan zona waktu Z bukanlah ilmu roket, spesifikasi untuk konsep waktu tidak berubah dalam beberapa tahun, dan seharusnya' t memerlukan pemeliharaan apa pun selain memastikannya masih dapat menelurkan pekerjaan asli Kubernetes pada waktu yang tepat (dan basis data zona waktu mutakhir, di mana ada pembantu yang tersedia berkat @mterron).

Selama itu mampu menelurkan pekerjaan ini, yang sangat mampu terakhir kali saya periksa, waktu saya lebih baik dihabiskan di tempat lain. Jika ini tidak memenuhi standar Anda, saya sarankan mempekerjakan seseorang untuk menulis dan memelihara solusi yang sama untuk Anda.

@hiddeco

Saya harus dengan hormat tidak setuju dengan apa pun yang Anda nyatakan sejauh ini

Apa pun? Itu pernyataan yang kuat.

Mengingat alasan yang disebutkan di bawah, saya tidak berharap hulu banyak berubah (juga tidak)

Ini mungkin tidak berubah _banyak_ tetapi juga tidak akan tetap statis. Tim kubernetes menyatakan bahwa mereka menginginkan solusi "yang diadopsi secara luas" sebelum "dapat dipertimbangkan untuk Kubernetes inti". Dalam pengalaman saya, solusi yang tidak dipertahankan secara aktif (tidak ada perubahan selama hampir satu tahun) jarang "diadopsi secara luas". Selain itu, sejauh ini tidak ada yang menunjukkan, bahwa pengontrol Kubernetes CronJob dan dependensinya tidak berubah sama sekali. Saya pribadi tidak dapat menemukan cara yang baik untuk membandingkan, semua file yang terpengaruh dan semua dependensi yang mendasarinya.

Kedua, memunculkan job X pada waktu Y dengan mempertimbangkan zona waktu Z bukanlah ilmu roket, spesifikasi untuk waktu konsep tidak berubah dalam beberapa tahun, dan tidak memerlukan pemeliharaan apa pun selain memastikannya masih dapat memunculkan job asli Kubernetes di waktu yang tepat (dan basis data zona waktu mutakhir, di mana ada pembantu yang tersedia berkat @mterron).

Ini terdengar terlalu optimis bagi saya. Ini jarang tentang perubahan "spesifikasi". Hal-hal kecil yang membunuhmu. Bug ditemukan terus-menerus, bahkan dalam proyek "dewasa dan terbukti waktu" dan diperbaiki. Menghasilkan pekerjaan mungkin bukan ilmu roket, tetapi mencari tahu bagaimana perubahan terkait dalam basis kode kubernetes memengaruhi perubahan Anda bisa menjadi rumit dengan cepat. Misalnya, selama tahun lalu upaya telah dilakukan untuk memindahkan api klien (kubectl) ke staging. Apakah itu mempengaruhi cron jobber? Saya tidak tahu. Versi pustaka cron yang digunakan telah diperbarui ke hulu. Apakah itu mempengaruhi cron jobber? Sekali lagi, saya tidak tahu.

Selama itu mampu menelurkan pekerjaan ini, yang sangat mampu terakhir kali saya periksa, waktu saya lebih baik dihabiskan di tempat lain.

Dan itu bagus. Anda sudah melakukan lebih dari yang harus Anda lakukan. Anda menggabungkan PR, dan Anda memublikasikan karya Anda untuk digunakan siapa saja. Terima kasih.

Jika ini tidak memenuhi standar Anda, saya sarankan mempekerjakan seseorang untuk menulis dan memelihara solusi yang sama untuk Anda.

Sekali lagi, ini bukan tentang saya, seperti yang saya jelaskan di komentar di atas. Ini tentang menjadi berguna untuk kelas orang yang lebih luas. Sepertinya saya mengulangi diri saya sekarang. Mungkin segalanya untuk mengatakan tentang topik itu sudah dikatakan? Bagaimana menurut anda?

Ini terdengar terlalu optimis bagi saya. Ini jarang tentang perubahan "spesifikasi". Hal-hal kecil yang membunuhmu. Bug ditemukan terus-menerus, bahkan dalam proyek "dewasa dan terbukti waktu" dan diperbaiki. Menghasilkan pekerjaan mungkin bukan ilmu roket, tetapi mencari tahu bagaimana perubahan terkait dalam basis kode kubernetes memengaruhi perubahan Anda bisa menjadi rumit dengan cepat. Misalnya, selama tahun lalu upaya telah dilakukan untuk memindahkan api klien (kubectl) ke staging. Apakah itu mempengaruhi cron jobber? Saya tidak tahu. Versi pustaka cron yang digunakan telah diperbarui ke hulu. Apakah itu mempengaruhi cron jobber? Sekali lagi, saya tidak tahu.

Sejujurnya ini datang kepada saya sebagai whatabouttisme yang mengakibatkan obstruksi. Logika ini dapat digunakan untuk membantah apa pun jadi saya tidak tahu apa yang ingin Anda capai di sini. Tidak ada yang benar-benar rumit tentang menjalankan cronjobs yang sadar zona waktu. Setiap sistem *nix utama (yang dijalankan oleh k8) telah memiliki dukungan zona waktu yang solid selama beberapa dekade (karena kejutan yang mengejutkan, sistem *nix telah sebagian besar berjalan di lingkungan server yang memiliki serangkaian kekhawatiran serupa selama 40+ tahun).

Sekali lagi, ini bukan tentang saya, seperti yang saya jelaskan di komentar di atas. Ini tentang menjadi berguna untuk kelas orang yang lebih luas. Sepertinya saya mengulangi diri saya sekarang. Mungkin segalanya untuk mengatakan tentang topik itu sudah dikatakan? Bagaimana menurut anda?

Dan seperti yang telah dinyatakan ad-mual, implementasi saat ini hampir tidak berguna karena sama sekali mengabaikan zona waktu sedangkan implementasi yang sadar zona waktu jauh lebih berguna untuk sekelompok orang yang lebih luas, apa gunanya Anda di sini?

Logika ini bisa digunakan untuk membantah apapun

Saya tidak berpikir itu bisa. Anda dipersilakan untuk mendemonstrasikannya, jika Anda mau, tetapi tetap berpegang pada apa yang dikatakan, bukan apa yang tersirat.

jadi saya tidak tahu apa yang ingin Anda capai di sini.

Oh, saya hanya menjawab komentar dari hiddeco yang ditujukan kepada saya, Anda dapat menemukannya di atas.

Dan seperti yang telah dinyatakan ad-mual, implementasi saat ini hampir tidak berguna karena sama sekali mengabaikan zona waktu sedangkan implementasi yang sadar zona waktu jauh lebih bermanfaat bagi orang-orang yang lebih luas.

Jika kita ulangi bahwa, untuk mengatakan bahwa Anda dan saya memiliki preferensi bahwa kubernetes cronjob mendukung zona waktu, itu akan benar. Saya menemukan "mendekati tidak berguna" agak terlalu kuat, tetapi saya sangat setuju bahwa implementasi sadar zona waktu yang didukung akan jauh lebih bermanfaat.

apa maksudmu disini?

Intinya adalah tidak ada bukti, bahwa "garpu" yang kita diskusikan "diterima secara luas", dan oleh karena itu kecil kemungkinan tim kubernetes akan menerimanya, yang sangat disayangkan, karena itulah yang ingin saya lakukan. lihat dimasukkan ke dalam kubernetes.

Bug ditemukan terus-menerus, bahkan dalam proyek "dewasa dan terbukti waktu" dan diperbaiki.

Pertama, kata "dewasa" dan "terbukti waktu" tidak memiliki tempat dalam kalimat tentang kubernetes, atau ekosistemnya.

Kedua, sejak kapan bug menjadi masalah di kubernetes? @fejta-bot hanya akan "memperbaiki" (menutup) mereka secara otomatis. Tidak perlu memikirkan bug. Semua baik-baik saja.

Saya ingin tahu kapan/jika ada pengelola yang peduli/berkomentar?

Saya pikir ini harus didokumentasikan di bawah https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#cron -job-limitations

Saya setuju bahwa " cronjobs " di kubernetes harus memiliki dukungan zona waktu karena kluster Kubernetes berjalan di Linux yang menyediakan ini. Apakah kami menolak gagasan ini karena beberapa pihak memiliki desain untuk menjalankan Kubernetes (atau varian) di Windows dalam waktu dekat? Alasan yang cukup lemah untuk menolak masalah ini jika terjadi. Tolong bisakah kita setidaknya menambahkan tag "triase/belum terselesaikan" untuk membedakan ini dari masalah yang telah diselesaikan?

Jika keputusannya adalah bahwa inti k8 tidak boleh diperluas ke fungsi ini, maka saya setuju dengan komentar di atas bahwa dukungan cronjob harus dihapus sehingga orang didorong untuk mengadopsi solusi ekosistem sesuai pilihan mereka. Ini benar-benar menonjol sebagai sesuatu di k8s inti yang tidak eksplisit tentang hasil yang diinginkan, dan yang membuat orang tersandung.

Sejak Go 1.15 sekarang telah mendapatkan paket time/tzdata di perpustakaan intinya, mungkin …?

Bagaimana saya bisa menyediakan cluster saya secara berlebihan pada jam 7 pagi hingga jam 7 malam?
Di mana pengguna saya berada, ada waktu musim panas dan waktu musim dingin.
Jadi saya tidak bisa mengandalkan itu sama sekali.

TIDAK mengelola zona waktu dengan cronjobs adalah keputusan yang sangat aneh yang Anda ambil.

Kami menemukan solusi yang baik untuk masalah ini: berhenti menggunakan K8s CronJobs dan gunakan Apache Airflow sebagai gantinya.

Hidup menjadi jauh lebih baik sejak kami melakukannya. Bergabunglah dengan kami!

Masalah ini diselesaikan secara eksternal di sana: https://github.com/hiddeco/cronjobber

@mattfarina

1. Jika solusi diadopsi secara luas dan dapat digunakan oleh semua orang (termasuk skala kecil, multi-cluster, dll) maka solusi tersebut dapat dipertimbangkan untuk Kubernetes inti

Bagaimana, dan kapan, adopsi solusi komunitas diukur?

https://github.com/kubernetes/enhancements/pull/1996

@mattfarina @soltysh sekarang dengan KEP-19: Luluskan CronJob ke stable , yang menyebutkan zona waktu sebagai salah satu peningkatan untuk dipertimbangkan, disetujui dan digabungkan dan pekerjaan pada pengontrol cronjob v2 sedang dalam proses, dapatkah masalah ini dibuka kembali dan dipertimbangkan kembali?

Disebutkan ini sebagai pertimbangan/kemungkinan perbaikan. Itu tidak menjamin apakah atau kapan ini akan didekati. Saya dapat mengatakan dengan jaminan 100% itu tidak akan terjadi sebelum CronJob GA, yang akan mengambil ini dan 2 rilis lainnya.

@soltysh Masih bisa didiskusikan dengan baik. Telah ditunjukkan secara luas bahwa ini adalah fitur yang diperlukan. Desakan untuk menendang bola di jalan ini menunjukkan keterputusan yang sangat besar antara pengelola dan pengguna.

@benlangfeld Saya sangat terbuka untuk ini, tetapi waktu adalah faktor pembatas utama di sini :kecewa:

@benlangfeld Saya sangat terbuka untuk ini, tetapi waktu adalah faktor pembatas utama di sini

Sudah ada perbaikan yang diusulkan. Masukan apa yang Anda butuhkan agar ini diterima?

Pengontrol sedang ditulis ulang, itulah fokus utama saat ini. Perubahan hanya dapat dilakukan dengan pengontrol baru. Tidak ada gunanya mengubah yang lama yang dimaksudkan untuk diganti.