The following guide will explain the procedure of how to set up the Kong Gateway as an Ingress controller in a Kubernetes environment from scratch.
As always, check out Kong’s documentation for updated installation instructions at https://github.com/Kong/kubernetes-ingress-controller.
Prerequisite
We will use Helm (https://helm.sh/) to install the Kong Ingress. Begin with installing a binary release of Kong from the following page (https://github.com/helm/helm/releases). Make sure you can run the helm command from your terminal of choice, i.e. add helm to your PATH variable.
In this guide we will for simplicity proceed with the Kubernetes HTTP load balancing feature disabled, since we are going to use the “kong” ingress controller class for all ingresses.
Installation
Run the following commands to install Kong Ingress to your cluster. The kubectl command must be connected to your cluster before executing the commands.
# Add the kong repo helm repo add kong https://charts.konghq.com helm repo update # Install kong helm install kong/kong --version v1.11.0 --generate-name --set ingressController.installCRDs=false # List installed modules helm ls # List installed services (to view External IP) kubectl get services
Configuration
The next step is to install the ingress configuration, which routes our requests to the correct service. The following configuration contains a basic default configuration that can be used as start, but can be expanded at a later stage with various Kong plugins. Make sure to install the ingress.yml last, since it depends on the other two configurations.
The kubernetes.io/ingress.class: "kong"
will make sure Kubernetes uses Kong as the ingress controller, if for any reason the HTTP load balancer is enabled. It is also a requirement from now on for Kong to work in later versions.
# ingress.yml apiVersion: networking.k8s.io/v1beta1 kind: Ingress metadata: name: my-api-ingress annotations: kubernetes.io/ingress.class: "kong" spec: rules: - host: example.com http: paths: - path: /v1 backend: serviceName: my-v1-services servicePort: 8080 - path: /v2 backend: serviceName: my-v2-services servicePort: 8080
Kubernetes services
A final note on exposing services in Kubernetes. Kubernetes services needs to be exposed as NodePorts, and not ClusterIPs, for Kong to be able to direct route traffic to the service(s) without going through the kube-proxy service.
Thats it! If you want to add certificates with Lets Encrypt with this configuration, check out the other post with Kong + Lets Encrypt.