Skip to content
Kong Logo | Kong Docs Logo
search
  • We're Hiring!
  • Docs
    • Kong Gateway
    • Kong Konnect
    • Kong Mesh
    • Plugin Hub
    • decK
    • Kubernetes Ingress Controller
    • Insomnia
    • Kuma

    • Docs contribution guidelines
  • Plugin Hub
  • Support
  • Community
  • Kong Academy
Early Access
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Plugin Hub
  • decK
  • Kubernetes Ingress Controller
  • Insomnia
  • Kuma

  • Docs contribution guidelines
  • 2.8.x (latest)
  • 2.7.x
  • 2.6.x
  • 2.5.x
  • 2.4.x
  • 2.3.x
  • 2.2.x
  • 2.1.x
  • 2.0.x
  • 1.3.x
  • 1.2.x
  • 1.1.x
  • 1.0.x
    • FAQ
    • Version Support Policy
    • Stages of Software Availability
    • Changelog
    • Architecture
    • Custom Resources
    • Deployment Methods
    • Kong for Kubernetes with Kong Enterprise
    • High-Availability and Scaling
    • Resource Classes
    • Security
    • Ingress Resource API Versions
    • Gateway API
    • Kong Ingress on Minikube
    • Kong for Kubernetes
    • Kong for Kubernetes Enterprise
    • Kong for Kubernetes with Kong Enterprise
    • Kong Ingress on AKS
    • Kong Ingress on EKS
    • Kong Ingress on GKE
    • Admission Controller
    • Installing Gateway APIs
    • Getting Started with KIC
    • Upgrading from previous versions
    • Getting Started using Istio
      • Using the Kong(Cluster)Plugin Resource
      • Using the KongIngress Resource
      • Using KongConsumer and Credential Resources
      • Using the TCPIngress Resource
      • Using the UDPIngress Resource
    • Using the ACL and JWT Plugins
    • Using cert-manager with Kong
    • Configuring a Fallback Service
    • Using an External Service
    • Configuring HTTPS Redirects for Services
    • Using Redis for Rate Limiting
    • Integrate KIC with Prometheus/Grafana
    • Configuring Circuit-Breaker and Health-Checking
    • Setting up a Custom Plugin
    • Using Ingress with gRPC
    • Setting up Upstream mTLS
    • Exposing a TCP-based Service
    • Exposing a UDP-based Service
    • Using the mTLS Auth Plugin
    • Configuring Custom Entities
    • Using the OpenID Connect Plugin
    • Rewriting Hosts and Paths
    • Preserving Client IP Address
    • Using Gateway API
    • Using Kong with Knative
    • KIC Annotations
    • CLI Arguments
    • Custom Resource Definitions
    • Plugin Compatibility
    • Version Compatibility
    • Troubleshooting
    • Prometheus Metrics
    • Feature Gates
    • Gateway API Support

github-edit-pageEdit this page

report-issueReport an issue

enterprise-switcher-iconSwitch to OSS

On this page
  • Installation
  • Testing Connectivity to Kong
  • Create a test Deployment
  • Create a Kubernetes service
  • Create an Ingress to expose the service at the path /myapp on example.com
  • Rewriting the host
  • Rewriting the path
Kubernetes Ingress Controller
2.5.x
  • Home
  • Kubernetes Ingress Controller
  • Guides
  • Rewriting hosts and paths
You are browsing documentation for an outdated version. See the latest documentation here.

Rewriting hosts and paths

This guide demonstrates host and path rewrites using Ingress and Service configuration.

Installation

Please follow the deployment documentation to install the Kubernetes Ingress Controller on your Kubernetes cluster.

Testing Connectivity to Kong

This guide assumes that the PROXY_IP environment variable is set to contain the IP address or URL pointing to Kong. Please follow one of the deployment guides to configure this environment variable.

If everything is setup correctly, making a request to Kong should return HTTP 404 Not Found.

$ curl -i $PROXY_IP
HTTP/1.1 404 Not Found
Content-Type: application/json; charset=utf-8
Connection: keep-alive
Content-Length: 48
Server: kong/1.2.1

{"message":"no Route matched with those values"}

This is expected as Kong does not yet know how to proxy the request.

Create a test Deployment

To test our requests, we create an echo server Deployment, which responds to HTTP requests with a summary of the request contents:

$ kubectl create namespace echo
namespace/echo created
$ kubectl apply -n echo -f https://bit.ly/echo-service
service/echo created
deployment.apps/echo created

After completing the examples in the guide, you can clean up the example configuration with kubectl delete namespace echo.

