Routing across multiple Knative services with Kong
This example shows how to map multiple Knative services to different paths under a single domain name using Kong Gateway. Kong Gateway is a general-purpose reverse proxy and API gateway built on Nginx, therefore these directions can also be used to configure routing based on other request data such as headers, or even to map Knative and external resources under the same domain name.
In this sample, we set up two web services: Search service and Login service, which simply read in an env variable SERVICE_NAME
and print "${SERVICE_NAME} is called"
. We’ll then define routing rules via Kong’s Kubernetes Ingress Controller and Kong’s request transformer plugin, so that example.com/search
maps to the Search service, and example.com/login
maps to the Login service.
Prerequisites
- A Kubernetes cluster with Knative Serving and Kong installed.
- Install Docker.
- Acquire a domain name.
- In this example, we use
example.com
. If you don’t have a domain name, you can modify your hosts file (on macOS or Linux) to mapexample.com
to your cluster’s ingress IP. - If you have configured a custom domain for your Knative installation, we will refer to it as
<YOUR_DOMAIN_NAME>
in the rest of this document
- In this example, we use
Check out the code:
go get -d github.com/knative/docs/docs/serving/samples/kong-routing-go
Setup
To check the domain name, run the following command:
kubectl get cm -n knative-serving config-domain -o yaml
Then, check the value for data
. The domain name should be in the format of <YOUR_DOMAIN_NAME>: ""
, if it is available.
Build the application container and publish it to a container registry:
Move into the sample directory:
cd $GOPATH/src/github.com/knative/docs
Set your preferred container registry:
If you use Google Container Registry (GCR), you will need to enable the GCR API in your GCP project.
export REPO="gcr.io/<YOUR_PROJECT_ID>"
If you use Docker Hub as your Docker image registry, replace
<username>
with your Docker Hub username and run the following command:export REPO="docker.io/<username>"
Use Docker to build your application container:
docker build \
--tag "${REPO}/kong-routing-go" \
--file=docs/serving/samples/kong-routing-go/Dockerfile .
Push your container to a container registry:
docker push "${REPO}/kong-routing-go"
Replace the image reference path with our published image path in the configuration file
docs/serving/samples/kong-routing-go/sample.yaml
in one of the following ways:- Manually replace
image: github.com/knative/docs/docs/serving/samples/kong-routing-go
withimage: ${REPO}/kong-routing-go
. If you manually changed the.yaml
file, you must replace${REPO}
with the correct path on your local machine. Run this command:
perl -pi -e "s@github.com/knative/docs/docs/serving/samples@${REPO}@g" docs/serving/samples/kong-routing-go/sample.yaml
- Manually replace
Deploy the Service
Deploy the Knative Serving sample:
kubectl apply -f docs/serving/samples/kong-routing-go/sample.yaml
Inspect the deployed Knative services with:
kubectl get ksvc
You should see 2 Knative services: search-service
and login-service
.
Exploring the Routes
Kong Gateway serves all incoming traffic to services managed by Knative. You can inspect the corresponding Kubernetes service for the gateway:
INGRESSGATEWAY=kong-proxy
kubectl get svc $INGRESSGATEWAY -n kong --output yaml
Access the Services
Find the gateway IP and export it as an environment variable:
export GATEWAY_IP=`kubectl get svc $INGRESSGATEWAY -n kong \
--output jsonpath="{.status.loadBalancer.ingress[*]['ip']}"`
Find the Search service URL:
kubectl get route search-service --output=custom-columns=NAME:.metadata.name,URL:.status.url
The output should looks like this:
NAME URL
search-service http://search-service.default.example.com
Make a cURL request to the service:
curl http://${GATEWAY_IP} --header "Host:search-service.default.example.com"
The output should look like this:
Search Service is called!
Similarly, you can also directly access Login service:
curl http://${GATEWAY_IP} --header "Host:login-service.default.example.com"
The output should look like this:
Login Service is called!
Apply Custom Routing Rule
Apply the custom routing rules defined in the
routing.yaml
file:kubectl apply -f docs/serving/samples/kong-routing-go/routing.yaml
If you have configured a custom domain name for your service, please replace all mentions of
example.com
inrouting.yaml
with<YOUR_DOMAIN_NAME>
.In addition, you need to verify how your domain template is defined. By default, we use the format of
{{.Name}}.{{.Namespace}}
, likesearch-service.default
andlogin-service.default
. However, some Knative environments may use other formats like{{.Name}}-{{.Namespace}}
. You can find out the format by running the command:kubectl get cm config-network -n knative-serving -o yaml
Then, look for the value for
domainTemplate
. If it is{{.Name}}-{{.Namespace}}.{{.Domain}}
, you need to changesearch-service.default
intosearch-service-default
andlogin-service.default
intologin-service-default
as well inrouting.yaml
.The
routing.yaml
file will create an ingress that forwards incoming requests atexample.com/search
tosearch-service.default.example.com
by updating the “Host” header tosearch-service.default.example.com
and stripping the request path. This modified request is then forwarded to the Knative ingress (Kong) and routed to the service as usual. Another ingress like this is also created for the Login service.kubectl get ingress {search,login}-service-ingress -n kong --output yaml
Send a request to the Search service and the Login service by using their corresponding URLs. You should get the same results as directly accessing these services.
Send a request to the Search service:
curl http://${GATEWAY_IP}/search --header "Host: example.com"
or
curl http://${GATEWAY_IP}/search --header "Host: <YOUR_DOMAIN_NAME>"
for the case using your own domain.
Send a request to the Login service:
curl http://${GATEWAY_IP}/login --header "Host: example.com"
or
curl http://${GATEWAY_IP}/login --header "Host: <YOUR_DOMAIN_NAME>"
for the case using your own domain.
How It Works
When a request with host example.com
or your own domain name reaches Kong Gateway, Kong will check if the URL path prefix is /search
or /login
. If the URL matches on of the two rules, then the “Host” header of the request will be rewritten into the host of the Search service or Login service, respectively, and the path will be stripped. The modified request will be forwarded to Kong again. Kong will check the “Host” header and forward the request to the Search or Login service according to the header value.
Clean Up
To clean up the sample resources:
kubectl delete --filename docs/serving/samples/kong-routing-go/sample.yaml
kubectl delete --filename docs/serving/samples/kong-routing-go/routing.yaml