Kubernetes: [테스트 플레이크] 마스터 확장 성 제품군

• 최근에 제품군에 추가 된 e2es (예 : https://github.com/kubernetes/kubernetes/pull/59391)가 많았 기 때문에 정확성 작업은 대부분 시간 초과로 인해 실패합니다 (그에 따라 일정을 조정해야 함).
• 100 노드 플레이크의 경우 https://github.com/kubernetes/kubernetes/issues/60500 (관련이 있다고 생각합니다. 확인해야 함).
• 성능 작업의 경우 회귀가 있다고 생각합니다 (팟 시작 지연 시간과 같은 최근 몇 번의 실행에서 보임). 어쩌면 더 sth.

나는 이번 주에 언젠가 그들에게 도착하려고 노력할 것입니다 (무료 사이클 atm이 부족함).

@shyamjvs 이 문제에 대한 업데이트가 있습니까?

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 분 이내에 완료된 테스트 없음

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

실제로 회귀처럼 보입니다. 회귀가 실행 중간에 발생했다고 생각합니다.
105 (아직 괜찮 았습니다)
108 (눈에 띄게 더 높은 시작 시간을 가짐)

kubemark-5000도 거기에 보이는지 살펴볼 수 있습니다.

Kubemark-5000은 꽤 안정적입니다. 이 그래프의 99 번째 백분위 수 (이전에 회귀가 발생했을 수도 있지만 105에서 108 사이에 있다고 생각합니다) :

정확성 테스트와 관련하여-gce-large-correctness도 실패합니다.
그 당시 매우 긴 테스트가 추가되었을 수 있습니까?

@ wojtek-t를 찾아 주셔서 감사합니다. WRT 성능 작업-회귀가 있다는 느낌이 너무 강합니다 (하지만 제대로 살펴볼 수는 없지만).

그 당시 매우 긴 테스트가 추가되었을 수 있습니까?

나는 얼마 전에 이것을 조사하고 있었다. 그리고 내가 발견 한 두 가지 의심스러운 변화가 있습니다.

• # 59391-이것은 로컬 스토리지에 대한 많은 테스트를 추가했습니다 (이 변경 후 실행은 시간 초과로 시작됨)
• 포드 방지 친화력 StatefulSet 볼륨이 (- 5hr이 테스트가 3.5 실행하는 것) - 노드에 분산 사용해야합니다 https://k8s-gubernator.appspot.com/build/kubernetes-jenkins/logs/ci-kubernetes-e2e -gce-scale-correctness / 79

cc @ kubernetes / sig-storage-bugs

/양수인

일부 로컬 저장소 테스트에서는 클러스터 크기가 그렇게 크지 않다고 생각하여 클러스터의 모든 노드를 사용하려고합니다. 최대 노드 수를 제한하는 수정 사항을 추가하겠습니다.

일부 로컬 저장소 테스트에서는 클러스터 크기가 그렇게 크지 않다고 생각하여 클러스터의 모든 노드를 사용하려고합니다. 최대 노드 수를 제한하는 수정 사항을 추가하겠습니다.

감사합니다 @ msau42- 좋을 것입니다.

https://k8s-testgrid.appspot.com/sig-release-master-blocking#gce -scale-performance suite로 돌아 가기

나는 최대 105 점과 108 점 이후를 면밀히 조사했다.
pod 시작 시간과 wrt의 가장 큰 차이는 단계에서 나타나는 것 같습니다.

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.85s 증가를 의미하며 이것은 대략 최종 결과에서 관찰되는 것입니다.

자, 그 "시계 지연"이 무엇인지.
기본적으로 "Kubelet에서 포드가 실행 중임을 관찰 함"에서 "포드 업데이트 상태를 실행 중으로 설정하는 테스트 관찰 시점"사이의 시간입니다.
회귀 할 수있는 몇 가지 가능성이 있습니다.

• kubelet의보고 상태가 느려집니다.
• kubelet이 qps 부족 (따라서보고 상태가 느려짐)
• apiserver가 느리기 때문에 (예 : CPU 부족) 요청 처리 속도가 느립니다 (쓰기, 감시 또는 둘 다).
• 테스트에 CPU가 부족하여 들어오는 이벤트 처리 속도가 느립니다.

pod의 "schedule-> start"사이의 차이를 실제로 관찰하지 못하기 때문에 아마도 apiserver가 아님을 시사합니다 (요청 처리와 watch도 해당 경로에 있기 때문). 대부분의 경우 느린 kubelet 너무 (포드를 시작하기 때문에).

그래서 가장 가능성이 높은 가설은 다음과 같습니다.

• kubelet은 qps가 부족합니다 (또는 상태 업데이트를 빠르게 보내지 못하게하는 sth).
• 테스트는 CPU가 부족합니다 (또는 그렇게 sth)

그 당시 테스트는 전혀 변하지 않았습니다. 그래서 나는 그것이 아마도 첫 번째라고 생각합니다.

즉, 105에서 108로 병합 된 PR을 살펴 봤지만 지금까지 유용한 정보를 찾지 못했습니다.

다음 단계는 다음과 같습니다.

• 가장 느린 포드 (가장 느린 것 사이에도 O (1s) 차이가있는 것처럼 보임)를 살펴보고 그 차이가 업데이트 상태 요청이 전송 된 "이전"의 "이전"인지 확인합니다.

그래서 예제 포드를 살펴 보았습니다. 그리고 나는 이미 이것을보고 있습니다 :

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"와 관련이 있다는 것이 분명해 보입니다.

소유자 계정의 할당량으로 인해 제한되는 API 호출입니까?

소유자 계정의 할당량으로 인해 제한되는 API 호출입니까?

이것은 처음에 생각했던 것처럼 조절되지 않습니다. 이는 apiserver의 429입니다 (이유는 어떤 이유로 인해 apiserver가 느려지거나 apiserver에 더 많은 요청이 수신 될 수 있습니다).

오 그래. 좋은 소식이 아닙니다.

/ 이정표 지우기

/ milestone v1.10

/ 이정표 지우기

@cjwagner : 마일스톤 을 설정하려면

/ milestone v1.9

@cjwagner : 마일스톤 을 설정하려면

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

그래서 그 볼륨 테스트에 대한 내 의심 은 실제로 옳았습니다. :)

