Kubernetes: CronJobsはタイムゾーンをサポートする必要があります

@iterionこの問題に関するsigラベルはありません。 次の方法でsigラベルを追加してください。
（1）シグに言及する： @kubernetes/sig-<team-name>-misc
（2）ラベルを手動で指定する： /sig <label>

_注：方法（1）は、チームへの通知をトリガーします。 チームリストはここにあり、ラベルリストはここにあります_

/ sigアプリ

私にはもっと自然に見えるので、2番目のオプションを好む

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

私も2番目の形式が好きですが、実装への最も簡単な方法は、その時間を取り除いて別々に使用することだと思われます。 また、「標準の」cronテンプレートを使用しているので、それを台無しにすべきではないという議論をすることもできます。

これは簡単に実装できるようです。
現在、time.Now（）をsyncOneループに渡すだけです。 k8sが使用しているcronlibは、気になるゾーンの時間を使用するだけで機能するようです。 したがって、CronJobからタイムゾーンを取得し、その時間をゾーンで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)

また、これを実装してみてうれしいです。

私はあなたのPRをレビューするのにふさわしい人物ではありませんが、セマンティクスについていくつか質問があります。

• タイムゾーンが指定されていない場合のセマンティクスは何ですか？
• 実装は、コントローラーホストで正しく構成されているタイムゾーンに依存しますか？
• タイムゾーンの合法性はいつ検証されますか？ オブジェクトの作成/更新時、またはそれ以降？
• APIオブジェクトが作成されたときにタイムゾーン名が有効であったが、将来は存在しなくなった場合はどうなりますか？ これは、名前が削除されたため（都市または国が存在しなくなった場合）、または基になるtzdataパッケージが古いバージョンに変更されたために発生する可能性があります。

タイムゾーンが定義されていない場合、デフォルトで現在の動作になり、ホストのタイムゾーンが使用されます。 ほとんどの場合、これはUTCとして構成されると思いますが、ユーザーは実際には任意のタイムゾーンを選択できます。 そのため、このPRの結果として、ホスト上で正しく構成されているタイムゾーンに大きく依存することはありません。

現在、ユーザーが無効なものを指定した場合は、ホストのタイムゾーンを使用してベイルアウトします。 ここでは、golangのtime.LoadLocation（str）メソッドに

最後の質問に関しては、それはもう少し未定義です。 現在、そしておそらく将来的には、デフォルトのタイムゾーンに基づいてジョブをスケジュールすることにフォールバックする可能性があります。 私はこの事件をどのように扱うかについての提案を受け入れています。

APIオブジェクトが作成されたときにタイムゾーン名が有効であったが、将来は存在しなくなった場合はどうなりますか？ これは、名前が削除されたため（都市または国が存在しなくなった場合）、または基になるtzdataパッケージが古いバージョンに変更されたために発生する可能性があります。

そのための私の提案は、適切なイベントでジョブの作成に失敗することです。 しかし率直に言って、私はこれがそれほど頻繁に起こるとは思えません。 これを実装@iterionに必ず追加します。

およびcron形式は、提出された年をサポートしていません。指定された時間に1回だけジョブを実行する方法は？

：+1：

@iterion問題とプルリクエストをありがとう。 SIG AppsとSIGArchitectureの両方で、この1週間でかなり議論しました。 ユースケースはこれが理にかなっている場合に役立つ可能性がありますが、欠点についても説明する必要がありました。 たとえば、準拠しているすべてのKubernetesディストリビューションには、タイムゾーンデータベースがあり、最新の状態に保つ必要があります。 タイムゾーン、夏時間、および現実世界の詳細がシフトできる一方で、この作業を機能させるための詳細は困難です。 これは、現在存在する20を超えるディストリビューションの追加作業になります。

同時に、Kubernetesの開発にも変化がありました。 それがどれほど広く伝達されているかはわかりません（伝達はSIGアーキテクチャで議論されたもう1つのポイントでした）。 シフトは、コアKubernetesに安定性とゆっくりとした動きに焦点を合わせてもらいたいという願望です。 現在、人々は、コアではなく、エコシステムにおけるこの種の問題を革新し、解決することが奨励されています。

