stackabletech / stackabletech/opa-operator
Research: Do we need resource limits for the bundle builder container if we use config maps/pvcs?
まだ誰も着手していません。
- 主要言語
- Rust
- スター
- 21
- フォーク
- 5
- 平均マージ
- 12時間 44分
- マージ済み PR(30日)
- 11
説明
The PR https://github.com/stackabletech/opa-operator/pull/347 implements resource limits and requests for the opa container. The second container opa-bundle-builder currently does not have any limits.
The opa-bundle-builder basically reads all provided OPA rego config maps and puts the content into a tar bundle. From the OPA docs this could grow to a quite a size.
Currently, the size of the data in ConfigMaps cannot exceed 1MB (etcd limit).
This can become a problem if there are many configmaps with rules / data.
The OpaBundleBuilder uses the tar crate, where it is stated that not all of the content must be explicitly in memory.
If rules are adapted dynamically, this also could put quite a load on the CPU when repacking the bundle.tar.gz (not sure we ever reach that many/big rules though).
This is done when:
- The tar crate is tested for memory consumption
- The tar crate is tested for CPU utilization
- We have some tests / estimates if we need more resources than the default ones for the opa-bundle-builder (e.g. with 1000 - 10000 Configmaps a ~1MB)
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず PR #347 と OpaBundleBuilder における tar crate の使用方法を確認し、次にリンクされている OPA のリソース利用に関するドキュメントを参照してください。バンドル作成時のメモリおよび CPU の挙動を測定し、それぞれ約 1 MB の ConfigMaps をおよそ 1,000~10,000 個扱うワークロードを評価してください。チェックリストに測定値または推定値が記載され、必要なリソース制限について明確な結論が出ていれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- kubernetes, rust
- 領域
- infrastructure
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 25/100