kubernetes 🚀 - [テストフレーク]マスタースケーラビリティスイート

最近スイートに追加されたe2esが多数あるため（https://github.com/kubernetes/kubernetes/pull/59391など）、主にタイムアウトが原因で正しさのジョブが失敗しています（それに応じてスケジュールを調整する必要があります）。
100ノードのフレークについては、 https：//github.com/kubernetes/kubernetes/issues/60500があり
パフォーマンスジョブについては、リグレッションがあると思います（ポッドの起動待ち時間の前後のように、最後の数回の実行からのようです）。多分もっとsth。

私は今週中にそれらに到達しようとします（フリーサイクルatmが不足しています）。

shyamjvs 2018年02月28日

@shyamjvsこの問題の更新はありますか？

krzyzacy 2018年03月02日

https://k8s-testgrid.appspot.com/sig-release-master-blocking#gce -scale-correctness

私はそれを簡単に調べました。そして、いくつかのテストが非常に遅いか、何かがぶら下がっています。前回の実行からのログのパー：

62571 I0301 23:01:31.360] Mar  1 23:01:31.348: INFO: Running AfterSuite actions on all node
62572 I0301 23:01:31.360]
62573 W0302 07:32:00.441] 2018/03/02 07:32:00 process.go:191: Abort after 9h30m0s timeout during ./hack/ginkgo-e2e.sh --ginkgo.flakeAttempts=2 --ginkgo.skip=\[Serial\]|\[Disruptive      \]|\[Flaky\]|\[Feature:.+\]|\[DisabledForLargeClusters\] --allowed-not-ready-nodes=50 --node-schedulable-timeout=90m --minStartupPods=8 --gather-resource-usage=master --gathe      r-metrics-at-teardown=master --logexporter-gcs-path=gs://kubernetes-jenkins/logs/ci-kubernetes-e2e-gce-scale-correctness/80/artifacts --report-dir=/workspace/_artifacts --dis      able-log-dump=true --cluster-ip-range=10.64.0.0/11. Will terminate in another 15m
62574 W0302 07:32:00.445] SIGABRT: abort

8時間30分以内にテストが終了しませんでした

wojtek-t 2018年03月02日

https://k8s-testgrid.appspot.com/sig-release-master-blocking#gce -scale-performance

確かに回帰のようです。回帰は実行間のどこかで起こったと思います：
105（それでも大丈夫だった）
108（起動時間が明らかに長かった）

kubemark-5000を調べて、そこにも表示されるかどうかを確認できます。

wojtek-t 2018年03月02日

Kubemark-5000はかなり安定しています。このグラフの99パーセンタイル（回帰は以前にも発生した可能性がありますが、105から108の間のどこかにあると思います）：

screenshot from 2018-03-02 14-36-54

wojtek-t 2018年03月02日

正当性テストに関して-gce-large-correctnessも失敗しています。
当時、非常に長いテストが追加されたのではないでしょうか。

wojtek-t 2018年03月02日

@ wojtek-tを見てくれてありがとう。 Wrtパフォーマンスジョブ-私も回帰があると強く感じています（ただし、それらを適切に調べることはできませんでした）。

当時、非常に長いテストが追加されたのではないでしょうか。

少し前に調べていました。そして、私が見つけた2つの疑わしい変更がありました：

＃59391-これにより、ローカルストレージに関する一連のテストが追加されました（この変更がタイムアウトし始めた後の実行）
ポッドの非アフィニティを備えたStatefulSetは、ノード全体に分散されたボリュームを使用する必要があります（このテストは3.5〜5時間実行されているようです）-https ： //k8s-gubernator.appspot.com/build/kubernetes-jenkins/logs/ci-kubernetes-e2e

shyamjvs 2018年03月02日

cc @ kubernetes / sig-ストレージ-バグ

shyamjvs 2018年03月02日

/割当

一部のローカルストレージテストでは、クラスターサイズはそれほど大きくないと考えて、クラスター内のすべてのノードを使用しようとします。ノードの最大数を制限する修正を追加します。

msau42 2018年03月02日

👍1

一部のローカルストレージテストでは、クラスターサイズはそれほど大きくないと考えて、クラスター内のすべてのノードを使用しようとします。ノードの最大数を制限する修正を追加します。

ありがとう@ msau42-それは素晴らしいことです。

wojtek-t 2018年03月02日

https://k8s-testgrid.appspot.com/sig-release-master-blocking#gce -scale-performancesuiteに戻ります

105回までのランと108回以降のランを詳しく調べました。
ポッドの起動時間との最大の違いは、次のステップで発生するようです。

10% worst watch latencies:

[その名前は誤解を招く可能性があります-以下で説明します]

105回までの実行では、一般的に次のようになりました。

I0129 21:17:43.450] Jan 29 21:17:43.356: INFO: perc50: 1.041233793s, perc90: 1.685463015s, perc99: 2.350747103s

108回の実行から、次のようになります。

Feb 12 10:08:57.123: INFO: perc50: 1.122693874s, perc90: 1.934670461s, perc99: 3.195883331s

これは基本的に約0.85秒の増加を意味し、これはおおよそ最終結果で観察されることです。

さて、その「ウォッチラグ」とは何ですか。
基本的には、「Kubeletがポッドが実行されていることを確認した」から「テストがポッドの更新を確認して状態を実行に設定したとき」までの時間です。
後退する可能性がいくつかあります。

kubeletのレポートステータスが遅くなります
kubeletはqpsが不足しています（したがって、ステータスのレポートが遅くなります）
apiserverは低速であるため（CPUが不足しているなど）、要求の処理が遅くなります（書き込み、監視、またはその両方）。
テストはCPU不足であるため、着信イベントの処理が遅くなります

ポッドの「スケジュール->開始」の違いは実際には観察されないため、おそらくapiserverではないことを示しています（リクエストとウォッチの処理もそのパス上にあるため）、おそらく遅いkubeletではありませんあまりにも（ポッドを開始するため）。

したがって、最も可能性の高い仮説は次のとおりです。

kubeletはqpsが不足しています（または、ステータス更新をすばやく送信できないようにするsth）
テストはCPUが不足しています（またはそのようなsth）

その頃、テストはまったく変わりませんでした。だから私はそれがおそらく最初のものだと思います。

そうは言っても、105回から108回の実行でマージされたPRを実行しましたが、これまでのところ有用なものは見つかりませんでした。

wojtek-t 2018年03月02日

次のステップは次のとおりだと思います。

最も遅いポッドを調べ（最も遅いポッドの間にもO（1s）の違いがあるようです）、その違いが更新ステータス要求が送信された「前」か「後」かを確認します。

wojtek-t 2018年03月02日

そこで、ポッドの例を調べました。そして、私はすでにこれを見ています：

I0209 10:01:19.960823       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-16-5pl6z/pods/density-latency-pod-3115-fh7hl/status: (1.615907ms) 200 [[kubelet/v1.10.0 (l    inux/amd64) kubernetes/05944b1] 35.196.200.5:37414]
...
I0209 10:01:22.464046       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-16-5pl6z/pods/density-latency-pod-3115-fh7hl/status: (279.153µs) 429 [[kubelet/v1.10.0 (li    nux/amd64) kubernetes/05944b1] 35.196.200.5:37414]
I0209 10:01:23.468353       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-16-5pl6z/pods/density-latency-pod-3115-fh7hl/status: (218.216µs) 429 [[kubelet/v1.10.0 (li    nux/amd64) kubernetes/05944b1] 35.196.200.5:37414]
I0209 10:01:24.470944       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-16-5pl6z/pods/density-latency-pod-3115-fh7hl/status: (1.42987ms) 200 [[kubelet/v1.10.0 (li    nux/amd64) kubernetes/05944b1] 35.196.200.5:37414]

I0209 09:57:01.559125       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-35-gjzmd/pods/density-latency-pod-2034-t7c7h/status: (1.836423ms) 200 [[kubelet/v1.10.0 (l    inux/amd64) kubernetes/05944b1] 35.229.43.12:37782]
...
I0209 09:57:04.452830       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-35-gjzmd/pods/density-latency-pod-2034-t7c7h/status: (231.2µs) 429 [[kubelet/v1.10.0 (linu    x/amd64) kubernetes/05944b1] 35.229.43.12:37782]
I0209 09:57:05.454274       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-35-gjzmd/pods/density-latency-pod-2034-t7c7h/status: (213.872µs) 429 [[kubelet/v1.10.0 (li    nux/amd64) kubernetes/05944b1] 35.229.43.12:37782]
I0209 09:57:06.458831       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-35-gjzmd/pods/density-latency-pod-2034-t7c7h/status: (2.13295ms) 200 [[kubelet/v1.10.0 (li    nux/amd64) kubernetes/05944b1] 35.229.43.12:37782]