ACK. 진행 중
ETA : 2018 년 9 월 3 일
위험 : k8s 성능에 대한 잠재적 영향

그래서 저는 이것에 대해 조금 파고 들어 5k 노드 테스트에 대한 pod-startup 지연 그래프에서 회귀가 b / w 실행 108 및 109에있을 수도 있다는 느낌을 받았습니다 (99 % ile 참조).

나는 diff를 빠르게 훑어

"NewRequest에서 요청 제한 시간을 끝까지 전달하도록 허용"# 51042

이 PR은 API 호출에 대한 쿼리 매개 변수로 클라이언트의 제한 시간을 전파 할 수있게합니다. 그리고 실제로 두 번의 실행에서 PATCH node/status 호출에서 다음과 같은 차이점이 있습니다 (apiserver 로그에서).

run-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 호출이 기내 대기열에서 충분한 대역폭을 얻지 못하여 429s로 반환됩니다. 그 결과 pod-status 업데이트시 kubelet 측 지연이 증가했습니다. 이 이야기는 위의 @ wojtek-t의 관찰과도 잘 맞습니다.

이 가설을 확인하기 위해 더 많은 증거를 수집하려고 노력할 것입니다.

그래서 테스트 실행 동안 PATCH node-status 지연 시간이 어떻게 달라지는 지 확인했는데 실제로 그 시간에 99 번째 백분위 수 (맨 위 줄 참조)가 증가한 것처럼 보입니다. 그러나 그것이 108과 109로 실행되었다는 것은 분명하지 않습니다.

[편집 : 이전 댓글이 429s의 개수를 잘못 언급했습니다 (클라이언트는 kubelet이 아니라 npd 임)]

나는 지금 더 많은 증거를 가지고 있습니다.

run-108 에서 우리는 429 건의 PATCH node/status 호출을 479k 건 받았습니다.

{
        "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"
        ]
      },

그리고 ... 이것 좀보세요 :

run-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"
        ]
      },

그리고 run-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"
        ]
      },

나는 몇 가지 다른 인접 실행에 대한 번호를 확인했습니다.

• run-104 의 경우 21187입니다.
• run-105 의 경우 22003입니다.
• run-108 의 경우 28594입니다.

-PR 합병-

• run-109 의 경우 33224입니다.
• run-110 의 경우 30977입니다.
• run-111 의 경우 25615입니다.

약간 다양해 보이지만 전반적으로 아니오처럼 보입니다. 429 개 중 약 25 % 증가했습니다.

그리고 429를받은 kubelet에서 오는 PATCH node-status 의 경우 숫자는 다음과 같습니다.

• 실행 -104 = 313348
• 실행 -105 = 309136
• 실행 108 = 479181

-PR 합병-

• 실행 -109 = 757318
• 실행 110 = 752062
• 실행 -111 = 296368

이것은 또한 다양하지만 일반적으로 증가하는 것처럼 보입니다.

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)

Btw-위의 모든 메트릭을 Wrt, 108은 정상보다 나쁜 실행으로 보이며 111은 정상보다 나은 실행으로 보입니다.

내일 대규모 5k 클러스터를 수동으로 실행하여이를 확인하려고합니다.

@shyamjvs 분류 주셔서 감사합니다

그래서 나는 ~ HEAD에 대해 5k 클러스터에 대해 밀도 테스트를 두 번 실행했고, 테스트는 놀랍게도 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

두 번째 실행은 다음과 같습니다.

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

이제 이전에 어떤 일이 있었는지 확인해 보겠습니다.

https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -370573938-이 내용을 따르고 있는지 잘 모르겠습니다. 예-시간 제한을 추가했지만 기본 시간 제한은 10 초 IIRC보다 큽니다. 상황을 악화시키지 마십시오.

