rewrite

[AdrienLemaire]

Hi, I've been struggling to set a rewrite rule for my ingress (GCP Kubernetes with a Deployment, Service NodePort and Ingress). What I'm trying to get is:

• api.example.com/ → backend/api/
• www.example.com/ → backend/www/

So that my server can server requests whether they start with /api/ or /www/, without a care about the subdomains.

I'm creating this issue because I have a question regarding your comment in https://github.com/kubernetes/ingress-gce#paths

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginxtest-ingress
spec:
  rules:
  - http:
      paths:
      - path: /hostname
        backend:
          serviceName: nginxtest
          servicePort: 80

Note what just happened, the endpoint exposes /hostname, and the loadbalancer forwarded the entire matching url to the endpoint. This means if you had '/foo' in the Ingress and tried accessing /hostname, your endpoint would've received /foo/hostname and not known how to route it.

I wish that was true... for me, loadbalancerip/foo would be the only queryable url, while everything else returns 404 Not Found errors. The Ingress only forward a request if it matches the path, that's it.

Anyways, if you have a suggestion regarding my problem, I'd really appreciate. Couldn't figure out how to get it working with annotations rewrite-url or app-root

[andybarron]

https://github.com/kubernetes/ingress-gce/blob/master/docs/annotations.md#url-related

Unfortunately, it seems that rewrite-target is not supported by the GCE ingress. This has been a pain point for me, too :/

[thecodejunkie]

No updates on this?

[nicksardo]

This is an upstream request to GCP load balancing: https://cloud.google.com/support/docs/issue-trackers
/close

[andybarron]

Are there any updates on this? I cannot find anything related to it in the issue tracker.

[bowei]

We most likely can't support this until the GCLB supports this. I would recommend looking at the open public issues and voting for rewriting for L7 load balancing:

https://issuetracker.google.com/savedsearches/559790

[andybarron]

Thank you for the quick response! Shame it's blocked though. Maybe time to wrestle with the Nginx ingress then.

[mkozjak]

Are there any updates for this feature? It's a basic ingress' feature and we'd like to have one.
Nobody responds on https://issuetracker.google.com/u/2/issues/72484862.

[bukzor]

The alpha API shows an alternative to "service" in "routeAction" which has a "urlRewrite" attribute.

https://developers.google.com/resources/api-libraries/documentation/compute/alpha/python/latest/compute_alpha.urlMaps.html#insert

        "urlRewrite": { # The spec for modifying the path before sending the request to the matched backend service. # The spec to modify the URL of the request, prior to forwarding the request to the matched service
          "hostRewrite": "A String", # Prior to forwarding the request to the selected service, the request's host header is replaced with contents of hostRewrite.
              # The value must be between 1 and 255 characters.
          "pathPrefixRewrite": "A String", # Prior to forwarding the request to the selected backend service, the matching portion of the request's path is replaced by pathPrefixRewrite.
              # The value must be between 1 and 1024 characters.
        },

So I guess it's coming? Someday?

[jgirdner]

Talk about limitations........

[diversario]

Wow, spent 4 hours debugging and turns out it's just not supported 🤣
FWIW, in the end didn't have to use rewrite, but moved to use nginx ingress anyway.

[thesayyn]

I can't believe that this is not supported.

[ramonvermeulen]

This should really be supported in GKE..

[drwxmrrs]

+1 Would love to see this supported

[sly01]

+1 I would like to see as well.

[ignacio83]

+1

[frank12001]

+1

[aeneasr]

