Helm не добавляет параметр тайм-аута в вызове сервера API - PullRequest
Новая
       185

Helm не добавляет параметр тайм-аута в вызове сервера API

0 голосов
/ 29 мая 2020

Когда мы используем helm для создания Istio VirtualService или DestinationRules, это занимает более 30 секунд. Таким образом, мы установили более высокий тайм-аут 5 м.

Используемая команда helm upgrade --install --wait --timeout 5m --v 9 helloworld ./templateDir

Однако я вижу, что helm не передает новое значение тайм-аута при вызове APIserver. Когда мы используем kubectl для создания того же самого, мы устанавливаем --request-timeout param для kubectl, и все в порядке

Поскольку это тайм-аут от apiserver, можно ли установить более высокое значение тайм-аута для всех серверов API запросы от руля? Есть ли другой способ решения этой проблемы? 

I0528 17:52:57.664992   11148 round_trippers.go:423] curl -k -v -XPOST  -H "Content-Type: application/json" -H "Accept: application/json" 'https://aaaa.sk1.us-east-1.eks.amazonaws.com/apis/networking.istio.io/v1beta1/namespaces/default/destinationrules '
I0528 17:53:27.981691   11148 round_trippers.go:443] POST https://aaaa.sk1.us-east-1.eks.amazonaws.com/apis/networking.istio.io/v1beta1/namespaces/default/destinationrules  504 Gateway Timeout in 30316 milliseconds
I0528 17:53:27.981691   11148 round_trippers.go:449] Response Headers:
I0528 17:53:27.981691   11148 round_trippers.go:452]     Audit-Id: cba23005-b8db-47f7-8801-4c89e6447cd3
I0528 17:53:27.981691   11148 round_trippers.go:452]     Content-Type: application/json
I0528 17:53:27.981691   11148 round_trippers.go:452]     Content-Length: 187
I0528 17:53:27.981691   11148 round_trippers.go:452]     Date: Thu, 28 May 2020 12:23:27 GMT
I0528 17:53:27.981691   11148 request.go:1017] Response Body: {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"Timeout: request did not complete within requested timeout 30s","reason":"Timeout","details":{},"code":504}
I0528 17:53:27.982759   11148 request.go:1017] Request Body: {"apiVersion":"networking.istio.io/v1beta1","kind":"VirtualService","metadata":{"name":"mbrsvc","namespace":"default"},"spec":{"hosts":["mbrsvc"],"http":[{"route":[{"destination":{"host":"mbrsvc","subset":"1.0.0"},"weight":100}]}]}}

Ответы [ 2 ]

0 голосов
/ 12 июня 2020

Этот тайм-аут исходит от сервера (код 504), а не от клиента (Helm). Предоставление --timeout здесь не повлияет, боюсь,

0 голосов
/ 29 мая 2020

В документации указано, что --timeout должно быть в секундах.

--timeout: значение в секундах для ожидания завершения команд Kubernetes. По умолчанию 5m0s

--wait: ожидает, пока все модули не будут в состоянии готовности, будут связаны PVC, в развертываниях будет минимум (Desired минус maxUnavailable) модулей в состоянии готовности, а у служб будет IP-адрес (и вход если a LoadBalancer), прежде чем отмечать выпуск как успешный. Он будет ждать до тех пор, пока не будет установлено значение --timeout. По истечении времени ожидания выпуск будет отмечен как FAILED. Примечание. В сценарии, в котором для параметра Deployment replicas установлено значение 1, а для maxUnavailable не установлено значение 0 как часть стратегии последовательного обновления, --wait будет возвращен как готовый, поскольку он удовлетворяет минимальному количеству Pod в состоянии готовности.

Надеюсь, это поможет.

...