Ingress

How Ingress works

An Ingress resource defines routing rules. An Ingress Controller, such as NGINX, Traefik, or HAProxy, reads those rules and handles the traffic.

Ingress lets teams expose many services under one external endpoint. It also handles TLS termination and routes by hostname or URL path.

1. A user sends a request to a hostname, such as app.example.com.
2. DNS points that hostname to the Ingress Controller.
3. The controller matches the host and path to an Ingress rule.
4. The request goes to the matching Kubernetes Service.
5. The Service forwards the request to a healthy pod.

Why Ingress matters in Kubernetes

Ingress centralizes traffic management for the whole cluster. Without it, teams manage external connectivity by hand, which leads to configuration sprawl.

• Controlled access: defines exactly how users and systems reach internal services
• Load balancing: routes traffic across multiple backend pods or services
• HTTPS support: manages TLS termination and certificates
• Less complexity: one entry point instead of many LoadBalancer or NodePort services
• Automation: works with cert-manager, external-dns, and GitOps workflows

Ingress vs. other ways to expose services

Kubernetes offers several options. Ingress fits best when many HTTP services share one entry point.

Common challenges with Ingress

• Controller differences: NGINX, Traefik, and Istio can behave differently or need custom annotations
• Certificate management: handling HTTPS certificates and renewals by hand is error-prone
• Complex routing: large apps with many routes create hard-to-read configurations
• Performance tuning: poor configuration can add latency or request bottlenecks
• Security gaps: loose rules or missing TLS can expose sensitive endpoints

How Ingress relates to Testkube

Testkube can be exposed with standard Kubernetes Ingress rules. Teams reach it securely without opening ports or creating separate load balancers.

• Dashboard and API access: developers and QA engineers trigger tests and view results
• Hostname-based access: for example, testkube.company.com for internal or public users
• TLS encryption: HTTPS for all external communication
• Authentication: OAuth, SSO, or API gateways in front of Testkube
• Automation: Ingress settings managed with GitOps or IaC across clusters

Real-world examples

• Shared routing: a DevOps team uses one NGINX Ingress Controller for several internal apps, including Testkube
• Secure QA access: a QA group exposes Testkube at qa.example.com with TLS certificates from cert-manager
• Helm-managed config: a platform team sets Testkube Ingress through Helm values across clusters
• GitOps control: a cloud-native startup versions every Ingress resource in Git

Frequently Asked Questions (FAQs)