나는 우리가 왜 더 많은 429를 관찰하는지 아직 이해하지 못한다고 생각합니다 (이것은 내가 이미 https://github.com/kubernetes/kubernetes/issues/60589#issuecomment-370036377에서 언급 한 429와 관련이 있다는 사실)

그리고 당신의 숫자와 관련하여-회귀가 109에 있다고 확신하지 않습니다-두 개의 회귀가 있었을 것입니다-하나는 105와 108 사이에 있고 다른 하나는 109에 있습니다.

흠 ... 나는 당신이 언급 한 가능성을 부정하지 않는다 (위는 단지 나의 가설이었다).
나는 현재 확인을 위해 bisection (지금 108의 커밋에 반함)을하고 있습니다.

회귀가 런 108 이전에 있다는 느낌은 더 강하고 강합니다.
예를 들어 api 호출의 지연 시간은 108 실행에서 이미 증가했습니다.

패치 노드 상태 :
90 % : 198ms (105) 447ms (108) 444ms (109)

포드 상태 넣기 :
99 % : 83ms (105) 657ms (108) 728ms (109)

내가 말하려는 것은 다음과 같습니다.

• 429의 수는 결과이며 우리는 그것에 너무 많은 시간을 소비해서는 안됩니다
• 근본 원인은 느린 API 호출 또는 더 많은 호출입니다.

우리는 108에서 더 느린 API 호출을 분명히 보는 것 같습니다. 문제는 더 많은 수의 API 호출이 있는지 여부입니다.

그래서 요청이 눈에 띄게 느린 이유를 생각합니다. 세 가지 주요 가능성이 있습니다.

1. 훨씬 더 많은 요청이 있습니다 (처음에는 그렇지 않은 것 같습니다)

2. 처리 경로에 무언가를 추가했거나 (예 : 추가 처리) 개체 자체가 더 큽니다.

3. 마스터 머신의 다른 것 (예 : 스케줄러)이 더 많은 CPU를 소비하므로 apiserver가 더 많이 소모됩니다.

그래서 저와 @ 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

이등분을 조금 더 쉽게 만들어야합니다.

불행히도 이러한 시계 지연 시간의 변화는 일회성처럼 보입니다 (그렇지 않으면 거의 동일합니다). 다행히도 회귀의 신뢰할 수있는 지표로 PUT pod-status 지연 시간이 있습니다. 나는 어제 2 라운드의 이분법을 실행 하고이 diff (~ 80 커밋)로 좁혔습니다. 나는 그것들을 훑어 보았고 다음에 대해 강한 의혹을 가지고 있습니다.

• # 58990-포드 상태에 새 필드를 추가합니다 (IIUC 선점이 발생하지 않는 테스트에서 채워질 지 확실하지 않지만 확인해야 함)
• # 58645-etcd 서버 버전을 3.2.14로 업데이트

# 58990이 여기에 관련되어 있는지 정말 의심 스럽습니다. NominatedNodeName은 단일 노드 이름을 포함하는 문자열입니다. 항상 채워지더라도 개체 크기의 변화는 무시할 수 있어야합니다.

@ wojtek-t-오프라인에서 제안 하셨듯이 kubemark (https://github.com/kubernetes/kubernetes/blob/master/test/kubemark/)에서 다른 버전 (3.2.16)을 사용하고있는 것 같습니다. start-kubemark.sh # L62)이 회귀를 볼 수없는 잠재적 인 이유입니다. :)

cc @jpbetz

현재 모든 곳에서 3.2.16을 사용하고 있습니다.

죄송합니다. 뒤늦게 알려 드려 죄송합니다. 잘못된 커밋 조합을보고있었습니다.

BTW-PUT 포드 / 상태 지연 시간의 증가는 대규모 실제 클러스터의 부하 테스트에서도 볼 수 있습니다.

그래서 나는 조금 더 파헤쳐 서 일반적으로 쓰기 요청에 대해 그 시간에 더 큰 대기 시간을 관찰하기 시작한 것처럼 보입니다 (etcd 변경을 더 의심하게 만듭니다).

사실 저는 적어도 문제의 일부가 여기에 있다고 투표합니다.
https://github.com/kubernetes/kubernetes/pull/58990/commits/384a86caa92bdb7cf9ac96b10a6ef333d2d60519#diff -c73f80ad83608f18657d22a06950d929R240

그것이 전체적인 문제라면 놀랄 것입니다 만, 그것이 기여할 수 있습니다.
잠시 후에 PR을 변경합니다.

참고-etcd 3.2.14 변경 전이지만 pod-status API 변경 후 커밋 에 대해 실행했을 때 put node-status 지연 시간이 완전히 괜찮아 보입니다 (예 : 99 % ile = 39ms).

그래서 실제로 3.2.14 로의 etcd 범프에 의해 발생하는지 확인했습니다. put pod-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

한 가지 가설 (우리가 kubemark에서 그것을 잡지 못한 이유-여전히 추측이지만)는 sth wrt를 그곳에서 인증서로 변경했을 수 있다는 것입니다.
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 자체를 살펴보면 그와 관련된 변화는 없지만 실제 클러스터에서만 그 라인을보아야하는 이유도 모르겠습니다 ...
생각을 위해 @jpbetz

ACK. 진행 중
ETA : 2018 년 9 월 3 일
위험 : 근본 원인 (대부분) 문제

Re peerTLS-이전 (3.1.11 포함)도 그랬던 것 같아서 빨간 청어라고 생각합니다

cc @gyuho @wenjiaswe

63ms는

그 번호는 어디에서 얻습니까? apiserver_request_latencies_summary 실제로 etcd 쓰기의 지연 시간을 측정합니까? 또한 etcd의 메트릭이 도움이 될 것입니다.

포함 : peerTLS : cert ...

피어 TLS가 구성된 경우 인쇄됩니다 (3.1에서 동일).

그 번호는 어디에서 얻습니까? apiserver_request_latencies_summary는 실제로 etcd 쓰기의 지연 시간을 측정합니까? 또한 etcd의 메트릭이 도움이 될 것입니다.

이것은 (적어도 쓰기 호출의 경우) etcd의 지연 시간을 포함하는 apicalls 지연 시간을 측정합니다.
우리는 여전히 무슨 일이 일어나고 있는지 실제로 이해하지 못하지만 이전 etcd 버전 (3.1)으로 되 돌리면 회귀가 수정됩니다. 그래서 분명히 문제는 etcd 어딘가에 있습니다.

뿡 빵뀨

실행중인 Kubemark 및 Kubernetes 버전은 무엇입니까? 우리는 etcd 3.2 대 3.3 (500 노드 워크로드)에 대해 Kubemark 1.10을 테스트했지만이를 관찰하지 못했습니다. 이를 재현하려면 몇 개의 노드가 필요합니까?

실행중인 Kubemark 및 Kubernetes 버전은 무엇입니까? 우리는 etcd 3.2 대 3.3 (500 노드 워크로드)에 대해 Kubemark 1.10을 테스트했지만이를 관찰하지 못했습니다. 이를 재현하려면 몇 개의 노드가 필요합니까?

5k 노드 1로도 kubemark로 재현 할 수 없습니다. https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -371171837의 하단을

이것은 실제 클러스터에서만 문제가되는 것 같습니다.
이것은 왜 그것이 사실인지에 대한 열린 질문입니다.

etcd 3.1로 롤백했기 때문에. kubernetes를 위해. 또한 kubernetes에 대한 유일한 중요한 수정 사항 인 mvcc "unsynced"watcher restore operation 과 함께 etcd 3.1.12 를 출시했습니다. 이 문제에서 발견 된 성능 회귀의 근본 원인을 찾아 수정 한 후에는 kubernetes에서 사용하는 etcd 서버를 3.2로 업그레이드하는 계획을 스케치 할 수 있습니다.

https://k8s-testgrid.appspot.com/sig-release-master-blocking#gci -gce-100은 오늘 아침부터 지속적으로 실패하기 시작합니다.

diff 에서 유일한 변경 사항은 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- 할당량 활성화가 확장성에 영향을 미치는 것 같습니다. :) 더 자세히 살펴보실 수 있습니까?
이 문제를 추적하기 위해 다른 문제를 제출하겠습니다.

@ wojtek-t @jpbetz @gyuho @timothysc 나는 etcd 버전 변경에서 정말 흥미로운 것을 발견했고, etcd 3.1.11에서 3.2.16으로 이동했을 때 상당한 효과를 제안했습니다.

작업이 k8s 릴리스 1.9에서 1.10으로 이동했을 때 100 노드 클러스터 (최대 2 배 증가)에서 etcd 메모리 사용량에 대한 다음 그래프를보십시오.

다음으로, etcd 3.2.16-> 3.1.11에서 복귀 한 직후 100 노드 작업 (HEAD에 대해 실행)이 메모리 사용량이 절반으로 감소하는 것을 확인합니다.

따라서 etcd 3.2 서버 버전은 영향을받는 성능을 보여줍니다 (다른 모든 변수는 동일하게 유지됨). :)

