I am trying to set up openunison in my Kubernetes cluster to do authentication. Technically they don't support Kong, but it is just an ingress controller so not sure why it would not be possible to configure. However I am seeing issues. I don't have a load balancer. I am using NodePort to expose Kong API and then use the ingress to map to back end services. I am seeing a timeout when trying to connect to the openunison pod 2021/03/04 22:11:44 [error] 22#0: *23854995 upstream timed out (110: Operation timed out) while connecting to upstream, client: 172.16.0.0, server: kong, request: "GET /auth HTTP/2.0", upstream: "https://172.16.127.167:8443/auth" If I hit the service from another pod in that namespace I seem to connect ok: openunison@openunison-operator-6b95dc6574-8sg49:/$ curl -L -k https://10.109.13.46:443/auth <?xml version="1.0" encoding="UTF-8" ?> <!-- Copyright 2015 Tremolo Security, Inc. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/openunison-orchestra ClusterIP 10.109.13.46 <none> 443/TCP,80/TCP 43h Here is my ingress apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: openunison labels: app: openunison-orchestra annotations: kubernetes.io/ingress.class: kong konghq.com/https_redirect_status_code: "301" konghq.com/preserve-host: "false" namespace: openunison spec: rules: - host: myhost http: paths: - path: / pathType: Prefix backend: service: name: openunison-orchestra port: number: 443
Is there anything unusual about your underlying network configuration, or anything that’d prevent Kong from talking to the Pods that provide that Service directly?
By default the controller retrieves the Pod IPs for Pods providing a Service and talks to those directly on the target port rather than sending requests through kube-proxy (which is what your test request is using, via the Service IP/port). Either approach should normally be valid, but some network configurations may disallow direct Pod to Pod communication: mesh proxies (e.g. Kuma or Istio) commonly do this.
Using the service-upstream annotation on your Services will instruct Kong to send traffic through kube-proxy instead if you have a network configuration that requires it.
I will try the service-upstream annotation as suggested. I am not aware of anything different with my configuration other than I am using nodePort versus loadbalancer. This is a test environment running on CentOS.
I get the same issue. Times out trying to communicate. I do see it trying to use the service clusterIP as the upstream client. Not sure why this openunison does not work with kong. Not sure what I am missing:
2021/03/23 18:31:51 [error] 22#0: *38290740 upstream timed out (110: Operation timed out) while connecting to upstream, client: 172.16.44.192, server: kong, request: “GET /auth HTTP/2.0”, upstream: "https://10.100.160.10:443