This is such a basic feature, it literally makes ingress with path matching unusable in almost 99% of the use cases. It is so frustrating to see such basic issues being open for 1 1/2 years and apparently no one from Google side gives a single ... The experience with Google Cloud is as always (and so frustrating and annoying, it's like Microsoft under Ballmer): Yeah talk to this team. Oh we can't do anything, please talk to this team. Ah yeah please create an issue in this tracker. Oh yeah well we still don't care enough to fix it. Infuriating.

By the way, the annotation docs have disappeared too and maybe I'm blind but I tried to find a list of supported annotations by this Ingress for over an hour without luck.

ps: Thanks for letting me vent.

[ramonvermeulen]

Eventually ended up putting a nginx back-end in front of the back-end services I did need to target to do the HTTP -> HTTPS redirect, not ideal tho. I really hope Google will get this feature in place.

[loxy]

WTF. Ridiculous...

[thockin]

Hey folks, let's keep it professional, please.

I don't disagree that this seems like a great feature, but the simple fact is that it isn't available yet.

[charlie-lk]

I think the real fact is that it is a great and one of the most essential features which Google have opened tickets as long as one and half years for.

But - yes. Let's be professional. Don't be like GKE ingress.

[mariusz-jasinski]

Amazing Google, no simple features inside Ingress:

• no rewrite
• no redirect http to https
  :-(

[masus04]

Is there any alternative/workaround/progress on this?

[pkerschbaum]

Hey @masus04!

At a project I am working on, we migrated from one domain to a new domain. We wanted to redirect all users using the old domain to the new domain.

We successfully deployed a workaround for this scenario which goes like this: the GCP Ingress does not allow rewrites/redirects; however, it allows to "route requests to different backend services depending on the URL path" (see https://cloud.google.com/kubernetes-engine/docs/concepts/ingress#multiple_backend_services).
So we deployed an Nginx service+deployment which only purpose is to redirect all incoming requests. We defined that Nginx as "default backend", and only the new domain as additional backend.

See the following k8s resource definitions.
"my-domain.com" would be the domain the users should be redirected to.
Please note that I had to manually configure a health check for the nginx Service because otherwise, the health check would have got 301 responses from the nginx Deployment, and those are considered "unhealthy".

Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: main-ingress
spec:
  defaultBackend:
    service:
      name: nginx-redirect-service
      port:
        number: 80
  rules:
    - host: my-domain.com
      http:
        paths:
          - backend:
              service:
                name: my-domain-service
                port:
                  number: 80
            pathType: ImplementationSpecific

nginx Service:

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/backend-config: '{ "ports": { "80": "nginx-redirect-service-backendconfig" } }'
    cloud.google.com/neg: '{ "ingress": true }'
  name: nginx-redirect-service
spec:
  ports:
    - port: 80
      protocol: TCP
      targetPort: 80
  selector:
    app: nginx-redirect-deployment
  type: ClusterIP

nginx BackendConfig (to configure health check):

apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: nginx-redirect-service-backendconfig
spec:
  healthCheck:
    checkIntervalSec: 15
    port: 80
    requestPath: /nginx-redirect-health
    type: HTTP

nginx configuration (as ConfigMap):

apiVersion: v1
data:
  nginx.conf: |
    user nginx;
    worker_processes 1;
    events {
      worker_connections 10240;
    }
    http {
      server {
        listen 80 default_server;
        listen [::]:80 default_server;

        location / {
          return 301 https://my-domain.com$request_uri;
        }

        location = /nginx-redirect-health {
          return 200 'health OK';
          add_header Content-Type text/plain;
        }
      }
    }
kind: ConfigMap
metadata:
  name: nginx-redirect-configmap

nginx Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-redirect-deployment
  name: nginx-redirect-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-redirect-deployment
  template:
    metadata:
      labels:
        app: nginx-redirect-deployment
    spec:
      containers:
        - image: nginx
          name: nginx-redirect-deployment
          ports:
            - containerPort: 80
          volumeMounts:
            - mountPath: /etc/nginx/nginx.conf
              name: nginx-conf
              readOnly: true
              subPath: nginx.conf
      volumes:
        - configMap:
            items:
              - key: nginx.conf
                path: nginx.conf
            name: nginx-redirect-configmap
          name: nginx-conf

[masus04]

Thx @pkerschbaum I'll consider it 👍

[swetharepakula]

The Gateway API natively allows specifying rewrites. We will look into supporting this through the Gateway API.

[masus04]

The Gateway API natively allows specifying rewrites. We will look into supporting this through the Gateway API.

What API is this exactly and is there an issue we can follow the progress on?

[swetharepakula]

The Gateway API is a newer Kubernetes API meant to replace Ingress.

Please look to the GKE Gateway Docs for more information about the GKE implementation.

[softwareplumber]

shakes head it took four years to not implement this basic feature and we're expected to believe that the yet-more-complicated Gateway API will be fit for use?

[masus04]

Having switched from Ingress to Gateway primarily because of this issue I think the Gateway API is definitely an improvement and the separation of HttpRoutes simplify the setup.

However, while the URL rewrite is part of the API specification, it appears the GCP implementation of it does not yet support the rewrite functionality.

[pewpewp3w]

/reopen

[k8s-ci-robot]

@pewpewp3w: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[therealsamlin]

/reopen

[k8s-ci-robot]

@therealsamlin: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[grzegorzjudas]

@swetharepakula can you please re-open once again? The issue is (still, after 4.5 years) valid.

[jaroslawhartman]

It's a shame that such basic functionality is not supported. Please reopen‼️

[grzegorzjudas]

There is (seemingly) related item in Google's issue tracker that I think they use to prioritize stuff: https://issuetracker.google.com/issues/194125076. Please vote on it, may help getting this finally implemented.

[dryleaf]

Since 2018, this issue is still not fixed. Unbelievable!!!

[cyberhorsey]

Lol

[davidivkovic]

This is a joke!

[grzegorzjudas]

May help some of you, as I struggle(d) with this for a long time, too: I don't think Kubernetes/Google team is ever going to implement it, given it's been so long - and I agree this is a joke. But!

While it's not necessarily in a state (yet) that some consider production-ready, there already is a successor for the Ingress resource based routing, that is Gateway API:

• https://gateway-api.sigs.k8s.io/
• https://cloud.google.com/kubernetes-engine/docs/concepts/gateway-api

Given how Ingress implementations deviate based on providers and what amazing things Gateways can achieve, I have tried using Gateway-based approach in GKE and, probably because supporting rewrite is kind of necessary to implement it at all, it works. Have it a go!

[jgirdner]

Sitting here sipping coffee reading these comments after 5 years of getting notifications from this thread 😂

[grzegorzjudas]

Rather sad news, but it looks like as of now, rewrites are not supported even as part of Gateway API (https://gateway-api.sigs.k8s.io/guides/http-redirect-rewrite/#rewrites). Following:

- filters:
      - type: URLRewrite
        urlRewrite:
          path:
            type: ReplacePrefixMatch
            replacePrefixMatch: /

results in:

error: error validating "httproute.yaml": error validating data: ValidationError(HTTPRoute.spec.rules[1].filters[0]): unknown field "urlRewrite" in io.k8s.networking.gateway.v1beta1.HTTPRoute.spec.rules.filters; if you choose to ignore these errors, turn validation off with --validate=false

Available filters are basically ones listed here.

[swetharepakula]

Gateway API now support URL rewrites: https://cloud.google.com/kubernetes-engine/docs/how-to/deploying-gateways#configure_url_rewrites

[ezeamara]

@swetharepakula This doesn't work. Error: no matches for kind "HTTPRoute" in version "gateway.networking.k8s.io/v1beta1" (same error message with gateway.networking.k8s.io/v1). Any idea why? Have things changed or been moved around?

[swetharepakula]

@ezeamara Please follow https://cloud.google.com/kubernetes-engine/docs/how-to/deploying-gateways#enable-gateway to ensure that the Gateway CRDs are installed on your cluster.

[ezeamara]

@swetharepakula Thank you, that was helpful.