これをKubernetesに配置する代わりに、次のことを行います。

1. 他の人が使用できるエコシステム（コントローラーなど）でこれを開発します。 それを配布し、そこで問題を解決し、更新がどのように見えるかを確認します
2. このソリューションが広く採用されており、すべてのユーザー（小規模、マルチクラスターなどを含む）で使用できる場合は、コアKubernetesを検討することができます。

それが役立つ場合は、これが同じ方向性を受け取っている機能だけではありません（同じSIGアーキテクチャ会議でも）。 私はこれをワードプレスのようなものと同じように考え始めています（これは非常に一般的な例であるため、ワードプレスを使用します）。 プラグインであることとワードプレス自体の一部であることには違いがあります。 現在の方向性は、いわばプラグインの革新を促進することです。

このようなものを作成する場合は、SIG Appsでデモを行い、人々に紹介してもらいたいと思います。 コミュニティミーティングでデモを行うこともできます。

ご不明な点がございましたら、お気軽にお問い合わせください。

前のコメントを考えると、この問題を解決できると思います。 同意できない場合は、お気軽に再開してください。

FWIW、「タイムゾーンを設定する方法」は、CronJobを作成するすべてのユーザー（開発者と管理者）から尋ねられます。

@iterionこれ

• 修正を加えたkubernetesのフォークから実行
• cronコントローラーコードを外部コントローラーにコピーし、別のapiVersionを使用して2つを区別します。
• kube cronjobコントローラーの実装を反映しているが、CronJobリソースではなくアプリ固有の構成ファイルに基づいて、Rubyでプロジェクトに固有の何かを構築します。

私たちが出発点として使用できる何かがすでにあなたのために働いている場合、または@mattfarinaがこれを含めることを許可しないという彼の決定を覆すように促すのに

私は実際に新しい仕事に転向したので、個人的には元の問題はもう存在しません。 私の知る限り、以前の同僚はそれから生じる痛みに対処しているだけです。

とは言うものの、これに専念する時間があれば、必要に応じてCronJobsを監視および変更する小さなコントローラーを作成する可能性があります。 希望する時間とタイムゾーンでCronJobsに注釈を追加し、コントローラーにそのスケジュールをUTCにキャストさせ、CronJobsを変更するだけです。 この同期ループを一定の間隔で実行して、問題のあるエッジをキャッチすることができます。つまり、夏時間が開始または終了するときです。 このように、コントローラーは、既存のCronJobAPIの上にある非常にスリムなラッパーになります。

@mattfarinaに、これを含めることを許可しないという彼の決定を覆すように勧め

明確にするために、この決定は、sig-architecture会議の1つでまとめて行われました。 マットは、この問題でその決定を表明した唯一の人物でした。

Linuxの世界では、すべてのベルとホイッスルを使用するタイムゾーンの問題は長い間解決されてきました。 これがKubernetesデプロイメントの前提条件の多くであるのはなぜですか？

私が認めるユースケースの重要性について議論するのは難しいです。 ただし（そして私の謙虚な意見では）、サービスのユーザーと同期してサービスをスケジュールできることは、Kubernetesコアの資格を得るのに十分重要であるように思われます。

TimezoneAwareCronjobControllerを使用してオペレーターを作成することをいとわない人はいますか？ @iterionによって記述されたコードのほとんどは、おそらくリサイクルできます。
TZ処理をパッケージ化されたアプリケーションに移動すると、Kubernetesでのファーストクラスのcronジョブサポートを無効にする配布引数が解決されます。

