Open thirdeyenick opened 4 years ago
@thirdeyenick
FYI: we are still seeing the rpc error: code = Internal desc = transport: received the unexpected content-type "text/html"
errors even after setting nginx.ingress.kubernetes.io/proxy-http-version: "1.0"
, is there anything else we can do fix those errors?
I'm also getting this issue periodically
Also an issue here, when trying to use https://docs.konghq.com/kubernetes-ingress-controller/latest/ which would be configured accordingly to the 2 services setup. Kong is able to proxy grpc but the keepalive connections which are stored in the pool as ip|port (where ip is argocd pod ip and port is 8080) are being reused which cause intermittent failures both on the http and grcp calls.
FYI folks going to provide my ingresses annotations that apparently fixes those intermittent 502 unexpected content-type "text/html" issues:
HTTP:
annotations:
cert-manager.io/cluster-issuer: "letsencrypt"
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
nginx.ingress.kubernetes.io/backend-protocol: "HTTP"
nginx.ingress.kubernetes.io/proxy-http-version: "1.0"
GRPC:
annotations:
cert-manager.io/cluster-issuer: "letsencrypt"
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
nginx.ingress.kubernetes.io/backend-protocol: "GRPC"
nginx.ingress.kubernetes.io/configuration-snippet: |
grpc_next_upstream error timeout http_502 non_idempotent;
grpc_next_upstream_tries 3;
Hope it helps.
Summary
In the current documentation there are 2 options how to configure kubernetes ingresses to access Argo CD. We went with the second option and are using 2 separate ingresses together with nginx-ingress. However, we sometimes experienced issues when we used the Argo CD UI in parallel with the Argo CD cli app. When we tried to use the cli we sometimes got the following error:
Issuing the same command again afterwards worked flawless. In the nginx ingress logs we saw the following error messages:
We then created an issue for nginx-ingress , which sadly never got any attention. There is also this other issue which says that nginx does not support this (mixing http1 and http2 to the same target port).
For us the issue remained and it still seems to be the case that nginx-ingress can not handle HTTP1 and HTTP2 connections which need to be proxied to the same pod on the same port.
We are now working around the issue by using the annotation
nginx.ingress.kubernetes.io/proxy-http-version: "1.0"
on the normal web UI ingress. This disables keep-alive connections from nginx-ingress to the argocd server pod and our cli commands now work all the time.Nevertheless, this is just a workaround and we would like to use HTTP/1.1 as the upstream connection protocol again.
Would it be possible to provide an option to have a HTTP1 and a HTTP2 port exposed by argocd-server? Or is there any other solution known for this issue?
Motivation
Please see above