Kong Helm 代理入口控制器 400 错误请求

Question

通过 helm chart 安装 Kong 时，每当我尝试为代理启用入口控制器时都会收到错误消息。我正在打开入口控制器，以便它可以从证书管理器（运行正常）请求证书。关闭入口控制器后，一切都按预期工作。开启它后，我会收到 400 Bad Request The plain HTTP request was sent to HTTPS port 错误。

我试过了：

1. 在 tls 部分将容器端口（和 overrideServiceTargetPort）从 8443 更改为 8000、80、443 和 8443。在使用 8000 时，我收到了使用 https 的 Error code: SSL_ERROR_RX_RECORD_TOO_LONG 或使用 http 的 bad request 错误。在verrideServiceTargetPort 中使用端口443 确实允许我连接http，但https 导致We can’t connect to the server at XYZ

2. 为代理添加“konghq.com/protocol”:“https”注解。这会导致 http 和 https 的请求错误。

3. 在代理中关闭 http。

4. 在入口控制器中关闭 TLS。

5. 根据我在代理日志中看到的错误对管理 API 进行了一些更改。现在代理日志只显示 400 秒，没有任何错误。

6. 更改节点端口

7. 在入口资源中手动更改服务端口，并将路径更改为/?(.*)

我认为问题在于入口控制器正在终止 TLS 连接并将不安全的连接传递给 Kong 代理，只是在错误的端口上。这很好，但我似乎无法在代理中找到正确的端口来传递连接。

另一个奇怪的是，有时，在对 helm chart 应用更改后，如果在加载所有内容之前在 https 上导航到 Kong，它实际上会正确连接。但是，所有后续尝试都失败了。我也无法可靠地让它以这种方式连接

这是使用 GKE，因此 AWS LB 注释在这里不适用（我找不到类似的东西

金刚：2.8

入口：

Name:             kong-dev-kong-proxy
Namespace:        custom-namespace
Address:          123.123.123.123
Default backend:  default-http-backend:80 (192.168.0.3:8080)
TLS:
  kong-proxy-cert terminates kong-test.domain
Rules:
  Host                    Path  Backends
  ----                    ----  --------
  kong-test.domain  
                          /?(.*)   kong-dev-kong-proxy:443 (192.168.0.125:8443)
Annotations:              cert-manager.io/cluster-issuer: letsencrypt-cluster-issuer
                          kubernetes.io/tls-acme: true
                          meta.helm.sh/release-name: kong-dev
                          meta.helm.sh/release-namespace: custom-namespace
Events:                   <none>

头盔：

proxy:
  # Enable creating a Kubernetes service for the proxy
  enabled: true
  type: LoadBalancer
  # To specify annotations or labels for the proxy service, add them to the respective
  # "annotations" or "labels" dictionaries below.
  annotations: #{"konghq.com/protocol":"https"}
  # If terminating TLS at the ELB, the following annotations can be used
  #{"service.beta.kubernetes.io/aws-load-balancer-backend-protocol": "*",}
  # "service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled": "true",
  # "service.beta.kubernetes.io/aws-load-balancer-ssl-cert": "arn:aws:acm:REGION:ACCOUNT:certificate/XXXXXX-XXXXXXX-XXXXXXX-XXXXXXXX",
  # "service.beta.kubernetes.io/aws-load-balancer-ssl-ports": "kong-proxy-tls",
  # "service.beta.kubernetes.io/aws-load-balancer-type": "elb"
  labels:
    enable-metrics: "true"

  http:
    # Enable plaintext HTTP listen for the proxy
    enabled: true
    servicePort: 80
    containerPort: 8000
    # Set a nodePort which is available if service type is NodePort
    # nodePort: 32080
    # Additional listen parameters, e.g. "reuseport", "backlog=16384"
parameters: []

  tls:
    # Enable HTTPS listen for the proxy
    enabled: true
    servicePort: 443
    containerPort: 8443
    # Set a target port for the TLS port in proxy service
    #overrideServiceTargetPort: 8000
    # Set a nodePort which is available if service type is NodePort
    #nodePort: 32443
    # Additional listen parameters, e.g. "reuseport", "backlog=16384"
    parameters:
    - http2

  # Define stream (TCP) listen
  # To enable, remove "[]", uncomment the section below, and select your desired
  # ports and parameters. Listens are dynamically named after their servicePort,
  # e.g. "stream-9000" for the below.
  # Note: although you can select the protocol here, you cannot set UDP if you
  # use a LoadBalancer Service due to limitations in current Kubernetes versions.
  # To proxy both TCP and UDP with LoadBalancers, you must enable the udpProxy Service
  # in the next section and place all UDP stream listen configuration under it.
  stream: []
    #   # Set the container (internal) and service (external) ports for this listen.
    #   # These values should normally be the same. If your environment requires they
    #   # differ, note that Kong will match routes based on the containerPort only.
    # - containerPort: 9000
    #   servicePort: 9000
    #   protocol: TCP
    #   # Optionally set a static nodePort if the service type is NodePort
    #   # nodePort: 32080
    #   # Additional listen parameters, e.g. "ssl", "reuseport", "backlog=16384"
    #   # "ssl" is required for SNI-based routes. It is not supported on versions <2.0
    #   parameters: []

  # Kong proxy ingress settings.
  # Note: You need this only if you are using another Ingress Controller
  # to expose Kong outside the k8s cluster.
  ingress:
    # Enable/disable exposure using ingress.
    enabled: true
    ingressClassName: kong
    # Ingress hostname
    # TLS secret name.
    tls: kong-proxy-cert
    hostname: kong-test.domain
    # Map of ingress annotations.
    annotations: {"kubernetes.io/tls-acme": "true", "cert-manager.io/cluster-issuer": "letsencrypt-cluster-issuer"}
    # Ingress path.
    path: /
    # Each path in an Ingress is required to have a corresponding path type. (ImplementationSpecific/Exact/Prefix)
    pathType: ImplementationSpecific

  # Optionally specify a static load balancer IP.
  # loadBalancerIP:

更新：

每次我匹配协议时，通过将入口控制器中的后端端口更改为 80 或通过设置 konghq.com/protocol":"https"，我会通过初始 http 到 https 端口错误，但随后proxy返回一个标准的400 bad request错误。奇怪的是我在尝试使用入口中指定的主机名时只得到新的400错误。如果我直接curl代理服务名称（在入口的后端指定）从 Pod 甚至负载均衡器的外部 IP，我能够从代理获得典型的 404 响应，但是只要我为请求提供主机名时，400 bad request error 仍然会发生（当代理的入口控制器仅在使用提供给入口控制器的“主机”时才打开）。从内部 pod 直接对代理服务名称进行 curl 是可行的，但是一旦添加 -H 选项，它就会给我一个 400 bad request 错误并提供入口主机名。

Answer 1

我能够通过将此注释添加到代理入口注释部分来解决此问题。

"konghq.com/preserve-host": "false"

在数据库中手动进行更改不起作用。只有在我使用上述注释更新掌舵图时，一切才开始工作。