dasjestyr/kong_gke.md

## kong_gke.md

      
    Raw
  

              kong_gke.md
            
          
Setup


Install Kong to Kubernetes cluster via Marketplace

It installs a few pods: Proxy, Admin, and Postgres


Administration

Administration is done via CLI but don't expose the admin service to the internet. Instead, you need to tunnel into the admin pod:

Run kubectl get pods to find the admin pod. It's the one that isn't the deployer or postgres
Proxy to the pod with kubectl port-forward <pod name> <localport>:8001
From here you will access the admin REST API

Create a service

curl -i -X POST --url http://localhost:<port>/services/ \
--data 'name=<service-name>' \
--data 'url=<service-host>'

# example
curl -i -X POST --url http://localhost:8001/services \
--data 'name=reviews-api'
--data 'url=http://reviews'
This creates a service resource called 'reviews-api' that will forward requests to the dns entry 'reviews'. This example assumes that the upstream service is deployed as a NodePort service on port 80 (default).
Create a route

curl -i -X POST --url http://localhost:<port>/services/<service-name≥/routes \
--data 'paths[]=/<arbitrary name>'

## example
curl -i -X POST --url http://localhost:8001/services/reviews-api/routes \
--data 'paths[]=/reviews'
This will create a route /reviews which will be forwarded to the host specified in the service creation step. In this case, for example, a request to /reviews/configurations/123 will be forwarded to http://reviews/configurations/123
Routing can also be done via hostname. For example, if you wanted a request from https://api.mycompany.com to be sent to one service but requests from https://api.mydev.io to go to another, these can be handled on the same load balancer by setting hosts[]=mydev.io for example. See Kong docs (in routes section).
Notes


The documentation says that the Kong proxy defaults to port 8000 but the Google Marketplace deploys it on port 80 and 443. So just look at the kong proxy service in Kubernetes to see what port it is on. Wherever it is, is where your requests should go. So for example, if it were to be deployed on port 8080, then requests to services might look like this:

GET https://api.mycompany.com:8080/reviews/configuration/123 (forwards to internal http://reviews/configuration/123)
GET https://api.mycompany.com:8080/users/123 (forwards to internal http://users/123)

But if we just keep it on port 80, we can just use it as an ingress point and it not look weird.
GET https://gateway.responselogix.io/reviews/configuration/123