etcd 3.2.16-> 3.2.11에서 내 되돌리기 :

3.1.11을 의미 했습니까?

맞아 .. 죄송합니다. 내 댓글을 수정했습니다.

@shyamjvs etcd는 어떻게 구성됩니까? v3.2에서 기본값 --snapshot-count 을 10000 에서 100000 늘 렸습니다. 따라서 스냅 샷 개수가 다른 경우 스냅 샷 개수가 더 큰 항목은 Raft 항목을 더 오래 보관하므로 오래된 로그를 삭제하기 전에 더 많은 상주 메모리가 필요합니다.

아! 그것은 참으로 의심스러운 변화처럼 보입니다. Wrt 플래그, k8s 측에서 변경된 사항이 없다고 생각합니다. 위의 두 번째 그래프에서 볼 수 있듯이 diff b / w는 11450을 실행하고 11451은 주로 내 etcd 되돌리기 변경 사항입니다 (플래그를 건드리지 않는 것 같음).

기본값 --snapshot-count를 10000에서 100000으로 늘 렸습니다.

이것이 메모리 사용량 증가의 근본 원인인지 확인해 주시겠습니까? 그렇다면 다음을 수행 할 수 있습니다.

• etcd를 원래 값으로 다시 패치하거나
• k8s에서 10000으로 설정

3.2로 다시 전환하기 전에

아! 그것은 참으로 의심스러운 변화처럼 보입니다.

예,이 변경 사항은 etcd 측에서 강조되어야합니다 (변경 로그 및 업그레이드 가이드를 개선 할 것입니다).

이것이 메모리 사용량 증가의 근본 원인인지 확인해 주시겠습니까?

이것이 근본 원인인지 확실하지 않습니다. 낮은 스냅 샷 수는 급증하는 메모리 사용량을 줄이는 데 확실히 도움이됩니다. 두 etcd 버전이 동일한 스냅 샷 수를 사용하지만 하나의 etcd가 여전히 훨씬 더 높은 메모리 사용량을 표시한다면 다른 것이 있어야합니다.

업데이트 : etcd mem 사용량의 증가가 실제로 더 높은 --snapshot-count 기본값으로 인해 발생 함을 확인했습니다. 더 자세한 사항은 여기에 - https://github.com/kubernetes/kubernetes/pull/61037#issuecomment -372457843

증가 된 메모리 사용량을 원하지 않는 경우 etcd 3.2.16에 도달 할 때 10,000으로 설정하는 것을 고려해야합니다.

cc @gyuho @ xiang90 @jpbetz

업데이트 : etcd 수정을 통해 포드 시작 지연 99 %는 여전히 5s SLO를 위반하는 것 같습니다. 적어도 하나의 다른 회귀가 있으며 5k 노드 성능 작업의 b / w 실행 111 및 112에서 가능성이 가장 높다는 증거를 수집했습니다 (https : /에 붙여 넣은 그래프에서 실행되는 범프 b / w 참조). /github.com/kubernetes/kubernetes/issues/60589#issuecomment-370568929). 현재 나는 (약 50 개의 커밋이있는) diff를 이등분하고 있으며 테스트는 반복 당 ~ 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

한편, 누군가가 베팅 게임을하고 있다면 위에서 언급 한 커밋 diff를 살펴보고 잘못된 것을 추측 할 수 있습니다. :)

ACK. 진행 중
ETA : 2018 년 3 월 13 일
위험 : 그 전에 디버깅하지 않으면 릴리스 날짜를 푸시 할 수 있습니다.

@shyamjvs toooooooo 많은 커밋이 베팅을합니다 :)

@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.6 초-> 3.6 초에서 직선 점프가 아니기 때문에)-b / w "a042ecde36-5f7b530d87"및 다른 b / w "a8060ab0a1-430c1a68c8". 한숨!

비교 링크를 얻기 위해 범위로 표현 :
a042ecde36 ... 5f7b530
a8060ab0a1 ... 430c1a6

a042ecde36에 대한 수동 실행 결과를 얻었으며 삶을 더 어렵게 만듭니다.

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

이것은 아마도 불안정한 회귀 일 수 있음을 의미하기 때문입니다.

나는 현재 a042ecde36에 대한 테스트를 한 번 더 실행하여 회귀가 이전에도 들어 왔을 가능성을 확인하고 있습니다.

따라서 다음은 a042ecd에 대해 다시 실행 한 결과입니다.

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

이것은 아마도 run-111 이전에도 회귀가 입력되었음을 의미합니다 (이분법에 대한 올바른 끝이 있다는 좋은 소식).
이제 왼쪽 끝을 추구해 보겠습니다. Run-108 (커밋 11104d75f)은 잠재적 후보로, 이전에 실행했을 때 (etcd 3.1.11 사용) 다음과 같은 결과가 나타납니다.

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

커밋 11104d7에 대한 내 재실행은 그것이 좋은 것이라고 말하는 것 같습니다.

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

11104d7 ... a042ecd 범위에서 이등분 할 때 여기에서 찌르겠습니다.

업데이트 : 자신감을 얻기 위해 커밋 097efb71a315를 세 번 테스트해야했습니다. 약간의 차이가 있지만 좋은 커밋처럼 보입니다.

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

더 이등분을 계속하겠습니다.
즉, 며칠 전에 포드 시작 지연 시간이 또 다시 급증한 것 같습니다 (~ 1 초). 그리고 이것은 99 %를 거의 6 초로 밀고 있습니다.

