LyftがKubernetesCronJobsを改善した方法と理由

約transl。この記事は、もともと2部構成で、LyftのソフトウェアエンジニアであるKevin Yangによって書かれました。これは、少なくともEnvoyの作成でKubernetesコミュニティでよく知られています。新しい資料では、著者は、多数の従来のcronタスクをLinuxからK8のCronJobsに移行するという興味深い経験を共有しています。これがLyft全体でどのような問題を引き起こし、会社のエンジニアがどのように解決したかを詳細に知ることができます。







Lyftは、自動化が提供するメリットを活用するために、サーバーインフラストラクチャを分散コンテナオーケストレーションシステムであるKubernetesに移動することを決定しました。彼らは、さらなる開発の基盤となるだけでなく、効率を高めながら全体的なコストを削減できる、堅牢で信頼性の高いプラットフォームを望んでいました。



分散システムは理解と分析が難しい場合があり、Kubernetesも例外ではありません。多くの利点があるにもかかわらず、スケジュールに従って反復的なタスクを実行するためにKubernetesに組み込まれているシステムであるCronJobに移行するときに、いくつかのボトルネックを特定しました。この2部構成のシリーズでは、大規模なプロジェクトで使用した場合のKubernetes CronJobの技術的および運用上の欠点について説明し、それらを克服した経験を共有します。



まず、Lyftで使用したときに遭遇したKubernetesCronJobsの欠点について説明します。次に（第2部）-Kubernetesスタックのこれらの欠点を解消し、使いやすさを向上させ、信頼性を向上させた方法を説明します。

パート1。はじめに

これらの記事から誰が恩恵を受けますか？

• KubernetesCronJobユーザー。
• , Kubernetes.
• , Kubernetes .
• , Kubernetes , .
• Contributor' Kubernetes.

?

• , Kubernetes ( , CronJob) .
• , Kubernetes Lyft , .

:

• cron'.
• , CronJob, — , CronJob, Job' Pod', . CronJob Unix cron' .
• sidecar- , . Lyft sidecar- , runtime- Envoy, statsd .., sidecar-, , .

• ronjobcontroller — Kubernetes, CronJob'.
• , cron , ( ).
• Lyft Engineering , ( «», « », « ») — Lyft ( «», « », «» «»). , , «-» .

CronJob' Lyft

現在、マルチテナントの実稼働環境には、1時間に1500回以上呼び出される500近くのcronジョブがあります。



定期的なスケジュールされたタスクは、Lyftによってさまざまな目的で広く使用されています。 Kubernetesに移行する前は、通常のUnixcronを使用してLinuxマシンで直接実行していました。開発チームは、crontab定義を記述し、Infrastructure As Code（IaC）パイプラインを使用してそれらを実行するインスタンスをプロビジョニングする責任があり、インフラストラクチャチームはそれらを維持する責任がありました。



ワークロードをコンテナ化して独自のKubernetesプラットフォームに移行するためのより大きな取り組みの一環として、CronJob *に移行し、従来のUnixcronを対応するKubernetesに置き換えることにしました。他の多くの人と同様に、Kubernetesは、リソースの効率的な使用など、（少なくとも理論的には）その大きな利点のために選択されました。



週に1回15分間実行されるcronタスクを想像してみてください。古い環境では、このタスク専用のマシンは99.85％の時間アイドル状態になります。 Kubernetesの場合、計算リソース（CPU、メモリ）は通話中にのみ使用されます。残りの時間は、未使用の容量を使用して他のCronJobを起動したり、単にスケールダウンしたりできます。集まる。 cronジョブを実行する過去の方法を考えると、ジョブが一時的なモデルに移行することで多くのメリットが得られます。





Lyftスタック内の開発者とプラットフォームエンジニアの責任境界



Kubernetesプラットフォームに移行した後、開発チームは独自のコンピューティングインスタンスの割り当てと運用を停止しました。プラットフォームチームは現在、Kubernetesスタックの計算リソースとランタイム依存関係の維持と運用を担当しています。さらに、彼女はCronJobオブジェクト自体を作成する責任があります。開発者は、タスクスケジュールとアプリケーションコードを構成するだけで済みます。



