Kong-ingress services usage avoidance

Hi everyone!

I’m reading the following on Kong-ingress docs: “The Kong ingress controller does not use Services to route traffic to the pods. Instead it uses the Endpoints API to bypass kube-proxy to allow Kong features like session affinity and custom load balancing algorithms. It also removes overhead, such as conntrack entries for iptables DNAT.”
Is it possible to achieve the same Services usage avoidance without the Kong-ingress container? Just with plain Kong.
The major option I demand on is cookie-based session stickiness.

Thanks!

Hello @megastallman,

You could technically do it without Kong Ingress controller, i.e. with Kong only, however, you will need to write a small controller.

Allow me to explain.
To bypass kube-proxy, Kong (or anything else) needs to know the real destination address. Services in k8s have a virtual address which is translated to the real address of a Pod by kube-proxy.
To figure out the real address of pod(s) belonging to a service in k8s, you can use the Endpoints API in k8s.

The problem here is, pods in k8s will be rescheduled and come and go away dynamically and hence the list of pod addresses for a service needs to be synced to Kong whenever a change happens.

A small program(in place of ingress controller), will need to keep the pod address in k8s with the Targets for a particular Upstream in Kong and then Kong can provide stickiness.

I recommend using the Ingress Controller to do this for you. Any reason you are currently avoiding it?

Thanks @hbagdi!

That looks good! I’m staying with Kong-ingress.
I’m asking that in a context of More control with Kong ACLs
At the moment I’ve got all my Services, Routes and Upstreams generated from Kubernetes Ingress resources. The same resources I’m using for Openshift Router and/or Nginx Ingress configuration.
But as long as we’ve got more complicated requirements on API filtering and restrictions, I see I need to create much more Kubernetes Ingress resources, e.g:
/p1/p2/p3/
/p1/p2/
/p1/
and so forth…
Did I get it right?

Thanks!

@megastallman, that sounds correct to me!