問題タブ [hpa]

私は Nats と Kubernetes の両方に不慣れです。nats-server にサブスクライブし、Kubernetes の Deployment オブジェクトを含むポッドにラップされた Python コンソール アプリケーションを作成しました。ここで、この Python クライアントの nats-server で発行されたイベントの数に基づいて、ポッドを自動スケーリングしたいと考えています。どうすればそれができますか？誰でも私にアイデアを与えることができますか？

前もって感謝します。

Deployment の合計容量を減らさずに Pod を終了する必要があるシナリオがいくつかあります。

• メンテナンスのためのノードのドレイン
• ビンパッキングのためのノードのドレイン
• Pod の誤動作 / OOM Killer をトリガーせずにメモリ リークを処理する

2 つの Pod がかなりのトラフィックを消費している状況を想像してください。Pod を終了し、Kubernetes を再作成して反応させるデフォルトのワークフローを使用すると、任意の時間の間、50% の処理能力が得られます。

スループットの高いアプリケーションでは、次のいずれかの方法でサービス レベルが低下します。

• Rails などのマルチスレッド化されていない非非同期アプリケーションでのリクエスト キューイングにより、応答時間が長くなる
• 非同期マルチスレッド アプリケーションの場合、より高いコンテキスト スイッチングにより、応答時間が増加します。
• 応答時間の SLO とタイムアウトが厳密なアプリケーションでタイムアウト エラーが急増する
• 厳密な応答時間の SLO とタイムアウトを適用しない場合、問題の高スループット アプリケーションに依存するサービスのカスケード速度低下

理想的には、私が探しているのは、作成前に破棄するパターンです。たとえば、Kube に Pod を終了するように依頼しますが、リストされているサービスのエンドポイントから削除する前に、Kube はスケールアップをトリガーし、Readiness Gate を尊重してから、終了するように依頼した Pod の終了を開始します。Kubernetes でそのようなパターンについての言及は見つかりませんでした。

人々はこのシナリオにどのように対処しますか? 次のことが想像できます。

• HPA が低いtargeAverageUtilizationため、一時的な容量の 50% の削減は許容できますが、これは必要以上の費用がかかることを意味します
• Pod の準備完了までの時間を最適化して、ほんの数秒間、プロビジョニング不足のままにしますが、たとえば、AWS ロード バランサーが新しいターゲットを正常にするのに少なくとも 10 秒かかる場合、これは非常に難しいようです。
• kubectl delete [pod]私たち の代わりに、関連するワークフローを作成します。
  • HPAminReplicasを現在のレプリカより 1 つ上に上げる
  • Pod の準備が整うまで待ちます
  • ウォームアップするまで数秒待ちます
  • 実行kubectl delete [pod]して目的のポッドを殺します
  • 新しい交換用ポッドの準備が整うまで待ちます
  • ウォームアップするまで数秒待ちます
  • minReplicasHPA での復元
  • この操作全体がトラフィックの増加/スパイクと同時に発生し、上記の低下の影響が見られるリスクを冒してください。

これらはどれも良いようには見えません。特に最後の例では、クラスター オートスケーラーがインスタンスをドレインする方法を置き換えることができないため、ビンパッキングについては説明しません。