しかし、それはすべて紙の上でよく見えます。実際には、十分に研究された従来のUnix cron環境から、Kubernetesの分散型の一時的なCronJob環境に移行する際に、いくつかのボトルネックを特定しました。



* CronJobは（Kubernetes v1.18の時点で）ベータ版のステータスでしたが、当時のニーズを十分に満たし、他のKubernetesインフラストラクチャツールキットとも完全に適合していることがわかりました。 ..。

KubernetesCronJobはUnixcronとどのように異なりますか？

KubernetesCronJobの作業に関連するイベントとK8sソフトウェアコンポーネントの簡略化されたシーケンス



実稼働環境でのKubernetesCronJobの操作が特定の問題に関連する理由をよりよく説明するために、まず、それらが従来のものとどのように異なるかを定義しましょう。CronJobは、LinuxまたはUnixのcronジョブと同じように機能するはずです。ただし、実際には、動作には少なくとも2つの大きな違いがあります。起動速度とクラッシュ処理です。

起動速度

遅延開始 （開始遅延）は、スケジュールされた開始cronからアプリケーションコードの実際の開始までの経過時間として定義されます。つまり、cronが00:00:00に開始するようにスケジュールされていて、アプリケーションが00:00:22に実行を開始した場合、その特定のcronの開始の遅延は22秒になります。



従来のUnixcronの場合、起動遅延は最小限です。タイミングが合えば、これらのコマンドは単純に実行されます。次の例でこれを確認しましょう。

#   date    
0 0 * * * date >> date-cron.log

このようなcron構成では、次の出力が得られる可能性があります date-cron.log。

Mon Jun 22 00:00:00 PDT 2020
Tue Jun 23 00:00:00 PDT 2020
…

一方、Kubernetes CronJobでは、アプリケーションの前にいくつかのイベントが発生するため、起動が大幅に遅れる可能性があります。それらのいくつかを次に示します。

1. cronjobcontroller 処理し、CronJobを呼び出すことを決定します。
2. cronjobcontroller CronJobジョブ仕様に基づいてジョブを作成します。
3. jobcontroller 新しいジョブに気づき、ポッドを作成します。
4. Admission Controllerは、サイドカーコンテナデータをポッド仕様に挿入します*;
5. kube-scheduler kubeletでポッドを計画する。
6. kubelet Podを起動します（すべてのコンテナイメージをフェッチします）。
7. kubelet すべてのサイドカーコンテナを開始します*;
8. kubelet アプリケーションコンテナを起動します*。

*これらのステージは、LyftKubernetesスタックに固有のものです。



Kubernetes環境でCronJobの特定のスケールに達すると、項目1、5、および7が遅延に最も大きく寄与することがわかりました。

仕事による遅れ cronjobcontroller'

遅延がどこから来るのかをよりよく理解するために、インラインソースコードを調べてみましょうcronjobcontroller'。Kubernetes 1.18では、10秒ごとにcronjobcontrollerすべてのCronJobをチェックし、それぞれに対していくつかのロジックを実行します。 実装は、CronJobごとに少なくとも1つの追加のAPI呼び出しを行うことにより、これを同期的に実行します。CronJobの数が特定の数を超えると、これらのAPI呼び出しはクライアント側の制約を受け始めます。 10秒のポーリングサイクルとクライアント側のAPI呼び出しにより、CronJobの起動遅延が大幅に増加します。



cronjobcontroller'

cronを使用したポッドのスケジューリング

cronスケジュールの性質上、それらのほとんどは分の始めに実行されます（XX：YY：00）。たとえば、@hourly（毎時）cronは01：00：00、02：00：00などに実行されます。 1時間ごと、15分ごと、5分ごとなど、多数のcronが実行されているマルチテナントcronプラットフォームの場合、複数のcronが開始されるとボトルネック （ホットスポット）が発生します。同時に。 Lyftの私たちは、そのような場所の1つが時間の始まり（XX：00：00）であることに気づきました。これらのホットスポットは、次のようなcronジョブの実行に関わる制御層のコンポーネントで要求の頻度を制限する追加の負荷や鉛、作成kube-schedulerおよびkube-apiserver、スタートアップ遅延の顕著な増加につながるし。



