Swap Knative’s default example.com for a custom domain with path routing

Background

Knative Serving automatically creates a DNS name for each Service using the default master domain example.com. This domain cannot be used in production because it is not publicly routable.

Deploy a sample Knative Service

Save the following manifest as helloworld.yaml and apply it:

---
apiVersion: v1
kind: Namespace
metadata:
  name: helloworld
---
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: hello
  namespace: helloworld
spec:
  template:
    metadata:
      labels:
        app: hello
      annotations:
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/simple-app:132e07c14c49
        env:
        - name: TARGET
          value: "World!"

Run kubectl apply -f helloworld.yaml to create the Service in the helloworld namespace.

Check the automatically generated domain

List the Service: kubectl -n helloworld get ksvc The output shows a URL such as http://hello.helloworld.example.com. Retrieve the Istio IngressGateway IP:

# Get Istio IngressGateway IP
kubectl get svc istio-ingressgateway -n istio-system -o jsonpath="{.status.loadBalancer.ingress[0].ip}"
# Example output: 47.95.191.136

Access the Service with curl by setting the Host header:

curl -H "Host: hello.helloworld.example.com" http://47.95.191.136/

Configure a custom master domain

Edit the ConfigMap config-domain in the knative-serving namespace and add your own domain, e.g. serverless.kuberun.com:

kubectl edit cm config-domain -n knative-serving

After saving, Knative will generate URLs like hello.helloworld.serverless.kuberun.com. Create a wildcard DNS record *.serverless.kuberun.com that points to the IngressGateway IP.

Expose a friendly custom service domain

To make the Service reachable via hello.kuberun.com, create an Istio VirtualService that rewrites the host header:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: hello-ingress-route
  namespace: knative-serving
spec:
  gateways:
  - knative-ingress-gateway
  hosts:
  - hello.helloworld.serverless.kuberun.com
  - hello.kuberun.com
  http:
  - match:
    - uri:
        prefix: "/"
    rewrite:
      authority: hello.helloworld.svc.cluster.local
    route:
    - destination:
        host: istio-ingressgateway.istio-system.svc.cluster.local
        port:
          number: 80
    timeout: 10m0s
    websocketUpgrade: true

Add an A record for hello.kuberun.com that points to the IngressGateway IP. After the VirtualService is applied, the Service is reachable at http://hello.kuberun.com/.

Path‑based routing to multiple services

Deploy a second Service (blog) in its own namespace:

---
apiVersion: v1
kind: Namespace
metadata:
  name: blog
---
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
  name: hello-blog
  namespace: blog
spec:
  template:
    metadata:
      labels:
        app: hello
      annotations:
        autoscaling.knative.dev/target: "10"
    spec:
      containers:
      - image: registry.cn-hangzhou.aliyuncs.com/knative-sample/simple-app:132e07c14c49
        env:
        - name: TARGET
          value: "Blog!"

Apply it with kubectl apply -f blog.yaml. The Service receives a URL like hello-blog.blog.serverless.kuberun.com.

Extend the same VirtualService to route /blog to the blog Service while keeping the root path for the hello Service:

# Add a new match block to hello-ingress-route.yaml
- match:
  - uri:
      prefix: "/blog"
  rewrite:
    authority: hello-blog.blog.svc.cluster.local
  route:
  - destination:
      host: istio-ingressgateway.istio-system.svc.cluster.local
      port:
        number: 80
  timeout: 10m0s
  websocketUpgrade: true

Now http://hello.kuberun.com/ serves the hello Service and http://hello.kuberun.com/blog forwards to the blog Service.

Summary

Knative’s default master domain is example.com, and each Service gets a sub‑domain of the form service.namespace.example.com.

Custom master domains are configured via the config-domain ConfigMap and require a wildcard DNS entry.

Individual service domains can be made user‑friendly by adding Istio VirtualService rules that rewrite the Host header.

Path‑based routing enables multiple services to share a single custom domain.