リトライタイムアウトルール

Kubernetes Engineの使用中に、以下の2つのプロセスでタイムアウトが発生する可能性があります：

1. Provisionタイムアウト

Kubernetes Engineのclusterプロビジョニング中に問題が発生し、タイムアウトになる場合があります。タイムアウトは以下の表に従って計算されます：

プロビジョニングでは、以下の2つの結果のいずれかが発生します：

Provisionが失敗した場合、2つの状況が考えられます：

Provisionは成功したがステータスの同期が失われた場合：
- Kubernetes clusterは実際には正常に作成されています。
- Retryを選択すると、システムはデータを再同期し、provisionプロセスを再実行しません。
処理エラーによりProvisionが失敗した場合：
- status = failedの場合、ユーザーが再試行できるようRetryオプションが表示されます。
- status = provisioningの場合、システムはリクエスト送信時から時間のカウントを開始します。
  - 20分経過してもステータスが変化しない場合、システムはstatusをslowingに移行します。
  - slowing状態で20分経過してもステータスが変化しない場合、システムはstatusをpendingに移行します。
  - pending状態で40分経過してもステータスが変化しない場合、システムはstatusをerrorに移行します。
  - status = errorになると、ユーザーはRetryができます。システムはカウンターをリセットし、provisionプロセスを最初から再開します。
- プロビジョニング開始から完全タイムアウトまでの総時間：1時間20分。
- status = errorになると、ユーザーはretryができます。

Kubernetes clusterが正常に作成された後、オートスケールまたは手動スケール中に、コアプロセッサがnodeをスケールアップ/ダウンします：

スケーリングでは、以下の2つの結果のいずれかが発生します：

Scalingが失敗した場合、2つの状況が考えられます：

Scalingは成功したがステータスの同期が失われた場合：
- Kubernetes clusterには実際にスケール条件で指定した数のworkerが追加されています。
- Retryを選択すると、システムはデータを再同期し、scalingプロセスを再実行しません。
処理エラーによりScalingが失敗した場合：
- status = failedの場合、ユーザーが再試行できるようRetryオプションが表示されます。
- status = processingの場合、システムはリクエスト送信時から時間のカウントを開始します。
  - 10分（追加worker数に応じて増加）経過してもステータスが変化しない場合（failed/success）、システムはstatusをslowingに移行します。
  - slowing状態で20分経過してもステータスが変化しない場合、システムはstatusをpendingに移行します。
  - pending状態で30分経過してもステータスが変化しない場合、システムはstatusをerrorに移行します。
  - status = errorになると、ユーザーはRetryができます。システムはカウンターをリセットし、スケーリングプロセスを最初から再開します。
- スケーリング開始から完全タイムアウトまでの総時間：1時間（5台以上の新規worker追加では増加します）。

clusterがerrorステータスになると、ユーザーはRetryを選択できます。