커밋 차이 에서 내 주요 용의자는 3.1.11-> 3.1.12 (https://github.com/kubernetes/kubernetes/pull/60998)의 etcd 변경입니다. 일회성이 아니라는 것을 확인하기 위해 다음 실행 (현재 진행 중)을 기다릴 것입니다.하지만 우리는 이것을 정말로 이해해야합니다.

cc @jpbetz @gyuho

이번 주 목요일에 휴가를 보낼 예정이므로 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
  
  
  • 클러스터 / 이미지 / etcd / Makefile
  
  
  • 해킹 /lib/etcd.sh
  
  

참조 : @ wojtek-t

etcd v3.1.12는 복원시 시계 이벤트 누락을 수정합니다. 그리고 이것은 우리가 v3.1.11에서 변경 한 유일한 것입니다. 성능 테스트에 리더에서 스냅 샷을 트리거 할 수있는 etcd 재시작 또는 다중 노드가 포함됩니까?

성능 테스트에 etcd 재시작이 포함됩니까?

etcd logs 에서 다시 시작한 것처럼 보이지 않습니다.

다중 노드

우리는 설정에서 단일 노드 etcd 만 사용하고 있습니다 (당신이 요청한 것이라고 가정).

내가 참조. 그러면 v3.1.11과 v3.1.12도 다르지 않습니다. : 0
두 번째 실행에서도 더 높은 지연 시간이 표시되면 다시 살펴볼 것입니다.

cc : @jpbetz

etcd 에 대한 유일한 코드 변경은 코드를 다시 시작 / 복구하는 데 격리되어 있다는 점을 @gyuho 와 동의합니다.

유일한 다른 변경 사항은 etcd를 go1.8.5에서 go1.8.7로 업그레이드하는 것입니다. 그러나 그로 인해 상당한 성능 저하를 볼 수 있을지 의심 스럽습니다.

따라서 이분법을 계속하면 ff7918d1f가 좋은 것 같습니다.

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

이에 따라 https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -373051051에서 커밋 범위를 업데이트하겠습니다.

다음으로 커밋 aa19a1726은 좋은 것처럼 보이지만 확인을 위해 다시 시도하는 것이 좋습니다.

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

이 시점에서 이분법을 일시 중지하고 휴가를 시작하겠습니다. :)
다음 실행을위한 공간을 확보하기 위해 클러스터를 다운했습니다.

감사합니다 Shyam. aa19a172693a4ad60d5a08e9b93557267d259c37을 다시 시도하고 있습니다.

커밋 aa19a172693a4ad60d5a08e9b93557267d259c37에 대해 다음과 같은 결과를 얻었습니다.

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

그래서 이것은 좋아 보인다. 계속 이분법.

현재 의심되는 커밋 범위 : aa19a172693a4ad60d5a08e9b93557267d259c37 ... a042ecde362000e51f1e7bdbbda5bf9d81116f84

@ wasylkowski-a 오후 5시 (UTC) / 1PM (동부 표준시 / 10시 태평양 표준시)에 출시 회의에 참석해 주시겠습니까? Zoom 회의입니다 : https://zoom.us/j/2018742972

참석하겠습니다.

커밋 cca7ccbff161255292f72c2d18459cdface62122는 다음과 같은 결과로 명확하지 않습니다.

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

이분법의 절반을 잘못 입력하지 않는다는 자신감을 얻기 위해 이것을 한 번 더 실행할 것입니다.

이제 cca7ccbff161255292f72c2d18459cdface62122가 나쁘다고 확신합니다.

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

범위를 aa19a172693a4ad60d5a08e9b93557267d259c37 ... cca7ccbff161255292f72c2d18459cdface62122로 조정하고 92e4d3da0076f923a45d54d69c84e91ac6a61a55를 시도합니다.

커밋 92e4d3da0076f923a45d54d69c84e91ac6a61a55가 좋아 보입니다.

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

새로운 용의자 커밋 범위는 92e4d3da0076f923a45d54d69c84e91ac6a61a55 ... cca7ccbff161255292f72c2d18459cdface62122, 603ebe466d335a37392315d491782ed18d1bae11입니다.

커밋 중 하나, 즉 있습니다 @wasylkowski https://github.com/kubernetes/kubernetes/commit/4c289014a05669c376994868d8d91f7565a204b5 에 복귀있어 https://github.com/kubernetes/kubernetes/commit/493f33583053bb4ce9f7d348c5bac39975883cb8

@dims 주석을 더 명확하게 다시

이분법을 계속하는 대신 1.10 브랜치 헤드에 대해 한 번 재 테스트의 우선 순위를 지정할 수 있습니까?

@wasylkowski / @ wasylkowski-a ^^^^

@ wojtek-t PTAL 최대한 빨리

@dims 와 @tpepper에게 감사드립니다. 1.10 브랜치 헤드를 상대로 시도하고 무슨 일이 일어나는지 보자.

감사합니다 @wasylkowski 최악의 경우 우리가 이전에 양분했던 것으로 돌아갑니다. 권리?

1.10 머리에는 회귀가 있습니다.

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

이것은 etcd 3.1.11이 아닌 etcd 3.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가 여기서 범인 일 수도 있지만, 이는 우리가 머리에 나타나는 또 다른 회귀가 있음을 의미합니다.

좋아, 분명히 6590ea6d5d50700d34255b1e037b2702ad26b7fc를 커밋하는 것이 좋습니다.

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

커밋 7b678dc4035c61a1991b5e1442edb13f40deae72는 나쁘다 :

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

나쁜 커밋은 @dims 에서 언급 한 되 돌린 커밋의 병합이므로 머리에서 또 다른 회귀를 관찰해야합니다.

3.1.12 대신 etcd 3.1.11에서 헤드를 다시 실행하고 어떤 일이 발생하는지 살펴 보겠습니다.

@ wasylkowski-a 아 고전적인 좋은 소식 나쁜 소식 :) 계속해 주셔서 감사합니다.

@ wojtek-t 다른 제안이 있습니까?

etcd 3.1.11의 헤드도 나쁘다. 내 다음 시도는 복귀 직후에 직접 시도하는 것입니다 (따라서 cdecea545553eff09e280d389a3aef69e2f32bf1에서), 3.2.14 대신 etcd 3.1.11을 사용하십시오.