FWIW、 https： //gopkg.in/robfig/cron.v2（既存のコントローラーが使用する古いサブセット）は、TZの受け渡しと、わずかに豊富な時間定義のセットをサポートしています。
内部ワークロードの一部に対してcronジョブを作成するコントローラーが内部にあり、それらのタイムゾーンを指定できることは優れた機能要求です。 誤ってジョブをスキップしたり、ジョブを再実行したりせずに、既存のcronジョブ定義を安全に更新する方法を検討する必要があります。 この時点で、既存のコントローラーからジョブスケジューリングを盗み出し、（cronjobよりも）ジョブ定義を直接作成する方が実際には簡単であるように感じます。

K8sを使い始めてから、年に2回この問題に戻ります。この問題は、すべてのCronJobのスケジュールを変更せざるを得なくなり、ようやく再開されることを望んでいます。 クロノスとcrontabに機能がある場合、K8sはまだこれをサポートしていませんか？

長期的な問題（自己メモ）

うまくいけば、この問題が再開され、UTC時刻を毎日見るのは少し奇妙です。

毎月1日の現地時間に実行する必要のあるcronジョブがありますが、UTC時間は先月の最終日の16:00です。 先月の最終日を定義するにはどうすればよいですか？ CronjobはLをサポートしていません。

代替ソリューションが存在しないようです。 こことここで私の質問を参照してください

まだこれを待っている人のために; ネイティブのKubernetescronjobコントローラーと閉じられた元のPRから派生したコントローラーを作成しました。

https://github.com/hiddeco/cronjobber

編集（2019年5月12日）：@mterronのおかげで、Cronjobberは今サイドカーを使用して、ホストの独立したタイムゾーンデータベースをサポートしています。

@hiddeco既存のコントローラーを変更するのではなく、コントローラー制御の標準CJコントローラーを使用する方がよいでしょうか。 後者のアプローチでは、実際のCJコントローラーの変更に対応する必要がありますが、これは常に実行可能とは限りません。 お疲れ様でした。

@andrewsavは望ましいですが、実行できません。 既存のCJコントローラーを「制御」する唯一の方法は、 CronJobのスケジュールをタイムゾーンのオフセットに変更することです。 考えられるすべてのスケジュールの組み合わせに対してそれを行う方法はありません。

とにかくCJコントローラーに多くの変更が加えられることは期待していません。さらに、自己完結型であるため、CJコントローラーとの同期を維持して実行を継続する義務はありません（クライアントへの依存とJob仕様を除く） 。

@hiddeco

考えられるすべてのスケジュールの組み合わせに対してそれを行う方法はありません。

これを説明してもらえますか？

@AndrewSavの簡単な例： 0 0 1 * * NZDT （UTC + 13）で実行されている0 0 1 * *は、前月の最終日に実行する必要があるため、毎月再計算する必要があることを意味します。 UTCの午前11時。

スケジュールの複雑さが増すと、同期を維持するために必要な変更の量も増えます。 さらに、タイムゾーン領域がDSTからSTに変更されるたびに変更する必要があります。

これはそれを非常に複雑にし、間違った時間に、あるいはさらに悪いことにそれを実行するために多くのスペースを開きます。 全くない。

解決策は、タイムゾーンに応じて「可能な」時間ごとにcronを実行し、現在の時刻が予期された時刻でない場合はスキップすることです。 でも、kubernetesレベルでそれができたらいいのにと思います。

DSTの場合、これは1日1回ではなく1日2回実行され、DSTに応じて最初の1つまたは2番目の1つをスキップすることを意味します。

たとえば、準拠しているすべてのKubernetesディストリビューションには、タイムゾーンデータベースがあり、最新の状態に保つ必要があります。 タイムゾーン、夏時間、および現実世界の詳細がシフトできる一方で、この作業を機能させるための詳細は困難です。 これは、現在存在する20を超えるディストリビューションの追加作業になります。

タイムゾーンデータベース（DST）は、kubernetesディストリビューションが依存する必要があるOSディストリビューションによって非常によく維持されます。 「配布には大変な作業です」という言い訳は、有効なIMOではありません。

コンセプトがPeriodicJobと呼ばれたのかRepeatingJobと呼ばれたのかについては議論しません。 ただし、代わりにCronJobと呼ばれます。 それはカレンダーと時計と結びついています。 タイムゾーンの認識がこのための重要な要件であることは否定できません。