I0209 10:01:53.063575       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-5-6w4kv/pods/density-latency-pod-3254-586j7/status: (1.410064ms) 200 [[kubelet/v1.10.0 (li    nux/amd64) kubernetes/05944b1] 35.196.212.60:3391
...
I0209 10:01:55.259949       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-5-6w4kv/pods/density-latency-pod-3254-586j7/status: (10.4894ms) 429 [[kubelet/v1.10.0 (lin    ux/amd64) kubernetes/05944b1] 35.196.212.60:33916]
I0209 10:01:56.266377       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-5-6w4kv/pods/density-latency-pod-3254-586j7/status: (233.931µs) 429 [[kubelet/v1.10.0 (lin    ux/amd64) kubernetes/05944b1] 35.196.212.60:33916]
I0209 10:01:57.269427       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-5-6w4kv/pods/density-latency-pod-3254-586j7/status: (182.035µs) 429 [[kubelet/v1.10.0 (lin    ux/amd64) kubernetes/05944b1] 35.196.212.60:33916]
I0209 10:01:58.290456       1 wrap.go:42] PUT /api/v1/namespaces/e2e-tests-density-30-5-6w4kv/pods/density-latency-pod-3254-586j7/status: (13.44863ms) 200 [[kubelet/v1.10.0 (li    nux/amd64) kubernetes/05944b1] 35.196.212.60:33916]

したがって、問題が「429」に関連していることはかなり明らかなようです。

wojtek-t 2018年03月02日

これらの抑制されたAPI呼び出しは、所有者アカウントの割り当てが原因ですか？

jdumars 2018年03月02日

これらの抑制されたAPI呼び出しは、所有者アカウントの割り当てが原因ですか？

私が最初に思ったように、これはスロットルではありません。これらはapiserver上の429です（理由は、何らかの理由でapiserverが遅いか、apiserverに要求が多い可能性があります）。

wojtek-t 2018年03月02日

ああ、わかりました。それは素晴らしいニュースではありません。

jdumars 2018年03月02日

/マイルストーンクリア

krzyzacy 2018年03月02日

/ milestone v1.10

krzyzacy 2018年03月02日

/マイルストーンクリア

cjwagner 2018年03月02日

@cjwagner ：マイルストーンを設定するには、

対応して、この：

/マイルストーンクリア

PRコメントを使用して私とやり取りするための手順は、こちらから入手できkubernetes / test-infraリポジトリに対して問題を

k8s-ci-robot 2018年03月02日

/ milestone v1.9

cjwagner 2018年03月02日

@cjwagner ：マイルストーンを設定するには、

対応して、この：

/ milestone v1.9

PRコメントを使用して私とやり取りするための手順は、こちらから入手できkubernetes / test-infraリポジトリに対して問題を

k8s-ci-robot 2018年03月02日

PRように思えるhttps://github.com/kubernetes/kubernetes/pull/60740タイムアウトの問題を修正-迅速な対応に感謝@ msau42。
私たちの正しさの仕事（2kと5kの両方）は今グリーンに戻っています：

https://k8s-testgrid.appspot.com/sig-scalability-gce#gce -large-correctness
https://k8s-testgrid.appspot.com/sig-scalability-gce#gce -scale-correctness

だから、それらのボリュームテストについての

shyamjvs 2018年03月05日

ACK。進行中
ETA：2018年9月3日
リスク：k8sのパフォーマンスへの潜在的な影響

shyamjvs 2018年03月05日

そこで、これを少し掘り下げて、5kノードテストのポッド起動待ち時間のグラフから、回帰は白黒実行108および109でも発生する可能性があると感じています（99％ileを参照）。

pod_startup_5k

shyamjvs 2018年03月05日

私はdiffをすばやくスイープしましたが、次の変更は私には疑わしいようです。

「NewRequestからのリクエストタイムアウトの受け渡しを許可する」＃51042

そのPRは、API呼び出しへのクエリパラメータとしてクライアントのタイムアウトの伝播を可能にします。そして、実際、これら2回の実行でのPATCH node/status呼び出しの違いは次のとおりです（apiserverログから）。

実行-108：

I0207 22:01:06.450385       1 wrap.go:42] PATCH /api/v1/nodes/gce-scale-cluster-minion-group-1-2rn2/status: (11.81392ms) 200 [[kubelet/v1.10.0 (linux/amd64) kubernetes/11104d7] 35.227.96.23:47270]
I0207 22:01:03.857892       1 wrap.go:42] PATCH /api/v1/nodes/gce-scale-cluster-minion-group-3-9659/status: (8.570809ms) 200 [[kubelet/v1.10.0 (linux/amd64) kubernetes/11104d7] 35.196.85.108:43532]
I0207 22:01:03.857972       1 wrap.go:42] PATCH /api/v1/nodes/gce-scale-cluster-minion-group-3-wc4w/status: (8.287643ms) 200 [[kubelet/v1.10.0 (linux/amd64) kubernetes/11104d7] 35.229.110.22:50530]

実行-109：

I0209 21:01:08.551289       1 wrap.go:42] PATCH /api/v1/nodes/gce-scale-cluster-minion-group-2-89f2/status?timeout=10s: (71.351634ms) 200 [[kubelet/v1.10.0 (linux/amd64) kubernetes/05944b1] 35.229.77.215:51070]
I0209 21:01:08.551310       1 wrap.go:42] PATCH /api/v1/nodes/gce-scale-cluster-minion-group-2-3ms3/status?timeout=10s: (70.705466ms) 200 [[kubelet/v1.10.0 (linux/amd64) kubernetes/05944b1] 35.227.84.87:49936]
I0209 21:01:08.551394       1 wrap.go:42] PATCH /api/v1/nodes/gce-scale-cluster-minion-group-3-wc02/status?timeout=10s: (70.847605ms) 200 [[kubelet/v1.10.0 (linux/amd64) kubernetes/05944b1] 35.196.125.143:53662]

私の仮説では、PATCH呼び出しに10秒のタイムアウトが追加されたため、これらの呼び出しはサーバー側でより長く持続します（IIUCこのコメントは正しく）。これは、彼らが現在、より長い期間機内キューにいることを意味します。これは、これらのPATCH呼び出しがこのような大きなクラスターで大量に発生するという事実と相まって、 PUT pod/status呼び出しが機内キューで十分な帯域幅を取得できず、429で返されることになります。その結果、ポッドステータスの更新におけるkubelet側の遅延が増加しました。この話は、上記の@ wojtek-tの観察にもよく合います。

この仮説を検証するために、さらに証拠を収集しようと思います。

shyamjvs 2018年03月05日

そこで、テストの実行中にPATCH node-statusレイテンシがどのように変化するかを確認しました。実際、その頃に99パーセンタイル（一番上の行を参照）が上昇しているようです。しかし、それが108と109の実行で発生したことはあまり明確ではありません（私の信念はそうですが）：

patch_node_status_latency

shyamjvs 2018年03月05日

[編集：私の以前のコメントは、それらの429の数について誤って言及していました（クライアントは、kubeletではなくnpdでした）]

私は今、より多くの裏付けとなる証拠を持っています：

run-108では、429を取得した約479k PATCH node/status呼び出しがありました。

{
        "metric": {
          "__name__": "apiserver_request_count",
          "client": "kubelet/v1.10.0 (linux/amd64) kubernetes/11104d7",
          "code": "429",
          "contentType": "resource",
          "resource": "nodes",
          "scope": "",
          "subresource": "status",
          "verb": "PATCH"
        },
        "value": [
          0,
          "479181"
        ]
      },

そしてrun-109では、それらの〜757kがあります：

{
        "metric": {
          "__name__": "apiserver_request_count",
          "client": "kubelet/v1.10.0 (linux/amd64) kubernetes/05944b1",
          "code": "429",
          "contentType": "resource",
          "resource": "nodes",
          "scope": "",
          "subresource": "status",
          "verb": "PATCH"
        },
        "value": [
          0,
          "757318"
        ]
      },

shyamjvs 2018年03月05日

そして...これを見てください：

実行中-108：

{
        "metric": {
          "__name__": "apiserver_request_count",
          "client": "kubelet/v1.10.0 (linux/amd64) kubernetes/11104d7",
          "code": "429",
          "contentType": "namespace",
          "resource": "pods",
          "scope": "",
          "subresource": "status",
          "verb": "UPDATE"
        },
        "value": [
          0,
          "28594"
        ]
      },

および実行中-109：

