Kong Ingress Controller with Istio

Questions
1

Hello,

I followed this blog post: https://kubernetes.io/blog/2020/03/18/kong-ingress-controller-and-istio-service-mesh/. I went through and followed all of the steps but when I get to the point where you should be able to curl the newly exposed endpoint, I get {"message":"no Route matched with those values"}.

Here is the Ingress resource:

kind: Ingress
metadata:
  annotations:
    configuration.konghq.com: do-not-preserve-host
  name: productpage
spec:
  rules:
  - http:
      paths:
      - backend:
          serviceName: productpage
          servicePort: 9080
        path: /

My KongIngress resource:

apiVersion: configuration.konghq.com/v1
kind: KongIngress
metadata:
  name: do-not-preserve-host
route:
  preserve_host: false
upstream:
  host_header: productpage.default.svc

The productpage service resource:

apiVersion: v1
kind: Service
metadata:
  annotations:
    ingress.kubernetes.io/service-upstream: "true"
  labels:
    app: productpage
    service: productpage
  name: productpage
spec:
  ports:
  - name: http
    port: 9080
    protocol: TCP
    targetPort: 9080
  selector:
    app: productpage
  sessionAffinity: None
  type: ClusterIP

And lastly the curl command: curl -i localhost:8080

Can anyone see anything I’m doing wrong?

2

Env: minikube , istio v 1.7.3 with mTLS enabled
I have done the same configuration and got the same results.

 curl -iv http://localhost:8080/productpage
....
Handling connection for 8080
< HTTP/1.1 404 Not Found
HTTP/1.1 404 Not Found
< Date: Thu, 29 Oct 2020 12:20:36 GMT
Date: Thu, 29 Oct 2020 12:20:36 GMT
< Content-Type: application/json; charset=utf-8
Content-Type: application/json; charset=utf-8
< Connection: keep-alive
Connection: keep-alive
< Content-Length: 48
Content-Length: 48
< X-Kong-Response-Latency: 0
X-Kong-Response-Latency: 0
< Server: kong/2.1.4
Server: kong/2.1.4

< 
* Connection #0 to host localhost left intact
{"message":"no Route matched with those values"}* Closing connection 0
3 
    I have done this Change : 
    1.  Add the annotation :  kubernetes.io/ingress.class: kong to the Ingress
    2.  Add Host header to curl command
          curl -iv http://localhost:8080/productpage -H 'Host: productpage.default.svc'
    Then you should get  http 200
4

@daya_bethmage I add the annotation and the host header on the curl like you suggested and it works for me as well.

Question: Should there be something that is automatically adding that host header or is that an expected behavior?

5

Also, this could be just a me problem but I am running Kong and Istio on PKS. When the Kong Proxy Service is made it creates a load balancer.

When I port-forward the service I am able to successfully get results, however if I try to curl the endpoint via the load balancer url I get an “empty reply from server”.

Any ideas on what’s going on there?

6

Alright so for the above I got past the “empty reply from server” and am now on a “504 Gateway Timeout” error. Progress is progress.

7

Sorry for my late answer…

Well I am new to Kong and this may not the right answer why we need the Host header in curl

  1. Done a deck dump to get the kongs configuration (generates kong.yaml file)
  kubectl port-forward svc/kong-admin 8444:8444 &
   deck dump --tls-skip-verify --kong-addr https://localhost:8444 

The output kong.yaml:


_format_version: "1.1"
services:
- connect_timeout: 60000
host: productpage.default.9080.svc
name: default.productpage.9080
path: /
port: 80
protocol: http
read_timeout: 60000
retries: 5
write_timeout: 60000
routes:
- name: default.productpage.00
paths:
- /
path_handling: v0
preserve_host: true       ## This is overriden by KongInhgress ???
protocols:
- http
- https
regex_priority: 0
strip_path: false
https_redirect_status_code: 426
upstreams:
- name: productpage.default.9080.svc       
algorithm: round-robin

......
  1. The KongIngress manifest. Overrides the ingress properties ?
apiVersion: configuration.konghq.com/v1
kind: KongIngress
metadata:
  name: do-not-preserve-host
route:
  preserve_host: false
upstream:
  host_header: productpage.default.svc


-- 
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    configuration.konghq.com: do-not-preserve-host

This means for me
the upstream host should be ==> productpage.default.svc

As the Kong Docs says… we DO NOT need to add the Host header to the curl command.
But curl fail with :
upstream connect error or disconnect/reset before headers. reset reason: connection termination* Closing connection 0

envoy proxy log:
[2020-10-31T13:29:26.039Z] “GET /productpage HTTP/1.1” 503 UC “-” “-” 0 95 2 - “127.0.0.1” “curl/7.64.1” “d5cb97d5-095d-4d54-b07b-151de37e169d” “localhost:8080” “10.0.122.237:9080” PassthroughCluster 10.233.226.17:34042 10.0.122.237:9080 127.0.0.1:0 - allow_any

productpage SVC has the ClusterIP : 10.0.122.237
Pod endpoint : 10.233.226.56:9080

With the Host header it works
curl http://localhost:8080/productpage --header ‘host: productpage.default.svc’

and envoy proxy logs …

[2020-10-31T13:49:38.193Z] “GET /productpage HTTP/1.1” 200 - “-” “-” 0 5183 35 35 “127.0.0.1” “curl/7.64.1” “3090b64b-886f-41ec-935c-28a5baa7c099” “productpage.default.svc” “10.233.226.56:9080” outbound|9080||productpage.default.svc.cluster.local 10.233.226.17:52290 10.0.122.237:9080 127.0.0.1:0 - default

It looks good and the request goes through the Istio envoy as expected.

I really cannot understand HOW Kong pass the upstream hostname to the envoy-proxy (our istio case with SVC productpage annotation : ingress.kubernetes.io/service-upstream: “true”)

Hope somebody from the community can explain us, whats wrong here. (please)

See here : https://docs.konghq.com/2.0.x/proxy/#the-preserve_host-property

The preserve_host property : false
When proxying, Kong’s default behavior is to set the upstream request’s Host header to the hostname specified in the Service’s host
This means host header should be: productpage.default.9080.svc