使用EKS的头盔超时

Question

[当我们使用掌舵来创建Istio VirtualService或DestinationRules时，将花费30秒以上。因此我们将超时设置为5m。

使用的命令helm upgrade --install --wait --timeout 5m --v 9 helloworld ./templateDir

但是，API Server调用会在30秒后超时，而不是等待5分钟。我从下面的掌舵粘贴了日志。当我们使用kubectl来创建它时，我们为--request-timeout设置了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}]}]}}

Answer 1

[Documentation指出--timeout应该以秒为单位。

--timeout：等待Kubernetes命令完成的秒数（默认为5m0s

）

--wait：等到所有Pod都处于就绪状态，PVC绑定，部署的数量最少（Desired减去maxUnavailable），Pod处于就绪状态，服务具有IP地址（如果为LoadBalancer，则为Ingress ），然后将发布标记为成功。它将等待--timeout值。如果达到超时，版本将被标记为FAILED。注意：在部署将replicas设置为1且未将maxUnavailable设置为0作为滚动更新策略的一部分的情况下，--wait将返回就绪状态，因为它已满足就绪状态中的最小Pod。

希望有所帮助。