Introduction

To expose a service under a URL prefix with Kubernetes Ingress, you usually configure the Ingress path, not the Service itself. The Service still listens on its normal port, while the Ingress matches a path such as /api or /app and forwards matching traffic to that backend.

Use a Prefix Path in the Ingress Rule

The standard Ingress API supports prefix matching through pathType: Prefix. A basic example looks like this:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app-ingress
5spec:
6  ingressClassName: nginx
7  rules:
8    - host: example.com
9      http:
10        paths:
11          - path: /api
12            pathType: Prefix
13            backend:
14              service:
15                name: api-service
16                port:
17                  number: 8080

With this rule:

• '/api'
• '/api/'
• '/api/users'

all route to api-service.

This is the normal answer when the application already knows how to serve content under /api.

Understand What Prefix Matching Means

Prefix does not rewrite the request path. It only decides whether the request should match the rule. If the incoming request is /api/users, the backend usually receives /api/users unless your ingress controller applies an explicit rewrite rule.

That distinction matters a lot:

• If the backend expects /api/users, prefix routing alone is enough.
• If the backend expects /users, you also need a rewrite.

Rewriting the Prefix With NGINX Ingress

Path rewriting is controller-specific behavior, not generic Ingress behavior. With the NGINX Ingress Controller, a common pattern is:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: app-ingress
5  annotations:
6    nginx.ingress.kubernetes.io/rewrite-target: /$2
7spec:
8  ingressClassName: nginx
9  rules:
10    - host: example.com
11      http:
12        paths:
13          - path: /api(/|$)(.*)
14            pathType: ImplementationSpecific
15            backend:
16              service:
17                name: api-service
18                port:
19                  number: 8080

Now a request for /api/users is forwarded as /users to the backend.

This is useful when your application serves from root but you want to publish it under a prefixed external URL.

Prefix Routing for Multiple Services

Ingress prefix rules are especially useful when one hostname serves multiple backends:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: multi-service-ingress
5spec:
6  ingressClassName: nginx
7  rules:
8    - host: example.com
9      http:
10        paths:
11          - path: /api
12            pathType: Prefix
13            backend:
14              service:
15                name: api-service
16                port:
17                  number: 8080
18          - path: /web
19            pathType: Prefix
20            backend:
21              service:
22                name: web-service
23                port:
24                  number: 80

That is often easier to manage than giving every service its own hostname.

Service Configuration Does Not Hold the Prefix

A common misunderstanding is trying to put the prefix on the Service object. Kubernetes Services do not know about URL paths. They route TCP or UDP traffic to pods. HTTP path matching lives at the Ingress layer.

So the mental model is:

• Service handles network destination and port.
• Ingress handles hostnames, paths, and controller-specific rewrites.

Common Pitfalls

The biggest mistake is expecting pathType: Prefix to strip the prefix from the request. It only matches; it does not rewrite.

Another problem is mixing generic Ingress behavior with controller-specific annotations. A rewrite annotation that works with NGINX will not automatically work with every other ingress controller.

Developers also sometimes choose ImplementationSpecific when simple Prefix would be clearer. Use Prefix unless you actually need controller-specific regex behavior.

Finally, make sure the application itself is compatible with the published path. Some apps generate absolute links assuming they live at /, which breaks when they are exposed under /app without extra configuration.

Summary

• Put the URL prefix on the Ingress path, not on the Service.
• Use pathType: Prefix when you want /api to match /api/....
• Prefix matching does not rewrite the path sent to the backend.
• Use controller-specific rewrite annotations only when the backend expects the prefix removed.
• Keep the division clear: Services route traffic, Ingress objects handle HTTP path rules.