oomichi
commented
6 years ago テスト概要を把握する。
test/e2e/node/kubelet_perf.go
224 // We assume that the scheduler will make reasonable scheduling choices
225 // and assign ~N pods on the node.
226 // Although we want to track N pods per node, there are N + add-on pods
227 // in the cluster. The cluster add-on pods can be distributed unevenly
228 // among the nodes because they are created during the cluster
229 // initialization. This *noise* is obvious when N is small. We
230 // deliberately set higher resource usage limits to account for the
231 // noise.
232 //
233 // We set all resource limits generously because this test is mainly
234 // used to catch resource leaks in the soak cluster. For tracking
235 // kubelet/runtime resource usage, please see the node e2e benchmark
236 // dashboard. http://node-perf-dash.k8s.io/我々は scheduler に筋の通ったスケジューリングを期待し、（たとえば）Node あたり N 個以下のPod 配置を期待する。 しかし、Node あたり N個以下のPod 配置を期待しても、そこには N + add-on の Pod が存在する。 add-on Pod は不均等に Node に分散される。なぜならば Cluster の初期化段階で add-on Pod が作られるからだ。 このノイズは N の数が小さいときに顕著になる。 このノイズのため、我々はわざと高いリソース利用制限をアカウントにセットすることになる。
（このテストでは）全てのリソース制限を寛大にかける。なぜならばこのテストは基本的に soak クラスタにおけるリソース漏れを検知するために使われるからだ。kubelet/runtime リソース利用を トラックするため、node e2e benchmark dashboard を見てほしい。
テストケースは2つ
- (1/2) Nodeあたりの Pod 数が0
- (2/2) Nodeあたりの Pod 数が100
runResourceTrackingTestの概要
- Cluster 全体の Pod 数を算出： NodeあたりのPod 数 * Node数
- 上記 Pod 数の Replicas で RC を作成 コンテナイメージは imageutils.GetPauseImageName() で取得
- Resource Monitor のログをクリア
- monitoringTime 時間、reportingPeriod のインターバルで logPodsOnNodes() を実施し続ける
- 採取したログ（CPU, MEM 使用量）をログ出力
- verifyMemoryLimits() で指定した Limit 内に MEM 使用量が収まっていたかチェック
- verifyCPULimits() で指定した Limit 内に CPU 使用量が収まっていたかチェック ★今回はここのチェックでエラーになった
まとめ