さらに、ピーク負荷の処理能力をプロビジョニングせず（および/またはクラウドサービスのコンピューティングインスタンスを使用）、代わりにクラスター自動スケーリングメカニズムを使用してノードを動的にスケーリングする場合、ノードの起動にかかる時間は起動待ち時間にさらに寄与します。ポッドCronJob。

ポッドの起動：ヘルパーコンテナ

CronJobポッドが正常にスケジュールされるkubeletと、後者はすべてのサイドカーとアプリケーション自体のコンテナイメージをフェッチして実行する必要があります。Lyftでのコンテナの起動の詳細（サイドカーコンテナはアプリケーションコンテナの前に起動します）により、サイドカーの起動の遅延は必然的に結果に影響を与え、タスクの開始がさらに遅延します。



したがって、必要なアプリケーションコードを実行する前の起動時の遅延は、マルチテナント環境での多数のCronJobと相まって、目立って予測できない起動遅延につながります。少し後で説明しますが、実際には、このような遅延はCronJobの動作に悪影響を及ぼし、起動を逃す恐れがあります。

コンテナのクラッシュ処理

一般に、cronの動作に注意を払うことをお勧めします。 Unixシステムの場合、これはかなり簡単です。 Unixクローンは、指定されたシェルを使用して指定されたコマンドを解釈し$SHELL、コマンドが終了した後（成功したかどうかに関係なく）、その特定の呼び出しは完了したと見なされます。次のような簡単なスクリプトを使用して、Unixでのcronの実行を追跡できます。

#!/bin/sh

my-cron-command
exitcode=$?

if [[ $exitcode -ne 0 ]]; then
    # stat-and-log is pseudocode for emitting metrics and logs
    stat-and-log "failure"
else
    stat-and-log "success"
fi

exit $exitcode

Unixの場合、cronstat-and-logは、$exitcode。に関係なく、cron呼び出しごとに1回だけ実行されます。したがって、これらのメトリックを使用して、失敗した呼び出しに関する最も単純な通知を整理できます。



失敗に対する再試行がデフォルトで定義されており、失敗自体がさまざまな理由（ジョブの失敗またはコンテナーの失敗）によって引き起こされる可能性があるCronJob Kubernetesの場合、監視はそれほど単純で単純ではありません。



失敗時に再起動するように構成されたことが到達するまでアプリケーションコンテナにし、ジョブと同様のスクリプトを使用すると、cronジョブは、プロセスでのメトリックとログを生成し、失敗したときにタスクを実行しようとBackoffLimitを（最大再試行回数）。したがって、問題の原因を特定しようとする開発者は、多くの不要な「ゴミ」を整理する必要があります。さらに、最初の失敗に応答するシェルスクリプトからのアラートは、アプリケーションコンテナがそれ自体でタスクを回復して正常に完了することができるため、それ以上のアクションに基づくことができない通常のノイズである可能性もあります。



アラートは、アプリケーションコンテナレベルではなく、ジョブレベルで実装できます。このために、kube_job_status_failedからなど、ジョブの失敗に関するAPIレベルのメトリックを使用できますkube-state-metrics。このアプローチの欠点は、ジョブが「最終的な障害段階」に達して制限BackoffLimitに達した後にのみ、当直のエンジニアが問題に気付くということです。これは、アプリケーションコンテナの最初の障害よりもはるかに遅く発生する可能性があります。

CronJob'

大幅な開始遅延と再起動サイクルにより、追加の遅延が発生し、KubernetesCronJobの再実行が妨げられる可能性があります。頻繁に呼び出されるCronJobの場合、または実行時間がアイドル時間よりも大幅に長いCronJobの場合、この追加の遅延により、次にスケジュールされた呼び出しで問題が発生する可能性があります。 CronJobに同時実行ConcurrencyPolicy: Forbidを禁止するポリシーがある場合、遅延により、将来の呼び出しが時間どおりに完了せず、遅延します。