{
        "metric": {
          "__name__": "apiserver_request_count",
          "client": "kubelet/v1.10.0 (linux/amd64) kubernetes/05944b1",
          "code": "429",
          "contentType": "namespace",
          "resource": "pods",
          "scope": "",
          "subresource": "status",
          "verb": "UPDATE"
        },
        "value": [
          0,
          "33224"
        ]
      },

shyamjvs 2018年03月05日

他のいくつかの隣接する実行の数を確認しました。

run-104の場合は21187です
run-105の場合は22003です
run-108の場合は28594です

-そのPRが合併しました-

run-109の場合は33224です
run-110の場合は30977です
run-111の場合は25615です

少し変化しているように見えますが、全体的にはノーのように見えます。 429の約25％増加しました。

shyamjvs 2018年03月05日

そして、429を受け取ったkubeletsからのPATCH node-statusの場合、数字は次のようになります。

実行-104 = 313348
実行-105 = 309136
実行-108 = 479181

-そのPRが合併しました-

実行-109 = 757318
実行-110 = 752062
実行-111 = 296368

これもさまざまですが、一般的には増加しているようです。

shyamjvs 2018年03月05日

PATCH node-status呼び出し待ち時間の99番目の％ileも一般的に増加しているようです（https://github.com/kubernetes/kubernetes/issues/60589#issuecomment-370573938で予測していたように）：

run-104 (798ms), run-105 (783ms), run-108 (826ms)

run-109 (878ms), run-110 (869ms), run-111 (806ms)

ところで-上記のすべてのメトリックについて、108は通常よりも悪い実行であり、111は通常よりも優れているようです。

shyamjvs 2018年03月05日

明日は、大規模な5kクラスターを手動で実行してこれを確認しようと思います。

shyamjvs 2018年03月05日

トリアージ@shyamjvsをありがとう

krzyzacy 2018年03月05日

そのため、〜HEADに対して5kクラスターに対して密度テストを2回実行しましたが、驚くべきことに、99％ileポッドの起動レイテンシが4.510015461sと4.623276837s両方でテストに合格しました。ただし、「ウォッチレイテンシ」は、@ wojtek-tがhttps://github.com/kubernetes/kubernetes/issues/60589#issuecomment-369951288で指摘した増加を示してい

最初の実行では、次のようになりました。

INFO: perc50: 1.123056294s, perc90: 1.932503347s, perc99: 3.061238209s

2回目の実行は次のとおりです。

INFO: perc50: 1.121218293s, perc90: 1.996638787s, perc99: 3.137325187s

以前の状況を確認してみましょう。

shyamjvs 2018年03月06日

https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -370573938-これをフォローしているかどうかはわかりませんはい-タイムアウトを追加しましたが、デフォルトのタイムアウトは10秒IIRCよりも大きいため、役立つはずです事態を悪化させないでください。

なぜ429が増えるのか、まだ理解していないと思います（これは、https：//github.com/kubernetes/kubernetes/issues/60589#issuecomment-370036377ですでに述べた429に何らかの形で関連しているという事実）

wojtek-t 2018年03月06日

そして、あなたの数に関して-回帰が実行109であったとは確信していません-2つの回帰があった可能性があります-1つは105から108の間のどこかで、もう1つは109でです。

wojtek-t 2018年03月06日

うーん...私はあなたが言及した可能性を否定しません（上記は私の仮説にすぎませんでした）。
私は現在、検証のために二分法を実行しています（現在108のコミットに対して）。

shyamjvs 2018年03月06日

回帰が実行108の前であるという私の感覚はますます強くなっています。
例として、API呼び出しのレイテンシーは108回の実行ですでに増加しています。

パッチノードのステータス：
90％：198ms（105）447ms（108）444ms（109）

ポッドステータスを入力：
99％：83ms（105）657ms（108）728ms（109）

wojtek-t 2018年03月06日

私が言おうとしているのは：

429の数は結果であり、それに多くの時間を費やすべきではありません
根本的な原因は、API呼び出しが遅いか、それらの数が多いことです。

108では明らかに遅いAPI呼び出しが見られるようです。問題は、それらの数も多いかどうかです。

wojtek-t 2018年03月06日

だから私はなぜリクエストが目に見えて遅いのかと思います-3つの主な可能性があります

リクエストが大幅に増えています（一見したところ、そうではないようです）
処理のパスに何かを追加したか（追加の処理など）、オブジェクト自体が大きくなっています
マスターマシン上の他の何か（スケジューラーなど）がより多くのCPUを消費しているため、apiserverがさらに不足しています

wojtek-t 2018年03月06日

だから私と@ wojtek-tはオフラインで話し合ったが、108より前に回帰が起こる可能性が非常に高いことに同意した。いくつかのポイントを追加する：

リクエストが大幅に増えています（一見したところ、そうではないようです）

私にも当てはまらないようです

処理のパスに何かを追加したか（追加の処理など）、オブジェクト自体が大きくなっています

私の感じでは、apiserverとは対照的にkubeletの方が可能性が高いです（kubemark-5000のパッチ/プットのレイテンシーに目に見える変化は見られないため）

マスターマシン上の他の何か（スケジューラーなど）がより多くのCPUを消費しているため、apiserverがさらに不足しています

IMOは、マスターにかなりのCPU / memのたるみがあるため、そうではありません。また、perf-dashは、マスターコンポーネントの使用量が大幅に増加することを示唆していません。

そうは言っても、私は少し掘り下げて、「幸運なことに」、2kノードのクラスターでもウォッチのレイテンシーがこのように増加していることに気付いているようです。

INFO: perc50: 1.024377533s, perc90: 1.589770858s, perc99: 1.934099611s

INFO: perc50: 1.03503718s, perc90: 1.624451701s, perc99: 2.348645755s

二等分を少し簡単にする必要があります。

shyamjvs 2018年03月06日

残念ながら、これらの時計の待ち時間の変動は1回限りのようです（それ以外はほぼ同じです）。幸い、回帰の信頼できる指標としてPUT pod-statusレイテンシがあります。私は昨日2ラウンドの二等分線を実行し、この差分に絞り込みました（〜80コミット）。私はそれらをざっと見て、次のことを強く疑っています。

＃58990-pod-statusに新しいフィールドを追加します（ただし、IIUCプリエンプションが発生していないテストで入力されるかどうかはわかりませんが、確認する必要があります）
＃58645-etcdサーバーのバージョンを3.2.14に更新

shyamjvs 2018年03月07日

＃58990がここに関連していることを本当に疑っています-NominatedNodeNameは単一のノード名を含む文字列です。常にいっぱいになる場合でも、オブジェクトサイズの変化はごくわずかです。

wojtek-t 2018年03月07日

@ wojtek-t-オフラインで提案していたように、kubemark（https://github.com/kubernetes/kubernetes/blob/master/test/kubemark/）で別のバージョン（3.2.16）を使用しているようです。 start-kubemark.sh＃L62）これがこのリグレッションが表示されない潜在的な理由です:)

cc @jpbetz

shyamjvs 2018年03月07日

現在、どこでも3.2.16を使用しています。

wojtek-t 2018年03月07日

おっと..後知恵で申し訳ありません-私はコミットの間違った組み合わせを見ていました。

shyamjvs 2018年03月07日

ところで-PUTポッド/ステータスレイテンシの増加は、大規模な実際のクラスターでの負荷テストでも確認できます。

wojtek-t 2018年03月07日

だから私はもう少し掘り下げて、一般的に書き込み要求についてその頃により大きな待ち時間を観察し始めたようです（これは私にetcdの変更をさらに疑わせる）：

post-pod-binding
patch-node-status
post-replication-controllers

shyamjvs 2018年03月07日

実際、私は問題の少なくとも一部がここにあると投票します：
https://github.com/kubernetes/kubernetes/pull/58990/commits/384a86caa92bdb7cf9ac96b10a6ef333d2d60519#diff -c73f80ad83608f18657d22a06950d929R240

それが全体の問題だとしたら驚きますが、それが原因かもしれません。
すぐにそれを変更するPRを送信します。

wojtek-t 2018年03月07日

参考までに-etcd3.2.14の変更前であるが、ポッドステータスAPIの変更後のコミットに対して実行し

shyamjvs 2018年03月07日

そこで、3.2.14へのetcdバンプが原因であることを確認しました。 putpod-statusレイテンシーは次のようになります。

そのPRに対して：

{
      "data": {
        "Perc50": 1.479,
        "Perc90": 10.959,
        "Perc99": 163.095
      },
      "unit": "ms",
      "labels": {
        "Count": "344494",
        "Resource": "pods",
        "Scope": "namespace",
        "Subresource": "status",
        "Verb": "PUT"
      }
    },

