NGINX
NGINX is the most widely used ingress controller for Kubernetes, supporting advanced routing, TLS, and integration with all major clouds (AKS, EKS, GKE) and on-prem clusters. It is GitOps-friendly and production-proven.
Why Use NGINX Ingress?
Mature, large community, and well-documented
Supports advanced routing, TLS, and authentication
Works with GitOps tools (ArgoCD, Flux) for declarative, auditable deployments
Integrates with cloud load balancers (AKS, EKS, GKE)
Highly customizable via Helm or YAML
Installation (Helm)
Idempotent: installs or upgrades the controller in the
ingress-nginx
namespace.For all configurable values:
Installation (YAML Manifest)
Nearly identical resources as Helm install.
Pre-flight Check
Local Testing Example
Deploy a demo web server and expose it:
Create an ingress resource (host maps to localhost):
Port-forward to the ingress controller:
Test with curl:
Online Testing (Cloud LoadBalancer)
Get the external IP:
Set up a DNS record for your domain to point to the external IP.
Create an ingress resource for your domain:
GitOps Example (ArgoCD)
Store your ingress manifests in Git.
Define an ArgoCD Application:
Apply with:
Pros and Cons
Large community, mature
Can be complex to tune for high scale
Advanced routing, TLS, auth
Some features require custom templates
Works with all clouds
Default config may need hardening
GitOps-friendly
2025 Best Practices
Use GitOps (ArgoCD, Flux) for all NGINX config and upgrades
Store all manifests and Helm values in Git
Enable RBAC and network policies for security
Use HTTPS and automatic certificate management
Monitor with Prometheus/Grafana
Use LLMs (Copilot, Claude) to generate and review ingress configs
Common Pitfalls
Exposing services without TLS
Manual changes outside Git (causes drift)
Not monitoring for sync errors or drift
References
Last updated