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 時，我收到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 端口錯誤，但隨后代理返回一個標准400 bad request錯誤。奇怪的是，當我嘗試使用入口中指定的主機名時，我只收到新的 400 錯誤。如果我直接從 pod 卷曲代理服務名稱（在入口的后端中指定）甚至負載均衡器的外部 IP，我都能夠從代理獲得典型的 404 響應，但是只要我為請求提供主機名（當代理的入口控制器打開時），仍然會出現400 bad request error並且僅在使用提供給入口控制器的“主機”時）。從內部 pod 直接對代理服務名稱進行 curl 是有效的，但是一旦我添加 -H 選項並提供，它就會給我一個400 bad request錯誤入口主機名。

Answer 1

通過將此注釋添加到代理入口注釋部分，我能夠解決此問題。

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

在數據庫中手動進行更改不起作用。 只有在我使用上述注釋更新掌舵圖時，一切才開始工作。