stackabletech / stackabletech/commons-operator
Pod expiration drifts when system is suspended
まだ誰も着手していません。
- 主要言語
- Python
- スター
- 8
- フォーク
- 4
- 平均マージ
- 7時間 48分
- マージ済み PR(30日)
- 7
説明
Affected Stackable version
dev (24.11 prerelease)
Current and expected behavior
@xeniape ran into an issue (sble employees: see slack) where pods would be left with expired certificates after a while, rather than getting evicted by commons-op as expected. Restarting commons-op evicted the pods, as expected.
Our current working hypothesis here is that commons-op's re-reconciliation timer didn't advance while the computer was suspended, causing the eviction to be delayed by the same amount of time.
Possible solution
Either:
- Change the timer to use wall time instead of monotonic/CPU time
- Cap the re-reconciliation timer, causing spurious reconciles but at least limiting the issue
- Make the timer automatically expire when resuming from suspend
Either way, we should probably also communicate upstream with kube-rs and either fix it there or highlight the issue somehow.
Additional context
No response
Environment
No response
Would you like to work on fixing this bug?
None
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず commons-op の再調整タイマーを特定し、システムのサスペンドとレジュームをまたいだ kube-rs タイマーの動作を確認します。可能であれば遅延した pod の eviction を再現し、そのうえで upstream の kube-rs の修正と commons-op の変更のどちらが適切かを判断します。完了条件は、期限切れの証明書によってレジューム後に適時 eviction が行われ、回帰テストのカバレッジ、または制限事項を記録した upstream issue が存在することです。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- kubernetes, rust
- 領域
- devops, infrastructure
- issue の種類
- バグ
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 35/100