別の解決策; おそらく、kubernetesからCronJobを完全に削除することで、問題を解決できる可能性があります。 それが誰かを助けるというわけではありません。

別の解決策; おそらく、kubernetesからCronJobを完全に削除することで、問題を解決できる可能性があります。 それが誰かを助けるというわけではありません。

同意しました。k8sで適切なソリューションを実装できない場合は、ソリューションをまったく追加しないでください。 Cronjobはタイムゾーンで動作するように設計されており、現在のすべてのOSは、関連するOS関数でタイムゾーンを透過的に処理します。

推論は首尾一貫していないようです。このロジックを使用する場合、K8には存在してはならない機能がたくさんあるはずです。

これは確かにバグです。 Cronjobという名前自体は、Cronの仕様に準拠していないため、誤解を招く恐れがあります。 ほとんどのkubernetesユーザーは、タイムゾーンのサポートがすぐに利用できると想定します。 コア開発者がこれを含めないことを選択したのは残念です。 この問題は、UTC時間で操作しないユーザーの90％以上に影響するはずです。

これを再検討したいと思います。 私が抱えている問題の1つは、日本で月の最初の午前1時に特定のジョブを実行したいということです。これは確かに合理的/標準的なユースケースです。 cronがUTCで定義されていることを考えると、これを指定する方法はありません。 0 0 1 * *は日本時間の午前9時に実行されます。 （一部のcron実装で使用される月の最後の日に0 0 L * *を追加することもできます）

@johnnyshieldsおそらく@soltyshに再開するように依頼する必要があります。

これを再考したいのですが、チャンスは少ないと思います。 チームは集まって話し合い、これにより追加の作業が多すぎると判断しました。 それ以来、これは変わっていないので、決定も変わっていない可能性があります。

CronJobber https://github.com/hiddeco/cronjobberをご覧ください（そして貢献してください！）

最新バージョンのCronJobコントローラーに基づいたPRは素晴らしいですが、そのままで完全に機能します。

これを再考したいのですが、チャンスは少ないと思います。 チームは集まって話し合い、これにより追加の作業が多すぎると判断しました。 それ以来、これは変わっていないので、決定も変わっていない可能性があります。

その場合、少なくとも一貫性があり、cronjobの現在の実装を削除する必要があります。これは、非常に誤解を招くためです（控えめに言っても）。

@mterronの問題は、ほぼ1年前にパッチが適用され、更新されていないことです。その間に、改善とセキュリティ修正が行われたkubernetesのポイントリリースが多数ありました。 そのため、この領域のkubernetesのすべての最新の変更と機能を利用していることを、古いコントローラーを実行することに自信を持てません。

@AndrewSavそしてそれが私がそれについて助けを求めていた理由です。 私はできる限りのことをしました。 セキュリティ上のリスクがあるかどうかはわかりませんが、Kubernetesは常に変更されますが、セキュリティの意味で変更が意味を持つという意味ではありません。

そうは言っても、リベースはクールです。気軽に貢献して支援してください。

@mterronあなたはその作者ですよね？ ですから、それをする時間が見つからなくても、人々がもはや活動していない何かに貢献する可能性は低いです。 でも、とてもいいと思います、私は同意します。 そのプロジェクトが最初にプッシュされたとき、私はそれをギャンブルしてクラスターに入れるかどうかを簡単に考えましたが、それが維持される可能性は高くないと思いました。 一年後、私は間違っていなかったことがわかりました。 ですから、あなたの仕事に感謝しますが、現在の形では持続可能ではないのではないかと心配しています。

それがうまくいき、誰かが一貫してそれをリベースして維持し続けるなら、それはただ素晴らしいでしょう。

いいえ、私は著者ではありません。 私は、できる限り使用するプロジェクトに貢献するユーザーです。
あなたがどこから来たのかはわかりますが、コミュニティの利益のために人々が暇なときに行うことに対するあなたの期待は少し高いと思います。

