Routing across multiple Knative services - Go

This example shows how to map multiple Knative services to different paths under
a single domain name using the Istio VirtualService concept. Istio is a
general-purpose reverse proxy, 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 prints
"${SERVICE_NAME} is called". We’ll then create a VirtualService with host
example.com, and define routing rules in the VirtualService so that
example.com/search maps to the Search service, and example.com/login maps to
the Login service.

Replace the image reference path with our published image path in the
configuration file docs/serving/samples/knative-routing-go/sample.yaml:

Manually replace:
image: github.com/knative/docs/docs/serving/samples/knative-routing-go
with image: ${REPO}/knative-routing-go If you manually changed the .yaml
file, you must replace \${REPO} with the correct path on your local
machine.

Deploy the Service

Exploring the Routes

A shared Gateway knative-ingress-gateway is used within Knative service mesh
for serving all incoming traffic. You can inspect it and its corresponding
Kubernetes service with:

Check the shared Gateway:

kubectl get Gateway --namespace knative-serving --output yaml

Check the corresponding Kubernetes service for the shared Gateway:

# In Knative 0.2.x and prior versions, the `knative-ingressgateway` service was used instead of `istio-ingressgateway`.
INGRESSGATEWAY=knative-ingressgateway
# The use of `knative-ingressgateway` is deprecated in Knative v0.3.x.
# Use `istio-ingressgateway` instead, since `knative-ingressgateway`
# will be removed in Knative v0.4.
if kubectl get configmap config-istio -n knative-serving &> /dev/null; then
INGRESSGATEWAY=istio-ingressgateway
fi
kubectl get svc $INGRESSGATEWAY --namespace istio-system --output yaml

Inspect the deployed Knative services with:

kubectl get ksvc

You should see 2 Knative services: search-service and login-service.

Access the Services

Find the shared Gateway IP and export as an environment variable:

# In Knative 0.2.x and prior versions, the `knative-ingressgateway` service was used instead of `istio-ingressgateway`.INGRESSGATEWAY=knative-ingressgateway
# The use of `knative-ingressgateway` is deprecated in Knative v0.3.x.# Use `istio-ingressgateway` instead, since `knative-ingressgateway`# will be removed in Knative v0.4.if kubectl get configmap config-istio -n knative-serving &> /dev/null;thenINGRESSGATEWAY=istio-ingressgateway
fiexportGATEWAY_IP=`kubectl get svc $INGRESSGATEWAY --namespace istio-system \
--output jsonpath="{.status.loadBalancer.ingress[*]['ip']}"`

Apply Custom Routing Rule

If you have configured a custom domain name for your service, please replace all
mentions of “example.com” in routing.yaml with “” for
spec.hosts and spec.http.rewrite.authority.

In addition, you need to verify how your domain template is defined. By default,
we use the format of {{.Name}}.{{.Namespace}}, like search-service.default and
login-service.default. However, some Knative environments may use other format
like {{.Name}}-{{.Namespace}}. You can find out the format by running the
command:

kubectl get cm -n knative-serving config-network -o yaml

Then look for the value for domainTemplate. If it is
{{.Name}}-{{.Namespace}}.{{.Domain}}, you need to change
search-service.default into search-service-default and
login-service.default into login-service-default as well in routing.yaml.

The routing.yaml file will generate a new VirtualService entry-route for
domain example.com or your own domain name. View the VirtualService:

kubectl get VirtualService entry-route --output yaml

Send a request to the Search service and the Login service by using
corresponding URIs. You should get the same results as directly accessing
these services. _ Get the ingress IP:

# In Knative 0.2.x and prior versions, the `knative-ingressgateway` service was used instead of `istio-ingressgateway`.INGRESSGATEWAY=knative-ingressgateway
# The use of `knative-ingressgateway` is deprecated in Knative v0.3.x.# Use `istio-ingressgateway` instead, since `knative-ingressgateway`# will be removed in Knative v0.4.if kubectl get configmap config-istio -n knative-serving &> /dev/null;thenINGRESSGATEWAY=istio-ingressgateway
fiexportGATEWAY_IP=`kubectl get svc $INGRESSGATEWAY --namespace istio-system \
--output jsonpath="{.status.loadBalancer.ingress[*]['ip']}"`

How It Works

When an external request with host example.com or your own domain name reaches
knative-ingress-gateway Gateway, the entry-route VirtualService will check
if it has /search or /login URI. If the URI matches, then the host of
request will be rewritten into the host of Search service or Login service
correspondingly. This resets the final destination of the request. The request
with updated host will be forwarded to knative-ingress-gateway Gateway again.
The Gateway proxy checks the updated host, and forwards it to Search or
Login service according to its host setting.