Argo CD 如何配置 nginx ingress-nginx 暴露 gRPC 与 HTTPSssl-passthrough【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cdArgo CD 的 API server 同时运行 gRPC serverargocdCLI 使用和 HTTP/HTTPS serverUI 使用两者都通过argocd-serverService 暴露443 端口承载 gRPC/HTTPS80 端口承载 HTTP重定向到 HTTPS。在 Service 清单中http和https两个命名端口都指向 targetPort8080。问题是 ingress-nginx 的nginx.ingress.kubernetes.io/backend-protocol注解只接受单个协议值HTTP、HTTPS、GRPC、GRPCS 之一无法用一个 Ingress 对象同时描述同一端口上的两种协议。官方文档 Ingress Configuration 给出的解决方式是用nginx.ingress.kubernetes.io/ssl-passthrough注解把 TLS 连接直接透传给 Argo CD API server让 API server 自己终止 TLS 并根据探测到的协议gRPC 或 HTTPS应答从而用单条 Ingress 规则和单个域名同时暴露 UI 与 CLI 通道。需要说明文档标注 ingress-nginx 已退役2026 年 3 月 24 日归档该章节保留作为其他 Ingress 控制器的参考。如果你正在新建集群可以先看文档中其他控制器章节如果集群已经在用 ingress-nginx下面的步骤可直接套用。前置条件为 nginx-ingress-controller 开启 ssl-passthroughssl-passthrough注解要求nginx-ingress-controller的命令行参数中加入--enable-ssl-passthrough否则注解不会生效。修改 ingress-nginx 的 controller 启动参数后确认控制器重启完成再应用下面的 Ingress 资源。前提Argo CD 已安装在argocd命名空间argocd-serverService 存在且包含http80与https443两个命名端口。应用 SSL-Passthrough IngressapiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: argocd-server-ingress namespace: argocd annotations: nginx.ingress.kubernetes.io/force-ssl-redirect: true nginx.ingress.kubernetes.io/ssl-passthrough: true spec: ingressClassName: nginx rules: - host: argocd.example.com http: paths: - path: / pathType: Prefix backend: service: name: argocd-server port: name: https要点host替换为你自己的域名。这条规则没有tls段是有意为之TLS 在 Argo CD API server 一侧终止而不是在 Ingress 控制器终止。流量最终打到argocd-serverService 的https命名端口443 → targetPort 8080。force-ssl-redirect让 HTTP 请求重定向到 HTTPS。应用后Argo CD API server 负责终止 TLS并检测连接上实际使用的协议、按 gRPC 或 HTTPS 分别应答。UI 与 CLI 都通过同一个域名访问。文档给出的 CLI 登录示例为argocd login host其中host即 Ingress 中配置的域名可用它验证 gRPC 通道是否打通。可选结合 cert-manager 与 Lets Encrypt 签发证书如果你用 cert-manager 管理证书在 Ingress 上加cert-manager.io/cluster-issuer注解并补充tls段apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: argocd-server-ingress namespace: argocd annotations: cert-manager.io/cluster-issuer: letsencrypt-prod nginx.ingress.kubernetes.io/ssl-passthrough: true # If you encounter a redirect loop or are getting a 307 response code # then you need to force the nginx ingress to connect to the backend using HTTPS. # nginx.ingress.kubernetes.io/backend-protocol: HTTPS spec: ingressClassName: nginx rules: - host: argocd.example.com http: paths: - path: / pathType: Prefix backend: service: name: argocd-server port: name: https tls: - hosts: - argocd.example.com secretName: argocd-server-tls # as expected by argocd-server这一版与上一版的差异cert-manager.io/cluster-issuer: letsencrypt-prod指定集群签发者替换为你实际存在的 Issuer 名称。secretName: argocd-server-tls是文档标注的 as expected by argocd-server即 Argo CD API server 用于终止 TLS 的 Secret 名称不要改成别的名字否则 passthrough 模式下 API server 找不到自己的证书。nginx.ingress.kubernetes.io/backend-protocol: HTTPS注解在文档注释中说明遇到重定向循环或收到 307 响应码时用它强制 nginx 通过 HTTPS 连接后端。排查出现重定向循环或 307 时文档明确给出的判断标准是应用 SSL-Passthrough 配置后如果遇到 redirect loop或响应码为 307说明 nginx 到后端的连接协议不对需要加上nginx.ingress.kubernetes.io/backend-protocol: HTTPS注解见上一节的 Ingress。这是文档中针对该方案唯一列出的异常症状与修复手段。替代路径在 Ingress 控制器终止 TLS这是同一文档中的 Option 2适用于希望 TLS 在 Ingress 侧终止、且可以接受两个域名的场景与 ssl-passthrough 是二选一不要同时使用。由于 ingress-nginx 一个 Ingress 对象只支持单协议需要定义两个 Ingress各用一个域名且secretName必须不同以避免不可预期行为HTTP/HTTPS IngressapiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: argocd-server-http-ingress namespace: argocd annotations: nginx.ingress.kubernetes.io/force-ssl-redirect: true nginx.ingress.kubernetes.io/backend-protocol: HTTP spec: ingressClassName: nginx rules: - http: paths: - path: / pathType: Prefix backend: service: name: argocd-server port: name: http host: argocd.example.com tls: - hosts: - argocd.example.com secretName: argocd-ingress-httpgRPC IngressapiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: argocd-server-grpc-ingress namespace: argocd annotations: nginx.ingress.kubernetes.io/backend-protocol: GRPC spec: ingressClassName: nginx rules: - http: paths: - path: / pathType: Prefix backend: service: name: argocd-server port: name: https host: grpc.argocd.example.com tls: - hosts: - grpc.argocd.example.com secretName: argocd-ingress-grpc采用这条路径时Argo CD API server 必须关闭 TLS在argocd-serverDeployment 的启动命令加--insecure标志或在argocd-cmd-params-cmConfigMap 中设置server.insecure: true两种配置方式的说明见 additional configuration methods。文档对这条路径的取舍评价代价是 API server 需要两个独立域名一个 gRPC、一个 HTTP/HTTPS好处是 TLS 终止发生在 Ingress 控制器。ssl-passthrough 方案则只需一个域名、API server 保持默认 TLS且不需要改argocd-server的启动参数。限制ingress-nginx 项目已归档文档将本节定位为其他 Ingress 控制器的参考新集群选型时建议同时评估文档中给出的 Contour、Traefik、Gateway API 等方案。ssl-passthrough 依赖 API server 侧的 TLS 证书证书缺失或 Secret 名称不符cert-manager 场景下应为argocd-server-tls会导致连接异常排查方向以文档给出的 307/重定向循环现象为准。完整配置背景与其他控制器方案见 docs/operator-manual/ingress.md。【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Argo CD 如何配置 nginx ingress-nginx 暴露 gRPC 与 HTTPS（ssl-passthrough）
Argo CD 如何配置 nginx ingress-nginx 暴露 gRPC 与 HTTPSssl-passthrough【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cdArgo CD 的 API server 同时运行 gRPC serverargocdCLI 使用和 HTTP/HTTPS serverUI 使用两者都通过argocd-serverService 暴露443 端口承载 gRPC/HTTPS80 端口承载 HTTP重定向到 HTTPS。在 Service 清单中http和https两个命名端口都指向 targetPort8080。问题是 ingress-nginx 的nginx.ingress.kubernetes.io/backend-protocol注解只接受单个协议值HTTP、HTTPS、GRPC、GRPCS 之一无法用一个 Ingress 对象同时描述同一端口上的两种协议。官方文档 Ingress Configuration 给出的解决方式是用nginx.ingress.kubernetes.io/ssl-passthrough注解把 TLS 连接直接透传给 Argo CD API server让 API server 自己终止 TLS 并根据探测到的协议gRPC 或 HTTPS应答从而用单条 Ingress 规则和单个域名同时暴露 UI 与 CLI 通道。需要说明文档标注 ingress-nginx 已退役2026 年 3 月 24 日归档该章节保留作为其他 Ingress 控制器的参考。如果你正在新建集群可以先看文档中其他控制器章节如果集群已经在用 ingress-nginx下面的步骤可直接套用。前置条件为 nginx-ingress-controller 开启 ssl-passthroughssl-passthrough注解要求nginx-ingress-controller的命令行参数中加入--enable-ssl-passthrough否则注解不会生效。修改 ingress-nginx 的 controller 启动参数后确认控制器重启完成再应用下面的 Ingress 资源。前提Argo CD 已安装在argocd命名空间argocd-serverService 存在且包含http80与https443两个命名端口。应用 SSL-Passthrough IngressapiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: argocd-server-ingress namespace: argocd annotations: nginx.ingress.kubernetes.io/force-ssl-redirect: true nginx.ingress.kubernetes.io/ssl-passthrough: true spec: ingressClassName: nginx rules: - host: argocd.example.com http: paths: - path: / pathType: Prefix backend: service: name: argocd-server port: name: https要点host替换为你自己的域名。这条规则没有tls段是有意为之TLS 在 Argo CD API server 一侧终止而不是在 Ingress 控制器终止。流量最终打到argocd-serverService 的https命名端口443 → targetPort 8080。force-ssl-redirect让 HTTP 请求重定向到 HTTPS。应用后Argo CD API server 负责终止 TLS并检测连接上实际使用的协议、按 gRPC 或 HTTPS 分别应答。UI 与 CLI 都通过同一个域名访问。文档给出的 CLI 登录示例为argocd login host其中host即 Ingress 中配置的域名可用它验证 gRPC 通道是否打通。可选结合 cert-manager 与 Lets Encrypt 签发证书如果你用 cert-manager 管理证书在 Ingress 上加cert-manager.io/cluster-issuer注解并补充tls段apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: argocd-server-ingress namespace: argocd annotations: cert-manager.io/cluster-issuer: letsencrypt-prod nginx.ingress.kubernetes.io/ssl-passthrough: true # If you encounter a redirect loop or are getting a 307 response code # then you need to force the nginx ingress to connect to the backend using HTTPS. # nginx.ingress.kubernetes.io/backend-protocol: HTTPS spec: ingressClassName: nginx rules: - host: argocd.example.com http: paths: - path: / pathType: Prefix backend: service: name: argocd-server port: name: https tls: - hosts: - argocd.example.com secretName: argocd-server-tls # as expected by argocd-server这一版与上一版的差异cert-manager.io/cluster-issuer: letsencrypt-prod指定集群签发者替换为你实际存在的 Issuer 名称。secretName: argocd-server-tls是文档标注的 as expected by argocd-server即 Argo CD API server 用于终止 TLS 的 Secret 名称不要改成别的名字否则 passthrough 模式下 API server 找不到自己的证书。nginx.ingress.kubernetes.io/backend-protocol: HTTPS注解在文档注释中说明遇到重定向循环或收到 307 响应码时用它强制 nginx 通过 HTTPS 连接后端。排查出现重定向循环或 307 时文档明确给出的判断标准是应用 SSL-Passthrough 配置后如果遇到 redirect loop或响应码为 307说明 nginx 到后端的连接协议不对需要加上nginx.ingress.kubernetes.io/backend-protocol: HTTPS注解见上一节的 Ingress。这是文档中针对该方案唯一列出的异常症状与修复手段。替代路径在 Ingress 控制器终止 TLS这是同一文档中的 Option 2适用于希望 TLS 在 Ingress 侧终止、且可以接受两个域名的场景与 ssl-passthrough 是二选一不要同时使用。由于 ingress-nginx 一个 Ingress 对象只支持单协议需要定义两个 Ingress各用一个域名且secretName必须不同以避免不可预期行为HTTP/HTTPS IngressapiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: argocd-server-http-ingress namespace: argocd annotations: nginx.ingress.kubernetes.io/force-ssl-redirect: true nginx.ingress.kubernetes.io/backend-protocol: HTTP spec: ingressClassName: nginx rules: - http: paths: - path: / pathType: Prefix backend: service: name: argocd-server port: name: http host: argocd.example.com tls: - hosts: - argocd.example.com secretName: argocd-ingress-httpgRPC IngressapiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: argocd-server-grpc-ingress namespace: argocd annotations: nginx.ingress.kubernetes.io/backend-protocol: GRPC spec: ingressClassName: nginx rules: - http: paths: - path: / pathType: Prefix backend: service: name: argocd-server port: name: https host: grpc.argocd.example.com tls: - hosts: - grpc.argocd.example.com secretName: argocd-ingress-grpc采用这条路径时Argo CD API server 必须关闭 TLS在argocd-serverDeployment 的启动命令加--insecure标志或在argocd-cmd-params-cmConfigMap 中设置server.insecure: true两种配置方式的说明见 additional configuration methods。文档对这条路径的取舍评价代价是 API server 需要两个独立域名一个 gRPC、一个 HTTP/HTTPS好处是 TLS 终止发生在 Ingress 控制器。ssl-passthrough 方案则只需一个域名、API server 保持默认 TLS且不需要改argocd-server的启动参数。限制ingress-nginx 项目已归档文档将本节定位为其他 Ingress 控制器的参考新集群选型时建议同时评估文档中给出的 Contour、Traefik、Gateway API 等方案。ssl-passthrough 依赖 API server 侧的 TLS 证书证书缺失或 Secret 名称不符cert-manager 场景下应为argocd-server-tls会导致连接异常排查方向以文档给出的 307/重定向循环现象为准。完整配置背景与其他控制器方案见 docs/operator-manual/ingress.md。【免费下载链接】argo-cdDeclarative Continuous Deployment for Kubernetes项目地址: https://gitcode.com/GitHub_Trending/ar/argo-cd创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