좋은 Andrzej 소리

-어둡게

2018 년 3 월 17 일 오후 1시 19 분에 Andrzej Wasylkowski [email protected] 은 다음과 같이 썼습니다.

etcd 3.1.11의 헤드도 나쁘다. 내 다음 시도는 복귀 직후에 직접 시도하는 것입니다 (따라서 cdecea5 커밋에서), 3.2.14 대신 etcd 3.1.11을 사용하십시오.

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하십시오.

cdecea545553eff09e280d389a3aef69e2f32bf1 커밋이 좋으므로 나중에 회귀가 있습니다.

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

커밋 2a373ace6eda6a9cf050ce70a6cf99183c5e5b37은 분명히 나쁩니다.

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

@ wasylkowski-a 그래서 우리는 기본적으로 https://github.com/kubernetes/kubernetes/compare/cdecea5...2a373ac 범위의 커밋을보고 무엇이 잘못되었는지 확인합니다. (이 둘 사이에서 bisect 실행)?

예. 불행히도 이것은 엄청난 범위입니다. 나는 지금 aded0d922592fdff0137c70443caf2a9502c7580을 조사하고 있습니다.

감사합니다 @wasylkowski 현재 범위는 무엇입니까? (그래서 PR을 볼 수 있습니다).

커밋 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이 사실 불안정한 패스라고 의심하기 시작했습니다. 그래서 우리는 다른 왼쪽 끝이 필요합니다.

/ me는 https://github.com/kubernetes/kubernetes/commit/b259543985b10875f4a010ed0285ac43e335c8e0에 베팅을합니다.

cc @ wasylkowski-a

0e81651e77e0be7e75179e5986ef2c76601f4bd6은, 결과가 나쁘고, 따라서 b259543985b10875f4a010ed0285ac43e335c8e0 (244549f02afabc5be23fc56e86a60e5b3685938828, 0e81651e77e77e0e0e7e75179e77e77e0e0e7e75179e77e77e0e7e75179e77e0e0e7e75179e77e77e0e0e7e75179e77e)로 병합 됨

@ wojtek-t 및 @shyamjvs에 따라 cdecea545553eff09e280d389a3aef69e2f32bf1을 다시 실행하고 있습니다. 이것이 "불안정한 선"이었을 수도 있기 때문입니다.

내가 관찰 한 다음 결과를 기반으로 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)

현재 의심되는 범위 : cdecea545553eff09e280d389a3aef69e2f32bf1 ... 0e81651e77e0be7e75179e5986ef2c76601f4bd6

현재 테스트중인 99c87cf679e9cbd9647786bf7e81f0a2d771084f

이 작업을 계속해 주신 @wasylkowski 에게 감사드립니다.

오늘 토론에 따르면 fluentd-scaler에는 PR에 의해 수정되지 않은 https://github.com/kubernetes/kubernetes/issues/61190 여전히 문제가 있습니다. 이 회귀가 fluentd에 의해 발생할 수 있습니까?

fluentd https://github.com/kubernetes/kubernetes/commit/a88ddac1e47e0bc4b43bfa1b0df2f19aea4455f2 와 관련된 PR 중 하나가 최신 범위에 있습니다.

오늘 토론에 따르면 fluentd-scaler에는 PR에 의해 수정되지 않은 # 61190 문제가 여전히 있습니다. 이 회귀가 fluentd에 의해 발생할 수 있습니까?

TBH, 유창한 문제 때문이라면 정말 놀랄 것입니다. 하지만이 가설을 확실히 배제 할 수는 없습니다.
내 개인적인 느낌은 Kubelet에서 약간의 변화가 될 것이지만 그 범위의 PR도 조사했으며 실제로 의심스러운 것은 없습니다 ...
바라건대 범위는 내일 4 배 더 작아 질 것입니다.

좋아, 99c87cf679e9cbd9647786bf7e81f0a2d771084f가 좋아 보이지만 이것이 플레이크가 아닌지 확인하려면 세 번의 실행이 필요했습니다.

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 분석 중.

위에서 언급 한 범위를 살펴 보았습니다. PR이 9 개뿐입니다.
https://github.com/kubernetes/kubernetes/pull/59944-100 % 아님-소유자 파일 만 변경
https://github.com/kubernetes/kubernetes/pull/59953- 잠재적으로
https://github.com/kubernetes/kubernetes/pull/59809-kubectl 코드 만 건 드리기 때문에이 경우에는 중요하지 않습니다.
https://github.com/kubernetes/kubernetes/pull/59955-100 % NOT-관련없는 e2e 테스트 만 건 드리기
https://github.com/kubernetes/kubernetes/pull/59808- 잠재적으로 (클러스터 설정 변경)
https://github.com/kubernetes/kubernetes/pull/59913-100 % NOT-관련없는 e2e 테스트 만 건 드리기
https://github.com/kubernetes/kubernetes/pull/59917- 테스트를 변경하고 있지만 변경 사항을 켜지 않고 있으므로 가능성이 낮습니다.
https://github.com/kubernetes/kubernetes/pull/59668-100 % 아님-AWS 코드 만 건 드리면
https://github.com/kubernetes/kubernetes/pull/59909-100 % 아님-소유자 파일 만 건 드리기

그래서 저는 여기에 두 가지 후보가 있다고 생각합니다 : https://github.com/kubernetes/kubernetes/pull/59953 및 https://github.com/kubernetes/kubernetes/pull/59808
나는 그것들을 이해하기 위해 더 깊이 파고 들려고 노력할 것입니다.

c105796e4ba7fc9cfafc2e7a3cc4a556d7d9defd는 다소 나빠 보입니다.

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

이것이 Wojtek의 용의자 중 하나 인 # 59953의 병합이라는 점을 감안할 때, 이제 그 전에 한 커밋을 실행할 것이므로 f60083549a43f152b3142e01756e25611d911770입니다.