@mterron私は私の期待と同じレベルにあると思います。 どちらかといえば、彼らは低いです。 それが、私が自分のクラストでリンクされた作品を使用することを控えた主な理由です。

@AndrewSavは、cronjobberとアップストリームのcronjobコントローラーの間で差分をとる必要があります。 前回（1.17）行ったときは違いはありませんでした。 アップストリームのcronjobコントローラは、定義によって事実上維持されていません。

アップストリームコントローラには、もちろんcronjobberが継承する恐ろしいパフォーマンス特性もあります。

@benlangfeld

cronjobberとアップストリームのcronjobコントローラーを比較する必要があります

それは私についてではなく、一般的な使用のために持続可能であるということです。 すべての潜在的なユーザーに差分を要求することはほとんど合理的ではありません。 変更がなかったのは事実ですが、以下でさらに検討したいと思います。

アップストリームのcronjobコントローラは、定義によって事実上維持されていません。

これは私が言ったことの公正な解釈ではありません。

相違について：あなたは何と何を相違していますか？ そのリポジトリには50を超えるファイルがあり、すべての名前がkubernetesソースの名前と一致するわけではありません。 変化がなかったことをどうやって納得させることができるか説明できますか？ 明らかではないので、前のコメントよりももう少し詳細にすることが望ましいです。 特に、それぞれの側のどのブランチ/コミットでどのファイルを比較し、変更を検出しませんでしたか？

この問題に集中的に参加していることを考えると、Kubernetesのコア機能の再検討を要求するのは公平だと思います。

上記の次のステートメントが重要だと思います。「ソリューションが広く採用され、すべてのユーザー（小規模、マルチクラスターなどを含む）で使用できる場合は、コアKubernetesと見なすことができます」。 解決策があるようですが、まだ完全には準備ができていない可能性があります。 したがって、ユースケースがK8sコアに適格であると認められているというコアチームの声明は、プルリクエストの準備をするためのこれらのソリューションの開発者への素晴らしいシグナルになります。

「フォーク」の作者としての@AndrewSav私はあなたがこれまでに述べたことに敬意を表して反対しなければなりません、そして複数のOSSプロジェクトのメンテナーとして私はあなたの態度に驚いています。

まず、cronjobberはKubernetes CronJobコントローラーから派生したものです。これは、最も簡単な修正であり、成熟した（そして実績のある）ソリューションに必要な時間が最短であるためです。 下記の理由から、上流が大きく変わるとは思っていませんでした（また、変化もありません）。

第二に、タイムゾーンZを考慮しながら時間YジョブXを生成することはロケット科学ではなく、概念時間の仕様は何年も変わっていないので、すべきではありません。適切なタイミングでKubernetesネイティブジョブを生成できるようにする以外のメンテナンスが必要です（タイムゾーンデータベースは最新であり、@ mterronのおかげでヘルパーを利用できます）。

前回チェックしたときに完全に可能であるこれらのジョブを生成できる限り、私の時間は他の場所で費やしたほうがよいでしょう。 これがあなたの基準を満たしていない場合、私はあなたのために同様の解決策を書いて維持するために誰かを雇うことを提案します。

@hiddeco

私はあなたがこれまでに述べたことに敬意を表して反対しなければなりません

なんでも？ それは強い声明です。

下記の理由から、上流が大きく変わるとは思っていませんでした（また、変化もありません）。

変更されない可能性がありますが、静的なままにはなりません。 kubernetesチームは、「コアKubernetesで検討できる」前に、「広く採用されている」ソリューションが必要であると述べました。 私の経験では、積極的に維持されていない（ほぼ1年間変更がない）ソリューションが「広く採用」されることはめったにありません。 さらに、これまでのところ、KubernetesCronJobコントローラーとその依存関係がまったく変更されていないことを示す人は誰もいません。 私は個人的に、影響を受けたすべてのファイルとすべての基礎となる依存関係を比較する良い方法を理解することはできません。