そのPRが元に戻された〜HEAD（3月5日から）に対して（テストはまだ実行中ですが、まもなく終了します）：

apiserver_request_latencies_summary{resource="pods",scope="namespace",subresource="status",verb="PUT",quantile="0.5"} 1669
apiserver_request_latencies_summary{resource="pods",scope="namespace",subresource="status",verb="PUT",quantile="0.9"} 9597
apiserver_request_latencies_summary{resource="pods",scope="namespace",subresource="status",verb="PUT",quantile="0.99"} 63392

63msは以前と非常に似ている

バージョンを元に戻して、次のことを理解する必要があります。

etcd 3.2.14でこの増加が見られるのはなぜですか？
なぜこれをkubemarkで捕まえなかったのですか？

cc @jpbetz @ kubernetes / sig-api-machinery-bugs

shyamjvs 2018年03月07日

1つの仮説（kubemarkでそれをキャッチしなかった理由-それはまだ推測ですが）は、sthwrtをそこで証明書に変更した可能性があるというものです。
kubemarkと実際のクラスターからのetcdログを比較しているとき、後者でのみ次の行が表示されます。

2018-03-05 08:06:56.389648 I | embed: peerTLS: cert = /etc/srv/kubernetes/etcd-peer.crt, key = /etc/srv/kubernetes/etcd-peer.key, ca = , trusted-ca = /etc/srv/kubernetes/etcd-ca.crt, client-cert-auth = true

PR自体を調べても、その周りに変化は見られませんが、実際のクラスターでのみその行を表示する必要がある理由もわかりません...
考えのための

wojtek-t 2018年03月07日

ACK。進行中
ETA：2018年9月3日
リスク：根本原因の問題（主に）

shyamjvs 2018年03月07日

peerTLSに関して-以前も（3.1.11で）そうだったので、それは赤いニシンだと思います

wojtek-t 2018年03月07日

cc @gyuho @wenjiaswe

jpbetz 2018年03月07日

63msは何に非常に似ているようです

それらの番号はどこで入手できますか？ apiserver_request_latencies_summary実際にetcd書き込みのレイテンシーを測定していますか？また、etcdからのメトリックが役立ちます。

gyuho 2018年03月07日

埋め込み：peerTLS：証明書..。

ピアTLSが構成されている場合、これは出力されます（3.1と同じ）。

gyuho 2018年03月07日

それらの番号はどこで入手できますか？ apiserver_request_latencies_summaryは実際にetcd書き込みのレイテンシーを測定していますか？また、etcdからのメトリックが役立ちます。

これは、（少なくとも書き込み呼び出しの場合）etcdのレイテンシーを含むアピコールレイテンシーを測定します。
何が起こっているのかはまだよくわかりませんが、以前のetcdバージョン（3.1）に戻すと、リグレッションが修正されます。したがって、明らかに問題はetcdのどこかにあります。

wojtek-t 2018年03月07日

@shyamjvs

実行しているKubemarkとKubernetesのバージョンは何ですか？ Kubemark1.10をetcd3.2と3.3（500ノードのワークロード）に対してテストしましたが、これは観察されませんでした。これを再現するにはいくつのノードが必要ですか？

gyuho 2018年03月07日

実行しているKubemarkとKubernetesのバージョンは何ですか？ Kubemark1.10をetcd3.2と3.3（500ノードのワークロード）に対してテストしましたが、これは観察されませんでした。これを再現するにはいくつのノードが必要ですか？

5kノードのものでもkubemarkで再現することはできません-https ： //github.com/kubernetes/kubernetes/issues/60589#issuecomment-371171837の下部を参照して

これは、実際のクラスターでのみ問題になるようです。
これは未解決の質問です。なぜそうなるのですか。

wojtek-t 2018年03月07日

👍1

etcd3.1にロールバックしたので。 kubernetesの場合。また、etcd 3.1.12をリリースし、 mvcc「非同期」ウォッチャーの復元操作を追加しました。この問題で見つかったパフォーマンス低下の根本原因を見つけて修正したら、kubernetesで使用されるetcdサーバーを3.2にアップグレードする計画をスケッチできます。

jpbetz 2018年03月08日

https://k8s-testgrid.appspot.com/sig-release-master-blocking#gci -gce-100は、今朝から一貫して失敗し始めているようです

krzyzacy 2018年03月09日

差分からの唯一の変更はhttps://github.com/kubernetes/kubernetes/pull/60421で、これはデフォルトでパフォーマンステストでクォータを有効にしています。私たちが見ているエラーは次のとおりです。

Container kube-controller-manager-e2e-big-master/kube-controller-manager is using 0.531144723/0.5 CPU
not to have occurred

@ gmarek-クォータを有効にすることがスケーラビリティに影響を与えているようです:)これを詳しく調べて
これを軌道に乗せるために別の問題を提出させてください。

shyamjvs 2018年03月09日

@ wojtek-t @jpbetz @gyuho @timothysc etcdのバージョン変更で本当に面白いものを見つけました。これは、etcd3.1.11から3.2.16への移行の大きな効果を示唆しています。

ジョブがk8sリリース1.9から1.10に移動されたときの、100ノードクラスター（約2倍に増加）のetcdメモリ使用量の次のグラフを見てください。

1 9-1 10-etcd-mem-usage

次に、100ノードのジョブ（HEADに対して実行）で、etcd 3.2.16-> 3.1.11から戻った直後に、メモリ使用量が半分に減少する様子を見てみましょう。

3 2 16-3 1 11-etcd-change

したがって、etcd 3.2サーバーバージョンCLEARLYは、影響を受けるパフォーマンスを示しています（他のすべての変数は同じままです）:)

shyamjvs 2018年03月10日

etcdからの復帰3.2.16-> 3.2.11：

3.1.11のことですか？

gyuho 2018年03月10日

そうです..ごめんなさい。コメントを編集しました。

shyamjvs 2018年03月10日

@shyamjvs etcdはどのように構成されていますか？ v3.2では、デフォルト値--snapshot-countが10000から100000に増加しました。したがって、スナップショット数が異なる場合、スナップショット数が多い方がRaftエントリをより長く保持するため、古いログを破棄する前に、より多くの常駐メモリが必要になります。

gyuho 2018年03月10日

ああ！それは確かに疑わしい変化のようです。フラグについては、k8s側からの変更はないと思います。なぜなら、上の2番目のグラフでわかるように、 diff b / wは11450を実行し、11451は主に私のetcdの元に戻す変更です（フラグには触れていないようです）。

デフォルト値--snapshot-countを10000から100000に増やしました

これがmemの使用量の増加の根本原因であるかどうかを確認できますか？もしそうなら、私たちはしたいかもしれません：

etcdを元の値でパッチバックする、または
k8sで10000に設定します

3.2に戻す前に

shyamjvs 2018年03月10日

ああ！それは確かに疑わしい変化のようです。

ええ、この変更はetcd側から強調表示されているはずです（変更ログとアップグレードガイドが改善されます）。

これがmemの使用量の増加の根本原因であるかどうかを確認できますか？

それが根本的な原因かどうかはわかりません。スナップショット数を減らすと、急激なメモリ使用量を確実に軽減できます。両方のetcdバージョンが同じスナップショット数を使用しているが、一方のetcdが依然としてはるかに高いメモリ使用量を示している場合は、別の何かがあるはずです。

gyuho 2018年03月10日

更新：etcd memの使用量の増加は、-snapshot-countのデフォルト値が高いために実際に発生していることを確認しました。詳細はこちら-https ： //github.com/kubernetes/kubernetes/pull/61037#issuecomment-372457843

memの使用量を増やしたくない場合は、etcd3.2.16にぶつかるときに10,000に設定することを検討する必要があります。

cc @gyuho @ xiang90 @jpbetz

shyamjvs 2018年03月12日

👍1

更新：etcdの修正を加えても、ポッドの起動待ち時間99％は、5sSLOに違反しそうです。他に少なくとも1つの回帰があり、5kノードパフォーマンスジョブのb / w実行111および112で最も可能性が高いという証拠を収集しました（https：/に貼り付けたグラフでこれらの実行のバンプb / wを参照してください）。 /github.com/kubernetes/kubernetes/issues/60589#issuecomment-370568929）。現在、差分（約50のコミットがあります）を二等分しており、テストには反復ごとに最大4〜5時間かかります。

私が上で言及した証拠は次のとおりです。

111でのウォッチレイテンシは次のとおりです。

Feb 14 21:36:05.531: INFO: perc50: 1.070980786s, perc90: 1.743347483s, perc99: 2.629721166s

