The actual deployment installs fine and shows no error. The service LoadBalancer however is in a “pending” state. This seems consistent with the fact that this is a bare-metal set-up without a software LoadBalancer installed.
I have noticed however that although the service is in a pending state I can still run the test curl command if I use a node IP and the port in the 30000 range I get when I inspect the state of the service via kubectl.
My questions are:
Could I just replace the LoadBalancer service for a NodePort one so that the service is not stuck in a pending state?
I am not sure if connecting to the PROXY_IP like I have done actually proves that Kong is working as an ingress controller. How do I know if the ingress controller is actually working?
Could I just replace the LoadBalancer service for a NodePort one so that the service is not stuck in a pending state?
It is stuck in pending state because there is no loadBalancer. For local development, you can try metallb. The service itself is running, you can use port-forward to test the service.
How do I know if the ingress controller is actually working?
Thank you very much for your reply! I only went as far as the curl -i $PROXY_IP bit and saw that it was working, which threw me off. I’ll try creating an ingress.
The live environment will be in the same situation as the test environment (air-gapped, metal bare). So having the LoadBalancer service as “not pending” would be desirable. Would you know what options I’d have?
Thank you again. What about running Kong as a Daemonset, replacing NGinx? I could access the services directly as they are bound to the host ports I want. Would a LoadBalancer service still be of any use?
I managed to install Kong without the LB service. The steps in my case:
Install Helm
Copy the helm charts from github GitHub - Kong/charts: Helm chart for Kong locally
Install kong with this command line helm install -f [value file] [release name] [chart directory location]
where the value file, in my case looks like this: