Minimal Kong deployment on GKE

I’m trying out Kong on an existing cluster on GKE, using the all-in-one-dbless yaml:

What I’m doing is just route traffic to my internal Services with some Ingress resources, have them rate limited using KongPlugin and make each endpoint ask for a token at the Authorization header with OIDC plugin config with Keycloak (after modifying the base Kong image with ENV KONG_PLUGINS oidc).

Everything is working fine so far. But after scanning through the all-in-one-dbless yaml file, I was wondering is this the most minimal yaml to get Kong up and running? Is there anything that I can shave off?

Firstly, I am seeing 6 CRDs in the yaml file:

  • KongClusterPlugin
  • KongConsumer
  • KongCredential
  • KongIngress
  • KongPlugin
  • TCPIngress
    After reading the docs on the github repo, I think I would only make use of KongPlugin and maybe KongIngress, not all of them. I did go and try removing some of the CRDs, but most of the time the ingress-controller fails to start and the logs read that it could not find the CRDs defined.
    Is there anyway to maybe remove some of the CRDs and add it when I need it in the future?

Secondly, in the yaml file also defines a ServiceAccount. If I already have a ServiceAccount defined for my cluster, can I just add the necessary apiGroups, reousrces to the existing ServiceAccount and refer it to the Deployment of kong-ingress-controller?

Third one is that the Kong-proxy service is using these 2 annotations:

Lastly, there is a Service, kong-validation-webhook, what purpose does it serve and do I need this for a normal installation?
I did try removing it and everything still runs fine. Is this the yaml file behind it?
I’m not very familiar with and have a vague understanding that an admission webhook prevents some similar Resources from conflicting with each other (?)

I did my best to look through the docs to see if these are all mandatory but still not sure.

Best regards,

Not yet. The controller requires all the CRDs as of now. This is something we would like to change in future. A Github issue for this feature request would be helpful.


No. You can safely remove those.


1 Like

Thanks for the quick response, @hbagdi, it helped me clear things up.