そして、111での全体的なポッド起動待ち時間は次のとおりです。

Feb 14 21:36:05.671: INFO: perc50: 2.416307575s, perc90: 3.24553118s, perc99: 4.092430858s

112で同じでしたが：

Feb 16 10:07:43.222: INFO: perc50: 1.131108849s, perc90: 2.18487651s, perc99: 3.570548412s

そして

Feb 16 10:07:43.353: INFO: perc50: 2.56160248s, perc90: 3.754024568s, perc99: 4.967573867s

一方、誰かが賭けゲームに参加している場合は、上記のコミット差分を見て、欠陥のあるものを推測することができます:)

shyamjvs 2018年03月12日

ACK。進行中
ETA：2018年3月13日
リスク：それ以前にデバッグされていない場合、リリース日をプッシュできます

shyamjvs 2018年03月12日

@shyamjvstooooooooo多くのコミットが賭けをします:)

dims 2018年03月13日

@dimsそれは私が推測するより多くの楽しみを追加するでしょう;）

更新：それで、私は二分法を数回繰り返しました。これは、関連するメトリックがコミット全体でどのように見えるかを示しています（時系列で並べられています）。手動で実行したものについては、以前の回帰を元に戻して実行したことに注意してください（つまり、3.2。-> 3.1.11）。

| コミット| 99％の時計の待ち時間| 99％のポッド起動待ち時間| 良し悪し？ |
| ------------- | ------------- | ----- | ------- |
| a042ecde36（run-111から）| 2.629721166s | 4.092430858s | 良い（手動で再度確認）|
| 5f7b530d87（手動）| 3.150616856s | 4.683392706s | 悪い（可能性が高い）|
| a8060ab0a1（手動）| 3.11319985s | 4.710277511s | 悪い（可能性が高い）|
| 430c1a68c8（run-112から）| 3.570548412s | 4.967573867s | 悪い|
| 430c1a68c8（手動）| 3.63505091s | 4.96697776s | 悪い|

上記から、ここでは2つの回帰があるようです（2.6s-> 3.6sからの直線ジャンプではないため）-1つのb / w "a042ecde36-5f7b530d87"と他のb / w "a8060ab0a1-430c1a68c8"。はぁ！

shyamjvs 2018年03月13日

比較リンクを取得するための範囲として表現する：
a042ecde36 ... 5f7b530
a8060ab0a1 ... 430c1a6

liggitt 2018年03月13日

a042ecde36に対する手動実行の結果を取得したばかりであり、それは人生を困難にするだけです。

3.269330734s (watch), 4.939237532s (pod-startup)

これはおそらく、不安定な回帰である可能性があることを意味します。

shyamjvs 2018年03月13日

私は現在、a042ecde36に対してもう一度テストを実行して、それ以前でも回帰が発生した可能性を確認しています。

shyamjvs 2018年03月13日

したがって、a042ecdに対して再度実行した結果は次のとおりです。

2.645592996s (watch), 5.026010032s (pod-startup)

これはおそらく、run-111の前でも回帰が入力されたことを意味します（現在、二分法の右端があることは朗報です）。
私は今、左端を追求しようとします。 Run-108（commit 11104d75f）は潜在的な候補であり、以前に実行したときに次の結果が得られました（etcd 3.1.11を使用）。

2.593628224s (watch), 4.321942836s (pod-startup)

shyamjvs 2018年03月13日

👍1

コミット11104d7に対する私の再実行は、それが良いものだと言っているようです。

2.663456162s (watch), 4.288927203s (pod-startup)

ここで11104d7 ... a042ecdの範囲で二等分線を突き刺します

shyamjvs 2018年03月13日

更新：信頼を得るために、コミット097efb71a315を3回テストする必要がありました。それはかなりの差異を示していますが、良いコミットのようです：

2.578970061s (watch), 4.129003596s (pod-startup)
2.315561531s (watch), 4.70792639s (pod-startup)
2.303510957s (watch), 3.88150234s (pod-startup)

私はさらに二等分し続けます。
とは言うものの、ほんの数日前にポッドの起動待ち時間に（約1秒の）別のスパイクがあったようです。そしてこれは99％をほぼ6秒に押し上げています：

increase_again

commit diffからの私の主な疑いは、3.1.11-> 3.1.12（https://github.com/kubernetes/kubernetes/pull/60998）からのetcdの変更です。次の実行（現在進行中）が1回限りではないことを確認するのを待ちますが、これを本当に理解する必要があります。

cc @jpbetz @gyuho

shyamjvs 2018年03月14日

今週は木曜日から金曜日に休暇を取るので、5kノードクラスターに対して密度テストを実行するための指示を貼り付けています（プロジェクトにアクセスできる人が二分法を続行できるようにするため）。

# Start with a clean shell.
# Checkout to the right commit.
make quick-release

# Set the project:
gcloud config set project k8s-scale-testing

# Set some configs for creating/testing 5k-node cluster:
export CLOUDSDK_CORE_PRINT_UNHANDLED_TRACEBACKS=1
export KUBE_GCE_ZONE=us-east1-a
export NUM_NODES=5000
export NODE_SIZE=n1-standard-1
export NODE_DISK_SIZE=50GB
export MASTER_MIN_CPU_ARCHITECTURE=Intel\ Broadwell
export ENABLE_BIG_CLUSTER_SUBNETS=true
export LOGROTATE_MAX_SIZE=5G
export KUBE_ENABLE_CLUSTER_MONITORING=none
export ALLOWED_NOTREADY_NODES=50
export KUBE_GCE_ENABLE_IP_ALIASES=true
export TEST_CLUSTER_LOG_LEVEL=--v=1
export SCHEDULER_TEST_ARGS=--kube-api-qps=100
export CONTROLLER_MANAGER_TEST_ARGS=--kube-api-qps=100\ --kube-api-burst=100
export APISERVER_TEST_ARGS=--max-requests-inflight=3000\ --max-mutating-requests-inflight=1000
export TEST_CLUSTER_RESYNC_PERIOD=--min-resync-period=12h
export TEST_CLUSTER_DELETE_COLLECTION_WORKERS=--delete-collection-workers=16
export PREPULL_E2E_IMAGES=false
export ENABLE_APISERVER_ADVANCED_AUDIT=false

# Bring up the cluster (this brings down pre-existing one if present, so you don't have to explicitly '--down' the previous one) and run density test:
go run hack/e2e.go \
--up \
--test \
--test_args='--ginkgo.focus=\[sig\-scalability\]\sDensity\s\[Feature\:Performance\]\sshould\sallow\sstarting\s30\spods\sper\snode\susing\s\{\sReplicationController\}\swith\s0\ssecrets\,\s0\sconfigmaps\sand\s0\sdaemons$ --allowed-not-ready-nodes=30 --node-schedulable-timeout=30m --minStartupPods=8 --gather-resource-usage=master --gather-metrics-at-teardown=master' \
> somepath/build-log.txt 2>&1 

# To re-run the test on same cluster (without re-creating) just omit '--up' in the above.

重要な注意事項：

疑われる現在のコミット範囲はff7918d ... a042ecde3です（二分するときにこれを更新し続けましょう）
3.2.14の代わりにetcd-3.1.11を使用する必要があります（以前の回帰が含まれないようにするため）。次のファイルのバージョンを変更して、最小限の方法でそれを実現します。
- cluster / gce / manifests / etcd.manifest
- cluster / images / etcd / Makefile
- hack / lib / etcd.sh

shyamjvs 2018年03月14日

cc：@ wojtek-t

jdumars 2018年03月14日

etcd v3.1.12は、復元時のウォッチイベントのミスを修正します。そして、これはv3.1.11から行った唯一の変更です。パフォーマンステストには、リーダーからのスナップショットをトリガーする可能性のあるetcd再起動またはマルチノードの何かが含まれますか？

gyuho 2018年03月14日

パフォーマンステストには、etcdの再起動を伴うものが含まれますか

etcdログから、再起動がなかったようです。

マルチノード

セットアップでは単一ノードのetcdのみを使用しています（それがあなたの質問であると仮定しています）。

shyamjvs 2018年03月14日

そうですか。その場合、v3.1.11とv3.1.12に違いはありません：0
2回目の実行でも待ち時間が長くなる場合は、もう一度確認します。

gyuho 2018年03月14日

cc： @jpbetz

jdumars 2018年03月14日

etcdへの唯一のコード変更がコードの再起動/回復のために分離されていることを考えると、これについてより強力なシグナルを取得するように努めるべきであるという

その他の唯一の変更は、etcdのgo1.8.5からgo1.8.7へのアップグレードですが、これによってパフォーマンスが大幅に低下するかどうかは疑わしいです。