特定の1時間ごとのCronJobでstartingDeadlineSecondsを超えるタイムラインの例（cronjobcontrollerの観点から）：スケジュールされた開始をスキップし、次のスケジュールされた時間まで呼び出されません



CronJobが呼び出しを完全にスキップできるため、より不快なシナリオもあります（Lyftで発生しました）startingDeadlineSeconds。これは、CronJobがインストールされている場合です。このシナリオでは、起動遅延がを超えるstartingDeadlineSecondsと、CronJobは完全に起動をスキップします。



さらに、ConcurrencyPolicyCronJobがに設定されている場合Forbid、前の呼び出しのrestart-on-failure-cycleも次のCronJob呼び出しに干渉する可能性があります。

実世界の条件でKubernetesCronJobを操作する際の問題

繰り返しのカレンダータスクをKubernetesに移行し始めて以来、CronJobメカニズムを変更せずに使用すると、開発者の観点からもプラットフォームチームの観点からも、不快な瞬間が発生することがわかっています。残念ながら、彼らは私たちが最初にKubernetesCronJobを選んだ利点と利点を否定し始めました。開発者もプラットフォームチームも、CronJobを活用し、複雑なライフサイクルを理解するために必要なツールを自由に使用できないことにすぐに気付きました。



開発者はCronJobを利用して構成しようとしましたが、その結果、次のような多くの苦情や質問が寄せられました。

• cronが機能しないのはなぜですか？
• cronが機能しなくなったようです。実際に実行されていることをどのように確認できますか？
• cronが機能していないことを知らなかったので、すべて問題ないと思いました。
• 欠落しているcronを「修正」するにはどうすればよいですか？SSHログインだけでコマンドを自分で実行することはできません。
• このcronがXからYまでの複数の実行を見逃したように見える理由を教えてください。
• X（多数）のcronがあり、それぞれに独自の通知があり、それらすべてを維持するのはかなり面倒で困難になります。
• ポッド、ジョブ、サイドカー-これはどのようなナンセンスですか？

プラットフォームチームとして、次のような質問に答えることができませんでした。

• Kubernetes cronプラットフォームのパフォーマンスを定量化する方法は？
• 追加のCronJobを有効にすると、Kubernetes環境にどのような影響がありますか？
• Kubernetes CronJob' ( multi-tenant) single-tenant cron' Unix?
• Service-Level-Objectives (SLOs — ) ?
• , , , ?

CronJobのクラッシュのデバッグは簡単な作業ではありません。障害が発生する場所と証拠を探す場所を理解するには、多くの場合、直感が必要です。これらの手がかりを取得するのが非常に難しい場合があります。たとえば、cronjobcontroller'高レベルの詳細が有効になっている場合にのみ記録されるログなどです。さらに、トレースは一定期間後に単純に消えることがあります。これにより、デバッグはゲーム「Kick a mol」（これについて-約Transl。）と同様になります。たとえば、CronJob'ov、Job'ov、Pod'ovのKubernetesイベントデフォルトでは1時間だけ保持されます。これらの方法はどれも使いやすく、プラットフォーム上のCronJobの数が増えるにつれて、サポートの面でうまく拡張できるものはありません。



また、時々Kubernetesだけ実行を逃した回数が多すぎると、CronJobの実行を停止します。この場合、手動で再起動する必要があります。では実際の生活、これは、はるかに頻繁にあなたが想像するかもしれないより発生し、手動で問題を毎回修正する必要性が非常に苦しくなります。



これで、忙しいプロジェクトでKubernetesCronJobを使用したときに発生した技術的および運用上の問題について詳しく説明しました。第2部では、スタック内のKubernetesを排除し、使いやすさを向上させ、CronJobの信頼性を向上させた方法について説明します。

パート2。はじめに