次に、タイムゾーンZを考慮しながら時間YでジョブXを生成することはロケット科学ではなく、コンセプト時間の仕様は何年も変更されておらず、Kubernetesネイティブジョブを生成できることを確認する以外のメンテナンスは必要ありません。適切なタイミング（およびタイムゾーンデータベースは最新であり、@ mterronのおかげでヘルパーを利用できます）。

これは私には過度に楽観的に聞こえます。 これはめったに「仕様」の変更に関するものではありません。 あなたを殺すのは小さなことです。 バグは、「成熟していて実績のある」プロジェクトでも常に発見され、修正されます。 仕事を生み出すことはロケット科学ではないかもしれませんが、kubernetesコードベースの関連する変更が変更にどのように影響するかを見つけることは、すぐに難しい場合があります。 たとえば、昨年はクライアントAPI（kubectl）をステージングに移行する取り組みが行われました。 cronジョブバーに影響しますか？ わからない。 使用されているcronライブラリのバージョンがアップストリームで更新されました。 cronジョブバーに影響しますか？ 繰り返しますが、わかりません。

前回チェックしたときに完全に可能であるこれらのジョブを生成できる限り、私の時間は他の場所で費やしたほうがよいでしょう。

そして、それは大丈夫です。 あなたはすでにあなたがしなければならなかったより多くをしました。 PRを統合し、誰でも使用できるように作品を公開しました。 ありがとう。

これがあなたの基準を満たしていない場合、私はあなたのために同様の解決策を書いて維持するために誰かを雇うことを提案します。

繰り返しますが、上記のコメントで説明したように、これは私のことではありません。 それは、より幅広いクラスの人々に役立つことです。 今、繰り返しているようです。 トピックについて言うことはすべてすでに言われたのでしょうか？ どう思いますか？

これは私には過度に楽観的に聞こえます。 これはめったに「仕様」の変更に関するものではありません。 あなたを殺すのは小さなことです。 バグは、「成熟していて実績のある」プロジェクトでも常に発見され、修正されます。 仕事を生み出すことはロケット科学ではないかもしれませんが、kubernetesコードベースの関連する変更が変更にどのように影響するかを見つけることは、すぐに難しい場合があります。 たとえば、昨年はクライアントAPI（kubectl）をステージングに移行する取り組みが行われました。 cronジョブバーに影響しますか？ わからない。 使用されているcronライブラリのバージョンがアップストリームで更新されました。 cronジョブバーに影響しますか？ 繰り返しますが、わかりません。

正直なところ、これは閉塞主義をもたらすwhatabouttismとして私に来ます。 この論理は何に対しても議論するために使用できるので、あなたがここで何を達成しようとしているのか私にはわかりません。 タイムゾーンに対応したcronジョブの実行について、それほど複雑なことはありません。 主流の* nixシステム（k8が実行されているもの）は、何十年にもわたって堅実なタイムゾーンをサポートしてきました（驚いたことに、* nixシステムは主にサーバー環境で実行されており、40年以上にわたって同様の懸念事項があります）。

繰り返しますが、上記のコメントで説明したように、これは私のことではありません。 それは、より幅広いクラスの人々に役立つことです。 今、繰り返しているようです。 トピックについて言うことはすべてすでに言われたのでしょうか？ どう思いますか？

そして、うんざりして述べたように、現在の実装はタイムゾーンを完全に無視しているため、ほとんど役に立たないところですが、タイムゾーンを認識している実装は、より多くの人々にとってはるかに有用ですが、ここでのポイントは何ですか？

この論理は、何に対しても反論するために使用できます

私はそれができないと思います。 よろしければ、それをデモンストレーションすることを歓迎しますが、暗示されている可能性があることではなく、言われていることに固執してください。

だから私はあなたがここで何を達成しようとしているのか分かりません。

ああ、私は私に向けられたhiddecoからのコメントに答えているだけです、あなたはそれを上で見つけることができます。

そして、うんざりして述べたように、現在の実装はタイムゾーンを完全に無視するため、ほとんど役に立たないが、タイムゾーンを意識した実装は、より多くの人々にとってはるかに有用である。