jpbetz 2018年03月14日

👍1

したがって、二分法を続けると、ff7918d1fは良いようです。

2.246719086s (watch), 3.916350274s (pod-startup)

それに応じて、 https： //github.com/kubernetes/kubernetes/issues/60589#issuecomment-373051051のコミット範囲を更新し

shyamjvs 2018年03月14日

次に、コミットaa19a1726は良いもののようですが、確認のためにもう一度再試行することをお勧めします。

2.715156606s (watch), 4.382527095s (pod-startup)

この時点で、二分法を一時停止して休暇を開始します:)
次の実行のためのスペースを確保するために、クラスターをダウンさせました。

shyamjvs 2018年03月15日

シャムありがとう。 aa19a172693a4ad60d5a08e9b93557267d259c37を再試行しています。

wasylkowski-a 2018年03月15日

コミットaa19a172693a4ad60d5a08e9b93557267d259c37の場合、次の結果が得られました。

2.47655243s (watch), 4.174016696s (pod-startup)

だからこれはよさそうだ。継続的な二分。

疑わしい現在のコミット範囲：aa19a172693a4ad60d5a08e9b93557267d259c37 ... a042ecde362000e51f1e7bdbbda5bf9d81116f84

wasylkowski-a 2018年03月15日

👍1

@ wasylkowski-a午後5時UTC / 1午後東部/ 10AM太平洋でのリリースミーティングに参加できますか？ズームミーティングです： https ：

jdumars 2018年03月15日

参加します。

wasylkowski-a 2018年03月15日

コミットcca7ccbff161255292f72c2d18459cdface62122は不明瞭に見え、次の結果が得られます。

2.984185673s (watch), 4.568914929s (pod-startup)

二分法の間違った半分に入らないという確信を得るために、これをもう一度実行します。

wasylkowski-a 2018年03月15日

👍1

OK、それで私はcca7ccbff161255292f72c2d18459cdface62122が悪いとかなり確信しています：

3.285168535s (watch), 4.783986141s (pod-startup)

範囲をaa19a172693a4ad60d5a08e9b93557267d259c37 ... cca7ccbff161255292f72c2d18459cdface62122にトリミングし、92e4d3da0076f923a45d54d69c84e91ac6a61a55を試してみます。

wasylkowski-a 2018年03月16日

コミット92e4d3da0076f923a45d54d69c84e91ac6a61a55は良さそうです：

2.522438984s (watch), 4.21739985s (pod-startup)

新しい疑わしいコミット範囲は92e4d3da0076f923a45d54d69c84e91ac6a61a55 ... cca7ccbff161255292f72c2d18459cdface62122で、603ebe466d335a37392315d491782ed18d1bae11を試しています。

wasylkowski-a 2018年03月16日

@wasylkowskiコミットの1つ、つまりhttps://github.com/kubernetes/kubernetes/commit/4c289014a05669c376994868d8d91f7565a204b5がください

dims 2018年03月16日

👍1

@dimsコメントをより明確に言い換えると、ここの二分法でシグナルゴーストを追いかけている可能性があります。 4c28901が問題であり、一見無関係な理由ですでに493f335に戻っている場合、1.10ブランチヘッドに対するスケーラビリティテストで緑色の信号が表示されますか？

二分法を継続するのではなく、1.10ブランチヘッドに対して1回の再テストを優先できますか？

tpepper 2018年03月16日

@wasylkowski / @ wasylkowski-a ^^^^

tpepper 2018年03月16日

@ wojtek-t PTAL ASAP

jdumars 2018年03月16日

@dimsと@tpepperに感謝します。 1.10ブランチヘッドに対して試してみて、何が起こるか見てみましょう。

wasylkowski-a 2018年03月16日

@wasylkowskiの最悪のケースに感謝します。以前に二等分していたものに戻ります。正しい？

dims 2018年03月16日

1.10ヘッドにリグレッションがあります：

3.522924087s (watch), 4.946431238s (pod-startup)

これはetcd3.1.11ではなくetcd3.1.12にありますが、私が正しく理解していれば、これは大きな違いにはならないはずです。

また、603ebe466d335a37392315d491782ed18d1bae11は良さそうです。

2.744654024s (watch), 4.284582476s (pod-startup)
2.76287483s (watch), 4.326409841s (pod-startup)
2.560703844s (watch), 4.213785531s (pod-startup)

これにより、範囲603ebe466d335a37392315d491782ed18d1bae11 ... cca7ccbff161255292f72c2d18459cdface62122が残り、コミットは3つだけになります。私が見つけたものを見てみましょう。

実際に4c289014a05669c376994868d8d91f7565a204b5がここの原因である可能性もありますが、それは、頭に現れる別の回帰があることを意味します。

wasylkowski-a 2018年03月16日

👍1

OK、明らかにコミット6590ea6d5d50700d34255b1e037b2702ad26b7fcは良いです：

2.553170576s (watch), 4.22516704s (pod-startup)

コミット7b678dc4035c61a1991b5e1442edb13f40deae72が悪い間：

3.498855918s (watch), 4.886599251s (pod-startup)

悪いコミットは@dimsによって言及された元に戻されたコミットのマージであるため、頭の中で別のリグレッションを観察する必要があります。

3.1.12ではなくetcd3.1.11でヘッドを再実行して、何が起こるか見てみましょう。

wasylkowski-a 2018年03月17日

@ wasylkowski-ああ古典的な良いニュース悪いニュース:)これを続けてくれてありがとう。

@ wojtek-t他に何か提案はありますか？

dims 2018年03月17日

etcd3.1.11に向かうのも悪いです。私の次の試みは、復帰の直後に試みることです（つまり、commit cdecea545553eff09e280d389a3aef69e2f32bf1で）が、3.2.14ではなくetcd3.1.11を使用します。

wasylkowski-a 2018年03月17日

いいですねAndrzej

-薄暗い

2018年3月17日には、13:19で、アンジェイWasylkowski [email protected]書きました：
etcd3.1.11に向かうのも悪いです。私の次の試みは、復帰の直後に（つまり、commit cdecea5で）試行することですが、3.2.14ではなくetcd3.1.11を使用します。
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

dims 2018年03月17日

コミットcdecea545553eff09e280d389a3aef69e2f32bf1は適切なので、後で回帰します。

2.66454307s (watch), 4.308091589s (pod-startup)

wasylkowski-a 2018年03月17日

コミット2a373ace6eda6a9cf050ce70a6cf99183c5e5b37は明らかに悪いです：

3.656979569s (watch), 6.746987916s (pod-startup)

wasylkowski-a 2018年03月17日

@ wasylkowski-aつまり、基本的にhttps://github.com/kubernetes/kubernetes/compare/cdecea5...2a373acの範囲のコミットを調べて、何が問題なのかを確認しています。（これら2つの間で二等分を実行します）？

dims 2018年03月17日

はい。残念ながら、これは非常に広い範囲です。現在、aded0d922592fdff0137c70443caf2a9502c7580を調査しています。

wasylkowski-a 2018年03月17日

ありがとう@wasylkowski現在の範囲は何ですか？（だから私はPRを見に行くことができます）。

dims 2018年03月18日

👍1

コミットaded0d922592fdff0137c70443caf2a9502c7580が悪い：

3.626257043s (watch), 5.00754503s (pod-startup)

コミットf8298702ffe644a4f021e23a616ad6a8790a5537も悪いです：

3.747051371s (watch), 6.126914967s (pod-startup)

コミット20a6749c3f86c7cb9e98442046532380fb5f6e36もそうです：

3.641172882s (watch), 5.100922237s (pod-startup)

0e81651e77e0be7e75179e5986ef2c76601f4bd6も同様です。

3.687028394s (watch), 5.208157763s (pod-startup)

現在の範囲はcdecea545553eff09e280d389a3aef69e2f32bf1 ... 0e81651e77e0be7e75179e5986ef2c76601f4bd6です。私たち（私、@ wojtek-t、@ shyamjvs）は、cdecea545553eff09e280d389a3aef69e2f32bf1が実際には不安定なパスであると疑うようになっているため、別の左端が必要です。

wasylkowski-a 2018年03月19日

/ meは、犯人としてhttps://github.com/kubernetes/kubernetes/commit/b259543985b10875f4a010ed0285ac43e335c8e0に賭け

cc @ wasylkowski-a

dims 2018年03月19日

0e81651e77e0be7e75179e5986ef2c76601f4bd6は悪いことが判明したので、b259543985b10875f4a010ed0285ac43e335c8e0（244549f02afabc5be23fc56e84としてマージされました）

wasylkowski-a 2018年03月19日

