Can Kong be used on Kubernetes without the Kong Ingress-Controller

[MissakaI]

The current environment I am using is AWS EKS as my Kubernetes Service and AWS ALB (Application Load Balancer) as my Ingress Controller. In my cases the use of ALB is a must with the company policies and constraints.

So even if i use Kong Chart I will have to use the Kong Ingress-Controller behind the ALB not as a LoadBalancer but as a Kubernetes NodePort service. So my question is can I use Kong without the Kong Ingress-Controller? Because it will only be an additional hop if I am to use two Ingress Controllers and will result in significant delays at higher loads.

Also I don't mind not being able to manage Kong through Kubernetes Resources if I can setup them somewhere else.

PS: I am new to Kong and plans to use the Kong Open Source in this project.

[rainest]

You can, yes. Enable the admin API and disable the ingress controller and you'll be to send configuration to the admin API as usual.

[MissakaI]

If so I have to expose the proxy through the ALB I assume.

[rainest]

There's no requirement to. The proxy is an HTTP proxy and implements functionality similar to an ALB. Our standard recommendation is to use a TCP load balancer (an NLB), as adding multiple HTTP proxies in a chain without a known need to do so increases latency and makes it less obvious where HTTP-level operations are occurring between the client and upstream application.

Users do place ALBs in front of Kong in certain cases where they need functionality that only the ALB can provide. For example, only ALBs can run traffic through AWS's WAF, and Kong has no WAF of its own. Therefore, if you want to use both a WAF and some Kong plugin, that'd be a valid case to use an ALB over an NLB in front of Kong.

[MissakaI]

I have an valid case to use the ALB in front as the company has set all WAF and other rules to the ALB and We are using AWS DirectConnect to connect from our on-prem server to VPC and all configurations of that set up to use L7 protocols and verification. Hence using a L4 service like NLB is not feasible. That's the main reason of using the ALB.

And the idea of using Kong is also based on the fact that AWS API GW's HTTP API doesn't support the private VPC endpoints and only the REST API has the support for private endpoints. So AWS API GW HTTP API is a no go.

And it is not feasible request to change multiple points of the eco-system as only one tenant in cluster will be using Kong for the moment.

[MissakaI]

Since I am using this in a multi-tenant environment I will only be getting a single path mapping from the ALB such as ALB_DNS/kong/. Can I then use the proxy behind a path mapping.

[rainest]

Yes, you can have something like an ALB rule to route example.com/kong/ to Kong and then configure Kong to route example.com/kong/foo/ and example.com/kong/bar/ independently.

[winterelf]

disable the ingress controller

isn't disabling kong ingress controller and enabling admin api means I can't use custom CRDs to configure kong routes/consumers/plugins/etc.?

and if the above true, I guess I can't use infra as a code style to manage kong resources because I don't have a state (not CRD yaml files, and not. terraform state), because the only terraform provider that is being used, supports only kong 2.x and is hardly maintained over a year.