Ingress, Gateway API, and Edge Routing
Ingress, IngressClass, Ingress Controller, NGINX Ingress, cloud ingress controller, Gateway API, GatewayClass, Gateway, HTTPRoute, TLS termination, host/path routing, rewrite, backend protocol, sticky session, canary routing, API Gateway vs Ingress, and production review checklist.
Ingress, Gateway API, and Edge Routing
1. Core Mental Model
Ingress and Gateway are Kubernetes edge-routing abstractions.
They decide how traffic enters the cluster and reaches internal Services.
A typical request path:
Client
-> DNS
-> public or private load balancer
-> ingress controller or gateway controller
-> Kubernetes Service
-> EndpointSlice
-> Pod
-> Java/JAX-RS endpoint
The important distinction:
Ingress/Gateway object = routing intent
Ingress/Gateway controller = actual running dataplane that implements routing
A YAML object alone does not route traffic.
There must be a controller watching the object and configuring a proxy/load balancer.
Examples of controllers/dataplanes:
NGINX Ingress Controller
AWS Load Balancer Controller
Azure Application Gateway Ingress Controller
HAProxy Ingress
Traefik
Envoy-based Gateway implementations
Service mesh gateways
Cloud-native gateway controllers
For Java/JAX-RS services, edge routing is where external HTTP behavior meets internal application behavior:
Host routing
Path routing
TLS termination
Header forwarding
Timeouts
Body size limits
Authentication integration
Rate limiting
Canary routing
Backend protocol expectations
A senior backend engineer must understand this layer because many "application outages" are actually edge-routing failures.
2. Why Edge Routing Exists
Kubernetes Services expose stable internal endpoints, but production systems need controlled entry points.
You usually do not want every backend service directly exposed through a public load balancer.
Edge routing exists to centralize:
External traffic entry
TLS termination
Host-based routing
Path-based routing
Shared load balancer usage
HTTP policy enforcement
Header normalization
Timeout policy
WAF/API gateway integration
Canary or progressive routing
Operational visibility
Without edge routing, every service exposure becomes separate infrastructure:
Service A -> its own load balancer
Service B -> its own load balancer
Service C -> its own load balancer
Different TLS setup
Different DNS setup
Different timeout setup
Different logs
Different security rules
That becomes expensive, inconsistent, and difficult to secure.
A clean platform pattern is:
Shared or governed edge entry
-> controlled routing rules
-> internal Services
-> application pods
3. Ingress Concept
Ingress is a Kubernetes API object for HTTP/HTTPS routing.
A simple Ingress:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: quote-service
namespace: quote
spec:
ingressClassName: nginx
rules:
- host: quote.example.internal
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: quote-service
port:
name: http
tls:
- hosts:
- quote.example.internal
secretName: quote-service-tls
This says:
For host quote.example.internal
For path prefix /
Send traffic to Service quote-service on port named http
Use TLS certificate from secret quote-service-tls
But this object needs an ingress controller.
Without a matching controller:
Ingress object exists
No real routing happens
No external endpoint may be created
Always verify the controller and IngressClass.
4. IngressClass
IngressClass selects which controller should process an Ingress.
Example:
spec:
ingressClassName: nginx
Possible classes:
nginx
alb
agic
internal-nginx
public-nginx
private-gateway
The exact names are platform-specific.
Do not guess them.
Common failure:
Ingress created with wrong ingressClassName.
Controller ignores it.
No route is configured.
Another failure:
ingressClassName omitted.
Cluster has no default IngressClass.
Ingress is ignored.
Internal verification checklist must confirm:
Which IngressClass is standard?
Which is public?
Which is private/internal?
Which controller owns each class?
Are annotations allowed or restricted?
How are TLS certificates provisioned?
5. Ingress Controller
An ingress controller is the component that watches Ingress resources and configures a proxy or load balancer.
The controller has two jobs:
Watch Kubernetes API for routing objects
Program the dataplane to implement those routes
The dataplane may be:
NGINX pods inside the cluster
Envoy pods inside the cluster
Cloud ALB/Application Gateway outside or adjacent to the cluster
Provider-managed load balancer resources
Controller failure modes:
Controller not running
Controller cannot watch namespace
Controller rejects invalid annotation
Controller lacks cloud IAM/RBAC permission
Controller cannot update load balancer
Controller config reload fails
Controller routes to wrong backend
When debugging Ingress, inspect both:
Ingress object status/events
Ingress controller logs/events
Do not stop at the application pod.
6. NGINX Ingress Awareness
NGINX Ingress is a common implementation for HTTP routing.
It usually runs as pods inside the cluster and receives traffic from a LoadBalancer or NodePort.
Typical path:
Client
-> DNS
-> cloud/on-prem load balancer
-> NGINX Ingress Controller pod
-> Service backend
-> Java pod
NGINX-related concerns:
Path matching
Rewrite rules
Backend protocol
TLS termination
Request body size
Read timeout
Send timeout
Proxy buffer size
Header forwarding
WebSocket upgrade if needed
Canary annotations if supported
Common NGINX symptoms:
404
Route not matched or wrong host/path.
502
Backend connection failed or protocol mismatch.
503
Service has no ready endpoints or upstream unavailable.
504
Backend timed out.
For Java/JAX-RS services, NGINX timeouts must align with application timeouts.
Bad timeout chain:
NGINX proxy-read-timeout: 60s
Java request timeout: 120s
Client timeout: 10s
Database query timeout: 90s
This creates wasted work and confusing errors.
7. Cloud Ingress Controllers
Cloud environments may provide controllers that map Kubernetes objects to cloud load balancer resources.
Examples:
AWS Load Balancer Controller
Azure Application Gateway Ingress Controller
Provider-specific Gateway controllers
These controllers connect Kubernetes routing intent to cloud infrastructure.
They may manage:
ALB/NLB or Application Gateway
Listeners
Target groups/backend pools
Health checks
Security groups/NSGs
Certificates
Public/private frontend IPs
DNS integration indirectly
WAF integration where configured
This means an Ingress PR can create or modify cloud resources.
Review implications:
Cost
Public exposure
TLS certificate
Security group/NSG access
Health check path
Target type
Cross-zone traffic
Cloud IAM permissions
Controller annotations
Do not treat cloud ingress annotations as harmless metadata.
They may change production infrastructure.
8. Gateway API Mental Model
Gateway API is a newer, more expressive Kubernetes networking API family for routing.
It separates platform ownership from application routing more clearly.
Core objects:
GatewayClass
Defines a class of gateways handled by a controller.
Gateway
Represents an actual listener entry point such as HTTP/HTTPS on specific ports.
HTTPRoute
Defines HTTP routing rules from host/path/header/method to backend Services.
ReferenceGrant
Allows cross-namespace references where needed.
Mental model:
Platform team owns GatewayClass and often Gateway.
Application team owns HTTPRoute.
Gateway controller implements actual routing.
Example:
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: quote-service
namespace: quote
spec:
parentRefs:
- name: internal-gateway
namespace: platform-ingress
hostnames:
- quote.example.internal
rules:
- matches:
- path:
type: PathPrefix
value: /
backendRefs:
- name: quote-service
port: 8080
Gateway API can provide better structure for enterprise environments because it supports clearer delegation and richer routing models.
But actual behavior still depends on the installed controller implementation.
9. Ingress vs Gateway API
A simplified comparison:
Ingress
Older and widely supported.
Simpler object model.
Often extended heavily with annotations.
Controller behavior varies significantly.
Gateway API
More expressive.
Better role separation.
More structured routing objects.
Designed to reduce annotation sprawl.
Adoption depends on platform support.
Do not assume Gateway API is available just because Kubernetes supports the API type.
You need:
CRDs installed where required
Gateway controller installed
GatewayClass configured
Gateway provisioned
Route attachment allowed
Platform policy documented
For CSG/team usage, verify the actual standard.
Do not migrate from Ingress to Gateway API without platform alignment.
10. Host Routing
Host routing uses the HTTP Host header or TLS SNI to route requests.
Example:
quote.example.internal -> quote-service
order.example.internal -> order-service
catalog.example.internal -> catalog-service
Ingress example:
rules:
- host: quote.example.internal
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: quote-service
port:
name: http
Host routing concerns:
DNS record must point to the correct load balancer.
TLS certificate must include the hostname.
Ingress rule must match the host exactly or through approved wildcard.
Application must understand forwarded host if generating absolute URLs.
Common failure:
curl works with load balancer IP but browser gets 404.
Cause may be missing Host header.
Debug with:
curl -v -H 'Host: quote.example.internal' https://<load-balancer-address>/
11. Path Routing
Path routing sends different URL paths to different Services.
Example:
/api/quote -> quote-service
/api/order -> order-service
/api/catalog -> catalog-service
Ingress path types:
Exact
Must match exactly.
Prefix
Matches URL path prefix.
ImplementationSpecific
Controller-specific behavior; avoid unless required and documented.
Path routing risks:
Overlapping paths
Unexpected prefix match
Trailing slash behavior
Rewrite confusion
Controller-specific regex behavior
Route shadowing
For Java/JAX-RS services, path routing must align with application context path.
Example:
Ingress path: /quote
JAX-RS app path: /api/v1/quotes
Rewrite: enabled or not?
If rewrite is wrong, the app may receive:
/quote/api/v1/quotes
instead of:
/api/v1/quotes
or the opposite.
Path design is application architecture, not just platform config.
12. Rewrite Rules
Rewrite changes the request path before sending it to the backend.
Example intent:
External path: /quote/api/v1/items
Backend path: /api/v1/items
Rewrite is powerful but dangerous.
Risks:
Application logs show rewritten path, not original path.
OpenAPI docs mismatch external path.
Redirect Location headers become wrong.
Security rules are applied to one path while app sees another.
JAX-RS resource matching fails.
Canary route matches unexpected path.
Before using rewrite, ask:
Can the app serve the desired external base path directly?
Is there an API gateway standard for base path mapping?
Are OpenAPI docs generated with external or internal paths?
Are redirects used?
Does auth middleware depend on path?
Prefer simple path models.
Use rewrite only when there is a clear reason and a test proving behavior.
13. Backend Protocol
Ingress/Gateway must know how to speak to the backend.
Common backend protocols:
HTTP
HTTPS
HTTP/2
gRPC
WebSocket over HTTP upgrade
A Java/JAX-RS service usually exposes HTTP, sometimes HTTPS internally depending on platform standard.
Common protocol mismatch:
Ingress sends HTTP to backend port expecting HTTPS.
Result: 502 or connection reset.
Opposite mismatch:
Ingress sends HTTPS to backend port expecting HTTP.
Result: TLS handshake error.
Review:
Does backend Service port expose HTTP or HTTPS?
Where is TLS terminated?
Does app require client certificate?
Does ingress controller support HTTP/2/gRPC if needed?
Are health checks using the correct protocol?
For most REST APIs:
TLS at edge
HTTP inside cluster
may be acceptable in some platforms, while other environments require:
TLS/mTLS service-to-service
Verify internal policy.
14. TLS Termination Points
TLS can terminate at different layers:
External load balancer
Ingress controller
Gateway proxy
Service mesh sidecar/gateway
Application pod
Each option changes responsibility.
TLS at Load Balancer
Client -> HTTPS -> LB
LB -> HTTP or HTTPS -> ingress/controller/backend
Pros:
Cloud-native certificate management
Centralized edge TLS
Potential WAF integration
Cons:
Internal traffic may be plaintext unless re-encrypted
Forwarded headers must be correct
TLS at Ingress/Gateway
Client -> HTTPS -> ingress/gateway
Ingress/gateway -> HTTP/HTTPS -> Service
Pros:
Kubernetes-managed routing and certificates
Common ingress pattern
Cons:
Certificate secret lifecycle matters
Controller must reload correctly
TLS at Application Pod
Client/ingress -> HTTPS -> Java pod
Pros:
End-to-end encryption to app
Cons:
Certificate management per app
More complex probes
More complex rotation
JVM TLS config burden
Review exactly where TLS terminates.
Do not assume.
15. X-Forwarded Headers and Source IP
When traffic passes through proxies, the backend sees proxy information unless headers preserve original context.
Common headers:
X-Forwarded-For
X-Forwarded-Proto
X-Forwarded-Host
X-Real-IP
Forwarded
Java/JAX-RS services may use these for:
Audit logs
Absolute URL generation
Redirects
Security decisions
Rate limiting
Tenant routing
Request tracing
Be careful.
Forwarded headers can be spoofed if edge proxy does not sanitize them.
Correct model:
Edge proxy accepts client request
Edge proxy removes untrusted forwarded headers or normalizes them
Edge proxy appends trusted forwarded values
Application trusts headers only from known proxy path
Do not use X-Forwarded-For naively for security decisions without platform guidance.
Source IP preservation also varies by load balancer and controller configuration.
Verify actual behavior in EKS/AKS/on-prem.
16. Sticky Sessions
Sticky session routes the same client to the same backend.
Possible mechanisms:
Cookie-based affinity
Client IP affinity
Load balancer target stickiness
Ingress annotation-specific stickiness
Use carefully.
Sticky sessions may hide poor application design.
Bad reasons for sticky sessions:
Session stored in pod memory
Workflow state stored in local cache
Non-distributed authentication state
Local temporary file dependency
Better design:
Stateless REST API
External session store if required
Distributed cache for shared state
Idempotent API operations
Database/workflow engine as system of record
Operational risks of sticky sessions:
Uneven load
Hot pods
Longer drain during rollout
Client sticks to degraded pod
Reduced canary accuracy
If sticky session is required, document why and test rollout behavior.
17. Canary Routing
Canary routing sends a small portion of traffic to a new version.
Example:
95% -> quote-service stable
5% -> quote-service canary
Canary can be implemented through:
Ingress controller annotations
Gateway API weighted backendRefs where supported
Service mesh
Argo Rollouts
Flagger
Cloud load balancer rules
API gateway routing
Canary review questions:
What traffic percentage goes to canary?
Can traffic be routed by header, cookie, tenant, or path?
What metrics decide success/failure?
How fast can rollback happen?
Does canary version share database/schema safely?
Are events/messages backward compatible?
Does the canary receive representative traffic?
Canary is not just routing.
It requires observability and compatibility.
For Java/JAX-RS services, canary must consider:
API compatibility
DTO/schema compatibility
Database migration compatibility
Kafka/RabbitMQ event compatibility
Cache key compatibility
Idempotency
Feature flags
18. API Gateway vs Ingress
Ingress is usually infrastructure-level HTTP routing.
API Gateway usually adds API management capabilities.
Typical API Gateway features:
Authentication integration
Authorization policy
Rate limiting
Quota
API key management
Request/response transformation
Developer portal
API version management
WAF integration
Monetization or partner onboarding in some domains
Detailed API analytics
Ingress/Gateway may provide some of these, but not always.
Decision model:
Need basic host/path routing to internal service?
Ingress/Gateway may be enough.
Need external API product management, auth, quota, partner traffic, or API policy?
API Gateway may be required.
Need service-to-service routing inside platform?
Kubernetes Service, service mesh, or internal Gateway may apply.
For enterprise quote/order systems, external API exposure should usually be governed.
Do not expose a business API simply by adding an Ingress unless platform/API governance approves it.
19. Edge Routing and Service Relationship
Ingress/Gateway routes to Kubernetes Services.
Therefore, edge routing depends on Service correctness.
A request path:
Host/path matched by Ingress
Backend Service selected
Service port resolved
EndpointSlice selected
Pod IP chosen
Container port reached
Java server handles request
If any link breaks, symptoms may surface at the edge.
Examples:
Ingress 503
Could mean Service has no endpoints.
Ingress 502
Could mean wrong backend protocol or targetPort.
Ingress 404
Could mean host/path rule mismatch.
Ingress 504
Could mean Java app or downstream dependency timed out.
Do not debug all edge failures as ingress-only failures.
Trace downward.
20. Java/JAX-RS Backend Implications
20.1 Context Path Alignment
JAX-RS apps may have base paths like:
/api
/api/v1
/quote/api
Ingress path and rewrite rules must align with this.
Check:
External route path
Rewrite rule
Servlet/application context path
JAX-RS ApplicationPath
Resource method path
OpenAPI published path
20.2 Absolute URL Generation
Some apps generate absolute URLs in:
Location headers
redirect responses
OpenAPI server URLs
email callbacks
hypermedia links
If the app sees internal host/proto instead of external host/proto, it may generate wrong URLs.
Forwarded header configuration matters.
20.3 Request Size and Timeout
Quote/order APIs may carry large payloads or long-running operations.
Ingress may reject or timeout requests before Java sees them.
Review:
max body size
proxy read timeout
proxy send timeout
client body timeout
Java server request timeout
JAX-RS async timeout
database timeout
downstream timeout
20.4 Error Mapping
Ingress errors and application errors should be distinguishable.
Examples:
404 from ingress route mismatch
404 from JAX-RS resource not found
503 from no backend endpoints
503 from application maintenance mode
504 from proxy timeout
504 from upstream gateway timeout
Logs and headers should make this debuggable.
20.5 Health and Management Endpoints
Do not accidentally expose management endpoints externally.
Review:
/health
/metrics
/admin
/actuator
/debug
/openapi
/swagger
Some endpoints may be safe internally but not externally.
21. PostgreSQL, Kafka, RabbitMQ, Redis, Camunda, and NGINX Implications
PostgreSQL
Ingress is not normally used for PostgreSQL traffic.
Database access should usually be internal/private, not HTTP ingress.
If any TCP ingress/gateway is used, it requires explicit platform review.
Kafka
Kafka is not ordinary HTTP routing.
Do not assume Ingress can expose Kafka correctly.
Kafka exposure requires advertised listener design, TLS/SASL, broker identity, and sometimes specific load balancer patterns.
RabbitMQ
RabbitMQ has different surfaces:
AMQP protocol
Management UI over HTTP
Prometheus metrics endpoint
Ingress may be suitable for management UI only if approved and protected.
AMQP exposure needs protocol-aware design.
Redis
Redis should not be exposed through HTTP Ingress.
External exposure of Redis is usually a security smell unless specifically designed and private.
Camunda-like Workloads
Camunda-style systems may expose:
REST API
Web UI
Worker endpoints
Metrics
Each route may need different auth and exposure policy.
Do not put all endpoints behind one broad public route.
NGINX
NGINX may be:
Ingress controller
Sidecar reverse proxy
Standalone edge proxy
API gateway component in some architecture
Clarify which role NGINX plays before debugging.
22. EKS, AKS, On-Prem, and Hybrid Considerations
EKS
EKS edge routing may involve:
AWS Load Balancer Controller
ALB Ingress
NLB Service
NGINX behind NLB
Route 53
ACM certificates
Security groups
Target groups
WAF
Private/public subnets
Questions:
Is traffic going through ALB directly to pods or to nodes?
Is target type instance or IP?
Is the load balancer internal or internet-facing?
Which security group allows traffic?
Where does TLS terminate?
Which certificate is used?
AKS
AKS edge routing may involve:
Azure Load Balancer
Application Gateway
AGIC
Azure Front Door
Azure DNS
Managed certificates or Key Vault integration
NSG
UDR
Private endpoint
Questions:
Is Application Gateway used?
Is AGIC managing routes?
Is traffic public or private?
Where is TLS terminated?
Which NSG/UDR controls traffic?
Is Azure Front Door before the cluster?
On-Prem
On-prem edge routing may involve:
Hardware load balancer
F5/HAProxy/NGINX appliance
MetalLB
Static VIP
Internal DNS
Enterprise certificate authority
Corporate proxy/firewall
Do not assume cloud-style automatic provisioning.
Hybrid
Hybrid traffic flow may cross:
Corporate DNS
Firewall
Proxy
VPN
Direct Connect
ExpressRoute
Cloud LB
Ingress controller
Cluster Service
Each layer can alter headers, TLS, source IP, or timeout behavior.
Hybrid edge issues often require platform/network team collaboration.
23. Common Failure Modes
23.1 Ingress 404
Likely causes:
Host rule mismatch
Path rule mismatch
Wrong IngressClass
Controller did not load route
Default backend response
Rewrite mismatch causing app-level 404
Debug:
kubectl describe ingress -n quote quote-service
curl -v -H 'Host: quote.example.internal' https://<edge>/expected/path
Distinguish:
Ingress 404 vs application 404
23.2 Ingress 502
Likely causes:
Backend protocol mismatch
Service targetPort wrong
Pod not listening
Connection refused
TLS handshake failure to backend
Ingress controller cannot connect to Service endpoint
Debug:
kubectl get svc -n quote quote-service -o yaml
kubectl get endpointslice -n quote -l kubernetes.io/service-name=quote-service
kubectl logs -n <ingress-namespace> <ingress-controller-pod>
23.3 Ingress 503
Likely causes:
Service has no ready endpoints
Pods not ready
Readiness probe failing
Deployment scaled to zero
NetworkPolicy blocks controller to backend
Debug Service layer before changing ingress rules.
23.4 Ingress 504
Likely causes:
Backend response exceeds proxy timeout
Java thread pool saturated
Database query slow
Downstream service timeout
Connection leak
Retry storm
Debug app latency and downstream dependency metrics.
23.5 TLS Certificate Error
Likely causes:
Certificate missing hostname
Secret not found
Wrong certificate attached
Expired certificate
Intermediate chain issue
Client trust store issue
TLS terminated at unexpected layer
Debug:
kubectl get secret -n quote quote-service-tls
openssl s_client -connect quote.example.internal:443 -servername quote.example.internal
Use production-safe commands and follow team policy.
23.6 Route Works Internally But Not Externally
Likely causes:
Service is healthy
Ingress rule wrong
DNS record wrong
LB listener missing
Firewall/security group/NSG blocked
TLS/SNI mismatch
WAF/API gateway blocking
Trace from outside inward.
23.7 Route Works Externally But App Gets Wrong URL Scheme
Likely causes:
X-Forwarded-Proto missing or not trusted
App unaware of reverse proxy
TLS terminates before app
Redirect logic uses internal HTTP
Fix requires both ingress and app framework configuration.
24. Debugging Workflow
Debug edge routing as a chain.
Step 1: Confirm DNS
nslookup quote.example.internal
Check whether DNS points to the expected load balancer/front door.
Step 2: Confirm TLS and Host
curl -vk https://quote.example.internal/health
Check:
certificate hostname
TLS version
HTTP status
response headers
Step 3: Confirm Ingress/Gateway Object
kubectl get ingress -n quote
kubectl describe ingress -n quote quote-service
or Gateway API:
kubectl get httproute -n quote
kubectl describe httproute -n quote quote-service
Check:
class
hostnames
paths
backend Service
backend port
status conditions
events
Step 4: Confirm Controller
kubectl get pods -n <ingress-namespace>
kubectl logs -n <ingress-namespace> <controller-pod>
Check whether the controller accepted or rejected the route.
Step 5: Confirm Service Backend
kubectl get svc -n quote quote-service -o yaml
kubectl get endpointslice -n quote -l kubernetes.io/service-name=quote-service -o wide
No endpoints means the edge cannot route successfully.
Step 6: Test Backend Internally
From a debug pod:
curl -v http://quote-service.quote.svc.cluster.local:8080/health/ready
If internal Service fails, fix Service/pod first.
Step 7: Inspect App Logs and Metrics
Check:
JAX-RS request logs
HTTP access logs
Thread pool saturation
GC pause
Downstream latency
Error rate
Trace spans
Step 8: Check Network and Policy
Inspect:
NetworkPolicy
Security group / NSG
Firewall
WAF
Proxy
Private endpoint routing
Step 9: Check Timeout Chain
Compare:
client timeout
dns/lb timeout
ingress timeout
service mesh timeout
Java server timeout
JAX-RS async timeout
database/downstream timeout
Timeout mismatch often appears as edge 504.
25. Observability Concerns
Edge observability should include:
Request count by host/path/status
Ingress/Gateway 4xx and 5xx
Backend Service error rate
Latency percentiles
Upstream connection errors
TLS handshake errors
Route config reload errors
Controller reconciliation errors
Certificate expiry
Request body rejection
WAF/API gateway blocks if applicable
For Java/JAX-RS correlation:
Ingress request ID
Application correlation ID
Trace ID
X-Forwarded headers
Access log status
JAX-RS resource latency
Downstream call latency
A good dashboard lets you distinguish:
Edge rejected request
Route not matched
Backend unavailable
Application returned error
Dependency timeout
Client disconnected
Without this separation, teams waste time arguing whether the problem is ingress or app.
26. Security and Privacy Concerns
Edge routing is part of the security boundary.
Review:
Is the route public or private?
Is TLS required?
Where does TLS terminate?
Is HTTP redirected to HTTPS?
Are sensitive endpoints exposed?
Is authentication enforced at gateway/app?
Are forwarded headers sanitized?
Is request body size limited?
Is WAF/API gateway required?
Are internal-only APIs accidentally public?
Are management endpoints exposed?
Are PII values logged at ingress?
Do not rely on obscurity of URL paths.
Sensitive APIs need explicit access control.
Also verify logs.
Ingress logs may capture:
query strings
path parameters
headers
client IP
user agent
request IDs
If these contain PII, token values, or customer identifiers, logging policy matters.
27. Performance Concerns
Edge routing affects latency and throughput.
Key variables:
TLS termination cost
proxy buffering
request body size
connection reuse
HTTP keep-alive
HTTP/2 support
timeout settings
load balancer cross-zone routing
ingress controller CPU/memory
backend pod readiness
upstream connection pool
For large Java APIs:
Long request bodies may hit ingress limits.
Slow streaming may hit proxy timeouts.
Large response bodies may require buffer tuning.
Synchronous downstream calls may cause 504.
Retry storms may amplify ingress load.
Performance review should inspect both sides:
Edge proxy metrics
Application metrics
Downstream dependency metrics
Client timeout/retry behavior
28. Cost Concerns
Ingress and Gateway design affects cloud cost.
Cost drivers:
Number of load balancers
Public vs private load balancer
Cross-zone data transfer
NAT gateway traffic
WAF/API gateway charges
Log volume
Metrics volume
TLS/certificate infrastructure
Dedicated ingress controller replicas
Overprovisioned ingress pods
Cost-aware design:
Use shared governed edge where appropriate.
Avoid one public LB per microservice unless justified.
Route multiple services through common gateway where safe.
Control access logs volume.
Set right-sized ingress controller resources.
Understand cross-zone traffic implications.
A route change can have cost impact even if application code does not change.
29. Correctness Concerns
Edge correctness means the right request reaches the right backend with the right semantics.
Invariants:
DNS points to correct edge.
TLS certificate matches hostname.
Host/path rule matches intended API only.
Rewrite preserves application contract.
Backend protocol matches service listener.
Service port points to correct targetPort.
Forwarded headers are trustworthy.
Timeouts preserve intended failure behavior.
Canary routing does not mix incompatible versions.
Sensitive endpoints are not exposed.
Dangerous correctness failure:
/api/quote and /api/quotes overlap.
A broader Prefix route shadows a more specific route.
Traffic reaches the wrong service.
Failures appear random by path.
Another dangerous failure:
Canary and stable versions share route but not database/event compatibility.
A small canary causes persistent data corruption.
Edge routing must be reviewed with application compatibility.
30. PR Review Checklist
When reviewing Ingress/Gateway changes, ask:
Is this route public or private?
Is the hostname correct?
Does DNS exist or need to be created?
Does TLS certificate cover the hostname?
Where does TLS terminate?
Is HTTP-to-HTTPS redirect configured if required?
Is the IngressClass/GatewayClass correct?
Does the controller support the requested feature?
Is pathType correct?
Are paths overlapping with existing routes?
Is rewrite required and tested?
Is backend Service name correct?
Is backend Service port correct?
Does the Service have ready endpoints?
Is backend protocol correct?
Are timeouts aligned with app and client behavior?
Are request body limits appropriate?
Are forwarded headers sanitized/trusted correctly?
Are management endpoints excluded or protected?
Is auth handled at gateway, app, or both?
Is NetworkPolicy allowing ingress controller to backend?
Does route change create cloud resources or cost?
Does this change affect WAF/API gateway policy?
Are dashboards and alerts updated?
Is rollback simple and safe?
For Java/JAX-RS specifically:
Does route path align with ApplicationPath/resource paths?
Does app generate correct external URLs?
Are OpenAPI server URLs correct?
Are long-running endpoints protected by proper async/timeout design?
Are error responses distinguishable between edge and app?
31. Internal Verification Checklist
Verify in the CSG/team environment:
Which ingress controller is used?
Is Gateway API used or only Ingress?
What IngressClass/GatewayClass names are valid?
Which class is public vs internal?
Who owns DNS records?
Who owns certificates?
Is cert-manager used?
Is ACM/Key Vault/enterprise CA used?
Is NGINX Ingress used?
Is AWS Load Balancer Controller used?
Is AGIC/Application Gateway used?
Is Azure Front Door or AWS CloudFront/API Gateway in front?
Are WAF rules applied?
Are annotations restricted by policy?
What timeout defaults are configured?
What max body size defaults are configured?
How are forwarded headers sanitized?
How is source IP preserved?
Are management endpoints blocked at ingress?
Is there a standard route naming convention?
How are canary routes implemented?
Are Argo Rollouts/Flagger/service mesh used?
Which dashboards show ingress/gateway health?
Which logs are available to backend engineers?
What is the rollback procedure for a bad route?
What incident history exists around ingress, TLS, DNS, or routing?
Do not infer production edge architecture from Kubernetes examples.
Validate the real CSG platform path with platform/SRE/DevOps/security/backend teams.
32. Senior Engineer Summary
Ingress and Gateway are not just exposure mechanisms.
They are production traffic control points.
They affect:
Availability
Security
TLS
API contract
Routing correctness
Timeout behavior
Observability
Cost
Incident blast radius
The core invariant:
The intended host/path/protocol must route to the intended Service and only to healthy, compatible backend pods, with correct TLS, headers, timeout, and security behavior.
A senior backend engineer should be able to trace:
DNS
-> load balancer
-> ingress/gateway controller
-> route rule
-> Service backend
-> EndpointSlice
-> pod
-> Java/JAX-RS endpoint
and explain what can fail at each layer.
When edge routing breaks, symptoms often appear as simple HTTP status codes:
404
502
503
504
TLS error
connection timeout
But the root cause may be:
DNS
certificate
IngressClass
controller
Service
EndpointSlice
NetworkPolicy
backend protocol
app timeout
downstream dependency
Treat edge routing as a cross-layer system, not as a YAML detail.
You just completed lesson 18 in build core. Use the series map if you want to review the broader track, or continue directly into the next lesson while the context is still warm.
Keep the momentum while the lesson is still fresh. Move backward for review or continue forward into the next concept.