@ wojtek-tと@shyamjvsによると、

wasylkowski-a 2018年03月19日

私が観察した以下の結果に基づいて、cdecea545553eff09e280d389a3aef69e2f32bf1は実際に良好であると想定します。

2.66454307s (watch), 4.308091589s (pod-startup)
2.695629257s (watch), 4.194027608s (pod-startup)
2.660956347s (watch), 3m36.62259323s (pod-startup) <-- looks like an outlier
2.865445137s (watch), 4.594671099s (pod-startup)
2.412093606s (watch), 4.070130529s (pod-startup)

wasylkowski-a 2018年03月20日

現在疑われる範囲：cdecea545553eff09e280d389a3aef69e2f32bf1 ... 0e81651e77e0be7e75179e5986ef2c76601f4bd6

現在99c87cf679e9cbd9647786bf7e81f0a2d771084fをテスト中

wasylkowski-a 2018年03月20日

👍2

この作業を続けてくれてありがとう@wasylkowski 。

jdumars 2018年03月20日

今日のディスカッションごと：fluentd-scalerにはまだ問題があります： https ：

jberkus 2018年03月20日

fluentdhttps ：//github.com/kubernetes/kubernetes/commit/a88ddac1e47e0bc4b43bfa1b0df2f19aea4455f2に関連するPRの1つが最新の範囲にあります

dims 2018年03月20日

今日の議論によると：fluentd-scalerにはまだ問題があります：＃61190、PRによって修正されていません。このリグレッションがfluentdによって引き起こされる可能性はありますか？

TBH、流暢な問題が原因だとしたら、私は本当に驚きます。しかし、私はこの仮説を確実に排除することはできません。
私の個人的な気持ちはクベレットの変化かもしれませんが、私はその範囲のPRも調べましたが、本当に疑わしいものは何もありません...
うまくいけば、範囲は明日4分の1になります。つまり、PRが2つだけになることを意味します。

wojtek-t 2018年03月20日

OK、99c87cf679e9cbd9647786bf7e81f0a2d771084fは良さそうですが、これがフレークでないことを確認するために3回の実行が必要でした。

2.901624657s (watch), 4.418169754s (pod-startup)
2.938653965s (watch), 4.423465198s (pod-startup)
3.047455619s (watch), 4.455485098s (pod-startup)

次に、a88ddac1e47e0bc4b43bfa1b0df2f19aea4455f2が悪いです：

3.769747695s (watch), 5.338517616s (pod-startup)

現在の範囲は99c87cf679e9cbd9647786bf7e81f0a2d771084f ... a88ddac1e47e0bc4b43bfa1b0df2f19aea4455f2です。 c105796e4ba7fc9cfafc2e7a3cc4a556d7d9defdを分析しています。

wasylkowski-a 2018年03月20日

したがって、ここには2つの候補があると思います： https ： https://github.com/kubernetes/kubernetes/pull/59808
それらを理解するために、それらをより深く掘り下げてみます。

wojtek-t 2018年03月21日

👍1

c105796e4ba7fc9cfafc2e7a3cc4a556d7d9defdはかなり悪いように見えます：

3.428891786s (watch), 4.909251611s (pod-startup)

これがWojtekの容疑者の1人である＃59953のマージであることを考えると、その前に1つのコミットで実行するので、f60083549a43f152b3142e01756e25611d911770です。

ただし、そのコミットはOWNERS_ALIASESの変更であり、その前にその範囲に何も残っていないため、c105796e4ba7fc9cfafc2e7a3cc4a556d7d9defdが問題である必要があります。とにかく、安全のためだけにテストを実行します。

wasylkowski-a 2018年03月21日

オフラインで議論-代わりにこのコミットをローカルに戻した状態で、最初にテストを実行します。

wojtek-t 2018年03月21日

うわー！ワンライナーはとてもトラブルを引き起こします。ありがとう@ wasylkowski @ wojtek-t

dims 2018年03月21日

@dimsワンライナーは確かにスケーラビリティで荒廃を引き起こす可能性があります。別の例：過去から-https：//github.com/kubernetes/kubernetes/pull/53720#issue-145949976
一般的に、https：//github.com/kubernetes/community/blob/master/sig-scalability/blogs/scalability-regressions-case-studies.mdをよく読んでください:)

shyamjvs 2018年03月21日

❤2 🎉1

再更新します。ヘッドでのテスト：最初に、ローカルに戻されたコミットを渡して実行します。ただし、これはフレークの可能性があるため、再実行します。

wasylkowski-a 2018年03月21日

🎉1

https：//github.com/kubernetes/kubernetes/pull/59953のコミットを見て

liggitt 2018年03月21日

@ Random-Liu誰がその変更の影響をよりよく説明できるかもしれません:)

shyamjvs 2018年03月21日

＃59953のコミットを見ると...バグを修正していませんか？「スケジュール済み」ステータスを間違ったオブジェクトに配置するバグを修正しているようです。 kubeletは、ポッドが修正される前にスケジュールが早すぎると報告していた可能性がありますか？

ええ-バグ修正だったと思います。私はそれを完全には理解していません。
ポッドレポートの問題が「スケジュール済み」として修正されたようです。しかし、kubeletによって「StartedAt」として報告されるまで、問題は発生しません。
問題は、Kubeletによって「StartedAt」として報告された時間と、ポッドステータスの更新が報告され、テストによって監視されている時間との間に大幅な増加が見られることです。
ですから、ここでは「スケジュール済み」ビットは赤字だと思います。

私の推測（ただし、これはまだ単なる推測です）は、この変更により、ポッドステータスの更新がさらに送信され、その結果、429またはそのようなsthが増えるということです。そして最終的には、Kubeletがポッドのステータスを報告するのにより多くの時間がかかります。しかし、それはまだ確認する必要があります。

wojtek-t 2018年03月21日

2回実行した後、＃59953を元に戻すと問題が解決することを確信しています。

3.052567319s (watch), 4.489142104s (pod-startup)
2.799364978s (watch), 4.385999497s (pod-startup)

wasylkowski-a 2018年03月21日

より多くのポッドステータスの更新を送信しているため、429またはそのようなsthが増えています。そして最終的には、Kubeletがポッドのステータスを報告するのにより多くの時間がかかります。

これは、 https： //github.com/kubernetes/kubernetes/issues/60589#issuecomment -370573938で私が仮定していた効果とほぼ同じです（私が推測した原因は間違っていましたが）:)
また、IIRCではプットコールの429の数が増加しているように見えましたが（私のhttps://github.com/kubernetes/kubernetes/issues/60589#issuecomment-370582634を参照）、それは私が思う以前の範囲からでした（ etcdの変更の周り）。

shyamjvs 2018年03月21日

2回実行した後、＃59953を元に戻すと問題が解決することを確信しています。

問題がかなり早い段階でkubelet側にあることについての私の直感（https://github.com/kubernetes/kubernetes/issues/60589#issuecomment-370874602）は、結局のところ正しかったです:)

shyamjvs 2018年03月21日

🎉1

/ sigノード
@ kubernetes / sig-node-bugsリリースチームは、＃59953コミットとリバートのレビューとパフォーマンスの問題をここで実際に使用できます

tpepper 2018年03月21日

＃59953のコミットを見ると...バグを修正していませんか？「スケジュール済み」ステータスを間違ったオブジェクトに配置するバグを修正しているようです。そのPRで参照されている問題に基づくと、その修正なしでポッドがスケジュールされたという報告をkubeletが見逃す可能性があるようです。

@liggittこれを説明してくれてありがとう。ええ、そのPRはバグを修正しています。以前は、kubeletが常にPodScheduled設定するとは限りません

@shyamjvsポッドステータスの更新をさらに導入できるかどうかは
私が正しく理解していれば、 PodScheduled条件は最初のステータス更新で設定され、その後は常に存在し、変更されることはありません。なぜステータスアップデートが増えるのかわかりません。

それが本当により多くのステータス更新を導入する場合、それは2年前に導入された問題ですhttps://github.com/kubernetes/kubernetes/pull/24459がバグでカバーされており、＃59953はバグを修正するだけです...

@ wasylkowski-a https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -374982422およびhttps://github.com/kubernetes/kubernetes/issues/60589#に、2回のテスト実行のログがあり

Random-Liu 2018年03月21日

@yujuhongと私は、＃59953が静的ポッドのPodScheduled状態が更新され続けるという問題を明らかにしたことを発見しました。

Kubeletは、それを持たないポッドに対して新しいPodScheduled条件を生成します。静的ポッドにはそれがなく、そのステータスは更新されません（予期される動作）。したがって、kubeletは静的ポッドの新しいPodScheduled条件を生成し続けます。