Kubernetes CronJobは、変更されていないので、Unixの対応するものの単純で便利な代替品にはなり得ないことが明らかになりました。すべてのクローンを自信を持ってKubernetesに転送するには、CronJobの技術的な欠点を取り除くだけでなく、それらの使いやすさを向上させる必要がありました。すなわち：



1。開発者の話を聞いて、彼らが最も心配しているクローンについての質問に対する答えを理解します。例：私のcronは開始されましたか？アプリケーションコードは実行されましたか？起動は成功しましたか？ cronはどのくらい実行されましたか？ （アプリケーションコードにはどのくらい時間がかかりましたか？） 2。CronJobをより理解しやすくし、ライフサイクルをより透過的にし、プラットフォームとアプリケーションの境界を明確にすることで、



プラットフォームのメンテナンスを簡素化します。



3.プラットフォームに標準のメトリックとアラートを追加して、カスタムアラート構成の量を減らし、開発者が作成および維持する必要のある重複するcronバインディングの数を減らします。



4.簡単なクラッシュリカバリと新しいCronJob構成のテストのためのツールを開発します。



5.修正するために手動の介入を必要とし、1つの重大な障害シナリオ（startingDeadlineSecondsが設定されていない場合）でクラッシュを引き起こすTooManyMissedStartsバグなど、Kubernetesの長年の技術的問題を修正します。

決定

これらすべての問題を次のように解決しました。

1. (observability). CronJob', (Service Level Objectives, SLOs) .
2. CronJob' « » Kubernetes.
3. Kubernetes.

CronJob'

特定のcronジョブ監視するためのプラットフォームによって生成されたダッシュボードの例



：私たちはKubernetesスタックに次のメトリックを追加したが（彼らはLyft内のすべてのcronジョブのために定義されている）



1 started.count-このカウンタはされcronジョブが呼び出されたときにアプリケーションコンテナが最初に起動したときにインクリメント。 「アプリケーションコードは実行されましたか？」という質問に答えるのに役立ちます。 "。



2. {success, failure}.count-これらのカウンタがされている特定のcronジョブコールが到達したときにインクリメント、端末の状態を（であること、仕事をその仕事して、終了したjobcontrollerことを実行するために、もはや試行を）。彼らは質問に答えます。「打ち上げは成功しましたか？ "。



3.-scheduling-decision.{invoke, skip}.countこれらのカウンターcronjobcontrollerCronJobを呼び出すときに行われる決定について知ることができます。特に、次skip.countの質問に答えるのに役立ちます。「なぜ私のcronが機能しないのですか？"。次のラベルはそのパラメータとして機能しますreason。

• reason = concurrencyPolicy-cronjobcontrollerそれ以外の場合は、それを破るため、cronジョブへの呼び出しを逃しましたConcurrencyPolicy。
• reason = missedDeadline-cronjobcontroller指定された呼び出しウィンドウを見逃したため、CronJobの呼び出しを拒否しました.spec.startingDeadlineSeconds。
• reason = error CronJobを呼び出そうとしたときに発生する他のすべてのエラーに共通のパラメーターです。

4.-app-container-duration.secondsこのタイマーは、アプリケーションコンテナの寿命を測定します。これは、次の質問に答えるのに役立ちます。「アプリケーションコードはどのくらい実行されましたか？ "。このタイマーでは、ポッドのスケジューリング、サイドカーコンテナの起動などに必要な時間は、プラットフォームチームの責任であり、起動遅延に含まれているため、意図的に含めていません。



5.-start-delay.secondsこのタイマーは開始遅延を測定します。このメトリックをプラットフォーム全体で集計すると、それを維持するエンジニアは、プラットフォームのパフォーマンスを評価、監視、調整するだけでなく、起動遅延や最大cronスケジュール頻度などのパラメーターのSLOを決定するための基礎としても機能します。



これらの指標に基づいて、デフォルトのアラートを作成しました。次の場合に開発者に通知します。

