Skip to main content
This lesson walks through an existing NGINX Ingress controller and several deployed applications. You will inspect cluster resources, update an Ingress to change a route path, add new application routes, and create a namespace-scoped Ingress for a critical service. These steps illustrate common patterns for path-based routing and using the nginx.ingress.kubernetes.io/rewrite-target annotation to adapt backend expectations.

Environment overview

Start by checking cluster nodes and deployments to locate the Ingress controller and application workloads.
There are no deployments in the default namespace:
Show deployments across all namespaces to find the Ingress controller and app deployments:
(You may briefly see ingress-nginx-controller at 0/1 while it starts; it will transition to 1/1.) List pods across all namespaces to confirm which namespace hosts the controller and the application pods:
From the outputs:
  • The NGINX Ingress controller runs in the ingress-nginx namespace.
  • Application workloads are deployed in the app-space namespace.
Best practice: Keep Ingress resources in the same namespace as the application wherever possible so teams can manage access with namespace-scoped RBAC. This guide follows that approach for the new critical app.

Inspect the Ingress resource

List all Ingress resources to locate the one currently routing traffic for /wear and /watch:
Describe the ingress-wear-watch Ingress in app-space to see paths, backends, and annotations:
Key points:
  • The Ingress exposes /wear and /watch, routing respectively to wear-service:8080 and video-service:8080.
  • The annotation nginx.ingress.kubernetes.io/rewrite-target: / is present — this will rewrite matched prefixes to / before forwarding to the backend.
To summarize the current mapping, here is a quick reference:

Change /watch to /stream

Requirement: make the video application available at /stream instead of /watch. Edit the existing ingress-wear-watch to replace the /watch path with /stream. Ensure you use pathType: Prefix so that prefixes are matched and the existing rewrite remains functional. Example spec.rules excerpt after editing:
After saving the edit, verify the Ingress rules:
Test the routes (replace IP with your Ingress IP if different):
Both requests should return the respective application responses, with path prefixes rewritten to / by the annotation.

Add food delivery app at /eat

A new food delivery application (food-service) was migrated into app-space. Inspect services to confirm service names and ports:
Update the ingress-wear-watch Ingress to add /eat routing to food-service:8080. Example spec snippet after the change:
Apply the change (for example with kubectl edit or kubectl apply) and verify:
Now the food app is reachable at /eat. Verify with:

Expose a critical payment service in its own namespace

A critical payment application is deployed in critical-space and needs to be exposed at /pay. This demonstrates creating a namespace-scoped Ingress for a high-sensitivity app. Inspect the new deployment and service:
Note: Service ports can differ from container ports. pay-service exposes service port 8282; the pod may still serve on 8080. kubectl describe pod and kubectl describe svc will show the mappings. Create a namespace-scoped Ingress that maps /pay to pay-service:8282. A quick create command:
Describe the Ingress:
If you see 404 responses when curling /pay, check application logs:
Root cause:
  • The Ingress forwards requests including the /pay prefix. The payment application expects requests at root / (it has no /pay route), so the backend returns 404.
Solution:
  • Add the nginx.ingress.kubernetes.io/rewrite-target: / annotation to the ingress-pay metadata and ensure the path uses pathType: Prefix. This strips /pay before forwarding the request to the service, allowing the backend to receive /.
Example Ingress with the rewrite annotation:
Apply the change (kubectl edit or kubectl apply) and verify:
Test the endpoint and confirm logs show the backend receiving /:
After adding the rewrite annotation, the payment service should return 200 for /pay.

Summary & best practices

  • Always inspect namespaces, services, and ports (kubectl get svc -n <ns>) before editing Ingress resources.
  • Keep Ingress resources scoped to the application namespace when possible to simplify RBAC and team ownership.
  • Use nginx.ingress.kubernetes.io/rewrite-target: / to strip path prefixes if the backend expects root paths.
  • Use pathType: Prefix for prefix-based routing and combine it with rewrite-target to ensure clean backend paths.
  • For multi-namespace exposure, either create namespace-local Ingress resources or use a central gateway with appropriate RBAC and routing rules.
When exposing apps from multiple namespaces, prefer namespace-local Ingress resources (or a central gateway with appropriate RBAC). Always verify annotations and pathType settings so requests are routed and rewritten as intended.

Quick reference tables

Service list in app-space: Ingress path → backend mapping (final state):

Watch Video

Practice Lab