그러나 해당 커밋은 OWNERS_ALIASES 변경이며 그 전에 해당 범위에 아무것도 남아 있지 않으므로 c105796e4ba7fc9cfafc2e7a3cc4a556d7d9defd가 문제가 될 것입니다. 어쨌든 안전을 위해 테스트를 실행할 것입니다.

오프라인으로 논의-대신이 커밋을 로컬로 되 돌린 상태에서 테스트를 헤드에서 실행합니다.

와! 너무 많은 문제를 일으키는 원 라이너. 감사합니다 @wasylkowski @ wojtek-t

@dims One-
일반적으로 https://github.com/kubernetes/community/blob/master/sig-scalability/blogs/scalability-regressions-case-studies.md에서 좋은 읽기를 원할 수 있습니다. :)

다시 업데이트하십시오. 헤드에서 테스트 : 커밋을 로컬로 되 돌린 상태로 먼저 실행합니다. 그래도 플레이크 일 수 있으므로 다시 실행 중입니다.

https://github.com/kubernetes/kubernetes/pull/59953 의 커밋을 살펴보면 버그가 수정되지 않았습니까? "예약 된"상태를 잘못된 개체에 배치하는 버그를 수정 한 것으로 보입니다. 해당 PR에서 언급 된 문제에 따르면 kubelet이 해당 수정없이 포드가 예약되었다고보고하는 것을 놓칠 수있는 것 같습니다.

@ Random-Liu 그 변화의 효과가 무엇인지 우리에게 더 잘 설명 할 수있는 사람 :)

# 59953의 커밋을 보면 ... 버그가 수정되지 않았나요? "예약 된"상태를 잘못된 개체에 배치하는 버그를 수정 한 것으로 보입니다. kubelet이 pod가 수정 전에 너무 일찍 예약되었다고보고했을 수 있습니까?

예-버그 수정 이었음을 압니다. 나는 그것을 완전히 이해하지 못합니다.
pod보고 문제를 "Scheduled"로 수정 한 것 같습니다. 그러나 kubelet이 "StartedAt"으로보고 할 때까지도 문제가 발생하지 않습니다.
문제는 Kubelet에 의해 "StartedAt"으로보고 된 시간과 pod 상태 업데이트가보고되고 테스트에 의해 감시되는 시간 사이에 상당한 증가가 있다는 것입니다.
그래서 저는 "Scheduled"비트가 여기에서 붉은 청어라고 생각합니다.

내 생각에 (그러나 이것은 여전히 ​​추측 일뿐입니다)이 변경으로 인해 더 많은 Pod 상태 업데이트를 보내고 결과적으로 더 많은 429 또는 그와 같은 sth가 발생한다는 것입니다. 결국 Kubelet이 포드 상태를보고하는 데 더 많은 시간이 걸립니다. 그러나 그것은 우리가 여전히 확인해야 할 것입니다.

두 번 실행 한 후 # 59953을 되 돌리면 문제가 해결 될 것이라고 확신합니다.

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

우리는 더 많은 Pod 상태 업데이트를 보내고 있으며 결과적으로 더 많은 429s 또는 그와 같은 sth가 발생합니다. 결국 Kubelet이 포드 상태를보고하는 데 더 많은 시간이 걸립니다.