• 彼らのCronJobはスケジュールどおりに開始されませんでした（rate(scheduling-decision.skip.count) > 0）;
• 彼らのCronJobは失敗しました（rate(failure.count) > 0）。

開発者は、Kubernetesのクローンに対して独自のアラートとメトリックを定義する必要がなくなりました。プラットフォームは既製の対応物を提供します。

必要に応じてcronを実行する

kubectl create job test-job --from=cronjob/<your-cronjob>内部CLIツールに 適合させました。Lyftのエンジニアは、これを使用してKubernetesのサービスと対話し、必要に応じてCronJobを呼び出します。

• 断続的なCronJobクラッシュからの回復。
• runtime- , 3:00 ( , CronJob', Job' Pod' ), — , ;
• runtime- CronJob' Unix cron', , .

TooManyMissedStarts

TooManyMissedStartsのバグ を修正し、 100回連続して開始を逃した後にCronJobが「ハング」しないようにしました。このパッチを使用すると、手動で介入する必要がなくなるだけでなく、時間を超えたときに実際に追跡することもできます。おかげVallery Lancey設計、このパッチ、構築するためのトムWanielistaアルゴリズムの設計を支援するために。このパッチをメインのKubernetesブランチに提供するためにPRを開始しました（ただし、採用されることはなく、非アクティブのために終了しました-約Transl。）。startingDeadlineSeconds

cronモニタリングの実装

Kubernetes CronJobのライフサイクルのどの段階で、メトリックをエクスポートするためのメカニズムを追加しました

cronスケジュールに依存しないアラート

逃したcron呼び出し通知を実装する上で最も難しい部分は、スケジュールを処理することです（crontab.guruはそれらを解読するのに役立ちました）。たとえば、次のスケジュールについて考えてみます。

#   5 
*/5 * * * *

このcronのカウンターは、終了するたびにインクリメントできます（またはcronバインディングを使用します）。次に、通知システムで、「過去60分間を見て、カウンターの増加が12未満かどうかを知らせてください」という形式の条件式を記述できます。問題は解決しましたよね？



しかし、スケジュールが次のようになっている場合はどうなりますか。

#       9  17
#        .
#  ,    (9-17, -)
0 9–17 * * 1–5

この場合、条件をいじくり回す必要があります（ただし、システムに営業時間のみの通知機能がある場合もありますか？）。とはいえ、これらの例は、通知をcronスケジュールにバインドすることにはいくつかの欠点があることを示しています。

1. スケジュールを変更する場合は、通知ロジックを変更する必要があります。
2. 一部のcronスケジュールでは、時系列を使用して複製するために非常に複雑なクエリが必要です。
3. 誤検知を最小限に抑えるために、正確に時間内に作業を開始しないクローンには、ある種の「待機期間」が必要です。

ステップ2だけでは、プラットフォーム上のすべてのクローンに対してデフォルトで通知を生成することは非常に困難なタスクになります。ステップ3は、起動遅延が重要な要素であるKubernetesCronJobのような分散プラットフォームに特に関係があります。さらに、「デッドマンスイッチ」を使用するソリューションがあります。これにより、通知をcronのスケジュールにバインドする必要があります。また、異常検出アルゴリズムでは、トレーニングが必要で、新しいCronJobやその変更に対してすぐには機能しません。タイムテーブル。



問題を調べる別の方法は、自分自身に問いかけることです。cronが開始されるべきだったのに、開始されなかったとはどういう意味ですか？



Kubernetesでは、バグを忘れた場合cronjobcontroller'または、コントロールプレーン自体の落下の可能性（ただし、クラスターの状態を正しく追跡するとすぐに確認できます）-これはcronjobcontroller、CronJobが（cronのスケジュールに従って）呼び出す必要があることを評価および決定したことを意味しますが、何らかの理由で故意にしないことにした理由で。



おなじみのように聞こえますか？これはまさに私たちのメトリックが行うことscheduling-decision.skip.countです！ここで、変更を追跡しrate(scheduling-decision.skip.count)て、CronJobがトリガーされるべきであることをユーザーに通知する必要がありますが、トリガーされませんでした。



このソリューションは、cronスケジュールを通知自体から切り離し、いくつかの利点を提供します。

• これで、スケジュールを変更するときにアラートを再構成する必要がなくなりました。
• 複雑な時間の要求や条件は必要ありません。
• プラットフォーム上のすべてのCronJobのデフォルトアラートを簡単に生成できます。

これを、前述の他の時系列およびアラートと組み合わせると、CronJobの状態のより完全で理解しやすい図を作成するのに役立ちます。

開始遅延タイマーの実装

CronJobのライフサイクルは複雑であるため、このメトリックを確実かつ正確に測定するには、スタック上のツールキットの配置の特定のポイントを慎重に検討する必要がありました。その結果、すべては2つの時点を修正することになりました。

• T1：cronをいつ開始する必要があるか（スケジュールに従って）。
• T2：アプリケーションコードが実際に実行を開始したとき。

この場合start delay（開始遅延）= 2 — 1。瞬間T1を修正するために、のcron呼び出しロジックにコードを含めましたcronjobcontroller'。CronJobが呼び出されたとき.metadata.Annotationにcronjobcontroller作成するJobオブジェクトのように、予想される開始時間を記録します。通常のリクエストを使用して、任意のAPIクライアントを使用して取得できるようになりましたGET Job。



T2ではすべてがより複雑であることが判明しました。値をできるだけ実際に近づける必要があるため、T2は、アプリケーションを含むコンテナーが初めて起動された瞬間と一致する必要があります。いずれかでT2を撃った場合コンテナの起動時（再起動を含む）、この場合の起動の遅延には、アプリケーション自体の実行時間が含まれます。したがって、.metadata.Annotation特定のジョブのアプリケーションコンテナが最初にステータスを受け取ったことがわかったときはいつでも、別のジョブオブジェクトを割り当てることにしましたRunning。したがって、本質的に、分散ロックが作成され、このジョブのアプリケーションコンテナの将来の開始は無視されました（最初の開始の瞬間のみが保存されました）。

結果

新しい機能を展開してバグを修正した後、開発者から多くの肯定的なフィードバックを受け取りました。現在、開発者はKubernetesCronJobプラットフォームを使用しています。

• 独自の監視ツールやアラートについて困惑する必要がなくなりました。
• , CronJob' , .. alert' , ;
• CronJob' , CronJob' « »;
• ( app-container-duration.seconds).

さらに、プラットフォームメンテナンスエンジニアは、ユーザーエクスペリエンスとプラットフォームパフォーマンスを測定するための新しいパラメータ（開始遅延）を利用できるようになりました。



最後に（そしておそらく私たちの最大の勝利）、CronJob（およびその状態）をより透過的で追跡可能にすることで、開発者とプラットフォームエンジニアのデバッグプロセスを大幅に簡素化しました。同じデータを使用して一緒にデバッグできるようになったため、開発者が自分で問題を見つけ、プラットフォームが提供するツールを使用して問題を解決することがよくあります。

結論

分散されたスケジュールされたタスクの調整は簡単ではありません。CronJob Kubernetesは、それを整理する1つの方法にすぎません。CronJobは理想からはほど遠いものの、グローバルプロジェクトで作業する能力は十分にあります。もちろん、観察可能性の向上、障害の原因と詳細の理解、使いやすさを向上させるツールの追加など、時間と労力をかけて改善する準備ができている場合です。



注：CronJobの欠点を修正し、更新されたバージョンをGAに変換するためのオープンなKubernetes拡張提案（KEP）があります。この一連の記事のレビューに協力して



くれたRithuJohn、Scott Lau、Scarlett Perry、Julien Silland、TomWanielistaに感謝します。

翻訳者からのPS

私たちのブログも読んでください：

• " Kubernetesでのトラブルシューティングのビジュアルガイド»;
• " Kubernetes [およびその解決策]の操作における6つの面白いシステムバグ";
• 「生産におけるKubernetesのサクセスストーリー。パート6：BlaBlaCar "。