argoproj / argo-cd

Declarative Continuous Deployment for Kubernetes
https://argo-cd.readthedocs.io
Apache License 2.0
17.32k stars 5.26k forks source link

Enhance separate ingress solution #3896

Open thirdeyenick opened 4 years ago

thirdeyenick commented 4 years ago

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:

argocd login <cli ingress host> --sso
FATA[0000] rpc error: code = Internal desc = transport: received the unexpected content-type "text/html"

Issuing the same command again afterwards worked flawless. In the nginx ingress logs we saw the following error messages:

2020/07/03 12:42:23 [error] 941#941: *12825628 no connection data found for keepalive http2 connection while sending request to upstream, client: <IP>, server: <cli ingress host>, request: "POST /cluster.SettingsService/Get HTTP/2.0", upstream: "grpc://172.16.2.9:8080", host: "<cli ingress host>:443"

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

balusarakesh commented 2 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?

josecsotomorales commented 2 years ago

I'm also getting this issue periodically

lblazewski commented 1 year ago

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.

josecsotomorales commented 1 year ago

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.