この問題は＃24459で導入されましたが、バグでカバーされています。＃59953はバグを修正し、元の問題を公開しました。

これをすばやく修正するには、2つのオプションがあります。

オプション1：kubeletにPodScheduled条件を追加させないでください。kubeletは、スケジューラーによって設定されたPodScheduled条件を保持する必要があります。
- 長所：シンプル。
- 短所：静的ポッドとスケジューラーをバイパスする（ノード名を直接割り当てる）ポッドには、 PodScheduled条件がありません。実際には＃59953なしで、kubeletは最終的にこれらのポッドにこの条件を設定しますが、バグのために非常に長い時間がかかる場合があります。
オプション2：kubeletが最初に静的ポッドを確認したときに、静的ポッドのPodScheduled条件を生成します。

オプション2では、ユーザーが直面する変更が少なくなる可能性があります。

しかし、スケジューラーによってスケジュールされていないポッドにとって、 PodScheduledは何を意味するのでしょうか。これらのポッドには本当にこの条件が必要ですか？ / cc @ kubernetes / sig-autoscaling-bugs @yujuhongから、 PodScheduledが現在自動スケーリングで使用されていると言われたためです。
/ cc @ kubernetes / sig-node-bugs @ kubernetes / sig-scheduling-bugs

Random-Liu 2018年03月21日

@ Random-Liu very long time for kubelet to eventually set this conditionの効果は何ですか？エンドユーザーは（テストハーネスのフレークネス以外で）どのような問題に気づきますか？（オプション＃1から）

dims 2018年03月21日

@dimsユーザーには、 PodScheduled状態が長時間表示されません。

Random-Liu 2018年03月21日

https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -375103979にオプション2を実装する修正＃61504があります。

人々がそれがより良い修正であると考えるならば、私はそれをオプション1に変えることができます。 :)

Random-Liu 2018年03月21日

これを裏返しに知っている人に聞いた方がいいです！（リリースチームではありません😄！）

ping @dashpole @ dchen1107 @derekwaynecarr

dims 2018年03月21日

@ Random-Liu IIRCは、テストでノード上で実行されている唯一の静的ポッドはkube-proxyです。これらの「継続的な更新」がkubeletによって行われる頻度を教えてください。（バグによって導入された追加のqpsを見積もるために尋ねる）

shyamjvs 2018年03月21日

@ Random-Liu IIRCは、テストでノード上で実行されている唯一の静的ポッドはkube-proxyです。これらの「継続的な更新」がkubeletによって行われる頻度を教えてください。（バグによって導入された追加のqpsを見積もるために尋ねる）

@shyamjvsええ、 kube-proxyは現在ノード上にある唯一のものです。

ポッドの同期頻度https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/apis/kubeletconfig/v1beta1/defaults.go#L47に依存すると思います。これは1分です。したがって、kubeletは1分ごとに1つの追加のポッドステータス更新を生成します。

Random-Liu 2018年03月22日

ありがとう。つまり、ポッドステータス呼び出しが行われるため、5000/60 = 〜83qpsが追加されます。バグで前述した429の増加を説明しているようです。

shyamjvs 2018年03月22日

👍1

@ Random-Liuは、これを分類するのを手伝ってくれてありがとう。

jdumars 2018年03月22日

@jdumars np〜 @ yujuhongは私を大いに助けてくれました！

Random-Liu 2018年03月22日

しかし、PodScheduledがスケジューラーによってスケジュールされていないポッドにとって何を意味するのかを知りたいですか？これらのポッドには本当にこの条件が必要ですか？ / cc @ kubernetes / sig-autoscaling-bugs @yujuhongから、PodScheduledは現在自動スケーリングで使用されていると言われたため

kubeletにPodScheduled条件を設定させるのは、まだ少し奇妙だと思います（元のPRで述べたように）。 kubeletがこの条件を設定していなくても、オートスケーラーは特定の条件なしでポッドを無視するため、クラスターオートスケーラーには影響しません。とにかく、私たちが最終的に思いついた修正は、フットプリントが非常に小さく、現在の動作を維持する（つまり、常にPodScheduled条件を設定する）ので、それを使用します。

yujuhong 2018年03月22日

👍1

また、定常状態のポッド更新レート＃14391のテストを追加するための非常に古い問題を復活させました

yujuhong 2018年03月22日

とにかく、私たちが最終的に思いついた修正は、フットプリントが非常に小さく、現在の動作を維持する（つまり、常にPodScheduled条件を設定する）ので、それを使用します。

@ yujuhong-あなたはこれについて話している：＃61504（または私はそれを誤解していますか）？

@wasylkowski @ shyamjvs -PRをローカルにパッチした（マージする前に）5000ノードのテストを実行して、これが本当に役立つことを確認してください。

wojtek-t 2018年03月22日

1.10 HEAD +＃61504に対してテストを実行しましたが、ポッドの起動待ち時間は問題ないようです。

INFO: perc50: 2.594635536s, perc90: 3.483550118s, perc99: 4.327417676s

確認のためにもう一度実行します。

shyamjvs 2018年03月22日

❤1 🎉1 👍1

@ shyamjvs-どうもありがとう！

wojtek-t 2018年03月22日

2回目の実行も良さそうです：

INFO: perc50: 2.583489146s, perc90: 3.466873901s, perc99: 4.380595534s

修正がうまくいったので、かなり自信があります。できるだけ早く1.10に入れましょう。

shyamjvs 2018年03月22日

ありがとう@shyamjvs

オフラインで話したとき、先月かそこらでもう1つリグレッションが発生したと思いますが、リリースをブロックするべきではありません。

wojtek-t 2018年03月22日

@ yujuhong-あなたはこれについて話している：＃61504（または私はそれを誤解していますか）？

うん。そのPRの現在の修正は、 https： //github.com/kubernetes/kubernetes/issues/60589#issuecomment-375103979で最初に提案されたオプションには含まれていません

yujuhong 2018年03月22日

良好なパフォーマンステスト結果が得られるまで、再度開きます。

jberkus 2018年03月25日

@yujuhong @krzyzacy @shyamjvs @ wojtek-t @ Random-Liu @ wasylkowski-これに関する更新はありますか？これは現時点ではまだ1.10をブロックしています。

jdumars 2018年03月26日

したがって、リリースをブロックしていたこのバグの唯一の部分は、5kノードのパフォーマンスジョブです。残念ながら、別の理由で今日から実行を失いました（参照：https：//github.com/kubernetes/kubernetes/issues/61190#issuecomment-376150569）

とはいえ、手動での実行に基づいて修正が機能することはかなり確信しています（結果はhttps://github.com/kubernetes/kubernetes/issues/60589#issuecomment-375350217に貼り付けられています）。したがって、私見では、リリースをブロックする必要はありません（次の実行は水曜日に行われます）。

shyamjvs 2018年03月26日

+1
@ jdumars-これを非ブロッカーとして扱うことができると思います。

wojtek-t 2018年03月26日

申し訳ありませんが、上記の投稿を編集しました。私たちはそれを「非ブロッカー」として扱うべきだという意味でした。

wojtek-t 2018年03月26日

はい、ありがとうございます。この結論は、あなたが多大な時間を費やしたことを表しており、あなたが行った作業に対して十分に感謝することはできないでしょう。「コミュニティ」と「貢献者」について要約で話している間、あなたとこの問題に取り組んだ他の人々はそれを具体的に表現しています。あなたはこのプロジェクトの真髄であり、そのような情熱、献身、そしてプロ意識と一緒に働くことを光栄に思うとき、私は関係者全員のために話すことを知っています。

jdumars 2018年03月26日

[MILESTONENOTIFIER]マイルストーンの問題：プロセスの最新情報

@krzyzacy @ msau42 @shyamjvs @ wojtek-t

発行ラベル

sig/api-machinery sig/autoscaling sig/node sig/scalability sig/scheduling sig/storage ：問題は必要に応じてこれらのSIGにエスカレーションされます。
priority/critical-urgent ：問題をリリースマイルストーンから自動的に移動しないでください。利用可能なすべてのチャネルを通じて、コントリビューターとSIGに継続的にエスカレーションします。
kind/bug ：現在のリリースで発見されたバグを修正します。

助けて

k8s-github-robot 2018年04月11日

この問題は、1.10の関連する修正で解決されました。
1.11の場合、 https：//github.com/kubernetes/kubernetes/issues/63030で障害を追跡してい

/閉じる

shyamjvs 2018年05月25日

Kubernetes: [テストフレーク]マスタースケーラビリティスイート

最も参考になるコメント

全てのコメント164件

関連する問題