이것은 https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -370573938 (내가 생각한 원인이 잘못되었지만)에서 가설을 세운 효과입니다. :)
또한 IIRC는 풋 콜 (https://github.com/kubernetes/kubernetes/issues/60589#issuecomment-370582634 참조)에 대해 429s의 증가를 확인한 것처럼 보였지만 이전 범위에서 가져온 것입니다 ( etcd 변경 주변).

두 번 실행 한 후 # 59953을 되 돌리면 문제가 해결 될 것이라고 확신합니다.

내 직감 (https://github.com/kubernetes/kubernetes/issues/60589#issuecomment-370874602) 스레드에서 꽤 일찍 kubelet 측에 문제가 있다는 것은 결국 정확했습니다 :)

/ sig 노드
@ kubernetes / sig-node-bugs 릴리스 팀은 # 59953 커밋 대 되돌리기 및 성능 문제에 대한 리뷰를 실제로 사용할 수 있습니다.

# 59953의 커밋을 보면 ... 버그가 수정되지 않았나요? "예약 된"상태를 잘못된 개체에 배치하는 버그를 수정 한 것으로 보입니다. 해당 PR에서 언급 된 문제에 따르면 kubelet이 해당 수정없이 포드가 예약되었다고보고하는 것을 놓칠 수있는 것 같습니다.

@liggitt 설명해 주셔서 감사합니다. 네, 그 PR이 버그를 수정하고 있습니다. 이전에는 kubelet이 항상 PodScheduled 설정하지는 않았습니다. # 59953을 사용하면 kubelet이 올바르게 수행합니다.

@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 번 테스트 실행에 대한 로그가 있습니까?

@yujuhong 과 저는 # 59953이 정적 포드의 PodScheduled 조건이 계속 업데이트되는 문제를 노출했음을 발견했습니다.

Kubelet이없는 포드에 대해 새로운 PodScheduled 조건을 생성합니다. 정적 포드에는이 기능이 없으며 상태가 업데이트되지 않습니다 (예상 된 동작). 따라서 kubelet은 정적 포드에 대해 새로운 PodScheduled 조건을 계속 생성합니다.

이 문제는 # 24459에서 소개되었지만 버그로 덮여 있습니다. # 59953 버그를 수정하고 원래 문제를 노출했습니다.

이 문제를 신속하게 해결할 수있는 두 가지 옵션이 있습니다.

• 옵션 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 very long time for kubelet to eventually set this condition 의 효과는 무엇입니까? 최종 사용자는 어떤 문제를인지하고 직면하게됩니까 (테스트 장치의 벗겨짐 외부)? (옵션 # 1에서)

@dims 사용자는 PodScheduled 상태를 오랫동안 볼 수 없습니다.

https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -375103979에서 옵션 2를 구현하는 수정 # 61504가 있습니다.

사람들이 더 나은 해결책이라고 생각하면 옵션 1로 변경할 수 있습니다. :)

이것을 아는 사람들에게 물어 보는 것이 좋습니다! (출시 팀이 아닙니다 😄!)

핑 @dashpole @ dchen1107 @derekwaynecarr

@ Random-Liu IIRC는 테스트에서 노드에서 실행되는 유일한 정적 포드는 kube-proxy입니다. kubelet이 이러한 '지속적인 업데이트'를 얼마나 자주 수행하는지 알 수 있습니까? (버그에 의해 도입 된 추가 qps를 추정하기 위해 요청)

@ 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 에 따라 달라집니다. 따라서 kubelet은 1 분마다 하나의 추가 포드 상태 업데이트를 생성합니다.

감사. 즉, pod-status 호출로 인해 5000/60 = ~ 83 qps가 추가되었습니다. 버그에서 앞서 언급 한 증가 된 429를 설명하는 것 같습니다.

@ Random-Liu이 분류를 도와 주셔서 대단히 감사합니다.

@jdumars np ~ @yujuhong 이 저를 많이 도왔습니다!

하지만 스케줄러에 의해 예약되지 않은 포드에 대해 PodScheduled가 무엇을 의미하는지 묻고 싶습니다. 이러한 포드에이 조건이 정말로 필요합니까? / CC @는 Kubernetes / 시그마 --버그를 자동 확장 @yujuhong이 PodScheduled 이제 자동 확장에 의해 사용되는 것을 저에게 말했다 때문입니다.

나는 여전히 kubelet이 PodScheduled 조건을 설정하도록하는 것이 다소 이상하다고 생각합니다 (원래 PR에서 언급했듯이). kubelet이이 조건을 설정하지 않더라도 자동 확장 처리가 특정 조건없이 포드를 무시하므로 클러스터 자동 확장 처리에 영향을주지 않습니다. 어쨌든, 우리가 결국에 내놓은 수정은 매우 사소한 풋 프린트를 가지고 있으며 현재 동작을 유지할 것입니다 (즉, 항상 PodScheduled 조건을 설정). 그래서 우리는 그것으로 갈 것입니다.

또한 정상 상태 포드 업데이트 속도 # 14391에 대한 테스트를 추가하는 정말 오래된 문제를 되살 렸습니다.

어쨌든, 우리가 결국에 내놓은 수정은 매우 사소한 풋 프린트를 가지고 있으며 현재 동작을 유지할 것입니다 (즉, 항상 PodScheduled 조건을 설정). 그래서 우리는 그것으로 갈 것입니다.

@yujuhong- 당신은 이것에 대해 이야기하고 있습니까 : #

@wasylkowski @ shyamjvs- 이것이 정말로 도움이되는지 확인하기 위해 로컬로 패치 된 PR을 사용하여 5000 개 노드 테스트를 실행 해 주시겠습니까?

1.10 HEAD + # 61504에 대해 테스트를 실행했는데 포드 시작 대기 시간이 괜찮은 것 같습니다.

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

확인을 위해 다시 한 번 실행됩니다.

@shyamjvs- 감사합니다!

두 번째 실행도 좋습니다.

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

이제 수정이 트릭을 수행했다고 확신합니다. 최대한 빨리 1.10에 들어가 보겠습니다.

감사합니다 @shyamjvs

오프라인으로 이야기하면서-지난 달에 한 번 더 회귀가 있었지만 이로 인해 릴리스를 차단해서는 안됩니다.

@yujuhong- 당신은 이것에 대해 이야기하고 있습니까 : #

네. 해당 PR의 현재 수정 사항은 https://github.com/kubernetes/kubernetes/issues/60589#issuecomment -375103979에서 처음 제안 된 옵션에 없습니다.

좋은 성능 테스트 결과가 나올 때까지 다시 엽니 다.

@yujuhong @krzyzacy @shyamjvs @ wojtek-t @ Random-Liu @ wasylkowski-a에 대한 업데이트가 있습니까? 이것은 현재 1.10을 차단하고 있습니다.

따라서 릴리스를 차단하는이 버그의 유일한 부분은 5k 노드 성능 작업입니다. 불행히도 우리는 다른 이유로 오늘부터 실행을 잃었습니다 (참조 : https://github.com/kubernetes/kubernetes/issues/61190#issuecomment-376150569)

즉, 수동 실행 (https://github.com/kubernetes/kubernetes/issues/60589#issuecomment-375350217에 붙여 넣은 결과)을 기반으로 수정이 작동한다고 확신합니다. 그래서 IMHO 우리는 그것에 대한 릴리스를 차단할 필요가 없습니다 (다음 실행은 수요일에있을 것입니다).

+1
@jdumars- 나는 이것을 비 차단제로 취급 할 수 있다고 생각합니다.

죄송합니다. 위의 게시물을 수정했습니다. 나는 그것을 "비 차단제"로 취급해야한다는 것을 의미했습니다.

네, 대단히 감사합니다. 이 결론은 당신이 투자 한 엄청난 시간을 나타내며 당신이 한 일에 대해 충분히 감사 할 수는 없습니다. 초록에서 "커뮤니티"와 "기고자"에 대해 이야기하는 동안이 문제를 해결 한 다른 사람들은이를 구체적인 용어로 표현합니다. 여러분은이 프로젝트의 핵심이자 영혼이며, 그러한 열정, 헌신 및 전문성과 함께 일하는 것이 영광이라고 말할 때 관련된 모든 사람을 대변하는 것을 알고 있습니다.

[MILESTONENOTIFIER] 마일스톤 문제 : 프로세스에 대한 최신 정보

트윗 담아 가기

• sig/api-machinery sig/autoscaling sig/node sig/scalability sig/scheduling sig/storage : 필요한 경우 문제가이 SIG로 에스컬레이션됩니다.
• priority/critical-urgent : 릴리스 마일스톤에서 이슈를 자동으로 이동하지 않습니다. 사용 가능한 모든 채널을 통해 기여자 및 SIG에게 지속적으로 에스컬레이션합니다.
• kind/bug : 현재 릴리스에서 발견 된 버그를 수정합니다.
  
  
  
  

  도움

• 추가 지침
• 레이블 설정 명령

이 문제는 1.10의 관련 수정을 통해 해결되었습니다.
1.11의 경우 https://github.com/kubernetes/kubernetes/issues/63030 에서 오류를 추적하고 있습니다

/닫기