言い換えると、あなたと私はkubernetes cronjobがタイムゾーンをサポートすることを好みますが、それは正しいことです。 「役に立たない」というのは少し強すぎると思いますが、サポートされているタイムゾーン対応の実装の方がはるかに便利であることに強く同意します。

ここであなたのポイントは何ですか？

重要なのは、私たちが議論している「フォーク」が「広く採用されている」という証拠がないため、kubernetesチームがそれを採用する可能性が低いということです。これは本当に残念なことです。 kubernetesに組み込まれているを参照してください。

バグは、「成熟していて実績のある」プロジェクトでも常に発見され、修正されます。

まず、「成熟した」および「実績のある」という言葉は、kubernetesまたはそのエコシステムについての文には含まれていません。

第二に、バグがkubernetesで問題になるのはいつからですか？ @ fejta-botは、それらを自動的に「修正」（クローズ）します。 バグについて考える必要はありません。 すべては順調です。

いつ/誰かのメンテナが気にかける/コメントするのだろうか？

これはhttps://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#cron-job-limitationsで文書化する必要があると思います

KubernetesクラスターはLinux上で実行されるため、kubernetesの「 cronjobs 」はタイムゾーンをサポートする必要があることに同意します。 遠い将来、WindowsでKubernetes（またはバリアント）を実行する設計をしているパーティがあるため、この概念を拒否していますか？ 場合によっては、この問題を拒否するかなり弱い理由。 これを解決済みの問題と区別するために、少なくとも「トリアージ/未解決」タグを追加できますか？

コアk8をこの機能に拡張しないという決定が下された場合、ユーザーが選択したエコシステムソリューションを採用するように促すために、cronjobサポートを削除する必要があるという上記のコメントに同意します。 これは、コアk8の中で、意図した結果について明確ではなく、人々をつまずかせる何かとして実際に目立ちます。

Go 1.15以降、コアライブラリにtime/tzdataパッケージが含まれている可能性がありますが、おそらく…？

朝の7時から夕方の7時にクラスターをオーバープロビジョニングするにはどうすればよいですか？
私のユーザーがいるところには、夏時間と冬時間があります。
だから私はそれをまったく信頼できません。

cronjobsでタイムゾーンを管理しないことは、非常に奇妙な決断でした。

この問題の適切な回避策が見つかりました。K8sCronJobsの使用を中止し、代わりにApacheAirflowを使用してください。

私たちがやって以来、人生はずっと良くなりました。 参加しませんか！

この問題は外部で解決されています： //github.com/hiddeco/cronjobber

@mattfarina

1. このソリューションが広く採用されており、すべてのユーザー（小規模、マルチクラスターなどを含む）で使用できる場合は、コアKubernetesを検討することができます。

コミュニティソリューションの採用は、いつ、どのように測定されますか？

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

@mattfarina @soltyshがKEP-19に追加されました：CronJobからstableへの移行。検討対象の改善の1つとしてタイムゾーンが承認され、マージされ、 cronjobコントローラーv2の作業が進行中ですが、この問題を再開して再検討できますか？

これは、考慮事項/改善の可能性として言及されています。 これに近づくかどうか、またいつ近づくかは保証されません。 私は100％の保証で、これとさらに2つのリリースが必要なCronJobGAの前にそれが起こらないと言うことができます。

@soltyshそれでも適切に議論することができます。 これが必要な機能であることが広く実証されています。 これでボールを蹴り飛ばすという主張は、メンテナとユーザーの間の大きな断絶を示しています。

@benlangfeld私はこれに対して非常にオープンですが、ここでの主な制限要因は時間です：失望：

@benlangfeld私はこれに対して非常にオープンですが、ここでは時間が主な制限要因です😞

すでに提案された修正があります。 これを受け入れるには、どのような入力が必要ですか？

コントローラーは書き直されており、それが現在の主な焦点です。 変更は、新しいコントローラーでのみ可能になります。 交換する予定の古いものを変更するのは無意味です。