For your actual production configuration, replace echo with whatever namespace you use to run your application.

Create a Kubernetes service

First, create a Kubernetes Service:

echo "
apiVersion: v1
kind: Service
metadata:
  name: echo
  namespace: echo
spec:
  selector:
    app: echo
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80
" | kubectl apply -f -

When referenced by an Ingress, this Service will create a Kong service and upstream that uses the upstream IPs (Pod IPs) for its Host header and appends request paths starting at /.

Create an Ingress to expose the service at the path /myapp on example.com

echo '
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  namespace: echo
spec:
  ingressClassName: kong
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /myapp
        pathType: ImplementationSpecific
        backend:
          service:
            name: echo
            port:
              number: 80
' | kubectl create -f -

This Ingress will create a Kong route attached to the service we created above. It will preserve its path but honor the service’s hostname, so this request:

$ curl -svX GET http://myapp.example.com/myapp/foo --resolve myapp.example.com:80:$PROXY_IP
GET /myapp/foo HTTP/1.1
Host: myapp.example.com
User-Agent: curl/7.70.0
Accept: */*

will appear upstream as:

GET /myapp/foo HTTP/1.1
Host: 10.16.4.8
User-Agent: curl/7.70.0
Accept: */*

We’ll use this same cURL command in other examples as well.

Actual output from cURL and the echo server will be more verbose. These examples are condensed to focus primarily on the path and Host header.

Note that this default behavior uses strip_path=false on the route. This differs from Kong’s standard default to conform with expected ingress controller behavior.

Rewriting the host

There are two options to override the default Host header behavior:

  • Add the konghq.com/host-header annotation to your Service, which sets the Host header directly:
    $ kubectl patch -n echo service echo -p '{"metadata":{"annotations":{"konghq.com/host-header":"internal.myapp.example.com"}}}'
    

    The request upstream will now use the header from that annotation:

    GET /myapp/foo HTTP/1.1
    Host: internal.myapp.example.com
    User-Agent: curl/7.70.0
    Accept: */*
    
  • Add the konghq.com/preserve-host annotation to your Ingress, which sends the route/Ingress hostname:
    $ kubectl patch -n echo ingress my-app -p '{"metadata":{"annotations":{"konghq.com/preserve-host":"true"}}}'
    

    The request upstream will now include the hostname from the Ingress rule:

    GET /myapp/foo HTTP/1.1
    Host: myapp.example.com
    User-Agent: curl/7.70.0
    Accept: */*
    

The preserve-host annotation takes precedence, so if you add both annotations above, the upstream host header will be myapp.example.com.

Rewriting the path

There are two options to rewrite the default path handling behavior:

  • Add the konghq.com/strip-path annotation to your Ingress, which strips the path component of the route/Ingress, leaving the remainder of the path at the root:
    $ kubectl patch -n echo ingress my-app -p '{"metadata":{"annotations":{"konghq.com/strip-path":"true"}}}'
    

    The request upstream will now only contain the path components not in the Ingress rule:

    GET /foo HTTP/1.1
    Host: 10.16.4.8
    User-Agent: curl/7.70.0
    Accept: */*
    
  • Add the konghq.com/path annotation to your Service, which prepends that value to the upstream path:
    $ kubectl patch -n echo service echo -p '{"metadata":{"annotations":{"konghq.com/path":"/api"}}}'
    

    The request upstream will now contain a leading /api:

    GET /api/myapp/foo HTTP/1.1
    Host: 10.16.4.8
    User-Agent: curl/7.70.0
    Accept: */*
    

    strip-path and path can be combined together, with the path component coming first. Adding both annotations above will send requests for /api/foo.

Thank you for your feedback.
Was this page useful?
  • Kong
    THE CLOUD CONNECTIVITY COMPANY

    Kong powers reliable digital connections across APIs, hybrid and multi-cloud environments.

    • Company
    • Customers
    • Events
    • Investors
    • Careers Hiring!
    • Partners
    • Press
    • Contact
  • Products
    • Kong Konnect
    • Kong Gateway
    • Kong Mesh
    • Get Started
    • Pricing
  • Resources
    • eBooks
    • Webinars
    • Briefs
    • Blog
    • API Gateway
    • Microservices
  • Open Source
    • Install Kong Gateway
    • Kong Community
    • Kubernetes Ingress
    • Kuma
    • Insomnia
  • Solutions
    • Decentralize
    • Secure & Govern
    • Create a Dev Platform
    • API Gateway
    • Kubernetes
    • Service Mesh
Star
  • Terms•Privacy
© Kong Inc. 2023