I’m using the helm to configure the Kubernetes Cluster, I’m able to run the helm commands but the HOST variable is not being assigned when I try to run the command:
HOST=$(kubectl get svc --namespace default kong-1633429251-kong-proxy -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
And also, I see that all the configurations for Kong are done via declarative configurations. can you also guide me if there is any way to configure kong services using APIs.
If you are not deploying on a cloud provider, i.e, EKS, GKE, etc you will need to find another way to get the IP. The LoadBalancer service is used to auto configure a load balancer on a cloud platform. Running locally/bare metal/VM you may want to look into other options like MetalLB.
Optionally, you can change your service to type NodePort.
@Dileep - I am not sure if you have tried this but this kubernetes manifest file installs kong with postgres server. I have had problems with the postgres pod due to permission issues but that was a separate story.
With the above manifest file I could see all pods and kong services up and running without any modifications. Probably @joedas is right but surprisingly I didn’t have to change the service type from LoadBalancer to NodePort even when running k8s on my laptop through k3d and k3s.
As others mentioned, that command relies on the proxy having an external IP. Local Kubernetes distributions usually will not configure networking and cluster configuration for LoadBalancer Services automatically, but most provide plugins that you can use to provision external IPs on a local network interface, e.g.
You can alternately use kubectl port-forward to access the proxy without a LoadBalancer, in which case you’d reach it over localhost.
When using the ingress controller, you typically do not use the Kong admin API to configure your routes and services. You instead create Kubernetes Ingress and Service resources, and the controller will translate them into Kong configuration on your behalf, as shown in our getting started guide.
When using a database, you can create routes and services directly via the admin API if you expose it (using port-forward is probably the simplest means to access the admin API with your environment). This configuration can coexist with controller-managed configuration, but we typically don’t recommend mixing manually-managed and controller-managed configuration. Unless you have a known reason you cannot manage part of your configuration via the controller (for example, it doesn’t support Kong Enterprise Developer Portal configuration), you should manage configuration entirely through Kubernetes resources.